Re: Customizing UIO mmap'ing

[Henry Gomersall]

On 18/12/15 14:15, Kenneth Adam Miller wrote:
>
> On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall
>  <mailto:henry.gomers...@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? 

I don't know the answer to this. I'm pretty new to it myself :)

Henry


signature.asc
Description: OpenPGP digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Customizing UIO mmap'ing

[Henry Gomersall]

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
> .
>
> Am I correct?

It's not always necessary to modify uio_dmem_genirq.

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.

Henry



signature.asc
Description: OpenPGP digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Accessing novel DMAd hardware from userspace

[Henry Gomersall]

I asked this question on IRC, but my experience has been that IRC is
variable in its reliability, so I apologise for potentially breaking
etiquette.

I've recently been working with a Xilinx Zynq FPGA/ARM combined device,
in which I wish to use DMA to transfer data from the FPGA side to the
ARM side.

Now, this is well supported at the kernel level. Xilinx have a driver
that uses with the DMA engine subsystem

In this email thread:
http://www.spinics.net/lists/dmaengin/msg04599.html there was discussion
about writing a userspace facing driver for presenting the DMAd data and
the transactions.

There wasn't much discussion, but one criticism seemed to be that there
was no place for userspace facing DMA access and that there should be a
driver that encapsulates each device that uses the relevant subsystem.

The problem is, there isn't always a subsystem that fits every weird and
wonderful new bit of hardware that someone might create, which is a
pretty huge space of things when using FPGAs.

What is the preferred way to solve this problem? It was suggested to me
that the uio subsystem is the way to go, and I'm aware of this approach,
but I don't fully understand how to use this.

Does the uio handle the DMA through the DMA engine subsystem, or do I
need to handle the DMA from userspace? If so, can I add this to the uio
driver (to gain the benefits of the DMA engine).

Is there a better way to present entirely new bits of hardware (and
specifically hardware accessed through DMA) to userspace?

Thanks,

Henry



signature.asc
Description: OpenPGP digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Accessing novel DMAd hardware from userspace

[Henry Gomersall]

I asked this question on IRC, but my experience has been that IRC is
variable in whether the right person sees the message, so I apologise 
for potentially breaking etiquette.

I've recently been working with a Xilinx Zynq FPGA/ARM combined device,
in which I wish to use DMA to transfer data from the FPGA side to the
ARM side.

Now, this is well supported at the kernel level. Xilinx have a driver
that uses with the DMA engine subsystem

In this email thread:
http://www.spinics.net/lists/dmaengin/msg04599.html there was discussion
about writing a userspace facing driver for presenting the DMAd data and
the transactions.

There wasn't much discussion, but one criticism seemed to be that there
was no place for userspace facing DMA access and that there should be a
driver that encapsulates each device that uses the relevant subsystem.

The problem is, there isn't always a subsystem that fits every weird and
wonderful new bit of hardware that someone might create, which is a
pretty huge space of things when using FPGAs.

What is the preferred way to solve this problem? It was suggested to me
that the uio subsystem is the way to go, and I'm aware of this approach,
but I don't fully understand how to use this.

Does the uio handle the DMA through the DMA engine subsystem, or do I
need to handle the DMA from userspace? If so, can I add this to the uio
driver (to gain the benefits of the DMA engine).

Is there a better way to present entirely new bits of hardware (and
specifically hardware accessed through DMA) to userspace?

Thanks,

Henry




signature.asc
Description: OpenPGP digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies