Messages in this thread | | | Date | Fri, 4 Jul 2008 15:32:21 +0200 | From | "Hans J. Koch" <> | Subject | Re: [PATCH] uio: User IRQ Mode |
| |
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
| |