[linux-dvb] problems and workaround when tuning to a channel with DD enabled

Oliver Endriss o.endriss at gmx.de
Tue Jun 7 21:04:50 CEST 2005

Johannes Stezenbach wrote:
> Oliver Endriss wrote:
> > Johannes Stezenbach wrote:
> > > IMHO it's bad to sleep uninterruptibly for longer than,
> > > say, one second. But the way OSDSetBlock() is coded
> > > one cannot interrupt it without messing up the internal
> > > state. Or, maybe one could bail out after a BlitBitmap()
> > > and return -ERESTARTSYS, so the whole ioctl will
> > > be repeated?
> > 
> > With firmware 261d you could do that because Werner added a timeout for
> > bitmap transfers. 261c and earlier would block until the ARM was
> > rebooted... :(
> > 
> > Unfortunately, DPRAM bandwidth is a bottleneck. According to my test
> > results, a short timeout will prevent the bitmap transfer to complete
> > successfully under heavy load. So aborting+repeating the ioctl would
> > not help.
> Misunderstanding: When we sleep interruptibly we can use a long
> timeout. But we need to correct the error handling so that
> the ioctl is restarted when it got interrrupted, and the
> current partial transfer (LoadBitmap/BlitBitmap pair) must
> be terminated so the firmware state is not messed up.


[Sorry, I never worked with signals in the kernel.]
If I understood this -ERESTARTSYS thing correctly, the interrupted ioctl
will be automagically restarted when the user space signal handler has

Signals can occur anytime, so the driver is broken and has to be fixed.

The easiest and most robust fix would be to abort OSDSetBlock and
restart from the beginning. Can we tell the firmware to abort the
current bitmap transfer?

We could set IRQ_STATE_EXT = TX_LEN = TX_BUFF = 0 in DATA_BMP_LOAD, if
the firmware would accept that. Any comments?


VDR Remote Plugin available at

More information about the linux-dvb mailing list