Re: [PATCH] uio: User IRQ Mode

["Hans J. Koch" <hjk@linutronix.de>]

On Fri, Jul 04, 2008 at 08:01:08AM +0200, Uwe Kleine-K?nig wrote:
> Magnus Damm wrote:
> > On Thu, Jul 3, 2008 at 9:45 PM, Hans J. Koch <hjk@linutronix.de> wrote:
> > > On Thu, Jul 03, 2008 at 09:10:19AM +0200, Uwe Kleine-K?nig wrote:
> > >> Hans J. Koch wrote:
> > >> > On Wed, Jul 02, 2008 at 07:59:51PM +0900, Magnus Damm wrote:
> > >> > > From: Uwe Kleine-K?nig <Uwe.Kleine-Koenig@digi.com>
> > >> > >
> > >> > > This patch adds a "User IRQ Mode" to UIO. In this mode the user space driver
> > >> > > is responsible for acknowledging and re-enabling the interrupt.
> > >> >
> > >> > This can easily be done without your patch.
> > >
> > > BTW, the above wording "the user space driver is responsible for
> > > acknowledging and re-enabling the interrupt" is misleading. The kernel
> > > always has to acknowledge/disable/mask the interrupt. Userspace can only
> > > reenable it, ideally by writing to a chip register. In some cornercases
> > > for broken hardware we need the newly introduced write function.
> > 
> > You seem to be mixing up masking/acknowledging the interrupt
> > controller and masking/acknowledging the actual hardware device. In
> > User IRQ Mode, the only thing the user space driver is accessing is
> > the hardware device, with the exception of write() to re-enable
> > interrupts which results in a enable_irq() that touches the interrupt
> > controller.
> But to be honest Hans is right here, the commit log wording is not
> optimal.  I suggest:
> 
> 	This patch adds a "User IRQ Mode" to UIO. In this mode the
> 	kernel space simply disables the serviced interrupt in the
> 	interrupt controller and the user space driver is responsible
> 	for acknowledging it in the device and reenabling it.
> 
> 	Note that this implies that the interrupt might be disabled for
> 	long periods, so this isn't usable for shared interrupt lines.
> 
> Maybe it's sensible to add the User IRQ Mode functions at least for now
> into platform code.  Then at a later time if and when there are several
> copies the discussion to move it to the generic part might be easier.

Thanks for this suggestion. I agree. Maybe we find a different solution
until then.

> 
> BTW, I currently have a situation where it IMHO really makes sense to
> use the User IRQ Mode:  We sell a cpu module to a customer with
> Linux.  I provide a uio device for some memory mapped periphal on the
> customers board that I don't know in detail.  With the User IRQ Mode I
> only need to know the chip select and the irq line, no further
> information is needed for the device.

The only additional information you need now is which bit in which
register you have to set/clear to mask the irq. I also have customer
chips here where this one information is all I know about the chip.

Thanks,
Hans