<bbrezillon>
RSpliet: yep, or at least not such a simple replacement ;-), but still, this is interesting to have some results with when using the DMA engine
<bbrezillon>
RSpliet: well, supporting DMA was on my TODO list, but I'm glag you had a look at it :-)
<bbrezillon>
RSpliet: okay, so you're just replacing the copies into SRAM by dma transfers, right ?
<RSpliet>
bbrezillon: if I put on a blindfold and replace *all* vXalloc with kXalloc in ubi and ubifs... I get 10% speedup with a naive DMA
<RSpliet>
hrmphrrrmm.... UBI is not quite suitable for DMA-enabled devices
<RSpliet>
mripard: there's no allwinner 3.4 or android tree with code for this DMA engine?
<RSpliet>
mripard: has Emilio (or you) documented findings related to the DMA engine?
2015-06-10
<RSpliet>
bbrezillon: no feedback on patch 2? ;-) I'll fix #1 later today... playing around with DMA right now
2015-06-09
<RSpliet>
Is Emilio Lopez' DMA driver still in the pipeline for inclusion in mainline?
<paulk-collins>
is mainline good for that or should I instead use 3.4 due to DMA-related concerns?
2015-06-03
<mripard>
you should use regmap and dma
<sunxi_fan1>
but the underlying machinery for accessing registers (now regmap_update_bits() and similar but older are using different API AFAICS) and DMA (only some are using dmaengine AFAICS) is different.. right?
<sunxi_fan1>
so to make a long story short, i had a look at the many different designs present in sound/soc directory to understand they are all in "different stages" then the actual status of a properly designed and recent alsa ASOC driver.. at least this is my feeling. of course all of them do have support for the basic stuff: registers, DMA and INT, but some with different API still available in the mainline kernel.
<sunxi_fan1>
i indeed started working with other different approaches, from a ti omap source with dmaengine support and an external codec, and again from the PXA magician with UDA1380 but no DMA engine, but at the end i found there were distracting me a lot, as they were a bit different then sunxi SOC.
<sunxi_fan1>
then i changed all the init of the DAI from the "audio codec" to the I2S DAI registers. it's not that bad as a process. now i have compiling source code and suppose to start doing debugging with register printouts on real HW, but first i decide to test for real how it's working the "sunxi-codec", and it was useful already as i understood there are already binding to DTS that i need to enable in my code too. and there's the DMA en
<sunxi_fan1>
dma-names = "rx", "tx";
<sunxi_fan1>
dmas = <&dma 0 19>, <&dma 0 19>;
2015-05-26
<RSpliet>
the u-boot tree I linked you explicitly enables DMA in the CCU, I assume it doesn't, but it might help
<mripard>
UIO can help for the interrupts, but you'll still have the clocks and DMA issues
<mripard>
you have no way to set the clock rates from userspace, trigger DMA transfers, get an interrupt, etc. using /dev/mem
<RSpliet>
I changed some bits in the various clock definitions, and made the nand_init explicitly enable DMA too (plus using the right defines there)
<hansg>
sunxi_fan, i2c is a different functional block then the build in dac, so it would mostly be a new driver, but the dma engine code also in sunxi-wip certainly helps a lot and you can use the internal dac driver to see how to best port the i2s driver from sunxi-3.4 to mainline
<wens>
mripard: so you're picking up the dma and audio stuff?
2015-04-10
<MrBar>
of dma
<mripard_>
there's no way to reliably extract data from the PIO using DMA
<mripard_>
nor does it have any kind of FIFO that would buffer the data waiting for the DMA controller to fetch them
<mripard_>
MrBar: except that the PIO has no way to report to the DMA controller that it has something to transfer
<mripard_>
you can't drive the GPIOs with DMA.
<MrBar>
mripard_, i just found great project http://abyz.co.uk/rpi/pigpio/ they just handle pio with dma and i plan to port it on sunxi partially
<MrBar>
i just not know abount internal dma engines
<MrBar>
all stufs have internal dma controllers
<mripard_>
MMC has its own DMA controller
<mripard_>
but has its own DMA controller
<MrBar>
where f**ked dma?
<mripard_>
GMAC has its own DMA controller
<mripard_>
SPI and EMAC and the two main users of DDMA, and their drivers do support DMA
<MrBar>
so good news i can use all dma engines for my task
<MrBar>
mripard_, no, dma NOT used in 3.4
<mripard_>
what do you need DMA for?
<MrBar>
box without dma just trash
<MrBar>
why in sunxi-linux kernel dma ot used? not NDMA not DDMA ?
2015-03-31
<Skylark>
not sure what happens, though, if you ask the DMA to dma only 512 bytes from the internal NFC buffer
2015-03-23
<plaes>
diffstat is impressive for sun6i-dma
<wens>
sun4i dma doesn't use LLIs?
<wens>
also new unmerged stuff, scheduled dma
2015-03-20
<Turl>
paulk-collins: emac iirc can use DMA via the DMA slave, but it doesn't on mainline
<Turl>
paulk-collins: I think GMAC does DMA itself
<paulk-collins>
Turl, IIRC DMA support in mainline is incomplete, correct?
<paulk-collins>
is the ethernet controller doing DMA on mainline?
2015-03-17
<mripard_>
we were forcing it because otherwise the DMA controller doesn't work for some reason
<mripard_>
except we were doing at the time the DMA controller driver was probed
<wens>
we can also do the reparenting in the clock provider, instead of when the dma is probed
<hansg>
Ok, so lets assume that we can fix things in the dts to reparent ahb on sun5i / sun7i to ahb, what about sun6i, there we still have the problem of the ahb clk being changed by the dma driver, right ?
2015-03-11
<mripard_>
Turl: btw, any plan on submitting your DMA driver?
2015-03-05
<Turl>
oliv3r: when it's ready, dunno :p I hope DMA will be merged during the next merge window
2015-03-03
<Vanfanel>
thought it was done in hardware somehow, using a DMA or whatever
<wens>
Turl: dma driver!
2015-02-28
<pirea>
ssvb linux 3.19 have dma support?
2015-02-27
<plaes>
Turl: did you figure out which api fixes had to be done with DMA?
2015-02-12
<oliv3r>
Turl: the other SPI ports don't do DMA?
<Turl>
oliv3r: as an alternative to it, you can use dma on spi O:)
2015-02-11
<nuuhku>
Nice work on dma and the sunxi-codec. Hope your work gets mainlined soon.
<nuuhku>
Turl: Yes, apart from the one that disables uart dma (commit be35c0e). Seems like it was already applied or reverted. Also the duplicated stream widgets hack patch did not apply.
<nuuhku>
But now I have the perfect reason for getting the codec working on latest mainline. Oh yes... dma will be used today. 8)
<nuuhku>
Turl, err... probably nothing. :) I just assumed even usb audio needed the new dma stuff.
<Turl>
nuuhku: the codec patches should be mostly ok, I'll see about pushing a rebased codec branch together with dma v5
<Turl>
nuuhku: what are you using dma for? :)
<nuuhku>
Finally got kernel 3.19 working with a Cubieboard 2 and an usb sound card. Emilio's v4 dma patch works great... this is so cool!
<mripard_>
so it's probably something else than DMA that is wrong
<mripard_>
yeah, so it looks like the CSI is doing its dma accesses, but the data it sends are bad
<fest>
mripard_: it seems that I haven't configured the sensor correctly- if I write to the dma address before sensor __should__ be doing that, that memory is overwritten by zeroes
<Steven__>
To exchange data through bus or DMA channel, is it possbile?
<mripard_>
fest: so it's probably using peripheral DMA hten
<fest>
I also don't see any special dma api calls in existing drivers
<fest>
yeah, already do pass dma_addr to CSI
<mripard_>
either you'll have to use the Allwinner DMA API
<mripard_>
fest: I'd say it depends on wether you're doing peripheral DMA or using an external DMA controller
<fest>
I'm still trying to read camera sensor data from CSI interface, and I don't understand memory addressation in linux kernel. I am passing dma_addr_t which I got from dma_alloc_coherent to CSI, and then trying to read something at vaddr (return value from dma_alloc_coherent_call). Is there something else I should do with regards to DMA (e.g. set up source and target addresses etc), or is the problem with
2015-02-10
<mripard_>
if I remember correctly, you just have to enable it in the configuration, maybe change the amount reserved of reserved memory in the configuration too, and then you can just use dma_alloc_coherent
<mripard_>
and iirc dma_alloc_coherent has the same limit
<fest>
I'm writing a driver for ov5640 camera sensor (existing one doesn't work for large resolutions and is buggy). I need a large chunk of contiguous RAM (up to 16MiB) but both kmalloc and dma_alloc_coherent fail on buffers that large, even right after boot, with plenty of RAM (no idea if it's contiguous though)
2015-02-09
<mripard_>
the DMA driver would be in, we wouldn't have that discussion ;)
<wens>
i don't see sun4i-dma in slave-dma
<oliv3r>
Turl: but amazing, dma for 3.20, audio for 3.21?
<Turl>
oliv3r: DMA's looking good for 3.20
2015-01-31
<wens>
Turl: yay! dma!
2015-01-28
<plaes>
Turl: do you have time to rehash the DMA patchset?
2015-01-19
<plaes>
do you have any plans to reroll the DMA stuff?
2015-01-12
<silentcreek>
Hi! Is anybody familiar with the differences of the sunxi-3.4 kernel and recent mainline kernels with regards to DMA and performance? The wiki says the DMA driver for mainline is still being worked on. Is there a working DMA driver in the sunxi-3.4 kernel?
2015-01-08
<oliv3r>
Turl_: so DMA & Audio then?
<Turl_>
when I get back (~1w) I'll do one last round of dma testing and send a new set for that
2014-12-22
<maz>
quitte: you can use an IOMMU to limit the memory your device is going to DMA to/from.
<Turl>
quitte: master is when the device does the DMA
<quitte>
Turl: does the above imply that there is mainline support for DMA already? for example for sata or gmac ?
<quitte>
hmm. "DMAengine driver handles slave DMA clients..." what is master DMA and is it already supported on A20?
2014-12-18
<LinAdmin>
@adj_: thanks for your hints, I will try with a SDD, benchmark DMA and RAM and see for IRQ conflicts. bye
<LinAdmin>
my best guess: either the setup of dma engine is faulty or it is a problem in A20 chip itself
<LinAdmin>
Imho the same DMA engine is active in both directions?
<LinAdmin>
@Atlantic777: When DMA transfer between disk and RAM occurs, then there are only very few other interrupts. Do you think those could interfere?
<LinAdmin>
@libv: that is clear, but imho some expert in the chat might know that very technical problem of SATA-DMA????
<LinAdmin>
Imho reading and writing speeds from/to a fast enough 3.5" disk are limited by DMA transfer speed?
2014-12-11
<wens>
i'd think that dma stuff shouldn't suffer
2014-11-06
<wens>
OK, so this patch fixes the broken DMA.
<mripard>
wens: I don't care about the ahb1 unifying patches at this point. I care about the broken DMA.
<wens>
mripard: the 'original' ahb1 unifying patches which the dma driver patch was a part of is 7 patches total
<mripard>
wens: still talking about your clock patches. Where are the other patches for the DMA?
2014-10-27
<astr>
dma?
<arokux2>
dma*
2014-10-26
<arokux2>
Turl: are u still working on dma, btw?
2014-10-22
<rafaelMOD>
libv: the dma seems more decent then A20's, it seems to have dmaengine
<rafaelMOD>
Turl: i saw your codec driver for mainline, how did you solved this dma issue there? playback and capture doesnt work simultaneously?
<rafaelMOD>
i know alsa takes care pf dma pointers, but from my initial studies it need dmaengine and some dma_slave configurations that A20 sunxi-34 doesnt have! DOH!
<rafaelMOD>
Turl: what do you think of using DMA_CONTI_MODE_EN with NDMA_DEST_ADDR_TYPE = increment and NDMA_SRC_ADDR_TYPE = No Change for a I2S RX transfer? maybe it just reconfigure the pointers on the destinaton?!
<rafaelMOD>
i want to work on alsa with 64 samples transfers, so it would be great to have the same size on dma transfers
<rafaelMOD>
and a dma based on callbacks and only using bursts of 8 maximum is crap
<rafaelMOD>
the problem i see here is that for every DMA buffer transmition there is a callback call to a bufdone function, and that in sequency calls an enqueue function that reconfigure the dma_end and dma_start pointers
<rafaelMOD>
Turl: doesn't it rearrange the buffer pointers based on NDMA_DEST_DATA_WIDTH and DMA_DEST_BST_LEN?
<rafaelMOD>
and how to configure them on the invented A20 dma API
<rafaelMOD>
I was wondering how does the DMA_CONTI_MODE_EN (NDMA_CTRL_REG) works
<rafaelMOD>
Jhon Smirl told me that the normal dma on the mainline driver still does only one transfer, i need two, one for I2S_TX and one for I2S_RX, actually this is keeping me (plus the lack o time) from migrating to mainline
<Turl>
rafaelMOD: it doesn't support dma lists
<rafaelMOD>
have you ever used this bconti_mode on dma_config_t on A20?
<rafaelMOD>
so i am putting my cards on dma_config_t->bconti_mode, but i dont know how to configure for that and i haven't tested neither coded that
<rafaelMOD>
but i grepped every file of dma on A20 sunxi-3.4 and got nothing for slave configuration
<rafaelMOD>
as there are calls for slave dma functions
<rafaelMOD>
it really seems invented! inthe A23 latest sunxi3.4 kernel released on allwinner github, it seems that the new DMA does use dmaengine
<rafaelMOD>
but i know you cant use slave dma standard config
<rafaelMOD>
mripard told me he think A20 dma on sunxi doesnt have dmaengine, i am still not sure
<Turl>
rafaelMOD: but the dma block is pretty dumb and it doesn't even support lists
<rafaelMOD>
Turl: about sunxi-3.4 for A20, do you know if there is a way to work with dma buffers without the callback, enqeue functions? do you know if dma_config_t->bconti_mode = true does that trick?
<rafaelMOD>
I made major changes on i2s and i2s dma on sunxi-3.4
2014-10-21
<rafaelMOD>
Anyone know if dma_config_t->bconti_mode = true does the trick? i hate to have a callback on my DMA, sound gets underuns and i think its probably that
<rafaelMOD>
i suspect dma_config_t->bconti_mode = true should do that
<mripard>
I don't know Allwinner's DMA API, sorry :(
<rafaelMOD>
how do I avoid, on A20 sunxi-3.4, the need to use dma calback, then enqueue?
<mripard>
rafaelMOD: afaik, the A20 DMA driver doesn't use dmaengine
<rafaelMOD>
I think sunxi-3.4 dma driver don't support that, as there is no attribution to dma_device->device_control, am I right????
<rafaelMOD>
Hi guys, i am working on the I2S of A20 sunxi3.4 and i would love to have all pointers and enqueues controled by alsa, but for that i need to configure dma with dmaengine_slave_config. How do i get dma_slave_config->slave_id on sunxi3.4 for A20? It doesn't seem to have the #define sunxi_slave_id(d, s) define, grep cant find it
2014-10-20
<mripard>
the only thing is that it was not using DMA
2014-10-18
<ssvb>
lima-memtester is stressing competing accesses to dram from multiple ports, the dma use case may be also somewhat covered by this
<hramrach_>
btw the apt workload may use dma which is not tested by lima-memtester
2014-10-17
<patap>
dma isn't accepted to mainline yet, so no hurry
<Montjoie>
I will work on dma when the basic driver will be accepted
<Montjoie>
no dma
<patap>
Montjoie: is your driver using dma?
2014-10-15
<hramrach_>
arokux: a core is sold and the SoC manufacturer butchers the driver to integrate it with other parts of the SoC like interrupt controller, DMA controller, particular register mapping, pinmux, etc. Then the board vendor butchers it further to integrate id the baord design with particular power/reset pins. And that's what you receive if anything at all
2014-10-11
<wens>
slapin: DMA is WiP (by Turl)
2014-10-10
<slapin>
ssvb: was DMA implemented?
<bbrezillon>
slapin: almost, the only missing things are DMA (not sure this is essential), read retry on specific nand chips (I added support for the hynix one), and boot0 layout (though this could all be handled in userspace)
2014-10-01
<mripard>
the dma errors when pll6 is not the parent clock
2014-09-26
<wens>
it's using the system dma controller
<oliv3r>
ah i thought it did; i saw the BROM uses DMA with the SPI driver
<mripard>
oliv3r: no, it doesn't have its own DMA controller
<oliv3r>
mripard: the SPI has its own DMA doesn't it? It doesn't rely on turl's DMA work does it?
<wens>
mripard: so the dma mapping doesn't like tx_buf = NULL
<mripard>
it's forced to use DMA in every case here
<mripard>
you'll need my spi-dma branch
<wens>
ah, so i just turn on dma debugging and wait for the output
<mripard>
what was failing was whenever you were starting a DMA transfer, you wouldn't get any interrupt from the DMA controller
<wens>
nothing atm, was testing it for dma on sun6i/sun8i, then realized it wasn't needed
2014-09-24
<gzamboni>
i saw you did progressed with all the dma code, awesome, it was too hard for me, i saw also that Turl got into the A10/A20 dma also, but i think it still not merged
2014-09-22
<oliv3r>
Turl finished all the DMA stuff allready
<wens>
mripard: what do we have waiting for acks/merging atm? clocks, dma, watchdog?
2014-09-21
<wens>
just about to test sun6i dma without ahb1 muxing
2014-09-20
<Nazcafan>
there was this SOC intern who produced an impressive work for DMA, is this going to be mainlined or are some parts missing?
<wens>
Turl: any chance we can get sun4i dma in by the next merge window?
2014-09-05
<mawe242>
traeak: in case you're still playing around with realtime kernel and audio: make sure you increase the prio of the dma irq thread. that turns the a20 into a powerhorse! just tried it, works great!
<wens>
mripard_: sun8i dma doesn't require ahb1 to be clocked from pll6
<wens>
i have a bunch of intermingled patches for a31 ahb1, sun6i-dma followup fixes for ahb1, and sun8i dma
2014-09-04
<wens>
argh, sun8i dma still not working
2014-09-02
<mripard_>
and don't worry about the A31 dma driver
<wens>
if i add a clk div for it, i risk breaking the sun6i dma driver, as pll6 is no longer a direct parent of ahb1
2014-08-29
<wens>
mripard_: the allwinner dma driver looks a lot like yours :p
2014-08-27
<wens>
mripard_: i see some suspicious code in sun6i dma interrupt handler, will test a bit with debug on
<libv>
MY123: why do you think it took so long to get dma-buf and dma-buf-fences?
<MY123>
libv: It has only a high-latency DMA 2D engine
<Turl>
no review from the dma people so far :/
<wens>
ported sun6i-dma to sun8i, and it crashes :(
<wens>
Turl: how's dma going?
2014-08-26
<wens>
steev: clk, dma, pinctrl, those i know of
<wens>
i should finish my sun8i-dma stuff before diving in
2014-08-24
<quitte_>
I'm not even sure if the dma headers are free. those should be taken from the dma mainlining thing for that reason alone
2014-08-20
<oliv3r>
someone added duplex SPI support and added it to dma_defs, but it can't work, yet it's there
<oliv3r>
dma_defs.h is not included anywhere, but patches have been written against dma_defs.h
<oliv3r>
in dma_defs.h are all the definitions, but they are repeated in mach/dma.h
<oliv3r>
code wise its' easy, but the dma stuff between sun7i and 'sunxi' is different, hans did write a dma_compat.h to address some issues
2014-08-19
<oliv3r>
this is how it is defined for sun7i arch/arm/mach-sun7i/include/mach/dma.h:34:}dma_para_t;
<oliv3r>
in the mac drivers there's the cmbk for dma config
<oliv3r>
so need to port it to hans's dma_compat
<oliv3r_>
i see hans has worked on dma_compat.h for sunxi
<oliv3r_>
the spi logic is identical, but dma, and probably dma in general is just horrible between sunxi and sun7i
<oliv3r_>
oh. wow., sun7i spi driver is a mess with regards to dma
2014-08-17
<Turl>
i used to have the failed dma bug
<quitte>
(dma for ethernet,sata,mmc and nand)
2014-08-16
<oliv3r_>
mawe242: working on some dma stuff
<mawe242>
oliv3r_: i thought I had it done, but on building the modules got 4 errors regarding dma ("sw_dma_free" [drivers/spi/spi_sunxi.ko] undefined! ... )
<Turl>
wens: I was looking at those omap 8250 patches with dma, they looked interesting
<wens>
Turl: someone posted fixes for 8250 dma
2014-08-15
<Turl>
oliv3r_: sun7i uses a diff dma driver
<oliv3r_>
Turl: i'm sure you looked at sunxi 3.4 dma stuff, it looks like dma is not used for sun7i? or atleast, sun7i does it 'differently'
<oliv3r_>
hmm, the dma stuff is a big pain :(
<oliv3r_>
strange why sun7i is not mentioned in dma_ref.h
<oliv3r_>
just need to figure out why it's not compiling, but i'm guessing that's because some dma stuff is missing or some path has changed
2014-08-14
<Turl>
rafaelMOD: DMA is being reviewed, and Jon is working on I2S, he got it more or less working the other day
<rafaelMOD>
How is the dma and i2s drivers in the mainline for sun7i? Any WIP?
2014-08-11
<bbrezillon>
quitte: then we can consider optimizing this driver (by using DMA). BTW I tried to use the same OOB layout as the one used when doing DMA accesses in my v4 (still have to test that it really is the same) ;-)
<quitte>
i totally agree. mainlining trumps dma any day.
<quitte>
bbrezillon: on a uC i'd definately want to use dma for that. since there's caches and memory is slower than the cpu i'd still assume dma is worth it as long as channels aren't running low. However I haven't made any experiences with dma on something in the ghz range
<quitte>
the dma controller sits on the same memory bus as the cpu, doesn't it?
<bbrezillon>
quitte: but DMA transfers are often slower than CPU to peripheral transfers, and I expect better performances (in terms of read/write access times) without any DMA usage (but I can tell if it's actually the case because I've never done any perf tests) ;-)
<bbrezillon>
quitte: yes, in terms of cpu usage, DMA will definitely help
<quitte>
it frees the cpu for other tasks. i have only seen what dma does on microcontrollers first hand.
<bbrezillon>
quitte: what makes you think DMA will speed things up ?
<quitte>
yuq's employs dma. if it doesn't do unnecessary blocking it should perform a lot better. however that probably makes mainlining a lot harder
2014-08-07
<quitte>
does dma work in 3.4? if yes - what does it work with?
<Turl>
wens: "Note: If ByteCounter=0, DMA will transfer no byte. The maximum value is 128k."
<wens>
Turl: i could test a13 for you, but how do i test dma, without any spi pins (or a logic analyzer)
2014-08-01
<wens>
typo in sun6i dma commit by vinod: 92e4a3b dmaengine: sun6i: Remove
<wens>
&dma is also a label
<Turl>
I was going to send another set of dma driver patches (which, gasp! use <&dma endpoint>) but I think I'm going to sleep earlier
2014-07-30
<mripard_>
but we won't do DMA in u-boot anyway
<mripard_>
the only missing thing was DMA
2014-07-25
<codekipper>
Turls DMA works a treat
<hani>
wens: sorry I meant the entire codec node with the dma
<wens>
mripard_: dma driver finally merged :)
2014-07-21
<wens>
mripard_: what happens if the dma maintainer goes missing for a long time? can anyone replace him?
2014-07-16
<Dodger78>
standard clock, tried to raise voltage , no success, tried to change from ring DMA to chained DMA ,no success, things got worse.
<wens>
i see dma-buf fences being mentioned
2014-07-15
<mripard>
I'd really like for the DMA driver to come in too.
<wens>
not your dma patch, nor another patch splitting adb/baud clk, for 8250_dw
<wens>
just tested dma+codec on my ct, it's singing nicely
<wens>
Turl: your 'ARM: sunxi: refresh upstream defconfigs to enable DMA driver' patch seems to have removed some options for other platforms :p
2014-07-14
<BorgCuba>
the mali driver doesnt seem to compile: drivers/gpu/ion/ion.c:866:4: error: implicit declaration of function ‘__dma_page_cpu_to_dev’ [-Werror=implicit-function-declaration]
2014-07-12
<Turl>
ssvb_: this dma engine was certainly not made to be high performance
<ssvb_>
Turl: how fast is the dma working for you now?
<Turl>
ssvb_: so, if the dma engine can do burst of up to 8 32bit ops, that would be the most optimal then?
2014-07-08
<plaes>
groszek: currently (without DMA) the hw accelerator has almost the same speed as cpu-based crypto
<wens>
Turl: can spi do larger dma bursts? (i see maxburst is set to 1)
2014-07-07
<Turl>
doing a big transfer with DMA
<Turl>
wens: analog audio, using DMA :p
<wens>
Turl: may i ask why spi dma transfers for > 64byte didn't work the first time?
2014-07-06
<patapovich>
ok :D btw great job with dma driver!
<Turl>
patapovich: large spi dma transfers are working already
<patapovich>
could it help with large spi dma transfers?
<patapovich>
don't know if it can help with dma also
<patapovich>
just thinking if its gonna help with spi dma transfers
2014-07-03
<wens>
mripard: about ahb1 needing to be clocked from pll6 for dma, i remember a series for default clock parents in dt?
2014-07-02
<oliv3r>
bbrezillon: so the DMA is not hugely important and won't offer a HUGE benefit
<bbrezillon>
I'd say, there a lot of chance it is faster without DMA
<oliv3r>
so DMA is not a hugely crittical part to have?
<oliv3r>
have you monitored cpu load of the nand driver? since we lack dma
2014-07-01
<mripard>
oliv3r: DMA doesn't mean that it will be faster
2014-06-27
<Turl>
gzamboni: anyway, if you want to test you'll find the latest dma code on the sunxi-dma branch on my tree
<gzamboni>
i used the dma code from mripard in mainline without dma and the one from 3.4 with dma and the data transfer speed was better in the mainline :)
<Turl>
when you are using dma, the engine does it for you
<Turl>
gzamboni: just to be clear, when you are not using dma, the cpu needs to push data through a fifo register, and read data from another fifo register
<gzamboni>
so in a continuous transfer with dma it will surely use less cpu
<gzamboni>
yes, but what you receive will be automaticly got from at the direct access memory, so you just need a high speed spi Interated circuit to test it... if you want i can do so with and without the dma to see the differences
<Turl>
gzamboni: do you have/know some spi devices that would benefit from DMA?
<gzamboni>
Turl not yet, i was playing around with the dma code, but it was too complicate for me, i have to start with something smaller. AFAIK the most important stuff that uses dma are the audio and spi
2014-06-26
<gzamboni>
hey, Turl nice job with the dma code :)
2014-06-24
<wens>
tcon however can use dedicated DMA
<Turl>
libv: I don't recall seeing any disp stuff on the dma channels when working on that
<libv>
Turl: there might be an even bigger shortcut by using dma, but we have very little sample code
<Turl>
libv: it doesn't require DMA, does it?
2014-06-23
<Turl>
rz2k: I believe there's no dma involved in disp
<rz2k>
and figuring out the new DMA and missing clks?
2014-06-22
<oliv3r>
if we have dma enabled nand driver, i could atleast base my product around that ;)
2014-06-18
<libv>
dma-buf is not the reason
<libv>
and probably now properly syncs up with the mali blobs through dma-buf
<libv>
mdrjr is barking up the wrong tree with dma-buf.
<Vanfanel>
libv: it's very simple, but MAY be stupid from my part. mdrjr told me that the reason U3 is SO much faster now than it was 4 months ago in GLES2 is that they're using dma-buf now, wich is supposed to be faster in drawing to screen. So I wondered if the same thing could be archieved with the cubie2.. that's all.
<Vanfanel>
so I got an Odroid U3, wich uses dma-buf, and it's way faster
<Vanfanel>
hello! Is there a MALI blob for A20 wich does GLES2 and uses dma-buf??
2014-06-10
<Turl>
A23 DMA stuff is similar to sun6i I'd hope, which mripard already added support for
<oliv3r>
with dma stuff, you mean you are working on a23/a31 dma engine stuff?
<Turl>
Montjoie: I am cleaning up my dma code, I will give you a branch in a bit
2014-06-09
<Turl>
<&dma T C> where T = 1 for dedicated, 0 for normal
<wens>
and then use 3 cell dma bindings in DT to differentiate between normal and dedicated
<wens>
with dedicated dma, 8 channels run simultaneously
<Turl>
the DMA engine doesn't have any notion of priority either as far as I can see
<Turl>
wens: I got the UARTs and SPI working via DMA