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.
>> 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.
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. 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.
Cheers,
-Jeremy Trimble
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
