Customizing UIO mmap'ing
Kenneth Adam Miller
kennethadammiller at gmail.com
Fri Dec 18 09:15:04 EST 2015
On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall <
henry.gomersall at smartacoustics.co.uk> wrote:
> On 17/12/15 21:35, Kenneth Adam Miller wrote:
>
> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
> common module basis for isolating code common to the other specific
> modules. But for a specific purpose, uio_dmem_genirq.c has be either
> customized or extended in order that specific memory regions can be set as
> accessible. Most easily, this is done in a first come first serve approach
> by filling out the details (which exactly?) left missing in
> uio_dmem_genirq.c, and to start, that would be in uio_of_genirq_match
> <https://proxy-us.hide.me/go.php?u=zWvu%2Fc4k0RUgdQesK%2F26T4EuwcXktyOuOa%2F3x1F0nLo5r0d9WlQEzfN928BYniutwGWnnJXkaBWcsA6D&b=29>
> .
>
> Am I correct?
>
>
> It's not always necessary to modify uio_dmem_genirq.
>
>
Is it correct though, that I can use another module to stack on top of
uio_dmem_genirq, and that the correct thing to modify is in fact the
variable I mentioned?
> Certainly in cases where the hardware capability can be specified by a
> device tree (e.g. ARM systems), it is possible to specify an address space
> and an IRQ that can be immediately used from userspace with the
> uio_dmem_genirq driver with no modifications.
>
>
This is not our case. I have to programmatically retrieve the regions when
the driver is loaded (I know that's just a matter of putting the right code
in the right callback), and allow that to serve as a match.
> Henry
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/947e24a7/attachment.html
More information about the Kernelnewbies
mailing list