On Sun, Apr 18, 2010 at 05:22:30PM +0000, Frédéric Brière wrote:
quoted text
> Greg KH <greg@kroah.com> wrote:
> > > Our main concern is that this driver would be rejected by the kernel
> > > maintainers, due to the fact that it busy-waits with interrupts
> > > disabled, for up to 32ms (in the very worst and unlikely case).
> >
> > Why does it do this?
> 
> For precise timing purposes when polling the parallel port.  (Forgive
> the alliteration.)
> 
> For example, a talking device will pull CLK down for 20us and release
> it, after which DATA must be read within 70us.  Or, when sending a byte,
> after the listener has released DATA, transmission must start within
> 200us.  (Notice how we don't always monitor the same line.)
> 
> In such cases, if an interrupt were to be triggered and take too much
> time, the whole communication would be garbled.

Is this on a shared interrupt?  And what type of processor are you
expected to handle these types of requirements?

quoted text
> (There is one case, when a listener is signaling that it is ready, which
> has no upper bound and does not require prompt action.  That's when we
> use the parport IRQ.)
> 
> 
> BTW, I should point out that the 32ms above is the absolute worst case,
> and would require a device to maliciously skirt on the maximum timing
> allowances of this module.  I'm guessing 1-2ms is the likely case.)
> 
> 
> > > rs_put_char() in drivers/serial/68328serial.c.)  Unfortunately, this is
> > > the only way to achieve the precise timing required.
> >
> > Are you sure?
> 
> You tell me, you're the kernel demi-God.  :)
> 
> Basically, this module needs a guaranteed sub-20us resolution when
> polling the parallel port for inbound data.  (The PC parport
> unfortunately only has one line capable of triggering an IRQ, which is
> already used for the case above.)  And it may need an even greater
> resolution when sending data, as other devices may not be so forgiving
> of timing errors.

This seems like a very large abuse of the 'I know, let's bit-bang the
data out by hand' principle.  For such strict timing requirements, it's
almost always better to just build a simple piece of hardware to handle
it for you.

Is this a new device out in the wild, or something very old?

And post the code for inclusion, we can take it from there.

thanks,

greg k-h
_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors