2013-08-01

<wingrime> DMA
<woprr> and we need someone experienced with DMA to adapt the new/old dvb buffer core to A20 DMA system

2013-07-31

<wingrime> Turl: we have 2 - normal DMA capable IrDA transmitter/reciver
<Turl> oliv3r: I was talking about emac, and said dma was used for tx only on the driver we have

2013-07-30

<oliv3r> woprr: we don't have DMA in mainline kernel at the moment, mdp is working on it i belive
<woprr> wingrime, 1) for what sample code? 2) we can utilize good DMA system professionals from linuxtv.org 3) " mjpeg mpeg12 code" ? media?
<oliv3r> since we don't have dma yet ;)
<wingrime> woprr: 1) we have no sample code for TS 2) our dma driver - crap 3) we have as result of RE - mjpeg mpeg12 code
<wingrime> woprr: you not simply connect TS and DISP and Cedar, there need normal diriver that use DMA
<wingrime> mripard_: I need users for dma first
<mripard_> wingrime: so you'd work on audio instead of dma ?
<wingrime> mripard_: also there nice soc-audio-dma-engine support
<wingrime> than you can use in sun4i dt sun4i-dma version , and use sun5i-dma in sun5i dy
<mripard_> yet, if something differs, DMA routes, gpio pin sets, clock definitions, we should use different compatibles
<wingrime> you can add sun4i-dma and sun5i-dma string to match array
<wingrime> mripard_: dma are same , but routes not
<oliv3r> so if we have sunxi_dma.c, compatible should be allwinner,sun4i-dma
<oliv3r> wouldn't it be usefull to use dma for rx aswell?
<Turl> it just uses dma for tx from what I recall
<Turl> mripard_: emac can DMA too
<mripard_> mdp's plan is to write an SPI PIO driver, and then use SPI with DMA
<mripard_> wingrime: you'd need a driver that use DMA
<wingrime> mripard_: I write dma-engine driver skeleton and have no idea how test driver (only want see printks)

2013-07-29

<wingrime> oliv3r: dma_engine - kernel framework
<ssvb> wingrime: if you have some dma optimizations for clear or copy pages operations, it is easy to construct a userland test
<wingrime> oliv3r: do you have any idea how I can test dma
<wingrime> oliv3r: running dma slow process memory access
<wingrime> oliv3r: also, do you know that DMA use same BUS and mem contoller
<oliv3r> should yield quite some performance? but maybe native is just as fast or faster then dma
<wingrime> oliv3r: dma it self memory mover
<wingrime> oliv3r: dma-engine have interface
<oliv3r> what about dma memcopy?
<wingrime> oliv3r: I made dma-engine driver skelet code
<wingrime> writel(1<<16, dma_base + 0x8);
<wingrime> Turl: funny I find undocumented DMA reg
<Turl> wingrime: adding DMA to emac can be a 2nd test
<wingrime> 0.447266] sunxi-dma 1c02000.dma: initialized sunXi DMA driver
<wingrime> Turl: you must know that cpu have cache , and dma can wirte to memory in avoid cache update
<wingrime> Turl: and more important about cache and dma
<Turl> wingrime: I think there is a dma stress test thing in kernel
<wingrime> Turl: and I still no ide how test dma driver without anyclinets
<Turl> wingrime: for DMA driver I would not worry much, you would probably have 2-4 patches, one for driver and then one for dt (together or separate sun4/5/7i)
<wingrime> but DMA IP same
<wingrime> DMA 6
<Turl> wingrime: just checked, clocks = <&ahb_gates 16> for example if you need DMA gate on AHB
<wingrime> sunxi-dma: probe of 1c02000.dma failed with error -12
<wingrime> This allows the async_tx api to take advantage of offload engines for memcpy, memset, xor, and raid6 p+q operations. If your platform has a dma engine that can perform raid operations and you have enabled
<wingrime> but see CONFIG_ASYNC_TX_DMA:
<arokux1> wingrime, by dma-engine you mean hardware or respective kernel framework?
<wingrime> arokux1: no , it dma-engine ability
<wingrime> dma engine
<oliv3r> to dma engine?
<wingrime> oliv3r: nice , dma enigne can offload memcopy
<oliv3r> wingrime: mdp is working on dma isnt' he?
<wingrime> arokux1: I also thinking about do DMA and AXP stuff for mainline
<wingrime> hansg: dma hdmi sound bug http://paste.debian.net/19401/
<wingrime> hansg: also seems to be DMA IP same for a20
<hansg> wingrime, oh, that is not good (dma BUG)
<wingrime> hansg: dma get BUG()

2013-07-26

<wingrime> hno: strnage , I have no idea why thay rewrited dma , it not fits "strategy" (I mean "don't touch if it works)
<wingrime> mripard_: now dma driver looks like worser that old ((
<wingrime> mripard_: I noticed that AW new dma driver add two layers of code , but IP realy same , except some new security features
<oliv3r> rz2k: also, mmc controller has its own dedicated DMA engine
<rz2k> and kernel needs full-blown driver with dma support and ability to transfer huge amounts of data
<rz2k> arokux1: i bet u-boot mmc driver is non-dma one for simple 1-2 megabyte transactions

2013-07-25

<rz2k> dma is well documented, try reaching mdp if you want to help
<rz2k> DMA needs to be implemented using the kernel's DMAEngine framework
<slapin_nb> ARCH_DMA_MINALIGN is 64, sizeof is 10112
<slapin_nb> chip->buffers = memalign(ARCH_DMA_MINALIGN,

2013-07-24

<mripard> and he will use the SPI to bring up DMA after that
<mripard> yeah, DMA is the biggest showstoper these days
<rz2k> slapin_nb: nand is not happening until dma is ready

2013-07-20

<Turl> ssvb: I also noticed that it uses DMA on one way and cpu accesses on the other, maybe the dma path is to blame?

2013-07-19

<oliv3r> but I think it's how or what is (allowed) to connect it's dma to the memory

2013-07-18

<ssvb> wingrime: you can probably try to run some benchmarks yourself for different types of dma transfer handling (with and without cache flushes)
<wingrime> ssvb: now every (mostly) dma transefer on sunxi do flush at end . so you mean, it can cost more than simply memcpy without DMA
<wingrime> ssvb: in dma case, it realy not nessesory when you send somethig to IOMEM , and I think that normaly driver must allocate buffer with such flag
<wingrime> ssvb: about flush cache in dma driver , I stull not sure about we need it
<wingrime> ssvb: yeah, wemac is very strange , it use dma callbacks for TX (dma callbacks OMG in IRQ context)

2013-07-17

<wingrime> ssvb: dma also can't be used for help as it too have no any deal with mmu (may be we can use transfers one page sized?)

2013-07-16

<ssvb> wingrime: the low 32-bits of the physical address for G2D input DMA are stored in another register
<ssvb> wingrime: check the A10 manual and search for "Input DMA start address high 4bits register"
<wingrime> ssvb: as cedar have internal dma it can be internal dest device selector
<wingrime> Trul: it looks good for dma self refresh suspend ?

2013-07-15

<wingrime> nove: cedar hw have own DMA engine that can read and write result without cpu, you must only say where SRC and where DST buffers

2013-07-12

<zumbi> MALI400 proprietary module seems to be incompatible with PM_RUNTIME, PROFILING and DMA_SHARED_BUFFER

2013-07-10

<wingrime> jemk: I have idea that cedar can work like dma with shadow regs set

2013-07-08

<wingrime> mnemoc: but I have still unmerget tuchscreen driver, some dma patchs

2013-07-05

<wingrime> mripard: I can wite 'custom' api for dma but I don't think it ever acepted
<oliv3r> dma is reasonably well documented
<wingrime> mripard: I understand how dma work, but I have not understand dma-engine api
<mripard> Turl: wanting to do DMA (or SDIO, I didn't really started working on it)
<wingrime> mripard: dma are realy important
<mripard> I guess everyone wanting to start working either on DMA or SPI can start
<Turl> wingrime: I haven't ever heard back from the guy doing the DMA driver, mripard might know more :)
<wingrime> Turl: whats going on with mmc and dma drivers

2013-07-01

<oliv3r> oh dma
<Turl> mripard: do you have any news from mdp on DMA?

2013-06-21

<oliv3r> or does the AHB have it's own connection to the sdram? (for dma of the various drivers I expect)

2013-06-16

<derethor> and it seems that the protocol has some kind of DMA specification

2013-06-12

<hno> #define AHB_GATE_OFFSET_DMA 6
<hno> oliv3r, and the DMA gate is already defined.
<oliv3r> where should we define names for it? what spot is the best? e.g. CCM_AHB_GATE_DMA

2013-06-08

<hno> The controller will happily do a full NAND block DMA transfer if you ask it, divided in ECC sectors.

2013-05-31

<hglm> ssvb: Yeah IRQ would be nice. Not sure if they are using DMA IRQ's in the RPi kernel though (you would assume so though).
<ssvb> hglm: this means a bit of kernel hacking and proper use of IRQ which can signal DMA completion
<ssvb> hglm: but in any case, if we want to also have a good RPi support, DMA needs to be taken into use
<hglm> ssvb: No, I haven't touched "DMA-hell" on the RPi. They seem to require busy-waiting, no interrupt.
<ssvb> hglm: are you using RPI DMA for blits and fills?

2013-05-30

<hramrach_> I could run memtest on a x86 box all day but the moment I started DMA intensive data transfet it would crash

2013-05-28

<hno> Those NAND controller offsets os for direct SRAM access when it's mapped (in the NAND controller) for CPU access. The same SRAM can also be accessed via FIFO registers when mapped for DMA access.
<hno> but some can not be mapped to the CPU at all and is only accessible via such FIFO registers, and many of the FIFO registers can not be accessed by the CPU only by the DMA controller.
<oliv3r> you mean the hardware does some DMA'd SRAM -> main memory?
<hno> ssvb, quite likely. They use FIFO DMA registers everywhere for transfer between controller SRAM and normal memory. But in many cases the FIFO register is only accessible by the DMA controller.
<oliv3r> lxsameer: i think only DMA controller is left there, quite a tricky feat ;)
<Turl> slapin_nb: indeed, mainline has no dma yet
<slapin_nb> Turl: so no DMA there?

2013-05-27

<user_2> 3.4 souds good. it it "complete" or also it miss spi, i2c, dma etc?
<oliv3r> user_2: you sure? we don't have spi, i2c, dma etc yet. not even console or usb, no video

2013-05-23

<mnemoc> vinifm: try to catch wingrime. he did the dma unification
<techn_> vinifm: there is two dma patches.. you could try without them?
<techn_> mripard: Great. :) :* It seems to actually be a Mentor Graphics Inventra USB Controller (musb), that already support for it in mainline kernel, so it only needs a thin layer to adapt it to sunxi. Moreover, it's already supporting the PIO mode, so we could avoid relying on DMA to merge it. (Thanks to Arnd Bergmann for noticing

2013-05-22

<wingrime> 1) in dma_add request 2) in irq
<wingrime> mnemoc: Finite state machine mean that one function change dma_engine state ONCE
<wingrime> mnemoc: emac add new request in dma callback
<wingrime> DMA driver must be like https://en.wikipedia.org/wiki/Finite-state_machine
<wingrime> current driver have problems like 1) IRQ callbacks that allow call some dma_add functions that make IRQ handler check two times that changed
<mnemoc> so you don't want to finish the dma support? :(
<wingrime> and "half done" dma event callback
<wingrime> I make some dma rework
<wingrime> next patch will do some rework dma

