2013-11-03

<wingrime> pfdm_: you can't directly use render result, My opinion that, aw specialists made this only for mem bandwidth, just for not block memory with hi-priorty DMA transfer for whole frame

2013-10-30

<Montjoie> yeah I got DMA working for the crypto module
<Montjoie> when I have finished the SS module, I will very-document it non-DMA aware people
<hno> the DMA controller can't do that mapping. Must be done by kernel before talking to the DMA controller.
<mripard> and you don't need any dma controller for that
<mripard> leviathanch: you can use the dma-mapping API to do the translation between physical/virtual adresses
<hno> leviathanch, we have both CPU and DMA drivers for the MMC. DMA driver in Linux-3.4 and CPU driver in u-boot.
<hno> leviathanch, not sure what you actually ask, but mmc controller supports both DMA and CPU transfers.
<hno> leviathanch, but that's not a hardware documentation question. That's about actually asking the kernel to remap those buffers to physical address space before giving them to the DMA controller.
<leviathanch> I could do it without DMA of course
<hno> there is more than one DMA controller.
<leviathanch> which accesses the dma controller of the A1X
<leviathanch> hno: we need a dma driver
<hno> leviathanch, but yes, for any DMA operations any supplied buffers must be translated to physical address.
<hno> leviathanch, there is also a generic DMA controller.
<leviathanch> hno: of course mmc does dma on its own
<hno> leviathanch, is it? Last time I looked MMC had it's own DMA.
<leviathanch> arokux1: and a description on how the mmc controller is wired to dma (since it totally is!)
<Montjoie> with DMA, the destination is where you send data ? DMA documentation said the for SS the destination but for the TX IO but the SS doc said the data is sended to the RX IO
<hno> #define DMA_OFF_REG_PARA ( 0x0018 )
<hno> DMA_WRITE_REG(*(u32 *)&para, pchan->reg_base + DMA_OFF_REG_PARA);
<hno> csp_dma_set_para(pchan, *(dma_para_t *)parg);
<Montjoie> sended then to dma_ctrl() (arch/arm/mach-sun7i/dma/dma_core.c)
<Montjoie> this number is send to sw_dma_ctl()
<Montjoie> drivers/block/sunxi_nand/nfd/dma_for_nand.c:sunxi_dma_config(&nand_dma, &nand_hwconf, 0x7f077f07);
<oliv3r> the manual does list all the DMA registers iirc
<Montjoie> if someone know what is the means of DMA parameter 0x7f077f07 for nand and 0x03030303 for emac...
<oliv3r> Montjoie: dma, especially in mainline, hasn't been touchedy et
<Montjoie> I have question about sunxi_dma_config(), anyone know it ?

2013-10-28

<leviathanch> mripard: uhm, when you allocate DMA memory and pass the virtual address to the MMC controller by writing it into the register it requires DMA support to get it back
<arokux2> leviathanch: btw, usb problem wasn't a DMA one
<mripard> leviathanch: I'm not sure the dma controller driver will help you
<leviathanch> arokux2: but without DMA i'm not able to do further tests
<leviathanch> but as soon as DMA support is in linux-next
<leviathanch> without a working DMA driver in upstream

2013-10-26

<wingrime> mnemoc: only PCM DMA fix
<Turl> oliv3r: 3.4 from what I know, but it shouldn't be much of an issue to fast forward it (other than DMA)

2013-10-25

<Turl> montjoie[home]: there is a dma_compat.h header to support all sunx dma I think
<Turl> there is lots of dma stuff there too
<Turl> montjoie[home]: I think hansg got DMA going on 3.4 for sun7i
<montjoie[home]> I see all allwinner A1x DMA stuff declared in arch/arm/plat-sunxi/include/plat/dma_defs.h but only ofr SUN4I and SUN5I, is it normal that I see nothing for SUN7I ?
<Turl> montjoie[home]: I'm pretty sure there is a test dma module in kernel
<montjoie[home]> anyone experienced with DMA know a good code example for using it ?

