On Thu, May 28, 2015 at 06:11:52PM -0400, Jeremy Trimble wrote:
> Maxime,
>
> Thanks for the comments. I'm glad someone else might find it useful.
>
> > Even though I understand that this is the most convenient setup right
> > now, I would expect to have this a bit more dynamic, and be able to
> > request/release channels straight from the user-space (to have several
> > memset happening at the same time for example).
> >
> > That would probably require a different interface though, or at least
> > to implement some ioctls.
>
> I agree, the devicetree-based configuration is only good for some use
> cases. I'm not opposed to adding other ways to configure. One
> thought I had would be to allow additional ezdma devices to be
> added/removed dynamically at runtime using a sysfs interface (think
> netconsole). I guess this would also allow ezdma to be used on
> systems that don't typically use the devicetree as well.
>
> Note that there's no restriction on the number of ezdma devices (e.g.
> files in /dev/) that can be created concurrently. Basically you can
> have a separate entry in /dev for every channel you're interested in.
> In the example above, there happened to be 1 RX and 1 TX, but you
> could have any number in any direction.
I would have expected not to register any device at all, just like
i2c-dev does for example.
You could imagine having only one "control" device per controller to
request channels for userspace use, that would expose a new device for
that channel.
You could then read/write to that file, and that's it.
That way, you wouldn't need to register any new device, to care about
the DT case or not, and you could request as much channel as you'd
like from userspace.
That's especially true since that DT binding might be controversial
(see the number of debates on spidev that uses pretty much the same
constructs).
> >> 3. Sending data is as easy as:
> >>
> >> int tx_fd = open("/dev/loop_tx", O_WRONLY);
> >> int rx_fd = open("/dev/loop_rx", O_RDONLY);
> >>
> >> write(tx_fd, tx_buf, xfer_size); // send a DMA transaction
> >> read (rx_fd, rx_buf, xfer_size);
> >>
> >> Currently, each read()/write() call causes a single transfer to occur in the
> >> underlying slave DMA channel, but support could be added for readv()/writev()
> >> as well.
> >
> > How do you set the address it should be sent to? the width? burst? Is
> > it currently hardcoded (which is totally fine for your use case, but
> > wouldn't really work for other use).
>
> In my case, for sending data via write(), there was no destination
> address (as the content of the write() call would be turned into an
> AXI Stream packet by the AXI DMA core). For receiving data, the
> destination address is obviously the pointer passed to the read()
> call.
The source for the writes, and the destination for the reads are
obvious, but the others are not, and will completely depend on the
transfer you want to do, to which device, and what operation is being
run.
That might not be the case for your device, but you have to consider
the broader use case.
> Your question about the width/burst is a good point -- in my case I
> was just careful to only specify transfer lengths (to the count
> argument of read()/write()) that I knew to be compatible with the AXI
> DMA core, but this could pretty easily be enforced by adding extra
> parameters to the devicetree/sysfs configuration entries.
The width and burst will also depend on the kind of transfer you want
to do, and to which device you want to do.
All the dmaengine drivers should reject invalid (to the controller)
values in their prep_dma* functions, but that won't mean that it will
be valid to the target device.
> Currently each read()/write() results in a single scatter-gather
> transfer (1 descriptor per page).
>
> I'm currently traveling but I've cleaned up the code to compile
> against linux-next and pass checkpatch.pl with no issues. I plan to
> retest and send in a first version of the patch next week.
Cool, I'm looking forward to it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