2013-05-20

<hno> nove, yes, the cedarx is probably quite robust. I think the issues seen is in DMA mapping rather than CedarX.

2013-05-19

<wingrime> 0x01c0e228 constain dma base
<wingrime> check_bs_dma_busy in blob))
<wingrime> oliv3r: I think cedar use inner dma to copy mem and cedar JUST NEED POINTER TO MEM AND RET BUFFER

2013-05-18

<wingrime-android> dma aproved

2013-05-17

<oliv3r> no dma's etc, just interrupt

2013-05-15

<oliv3r> hno: when you worked with slapin on mtd, you tried to get it to work without DMA, right? Does yuq's also do this? or he only implemented it with dma, and if we'd want it without, we're still equally stuck?

2013-05-14

<oliv3r> going from that, if the emac hardware puts data directly into the sram (dma on the hardware end? and singals with an interrupt that the data is ready?) how do we get it out if it is restricted to the emac?
<mripard> DMA won't make things faster
<oliv3r> and finally, use DMA for emac
<mripard> (which is DMA)
<oliv3r> so you can us DMA on SRAM and regular ram
<mripard> with DMA, you offload the CPU from the data transfer between RAM/device
<oliv3r> and on that note, do you need/want DMA to access the SRAM?
<oliv3r> so how does sram have anything to do with using DMA?
<mnemoc> hno and slapin worked months on trying to get the nand working without DMA
<oliv3r> i don't know much/anything about DMA, but i thought DMA access, was direct RAM access (or sram i suppose)
<mnemoc> isn't it a bad idea to not use DMA for ethernet?
<mripard> and since we don't use DMA at all
<mripard> and I guess it's for DMA
<mripard> but yes, it's way faster than the RAM, so maybe they use it for faster DMA, I don't know.