2013-10-24

<montjoie[home]> hramrach I think the problem is the non-dma transfer

2013-10-19

<ssvb> Turl: and I guess dma-buf did not exist at the time when ump had been introduced, so something had to fill the void

2013-10-17

<ssvb> the "dma" buzzword and the terminology from the kernel framework layer does not magically make the hardware behave better
<ssvb> techn_: if we make it dma coherent, then the memory corruption issue is solved and we don't need the cache flush ioctl anymore
<techn_> ssvb: but wouldn't that dma coherent memory solve that issue? and after thinking.. isn't that issue.. memory must be dma coherent
<ssvb> techn_: and there is also "dma noncoherent" mapping, which means that cache flushing has to be done explicitly
<techn_> but flushed on dma transfers
<techn_> wingrime: I'm not sure, but dma coherent memory is cached
<wingrime> ssvb: I not sure about DMA coherent, and cache stuff

2013-10-15

<PiyushVerma> I think there is 2 way to render vdpau output one by MALI Texture other by Scalar & DMA

2013-10-11

<wingrime> oliv3r: can you ack my sound bugfix for DMA

2013-10-10

<oliv3r> so if DMA is implemented using the mbus on these SoC's; why would a10 not have one
<Turl> x86 has a dedicated chip to do DMA according to wikibooks
<hno> DMA is a function. Can be implemented in very many ways.
<oliv3r> so how is DMA implemented on, say x86 without an mbus?
<hno> no, mbus is a transport for dma requests.
<oliv3r> so mbus is a faster dma ;)
<Turl> mbus is the highway and dma is the trucks
<hno> The display engine DMA is surely done via mbus. But not all DMA.
<oliv3r> now if you would have said that dma is done through the mbus; i'd say 'ohh'
<hno> dma is a function. mbus a transport.
<oliv3r> so what's the difference between dma and mbus?
<oliv3r> talk to other then dma
<hno> but mbus is internal to the DRAM & DMA controller.

2013-10-09

<wingrime> oliv3r: cedar have own dma too
<wingrime> oliv3r: mmc have own dma
<oliv3r> wingrime: i wouldn't be supprised, mmc has it's own dma does it not? streaming directly from mmc might make things faster/lower CPU demanding?

2013-10-08

<popolon> in emac_readme.txt : 2) using cpu to read/write fifo, not dma

2013-10-05

<oliv3r> i think the dma controller is identical
<mouchon2> ok but looking at dma_defs.h used by spi_sunxi.c there is no def for sun7i should i need to add it before or need to look somewhere else ?
<mouchon2> just a question i reading spi code and try to enable it for sun7i and if i understand there is currently no dma support for sun7i ?

2013-10-03

<oliv3r> jemk: so maybe the mmc dma controller is slower/crappier?
<oliv3r> jemk: i thought they are connected tot he regular 'main' DMA controller
<oliv3r> jemk: well mmc has it's own dedicated dma controller i thought
<jemk> oliv3r: that would be a bad hack, and there are many more dma devices that need to be checked
<jemk> Turl, ssvb: my guess would be, mmc/sd has own dma which is directly connected to mbus. maybe cpu can handle such fast mbus, but dma can not

2013-10-01

<mripard> because you know "mainline support is not sufficient", "there's no IP supported there", "What? No DMA?!"

2013-09-27

