Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver

On Tue, May 20, 2008 at 07:51:32PM +0900, Magnus Damm wrote:

Hi Magnus,

These patches implement a reusable UIO platform driver.

Uwe Kleine-Koenig already submitted such a framework:

http://lkml.org/lkml/2008/5/20/94

It's his third version, and it looks good. I presume you didn't know
about his work. The main difference is that he leaves interrupt handling
to platform code. That might look strange (it did to me first), but it
has the advantage that you can put hardware dependent stuff in your
board support (which depends on hardware anyway).

Could you have a look at his patch and tell me if that does what you
need?

This driver
can be used to export hardware to user space, as long as the device
is a) memory mapped and b) equipped with an unique IRQ.

The uio_platform driver gets all information through platform data,
including address window information and IRQ number. The driver also
supports assigning a contiguous piece of memory to each instance.
This may be useful when the exported hardware blocks can bus master
but requires physically contiguous memory.

There are not many surprises in the code if you are familiar with UIO,
except for the interrupt handling. All UIO kernel drivers that I've
seen so far have hardware specific interrupt acknowledge code in the
interrupt handler. The uio_platform driver is different.

The interrupt handling code in uio_platform assumes the device is the
only user of the assigned interrupt.

Uwe's approach doesn't have this limitation.

This may be rare in the PC world
but for SuperH almost all interrupt sources are unique. Having an
unique interrupt for the device allows the code to use disable_irq()
and enable_irq() in kernel space and leave actual interrupt acknowledge
to user space. That way we have no hardware specific code in the kernel.

Interrupts are of course serviced in kernel space by the uio_platform
driver, but the uio_platform interrupt handler will simply disable the
IRQ until next read() or poll() syscall. The uio_platform kernel driver
assumes that the user space driver has taken care of acknowledging
the interrupt before doing read() and waiting for events again. If no
acknowledge has happened then an interrupt will occur again (since it's
still pending) and the kernel interrupt handler will disable the IRQ
again and unblock the user space process.

The last patch contains SuperH specific code that exports various
multimedia acceleration blocks to userspace. The following processors
and hardware blocks are exported for now:

sh7343: VPU
sh7722: VPU, VEU
sh7723: VPU, VEU, VEU

If anyone is interested then I have a proof of concept vidix driver
for mplayer that is interfacing using UIO to the VEU on a sh7722 to
provide accelerated color space conversion and stretching.

This sounds quite interesting. Unfortunately, I'm not familiar with the
SuperH architecture. Could you also do this with Uwe's approach?

I'm about to sign-off Uwe's patch, and we'll possibly have that in
mainline soon. I don't mind having a second "generic platform" driver,
but you'll need to have good technical arguments.

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
    ... In this mode the user space driver ... is responsible for acknowledging and re-enabling the interrupt. ... This can easily be done without your patch. ...
    (Linux-Kernel)
  • Re: Polling for ath driver
    ... but we've found polling to be extremely valuable on low-end hardware as described here. ... We use it only on fxp drivers, but it moved throughput on 133Mhz hardware from something around 8Mbps to 20Mbps on regular layer-3 packet forwarding and also bumped VPN performance up significantly when used with hardware VPN accelerators. ... Unless you've significantly restructured the interrupt handling in the ... Adding polling to this driver does increase performance on embedded ...
    (freebsd-net)
  • Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
    ... If the system fails in ACPI mode, but works in non-ACPI mode, ... Using ACPI for SMP configuration information ... Using IOAPIC for interrupt routing ... Non-volatile memory driver v1.2 ...
    (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)