2013-05-09

<mnemoc> to read the raw nand you have to use dma and use some randomization stuff, not directly from a memory address

2013-05-08

<oliv3r> mripard_: any news on i2c;spi;dma drivers for ML?

2013-05-06

<oliv3r> 3.11 is far far from usable atm, it boots, but no i2c, no spi, no dma etc yet

2013-04-24

<oliv3r> wingrime-android: turl was working on it, but without DMA, i'm starting work on PWM now, and afterthat, if nobody has, will play with crypto as that looks like a fun driver, but will require DMA
<oliv3r> wingrime-android: haven't done anything with DMA yet :( except for testing your patch that one time
<wingrime-android> oliv3r: any positive reeults with dma?

2013-04-20

<Turl> I suppose DMA would speed it up considerably, sending 32 bits at a time via a fifo is time consuming

2013-04-15

<hramrach> Turl: what did you test with the dma patches?

2013-04-14

<wingrime> Turl: you need sunxi:wemac: remove unused dma irq poll code sunxi:dma: optimize irq handling code sunxi:dma: do d-cache invalidation on transaction end
<wingrime> I don't know what to do with my dma patchset

2013-04-13

<shineworld> Actually I'm thinking to place cubie board upon our motion control card and share some memory with DMA (between fpga)

2013-04-12

<mripard_> we have all the basic blocks except dma

2013-04-09

<hramrach> serial driver with dma drivers/tty/serial/amba-pl011.c
<wingrime> every soc use own-way dma
<wingrime> but problem is,,,,kernel have not realy dma framework
<wingrime> mripard: dma actualy simpler than mtd
<mripard_> the only thing we miss to make it work is still the DMA
<wingrime> hramrach: dma support DRQ form UART
<hramrach> does not seem to have an option for dma
<wingrime> hramrach: dma also can be used with uart
<wingrime> hramrach: I realy don't thnk is dma difficult
<hramrach> yes, dma is kind of missing
<wingrime> but without dma it still possible
<wingrime> good wemac need dma
<wingrime> hramrach: wemac: send next packet It dma callback (irq contextx)
<wingrime> hramrach: dma code are realy strange
<wingrime> I still don't know are dma patches workable.....
<wingrime> hramrach: I still have questions form your dma test

2013-04-06

<wingrime> dma optimizatin also in kernel
<hramrach> hmm, modules should hopefully not be affected by the dma change
<wingrime> hramrach: dma used for wemac , sound , nand ,spi ,usb
<wingrime> hramrach: mmc not use general dma engine
<wingrime> hramrach: and than this is "dma-rework" branch ?
<hramrach> dma patches don't affect that at all
<hramrach> dma patches don't affect that at all
<wingrime> techn__: I have feeling that last patchas in "dma-rework" branch can make andorid fly better

2013-04-05

<mnemoc> wingrime: and then send your dma patchset
<wingrime> mnemoc: I still have some dma optimize/cleanup patches in my repo and I still wait benches for others
<wingrime> ssvb: are you tested dma patches ?

2013-04-04

<oliv3r> i'll check what the DMA controller is actually connected to
<wingrime> oliv3r: disp and mmc have own dma ability
<oliv3r> wingrime: it DOES say clearly, that it has its own dedicated DMA circuit :)
<wingrime> dma results
<oliv3r> wingrime: http://paste.debian.net/247346/ dma test
<hramrach> better dma is cool
<wingrime> hramrach: I testing dma fixes
<oliv3r> wingrime: dma rework bench on your github?
<wingrime> olv3r: chek my branch dma-rework