<Turl> n01: tried printk("%p %p\n", priv->dma_handle, ...) ? :)
<Turl> n01: and it uses the dma_handle instead of the return val of dma_alloc_coherent?
<n01> with dma_alloc_coherent(&pdev->dev, info->fix.smem_len, &priv->dma_handle, GFP_KERNEL);
<n01> pdest = (unsigned char *)priv->dma_handle;
<n01> Turl: yeah, dma_handle is supposed to be bus/phy addr
<n01> is it correct? dma_handle is a bus address
<n01> yes, but in a driver the guy does a memset on dma_handle
<mripard> n01: I have to go, so I don't really have much time to look at this, but isn't dma_handle suppose to be set by dma_alloc_coherent?
<n01> mripard: does it make sense memset-ting a dma_handle from dma_alloc_coherent()?
<n01> Turl: dma_addr_t dma_handle from dma_alloc_coherent()
<n01> Turl: does it make sense memset-ting a dma_handle??
<arokux1> jukivili: I'm currently without any ideas at all what to try next, I hoped Alan will say that this is DMA issue.......
<arokux1> jukivili: do you know something about dma? :)
<arokux1> jukivili: or.. it can be due to the missing dma support
<jukivili> arokux1: I have not been able to reproduce those dma problems that I had last spring with rtl8192cu on sunxi-3.4
<mripard> it has a chapter about DMA, and you can read Documentation/dmaengine.txt as well

2013-09-26

<rz2k> you need 9 dma operations
<rz2k> if you request block less or more, DMA will never finish
<arokux1> ideas the missing dma support can cause that -- but still not sure.
<arokux2> Turl, also: there is static mapping in 3.4, so even if it works without dma you still cann't be sure!
<arokux2> Turl, more likely dma, but I'll know for sure.
<arokux2> Turl, maybe it is a missing dma hooks??

2013-09-25

