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@xxxxxxxxxxxxx> 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@xxxxxxxx>

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] uio: User IRQ Mode
    ... 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. ...
    (Linux-Kernel)
  • Re: [PATCH] uio: User IRQ Mode
    ... 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. ...
    (Linux-Kernel)
  • Re: [PATCH] uio: User IRQ Mode V2
    ... In User IRQ Mode the kernel space interrupt handler simply disables ... part of the driver must reenable the interrupt using write. ...
    (Linux-Kernel)
  • Re: [PATCH] uio: User IRQ Mode
    ... This patch adds a "User IRQ Mode" to UIO. ... is responsible for acknowledging and re-enabling the interrupt. ... This can easily be done without your patch. ...
    (Linux-Kernel)
  • [PATCH] uio: User IRQ Mode V2
    ... This is V2 of the UIO "User IRQ Mode" patch. ... In User IRQ Mode the kernel space interrupt handler simply disables ...
    (Linux-Kernel)