2013-04-03

<wingrime> mnemoc: I removed some unused DMA feature - Halfdone irq callback handling
<mnemoc> wingrime: the dma patch?
<wingrime> techn__: touching dma is a like bees hive
<wingrime> ssvb: I mean dma
<ssvb> wingrime: sorry, I'm probably missing the context. What are you doing to get it on top? Is it the result of your dma irq rework patches?
<wingrime> mnemoc: I have no intension remake/resend such big patch as "dma merge"

2013-04-02

<wingrime> dma driver like bees hive
<wingrime> sound and usb use dma and work good
<wingrime> ssvb: I reworked (not fully) dma IRQ handler
<ssvb> wingrime: for 2D graphics there is G2D unit (Mixer Processor) which has 4 DMA channels for reading and 3 channels for writing
<wingrime> ssvb: you also try use dma for mem copy
<wingrime> mpd: how do you think it better "finite state machine" teory for dma code
<oliv3r> mdp: dmaengine-am335x-3.7-rc1 your most current dma work in?
<oliv3r> haven't checked u-boot SPL code if it uses dma actually
<oliv3r> i think i saw in boot0 code, that it can work with and without dma aswell (but my memory may be off here)
<wingrime> mpd : mmc have internal dma engine
<mdp> so the mainline progress page seems to imply that it's blocked on "dma", meaning dmaengine, when its not
<mdp> the sunxi mmc block doesn't use the normal/direct dma
<oliv3r> I've only started to read lddp3 it think it was called and read the dma chapter
<mdp> oliv3r: it does..it has its own dma controller
<oliv3r> mdp: i know nothing about dma :( wingrime has dug a lot. He did find something rather interesting. the MMC controller may have its own way of doing dma
<mdp> oliv3r: essentially the approach is that I really need a slave driver that uses normal/direct dma first...it's not much use without a client driver
<oliv3r> mdp: i probably haven't; wingrime has been investigating the DMA heavily the past few days :)
<oliv3r> mdp: are you working on the dma driver? do you have a git repository for it?

2013-04-01

<wingrime> ssvb: I make some dma irq handler optimization
<oliv3r> wingrime: oh appearantly matt porter (mdp) is working on DMA a bit :)
<wingrime> vinifm: usb code totaly crap, even without dma
<vinifm> hi, I've been having problems with DMA
<oliv3r> wingrime: your dma patches didn't crash anything, wifi reset and got new ip; so no crasuh
<wingrime> oliv3r: dma HAS to be rewrited anyway but when, what is a guestion
<oliv3r> wingrime: in the end, It will not matter, since the dma code has to be rewritten anyway, and then it absolutly will be no aw copyright anymore
<ssvb> wingrime: is it difficult to change wemac, ether, nand, sound to use the standard dma framework?
<wingrime> ssvb: I uart also have full HW dma support
<wingrime> ssvb: and more interesting, try use dma_mapper as replacment for invalidation
<ssvb> wingrime: maybe we can just reuse some dma framework from the mainline?
<wingrime> ssvb: dma code is crap
<wingrime> ssvb: I just move cache invalidation form "drivers" to "dma"
<ssvb> wingrime: when optimizing dma, just be really careful with cache clean/invalidate operations, right now this stuff is messed up for sunxi
<wingrime> mripard: more interesting, I want try optimize main dma "finite state machine" code
<oliv3r> wingrime: that DMA engine also used in the u-boot driver?
<wingrime> mripard: mmc have no interact with main dma engine
<mripard_> wingrime: interesting, so the mmc controller has its own dma controller, separate from the "main" on?
<wingrime> mripard: mmc controller can copy data directly to mem, without cpu (some internal dma)
<oliv3r> wingrime: wouldn't the mmc driver eventually use the 'normal' dma engine? I can see that u-boot version be 'complete by itself' of course
<wingrime> mripard: Good News :mmc have own dma engine , so it have no depedences to mainlining
<wingrime> oliv3r: I know way how optimize dma
<wingrime> mripard: mmc have own dma engine , so it have no depedences to mainlining
<wingrime> mnemoc: I replaced mach/dma.h to plat/dma.h , my DMA unification will conflict with sound unification
<wingrime> I wonder That I didn't forget something for dma
<wingrime> and I now working on dma unfication
<wingrime> mnemoc: dma It like depedency hell