<leviathanch> I could get the mmc driver working without using the DMA engine
<leviathanch> doesn't seem to have published anything on DMA yet
<leviathanch> wasn't there someone already, who is working on DMA for A1X?!
<leviathanch> but since the kernel doesn't do hw dma
<leviathanch> no, it's more the problem: the mmc controller is configured to do DMA
<leviathanch> for DMA
<leviathanch> arokux2: have you disabled the uses_dma flag now? ;-)
<arokux2> leviathanch, i'm not sure usb needs dma
<leviathanch> mripard, arokux: well, unfortunately, all the chinese code does DMA related to MMC, and the documentation for the registers is non-existent
<mripard> arokux2: and if it still doesn't work after writing the dmaengine stuff, how will you possibly know if it's your USB driver or the DMA one that is not working?
<arokux2> mripard, what do you mean? I just want to find out if usb is really dma dependent
<oliv3r> arokux2: DMA engine in the user manual; though I looked at a20 manual as it tends to be more full
<oliv3r> where's the 'normal' dma has iit almost all
<oliv3r> but i know too little about dma to know the difference
<oliv3r> and then there's Dedicate DMA destination DRQ type (and source also) which has far far less IRQ's
<oliv3r> ok so we have NDMA_DEST_DRQ_TYPE; normal dma destination DRQ type; NDMA_SRC_DRQ_TYPE, normal dma source DRQ type
<arokux2> oliv3r, no... it is dma mode and works for storage
<arokux2> I wonder why usb storage works without DMA
<oliv3r> 1 dma engine supports 5 EP's so it sounded like it would be endpoints
<arokux2> oliv3r, musb uses dma too.... so things are complicated.
<oliv3r> arokux2: you can't 'just add dma support' the dma engine requires quite some work i'm affraid
<oliv3r> since we have no dma engine yet
<arokux2> oliv3r, I'd better add dma support....
<oliv3r> USB end point 1 is a dma dest.
<oliv3r> all I know about DMA, is that you can either copy data from 'somewhere' to memory using the CPU (like a = readl(addr) would be) or don't invoke the cpu at all, and have the device write code directly to ram
<arokux2> oliv3r, I see. the point is I've set my usb driver to actually use dma :)
<oliv3r> nothing really 'needs' dma, if your ok with slow speeds
<arokux2> oliv3r, well.. Hans said usb doesn't have dma! remember?!
<oliv3r> arokux2: to transfer data at high speeds, you wanna use dma to copy it away
<arokux2> oliv3r, as it looks like usb is using dma stuff. do not ask me why...
<oliv3r> arokux2: but usb doesn' thave its own dma controller like you said earlier, mmc does; but it'st he only defice
<arokux2> mripard, ah, I see. and that one is the driver for the dma controller?
<mripard> dmaengine is the framework we should put the dma controller support in
<arokux2> mripard, can you now tell me what bits are missing in -next for this dma usage to work correctly?
<mripard> and then complains that it actually uses DMA ? :)
<mripard> then you tell that you use DMA
<arokux2> mripard, no clue about: dma_map_sg ?
<arokux2> mripard, just checked by putting a printk. hcd->self.uses_dma is TRUE
<mripard> hmmm, it's actually not doing any dma related command unless you say that your driver can do DMA
<arokux2> mripard, it calls dma_map_sg. leviathanch said this one needs to be backed by a driver otherwise kernel will fallback to software emulation which (I do not know why) will fail/not work.
<arokux2> mripard, I see, the only thing is *dma* in its name
<arokux2> mripard, usb stack has something like map_urb_to_dma.. do you think there are some bits missing from -next for it to work correctly?
<mripard> since it has its own dma controller.
<arokux2> mripard, hey, have you read our dma discussion here? leviathanch has a suspicion DMA bits are needed for some devices to work
<oliv3r> btw, I don't recall USB having its very own DMA controller, I think there where only 2 DMA controllers, MMC and the SoC DMA controller
<oliv3r> mdp was working on the DMA stuff; we should ask him for a status :)
<leviathanch> your data ends up in digital nirvana without DMA
<leviathanch> you can't tell the DMA controller what address you wanna have the USB controller to put his data
<leviathanch> you only tell the DMA controller: get me some space together, where the usb host can put his data, I'll get it later
<leviathanch> these devices are all DMA clients
<arokux1> you can see channels in dma_route_sun4i.h there is nothing about mmc or usb host (only usb otg)
<leviathanch> and the usb module is doing DMA
<leviathanch> "advertize" in the sense that the DMA framework needs to use it
<leviathanch> since they have merged this functionality into the DMA API
<leviathanch> the kernel will just do bogus DMA in software
<leviathanch> if we do not provide a valid DMA controller device
<leviathanch> git grep dma
<leviathanch> look out for any DMA specific code in context with sunxi
<arokux1> leviathanch, my question is the following.. yes, usb stack calls dma_map_sg , but: does this function then internally need something that is soc specific??
<leviathanch> I was under the impression that the A1X-series would be using the default ARM DMA implementation
<arokux1> leviathanch, are there any DMA patches for sunxi for -next???
<leviathanch> do you have DMA patches for sunxi platform in your next branch?
<arokux1> leviathanch, the question is where dma_map_sg calls some SoC specific funcs
<leviathanch> given the usb module expects the DMA module to know the virtual address alocating the scattered blocks
<leviathanch> Linux is very well capable to emulate DMA itself in software on platforms where it isn't supported in hardware
<leviathanch> if it is being called without an actual DMA engine being informed about the allocation
<leviathanch> dma_map_sg for arm
<arokux1> leviathanch, can I put some printk noise into sunxi-3.4 to see if it uses any dma stuff?
<leviathanch> arokux1: some addresses you get out of pdev may very well have been allocated by dma calls on a higher abstraction layer
<arokux1> leviathanch, one question.. if I do not have dma calls, am I affected by this?
<leviathanch> and since there is no documentation about the internal DMA controller available
<leviathanch> the central DMA controller
<leviathanch> all the reference code is using DMA
<leviathanch> but the kernel never told the dma controller about the allocation
<leviathanch> I have to tell the DMA controller to map physical scatter list to a virtual address
<arokux1> hno, "if DMA is not used" <---- how do I know that? well, I do not have any dma calls, but maybe usb stack has them?
<hno> arokux1, if DMA is not used then there is no need for any physical DMA address mappings.
<arokux1> hno, this code is known to work: http://sprunge.us/BBPj?c no dma staff here except of masks, which I also set.
<arokux1> hno, I'm do not know anything about this DMA stuff.. how do you think, are there something connected to dma that could make usb stack to fail?
<hno> leviathanch, AW mmc driver uses sg_dma_address() to translate buffers to DMA address in the MMC DMA descriptors.
<arokux1> USB also has internal dma
<arokux1> something about dma
<hno> right, yes. MMC have an internal DMA controller.
<leviathanch> hno: also there is no device tree entry for a dma controller for sunxi
<hno> leviathanch, is there a sunxi dma driver in linux-next?
<leviathanch> arokux1: because all the other arches have DMA specific atomics
<leviathanch> hno: i know, but I think there isn't anything given to the DMA controller in linux-next
<arokux1> I suppose MMC uses DMA same as USB
<hno> leviathanch, virtaul addresses needs to be mapped to physical addresses before given to DMA controllers.
<leviathanch> mripard: unfortunately the the MMC module then requests this virtual address at the DMA controller, which doesn't know anything about this address since the one holding the table isn't the controller but the CPU
<leviathanch> mripard: obviously the kernel allocates virtual memory with the DMA functions, and then pushes the virtual address into the register of the IDMAC register of the MMC modules
<leviathanch> mripard: hi, i've got a problem with DMA and MMC... according addresses