2013-03-31

<oliv3r> i cherry-picked the dma fix on stage/sunxi-3.4 + header change. and your right, it was unstable. while waiting initially (after about 10 minutes) i had atleast a reboot. but it was only the one
<oliv3r> your dma patches do improve performance quite a bit.
<oliv3r> /silo/build/sunxi-bsp/linux-sunxi/arch/arm/mach-sun4i/dma/dma.c: In function 'sw_dma_loadbuffer':
<ssvb> wingrime: but the current allwinner dma code looks horrible to me, so the improvements should be generally a good thing
<wingrime> ssvb: becose dma used for audio.ethernet,usb,nand
<wingrime> ssvb: this fixes strange bugs , that dma_callback functions are called in irq context
<ssvb> but in any case, this whole dma irq handler looks very suspicious
<oliv3r> wingrime: what branch is your dma test on? i added your github as remote, but can't find it :)
<wingrime> ssvb: look at sw_dma_set_opfn
<wingrime> ssvb: look at sw_dma_set_halfdone_fn
<wingrime> ssvb: look at sw_dma_set_buffdone_fn
<wingrime> dma driver can call callbackfunction to some driver in irq context
<wingrime> ssvb: find sw_dma_set_opfn
<ssvb> wingrime: well, for this direction of transfer, invalidating the cache before dma transfer is complete seems wrong
<vinifm> I've been having problems with DMA, when using sockets
<wingrime> ssvb: dma can do nand->ram
<ssvb> wingrime: so is it a transfer from DMA to CPU (for example NAND read)?
<techn_> oh.. so when you use dma you should disable cache
<techn_> but why dma requires cache flush?
<wingrime> techn_: when you use DMA cpu don't know that data changed
<wingrime> for new dma transfet you must call sw_dma_enqueue
<ssvb> if there is a long delay (doing cache flush) between the completion of previous dma transfer and the start of a new dma transfer, then this is not good
<ssvb> you want to have dma transfers always running for best performance
<wingrime> ssvb: actualy sw_dma_enqueue not alawys send to dma
<ssvb> maybe it would be better to flush cache in the beginning of 'sw_dma_enqueue'?
<wingrime> ssvb: I actulay will try make irq lighter for dma
<wingrime> techn_: I want move dma irq handler to worker thread
<techn_> you could enable dma debug stuff.. I tried that once and it gave some warnings/errors
<wingrime> ssvb: I need someone who can measure nand speed with/without my patch for dma
<wingrime> oliv3r: sdhost use strange own dma
<wingrime> I found 2 things I can fix with dma

2013-03-30

<wingrime> now driver do it over dma always
<wingrime> hramrach: do you think we need some limit when send on dma
<wingrime> it realy required for dma?
<hramrach> but sram is small buffer and DRAM is generally good for the kind of stuff dma does
<hramrach> well, you can DMA to sram which is presumably fast
<wingrime> oliv3r: DMA offcose can write to SRAM
<hramrach> oliv3r: also disk reads/writes that use dma

2013-03-29

<oliv3r> ssvb: i've never done DMA programming. I know it's 'direct memory access' but thats where it stops for me :(
<oliv3r> i'll sound really stupid now, and say i didn't know you had to use dma for that :)
<ssvb> I guess the hardware PRNG is not very useful without DMA

2013-03-28

<wingrime> mnemoc: when G2D or DMA or CedarX write to mem, or read it use bus for it
<wingrime> libv: dma is great thing
<libv> wingrime: there are many possibilities for DMA, they could be really dumb, or they could end up being called a full 2d engine
<wingrime> libv: that dma engine can fill copy blocks , by event, autoinrementing or decrementing
<wingrime> libv: in summer I played with dma on msp430
<wingrime> libv: dma have many modes " copy " " fill "
<libv> wingrime: do we have a dma engine which can deal with stride changes?
<libv> ah, dma, sorry, i too should learn to read instead of dream