2013-09-24

<Turl> arokux2: maybe dma itself?
<Turl> arokux2: maybe it's dma masks or sth

2013-09-22

<leviathanch> I mean... what DMA addresses are possible
<leviathanch> for the DMA ability spec? I'd be shocked if not
<leviathanch> you actually change the DMA ability mask
<leviathanch> arokux2: there was some flag had to set by using dma_set_mask in order to get the USB host working, right?
<leviathanch> there was some flag had to set by using dma_set_mask in order to get the USB host working, right?

2013-09-20

<tgaz> theoretically... if the 4 SPI channels can use 4 separate DMA channels, you could reach 600 Mbps, which is still not nearly fast enough.
<tgaz> boss: at those speeds, i would *guess* that's too slow. you'll want something that can use DMA
<mripard> next step is dmaengine and spi using DMA
<mripard> the easiest path to get DMA is to do SPI, and then DMA, I have a SPI driver that should be not that far from working
<arokux1> oliv3r, yes, I'm asking because of DMA... any idea if he is working on it?
<oliv3r> Matt Porter is the guy who said was gonna do DMA if i remember correctly

2013-09-19

<arokux2> Turl, the dma engine isn't used by chinese code too
<arokux2> Turl, mm.. it has internal DMA
<Turl> arokux2: not bad I guess, considering you're not using DMA are you?

2013-09-18

<wingrime> oliv3r: firslty we must have pio users , than do dma
<oliv3r> have drivers that also work in pio mode; then add dma mode
<oliv3r> Turl: DMA is being done by matt
<wingrime> Turl: we furstly must have some testable dma users, than do
<Turl> nobody wants to do dma? :)
<Turl> maybe it has no DMA implemented

2013-09-16

<hno> The MBUS looks like a data bus between DDR controller and a number of DMA controllers. The MBUS likely manages both internal and external transactions.

2013-09-13

<leviathanch> arokux: it appears as if the internal DMA of the mmc host controller is too slow while accessing

2013-09-12

<leviathanch> the internal dma controller of the mmc host just writes onto a target address I pass on to it through a register
<arokux2> leviathanch, I see. I also had this error with usb without those dma bits: http://paste.debian.net/34574/
<arokux2> leviathanch, mmc has buit-in dma?

2013-09-10

<hno> arokux2, any more changes after the dma bits?
<oliv3r> arokux: most drivers wait for DMA support though
<hno> arokux, that code looks a little odd. Smells like it should be the other way around, first check coherent_dma_mask, then dma_mask.
<arokux2> oliv3r, so desperatly looking for "differences" I've added this dma shit and it worked..
<arokux2> however I find it odd, since pdev->dev.coherent_dma_mask is used and then overwritten. can anybody explain?
<arokux2> ganbold, well usb stick appears :) the problem was I haven't assigned pdev->dev.dma_mask and pdev->dev.coherent_dma_mask....

2013-09-05

<jukivili> arokux: ok.. lets remove the dma-hack. I'll try revive my mk802 and test with it later.
<arokux> jukivili, scanning works without dma hacks
<jukivili> if I remember right, without dma-hack scanning caused crash.
<jukivili> arokux: because, if you now take off the dma-hack and try rtl8192cu, you should be able to crash your mele quite quickly
<jukivili> arokux: for testing dma-hack and that rtl8192cu patch sunxi-3.4 is enough
<arokux> jukivili, with sunxi_hcd_*_urb_for_dma
<jukivili> arokux: are you testing with or without dma-hack in sunxi-ehci
<arokux1> jukivili, once it works, I'll send patches that drop "dma fixes"
<arokux1> jukivili, btw, do you know how to trigger the bug, if sunxi_*_map_urb_for_dma are not there?
<arokux1> jukivili, I see. well, let us remove the sunxi_*_map_urb_for_dma and wait for the user with rtl8192cu? :)
<arokux1> jukivili, so sunxi_*_map_urb_for_dma is guarding against overlapping buffers in one cacheline really?
<arokux1> jukivili, as the purpose of sunxi_*_map_urb_for_dma is to make sure everything is fine if non-aligned buffer is passed. but it works already?
<arokux1> jukivili, ok. so my question now: if the sunxi_*_map_urb_for_dma tries to fix what is already working fine, why do we need it?
<jukivili> no extra central code, but if host-driver cannot work with unaligned buffer that is mapped with dma_map_single/etc, then it needs hacks like in terga driver
<jukivili> arokux1: well.. there is not extra code to handle non-aligned buffers. usb-core just calls dma_map_single/etc, http://lxr.linux.no/linux+v3.11/drivers/usb/core/hcd.c#L1507
<jukivili> arokux1: 'somewhere else' means dma-map all cachelines that hold part of buffer
<jukivili> arokux1: there is no reason why not.. the sunxi_*_map_urb_for_dma even had off-by-one error at beginning (temporary buffers misaligned by one).. none has reported problems with that
<jukivili> I don't know about terga_*_map_urb_for_dma, maybe their hardware cannot handle unaligned-dma (or they fixed same bug as I did)
<jukivili> arokux1: sunxi_*_map_urb_for_dma was to fix sunxi-ehci to not crash with rtl8192. At first I thought that sunxi-ehci could not handle unaligned buffers. But I was wrong, rtl8192cu is buggy.
<jukivili> arokux1: The sunxi_*_map_urb_for_dma , that was before I knew better. Now they are still there to prevent buggy drivers from crashing kernel.
<arokux1> jukivili, ok. let me ask: why for are {tegra,sunxi}_ehci_map_urb_for_dma functions? I've thought they are for handling non-aligned buffers correctly?
<jukivili> arokux1: dma fixes in sunxi ehci/ohci?
<arokux1> jukivili, hm... I thought "dma fixes" was there to handle the buffers correctly...
<jukivili> arokux1: Problem with rtl8192cu was that there were multiple places that were wrong, and fixing one place didn't yield full success.. driver kept crashing machine. So I started looking at sunxi ehci and found working solution that was copying unaligned-dma fix from terga to sunxi.
<arokux1> jukivili, sunxi ehci/ohci can handle them because there are "dma fixes", but I've seen something like this only in tegra
<jukivili> jukivili: rtl8192cu for using non-dma'able buffers
<jukivili> because if you handle dma-unaligned buffers by copying to/from temporary buffer, cachelines don't overlap anymore
<jukivili> So, at first I thought the problems with rtl8192cu were because sunxi ehci not handling unaligned dma (and fixing unaligned dma with sunxi ehci fixed the issues with rtl8192cu).
<arokux1> jukivili, ah, ok. do you know a usb driver that respects dma alignment?
<jukivili> arokux1: maybe there would be performance issues if usb-core would be change to handle non-dma'able buffers (alloc new tmpbuf, copy, etc). Most of the drivers do the right thing so to fix small set of buggy drivers and cause performance regression for other makes little sense.
<jukivili> arokux1: then usb-host dma-maps those buffers that are on same cacheline.. at least sunxi and rasbperrybi does not like this too much
<arokux1> jukivili, as far as I understood if ARCH_DMA_MINALIGN is defined, kmalloc will return correct alignment, or?
<jukivili> arokux1: at first I thought it was problem with dma-alignment with ehci/ohci.. but in the end it was not
<arokux1> jukivili, the code from the sdk-2.0 doesn't have dma fixes
<arokux1> jukivili, do you know if usb host is somehow special about dma aligning?

2013-09-02

<Turl> leviathanch: no, no DMA
<wingrime> * Host side RX (IN) using Mentor DMA works as follows:
<mripard> leviathanch: and just like hans was saying, the MMC doesn't need the dma controller as far as we know
<leviathanch> Turl: is there DMA support for A20 within your branch already?

2013-08-25

<hno> and some DMA glue.

2013-08-24

<oliv3r> for DMA

2013-08-20

<woprr> maybe DMA, see some contigous buffer code
<woprr> DMA not working only PIO polling and no dvb api (device files) nor i2c/tuners yet
<benoitm974> good morning everyone. has anyone worked with sun7i dma ? I'm trying to use dam_compat from hans but can't find equiv to dma_setflags, should I code those ?

2013-08-19

<benoitm974> Following Hans advice I'm right now looking into using his dma_compat.h to port spi_sunxi.c any help/advice/hints appreciated...

2013-08-13

<arokux> mripard, it works now. only dma part should be added, but this is copy paste.
<arokux1> vinifr, you've seen the answers on the ML i.e. their absence. but usb host controllers have their own dma, so I do not need the other one
<vinifr> arokux1, yes, is there some progress with DMA?
<arokux> Turl, hm.. it seems usb has an internal DMA!

2013-08-12

<arokux> Turl, btw, who was supposed to be working on DMA?
<arokux> Turl, ok, I think it is DMA. because i've inserted some output into an old driver in 3.4 and I see this output. I inserted it into DMA functions
<arokux> Turl, do you think dma is needed for sending some urb messages?
<arokux> Turl, but smth fails again. I wonder if it could be dma this time

2013-08-08

<woprr> WTF $ grep -rsn VIDEOBUF_DMA_CONTIG drivers/media/ drivers/media/video/Kconfig:22:config VIDEOBUF_DMA_CONTIG

2013-08-06

<hno> vinifr, it uses DMA and is not quite up to mainline standards on style and register access.. plus a whopping 0 pages documentation of the registers.

2013-08-05

<arokux1> mnemoc, another question. there is dma driver missing. a lot of stuff depends on it. is there somebody working on dma?
<arokux1> jukivili, yes, I think, there is dma code
<jukivili> does ehci require dma?

2013-08-04

<wingrime> mnemoc: it have OWN dma too, so DMA not required here
<wingrime> Turl: we have bunch dma
<Turl> two dma?
<wingrime> Turl: it have OWN dma
<Turl> wingrime: you got good dma consumer to test now
<wingrime> Turl: sata use own dma ,

2013-08-03

<hno> arokux, not really. But sure it touches many areas. USB, SDRAM (and SRAM for the OTG port), clocks, GPIO, DMA, plus all the usual stuff of a kernel driver.
<wingrime> Turl: DMA capable)
<hno> oliv3r have mapped up more details on the HPCR bits than I have. But not aware of those being for SRAM access.. only SDRAM DMA I think.
<Turl> hno: it needs to map SRAM for usb, maybe for use on dma, I don't know for sure
<arokux> Turl, PIO is slower than DMA?
<Turl> arokux: dma is not on mainline, indeed
<arokux> I see some dma stuff in usb. should there be some support for that in mainline which is not there yet?
<wingrime> arokux: axp209 or dma

2013-08-01

<woprr> oliv3r, depends on DMA driver :D