<apritzel> from the mainline submissions it seems like the A100 shares a lot with the H616 (USB PHY, MMC DMA in words, etc.)


<apritzel> normal CPU DRAM traffic, display engine DMA from the framebuffer to the video transmitter, plus DMA transfers from Mali to the framebuffer


<apritzel> without DMA!
<apritzel> also the 13bit DMA limit for MMC2 on A64 & later
<jernej> that address shift is relevant only for DMA access?
<apritzel> jernej: well, as I said: without DMA we don't need to bother with DDR50 in U-Boot, so we could keep it to SDR50
<megi> I tested DMA patches on quite a lot of SoCs


<apritzel> so if I get ~20MB/s on every SoC, having DMA sounds less tempting


<megi> just start DMA do something else, and once you have that done, poll for end of DMA
<apritzel> well, the whole design idea of U-Boot is to be single threaded and linear, so no multi tasking, not even interrupt driven DMA in the background
<megi> sunxi mmc can basically DMA the whole kernel at once if it's stored in a single consecutive amount of blocks on the card
<megi> it would also probably allow some fun stuff in U-Boot spl too, if it implemented DMA... like starting the transfer and do some other stuff not waiting for it to finish
<megi> s/tested/comapred DMA vs PIO/
<megi> because I implemented DDR support after having DMA already working
<apritzel> mmh, DMA for MMC, what does that give you?
<megi> that branch in general has some good stuff, like DMA support, and support for DDR
<apritzel> yeah, many times you just need some kind of better DMA controller


<jernej> yeah, RPi has interesting DMA, but I forgot details...
<apritzel> the DMA buffer is even more limited there, IIRC
<apritzel> jernej: but U-Boot will allocate buffers from the heap, which is now well above 4GB, but the EMAC DMA descriptors only hold 32 bit worth of addresses
<apritzel> the EMAC code in Linux should be fine, thanks to the default DMA mask


<lightspot21> hello, so I am trying to port linux to an Allwinner F1C100s device. Latest kernel and uboot have been ported and work correctly. However, I also need to initialize an LCD screen, with a driver already provided in source. Although it compiles, when I attempt to load it I get a segfault on dma_alloc_attrs. I have found the culprit line, and it is a DMA allocation (dma_alloc_coherent). What could be the cause? And how can I somehow
<apritzel> the MMC driver doesn't use DMA anyway
<apritzel> the EMAC DMA still seems to be limited to 32bit anyways
<apritzel> the new MMC controller has its DMA address bits shifted by 2, so can cover 16 GB, but we still keep the DMA mask at 32 bits
<apritzel> IIRC most Linux device use a 32bit DMA mask by default anyway, don't they?
<jernej> unless if drivers don't have dma mask set correctly


<suprothunderbolt> ahh, I had to force tx and rx slots to be different to the tx and rx DMA buffers


<smaeul> wens: jernej: A2DP always uses UART, I2S is only for HSP/HFP, so UART DMA would be quite helpful
<tuxd3v> the uart dma sees nice :)
<megi> UART DMA might also be useful for UART<->modem connection when pushing GPRS data over UART, or other such bulk data uses. But it seems like most of the modems use USB these days anyway. For kernel console use, DMA in UART is force disables for reasons.
<jernej> better would be to sort out I2S, but DMA on UART sounds like an improvement
<wens> if it goes over UART, maybe we should try to hook up DMA for UARTs?


<mripard> and dma_alloc_coherent is supposed to return a coherent buffer
<mripard> paulk-leonov: yeah, vb2-dma-contig relies on dma_alloc_attrs, which works in the same way that dma_alloc_coherent for that case
<apritzel> SdtElectronics: I thought the Allwinner gadget driver does not support DMA at all? So we always use PIO, regardless of that switch?
<SdtElectronics> BTW, I noticed that option "Disable DMA (always use PIO)" is configured in the instructions of that page. I canceled that option in my configuration and everything seem to be just well. I wonder how does that option affect the gadget function, or it is merely due to the lack of support in older kernels?


<apritzel> DMA spoiling continuous bitstreams for some reason, or no DMA generating a small hiccup
<apritzel> mirko: I don't know if DMA is good or bad in your case, could be either way
<apritzel> the driver enables DMA only if the transfer size is bigger than the FIFO
<mirko> apritzel: i'm referencing the HW SPI bus within the spidev dts overlay, so whouldn't this imply DMA?
<apritzel> mirko: you could also check if the driver uses DMA or not, and play around with this


<jernej> mripard: with DE3.3 they introduced optional register DMA - so you set memory location which is then copied to respective registers automatically
<mripard> so yeah, strictly speaking the DE1 vs DE2 is only for the part that does the DMA and blending
<mripard> mostly the "planes" device that does the DMA and blending, the TCON that generates the timings, and (if relevant) the HDMI or DSI controller


<libv> then there are capture engines, which create dma buffers
<willmore> Which lets a kernel driver export a peripherial DMA accessable chunk of memory to user space?


<apritzel> jernej: ah, nice! So the manual is wrong then? We need the DMA address shift even for MMC2?


<apritzel> the manual says the DMA shift is NOT for MMC2, but the A100 code does it for all three


<apritzel> jernej: I forgot to CC: you on one reply to the MMC DMA shift patch, it should be on the list: "Re: [RESEND PATCH 17/19] mmc: sunxi: add support for A100 mmc controller"
<apritzel> jernej: the MMC DMA address shift is already used in the A100, there is already a patch for that on the list


<apritzel> it's not, but it should be DMA_BIT_MASK(34); in any case
<apritzel> jernej: was that "host->dma_mask = DMA_BIT_MASK(64);" line from the BSP?
<apritzel> jernej: yeah, I would hope that Linux would just allow you to allocate DMA buffer bigger than the CMA, when you have a scatter/gather IOMMU driver in place
<apritzel> buZz: for 64-bit we don't have any PAE, and DMA is physical addresses, so: no
<buZz> doesnt PAE help with DMA?
<apritzel> but Linux would have just allocated the DMA buffers from addresses below 4GB anyway
<apritzel> the default dma mask is 32bit, IIRC, so that just allows it to have the buffers between 3GB and 4GB
<jernej> is dma_mask needed? does that assure alignment?
<apritzel> jernej: wait! Did they put word addresses in the DMA descriptors instead of byte addresses, to cover >4GB of DRAM?
<apritzel> jernej: DMA for MMC means the internal/embedded DMA controller in the MMC IP, I think Linux relies on it
<jernej> mmc can work without DMA in linux, right?
<apritzel> (U-Boot does not use DMA)
<apritzel> or they changed some tiny detail somewhere in the DMA part


<bauen1> usually the SPC, SMC and some cpu configuration registers are marked as secure and the DMA is setup correctly


<smaeul> bauen1: no, it doesn't touch the SMC, just the DMA controller, both CCUs, the GIC, and the SPCI


<apritzel> karlp: and you would need to modify all *PCI device* drivers, since they believe they can access those mapped MMIO regions at any time, using some DMA controller, for instance
<apritzel> so *everything* has to be funnelled through this: config space, MMIO, DMA, I/O ...


<bauen1> but it's quite likely that the DMA descriptor is on the stack before the return address so some math and careful creation of an attack image might be required


<linkmauve> Yes, I also tried the one from ALARM which I had been using ever since, neither is setting up the DMA zone correctly (it shows up as “normal” instead).
<linkmauve> A difference I’ve noticed compared to ALARM’s default kernel is that I don’t get a DMA zone range in early boot.
<linkmauve> sun4i-drm display-engine: attempt to add DMA range to existing map


<bauen1> DMA shouldn't be possible if the (presumably existing) SPC is configured correctly


<smaeul> I either need to find a way to switch back to secure from FEL (RMR? second CPU? DMA attack?) or a way to enter FEL without switching to non-secure (brute force the "enter FEL" function address in the SBROM")


<bauen1> after the length has been read the sbrom will load data from the spi nor in 0x8000 increments using dma


<gediz0x539> actually, it goes like this: start_kernel > setup_arch > paging_init > dma_contiguous_remap > iotable_init > create_mapping > alloc_init_pud ...


<jernej> matteoelimo: it seems V3s specifc DMA driver changes are already made in mainline, you just need to add DT node for it
<jernej> also dma dts and drv commits
<jernej> I recently made this work (DMA, I2S, clock fix) for R40 (not pushed anywhere yet)
<jernej> oh, dma is also missing (important for I2S)
<jernej> problem is that there is zero required information - register base, dma channels, clocks, etc.


<tuxd3v> dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported


<rz> bit 6 in reg 0x01C20060 is DMA clock gating enabler
<rz> the fix is simple: in file arch/arm/plat-sunxi/dma.c, in function sw_dma_init() somehting like below should be put:
<rz> if someone is interested, proprietary DMA driver in 3.4-sunxi never initializes its clock, so DMA does not work in some booting schemes (like when booting from eMMC)
<rz> I managed ot six the DMA issue


<montjoie> H6 CryptoEngine convert BE to LE but only for some part of the DMA descriptor


<corecode> does anybody know of the status of dma patches for spi?


<mripard> dma_contig is using the iommu if available
<jernej> mripard: so vb2_dma_contig_memops are ok for iommu too or would be vb2_dma_sg_memops more appropriate for v4l2 m2m drivers?


<jernej> mirko: one way to achieve that (not sure of exact requirements you have) is to export dmabuf fd of cedrus capture buffer and import it as dma buf output buffer in next v4l2 driver


<sensille> i'm running sunxi-64 on an H5. can i use slave spi with dma out of the box?
<anarsoul> hw supports dma
<lvrp16> wens: and I'm assuming musb only support PIO and no DMA right?


<Ashleee> gah which driver am I missing, I have got all the ac200/ac200ephy + relevant i2c driver set up, ac200-ephy logs "DMA mask not set" which is only warning (lol) but the dwmac_sun8i still times out resetting


<corecode> oh, the spi driver only works up to fifo depth? uhu. no dma is no bueno


<megi> I'll also need the internal dma variant for older socs
<anarsoul> megi: are you implementing dma for udc?
<jrosss> plaes: I found some patches on the mailing list, but they don't inspire confidence, probably will roll a custom driver that uses the dma engine and spi core directly
<corecode> oh not all sunxi have full dma support for spi?
<jrosss> I notice in mainline the nand driver uses dma, that should give me a guide i guess
<jrosss> Hi is anyone expert in using SPI via DMA on sun5i (A13) in mainline Linux kernel? Is it possible?


<solderfumes> When using SDIO, the sunxi-mmc driver will use only DMA. This limits the data to 32b aligned address and size.


<megi> though DMA is fast, it's just on the CPU side


<megi> it's the reverse, I have a lot of patches that implement various optimizations around the SD controller (DMA DDR, etc.)


<grey-bit> It almost feels like the driver doesn't use DMA and copies the data byte by byte using CPU...


<tuxd3v> 'DMA mask not set'


<megi> maybe I can change dma memory access priorities somewhere?
<megi> and maybe sometimes the timing of incomming csi frame and rotation and de dma happening at the precisely same time align and the memory bus get overloaded
<megi> everything is basically running on dma
<megi> I'm probably stressing the memory bus somewhat with the rotation engine in/out, csi capture dma, and display dma with 3 different planes and scaling going at the same time, and if priorities don't align right, sometimes mixer will take a hit and disable the layer input


<megi> ah, sun8i-rotate 1020000.rotate: dma_alloc_coherent of size 8294400 failed in dmesg on A64
<megi> it may look different with CSI controller doing DMA at the same time as DRM


<mru> something is attempting to use a misaligned buffer for dma
<solderfumes> sunxi-mmc 4021000.mmc: map DMA failed


<jernej> I don't think this unit takes much memory. Doc says it's just dma engine
<jernej> v4l2 and DRM buffers are backed by dma_buf


<montjoie> so I use the length given by linux for the dma mapping in case of
<megi> most probably H6 also needs smaller DMA transfers just like A64 on MMC2


<montjoie> since I wait the end of task (via irq) and I handle DMA stuff, I cannot read too fast


<megi> probly not, musb driver already has an abstraction over dma for SoC that feature musb hardware
<willmore> megi, can you put a layer of abstraction around the DMA to make the core changes easier and then add the low level DMA on a per-chip or per-chip family level?
<megi> on A83T using mass-storage over USB is limited to 13MiB/s due to lack of DMA, and CPU load is 50% during transfer
<megi> half of the SoCs use internal DMA controller and half the external one
<megi> I'm thinking of adding DMA support to musb-sunx, but Alwwinner doesn't make it easy


<megi> But it makes sense that display BE needs a bit more info for various planes, so DMA implementaion needs to be more complicated
<megi> I'm starting to get DMA on A13. It seems like a mess from afar - sometimes you have to use DMA controller, sometimes it's directly hooked into some module and you set buffer registers inside that module (like in display backend), etc.
<megi> I'm trying to implement DRAM -> DMA -> TCON0 :)
<montjoie> using DMA needs dmamapping and some other checks
<megi> montjoie: is there any reason why sun4i-ss-cipher does not use DMA?


<willmore> montjoie, the encryption engine works like DMA in that it reads data and writes it out somewhere else (or back to the origin), right? Can it read/write from I/O devices like the SATA controller or SD controller? Or does it need to operate only on in-memory buffers?
<montjoie> the ce already do dma
<KotCzarny> and queuing a batch frees cpu from doing the work that was done earlier by dma
<KotCzarny> i think he asks if it works similar to dma


<willmore> Can it be used in place of an existing DMA operation?


<megi> and use it as a glorified DMA based bitbanging interface


<megi> so nevermind, SPL load of u-boot main image still uses DMA
<megi> though DMA can't be used because I couldn't make it work to transfer to SRAM


<megi> KotCzarny: it looks like the epd interface is really kind of simple and can be used with A13's LCD interface, and it also looks like it could be driven directly from dma<->tcon0 without involving any other display engine HW, so the epd driver will be kind of trivial


<megi> but you can probably get away with allocating just 10-20 DMA descriptors for the main u-boot to load from emmc so it may not be that memory hungry
<megi> there's DMA_BUF_MAX_SIZE macro that's need to be changed for those to work
<megi> for dma
<megi> btw, I've written DMA support for u-boot/sunxi-mmc


<dgp> karlp: 64MB of DDR2 in package. SPI NOR for root etc. NOR is memory mapped and has DMA so reading it takes almost no processor cycles
<plaes> devicetree has dma attributes
* dgp notices there doesn't seem to be dma in the sunxi spi drivers


<megi> adding u-boot MMC driver DMA support is another of my fun projects to do, sometime in the undefined future time
<megi> that's partly because u-boot doesn't use DMA


<libv> is the tcon or the hdmi block ever used without a debe attached? at no point do i see the dma bit from the diagram documented, and in our setup, the backend selects one or the other tcon block anyway...


<wens> I think the A20 hdmi audio patch is a bit over complicated though. it's straight DMA, and shouldn't need to go through ASoC
<codekipper> from what I remember it was barfing when allocating DMA


<fALSO> and the IRQ and DMA ports


<z3ntu> anarsoul: So the interrupt number for dma-controller is increasing about 50 per second when playing audio to the modem
<anarsoul> z3ntu: check if DMA is actually pumping any data (/proc/interrupts - check line for DMA)


<Hellsenberg> I think there's more than that: SPI, UART, I2C, some DMA controller as well...


<jernej> clementp[m]: Thanks for taking care of H6 DMA and IR


<DuClare> Also switch to 8-bit gfx if you're stuck with no dma


<hanni76> hi everyone, is there a spec describing DMA assignments for allwinner socs? I mean numbers used in device trees , like this dmas = <&dma 4>, <&dma 4>;


<clementp> I confirm the dma_sun6i isn't enable in the arm64 defconfig
<jernej> DMA is already in defconfig
<clementp> When should we update the arm64/configs/defconfig ? For example jernel in your DMA series should you not add it to the defconfig ?
<jernej> I already send out first version of DMA
<clementp> missing DMA :(
<clementp> [ 3.300477] sun4i-spdif 5093000.spdif: Missing dma channel for stream: 0 [ 3.307380] sun4i-spdif 5093000.spdif: ASoC: pcm constructor failed: -22 [ 3.314128] asoc-simple-card sound_spdif: ASoC: can't create pcm spdif-dit-hifi :-22 Initializing ran[ 3.321883] asoc-simple-card sound_spdif: ASoC: failed to instantiate card -22


<willmore> The answer is "only if the CPU is freakishly slow". Otherwise the CPU will wast more time setting up the crypto, waiting for it to transfer, and having its caches trashed by the DMA.


<willmore> His arguement is that the cost of syncing to an external processor (cache issues, DMA issues, IRQ overhead) outweigh the benefits--unless the CPU is horribly slow.


<MoeIcenowy> is it possible that some DMA happens?


<davidebeatrici> `fbdev`, `wayland`, `x11_dma_buf` or `x11_ump`?


<voodoovood_> [ 0.329947] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP803 found [ 0.332103] axp20x-adc axp813-adc: DMA mask not set [ 0.333273] dcdc1: supplied by regulator-dummy


<voodoovood> 18:49 <vicpt> anarsoul|2: Finally got sound working on A33 tablet board 18:50 <vicpt> what I was missing was basically DMA engine support 18:52 <vicpt> Thought it was enabled by default in sunxi_defconfig 18:53 <anarsoul> vicpt: cool 18:53 <vicpt> anarsoul: Thanks anyway for your help :) 18:53 <anarsoul> vicpt: np


<willmore> angelo_ts, the crypto units on the Allwinner chips are pretty weak--one core of the CPU does a better job and you don't have to suffer the slow small block size performance of setting up DMA, etc.


<vagrantc> but DMA timeout for cipher, cbc-des-sun8i-ce encryption failed with err -14 on test vector ...


<montjoie> I believed that it works because it dma map still the whole key


<KotCzarny> dma? bigger blocks? parallel data processing?


<jernej> wens: mripard: I wrote support for I2S and DMA on H6. Can I send this as one series? (I2S doesn't work without DMA)


<mru> plaes: well, dma over i2c isn't a thing
<plaes> I can see following messages regarding various axp20x subdevices: axp20x-usb-power-supply: DMA mask not set
<montjoie> do you guys, enable DMA-API DEBUG ? if yes do you get random "cpu touching an active dma mapped cacheline" ?


<hanetzer> KotCzarny: failed to request dma is ''normal'' (at least, the same message appears in my archlinuxarm boot which is fully functional)
<KotCzarny> also, 'failed to request dma' maybe it's cma related? (dont know if that applies in rockchip land too)


<catphish> yeah, i think we discussed before that the dma on the a20 backend can be limiting


<Dennboy> I forgot to mention this refers specifically to dma for using spi on the H2+, H3, H5 to enable using high speed adc's and such.
<Dennboy> Hi, I'm trying to get DMA to work on H2+, H3 and H5. I've digged up some patches from 2016 on the sunxi mailing list and ported them to newer mainline kernel (4.14.91-sunxi64), via armbian-next. However, don't get non-zero from dma_set_mask_and_coherent, any idea where to search?


<catphish> i don't fully understand the difference, but it implies that the dma is more efficient to the frontend
<catphish> i read that the frontend has superior dma, so wondered if you could actually get more by adding it into the pipeline


<wens> if you have a system that directly displays the captured frames in an efficient way, i.e. passing dma_buf directly from csi/v4l to drm/kms, then that would work


<catphish> i did wonder if i could use some better functions (neon or dma) do to it


<mickenx> We use the DMA way to access card


<jernej> MoeIcenowy: Do you plan doing DMA support for H6?


<megi> + cedrus 1c0e000.video-codec: dma_alloc_coherent of size 1048576 failed, but that only restates the above


<vtx_linux> Ok, thanks. I've got question regarding GMAC for r40. I've written simple bare-metal driver for r40 gmac, but unfortunately I cannot start any tx or rx dma transfers. I think I set properly GMAC registers GMAC_TX_CTL* but I see no progress in traversing any of rx or tx descriptors. Any suggestions?


<Kamilion> so if the H5 doesn't have the DMA issue, I'll definitely jump on that
<smaeul> the only issues I'm aware of relate to large transfers with DMA, which isn't relevant to flashrom


<timdorohin> parco: what type of blobs? x11_dma_buf or x11_ump?


<vicpt> what I was missing was basically DMA engine support


<micken> MMC adventure goes on. In the a64 manual it states that the dma buffer size for each desc should be a multiple of 4.. Is that like size/4 or just dividable by 4?


<micken> at last working with dma
<micken> still strugling with MMC. Is 37888 som sort of max length for a dma transfer?? If I do a big transfer, thats what actually end up in the bytecounter reg.


<micken> what relation has fifo water level and dma transfer size? The only way I can get reliable dma transfers for mmc is with 8k buffers, and that means slow speed
<micken> I have implemented dma transfers in my mmc driver.. (riscos/pinebook). However CMD23 fails to complete (no cc in rint and recv req in rint). Why do I get recv bit set in rint?


<fALSO> and I now copied the x11-dma-buf libs
<fALSO> well using the fbdev or x11-dma-buf doesnt make any changes
<timdorohin> x11-dma-buf variant


<wens> dont quite understand what is needed to get mali-x11-dma-buf to work


<micken> agraf: the only difference for me is that I don't use DMA


<messpl> (~0.5 ms). Should default driver use DMA configured in the device tree? With DMA I would expect to see at least complete transmission of DMA length.
<messpl> Hello, I have a question related to serial (UART). I am playing with it right now using A33-based board. From device tree I see that uart uses default linux driver, along with DMA configuration. I wrote simple C application that uses termios to access UART. The problem is I can see latnecy when I transmit somthing using UART. I send 128 bytes using write command but using logic analyser i see that data is sent in groups 1-3 bytes with small delays


<lvrp16_> in so far as i know, the dma buf hasn't worked for me


<gab> or look at functions that manipulate videobuf_dma_contig_memory structures
<gab> naggety: you probably want to do DMA mappings, take a look at Documentation/DMA-API.txt and Documentation/DMA-API-HOWTO.txt
<agraf> naggety: probably something with dma in its name ;)


<sensille> Pe3ucTop: the other day we talked about uart speed and dma. you said you were using uart at 12.5MHz. what did you have to do to make it possible?


<beeble> and somewhere at the top of the dtsi is the dma controller
<beeble> sensille: take a look st the dtsi. there you see the compatible you can search for. also the dma channels
<beeble> sensille: it's a designware uart and there is h3/h5 dma support. so should work i guess?
<sensille> i already asked in the morning but didn't get a definitive answer... does anybody know how well dma is supported for the uarts on H5
<Pe3ucTop> sensille: UART buffers at host is ~4k , higher buffers you need to implement in application. UART looks like suport DMA, SPI do not support DMA in mainline.
<sensille> do the drivers already support dma in some way?
<sensille> ah, the spi dma is explained in the dma chapter, and uart can also do dma
<sensille> but it can't dma into the H5's memory
<sensille> beeble: one idea was H5 as spi slave and feed data via DMA
<sensille> and does anyone know what the spi dma can do on the H5?


<f11f12_> The diagram in the manual shows DE0->mux-A->tcon_lcd0->mux-B->LVDS0. I assumed the 'DE0' is 'mixer0', and the mixer0 will run the DMA transfers. I could not find any documentation in the mux-A, my mux-B is probably correct as I can get tcon0 test output to LVDS.


<ElBarto> so it only need dma-buf ? you just load a kernel module and that's it ?


<Pe3ucTop> TheSeven: could you share your findings/code regarding SPI DMA burst setup ? Burst sizes Mem size / Register size ?
<Pe3ucTop> TheSeven: About SPI DMA , my experiaence is that SPI RX transfer is finished when DMA ig marked as finished (not only SPI transfer is finished). But I work with 1 byte burst.


<f11f12> the designware driver has a fixed offset DW_DMA_BASE_OFFSET of 0x1000, but in the memmap there is the hstimer located.


<TheSeven> this time it looks like after ~71 million DMA operations, a single DMA completion IRQ just went missing for no apparent reason
<TheSeven> aaaand of course my DMA thing failed again after several hours


<TheSeven> hmm there aren't really that many findings, other than that DMA has at least 2 bugs when talking to SPI (doesn't like non-incrementing address on RAM side, doesn't like TX and RX bursts at the same time?), and SPI seems to generally fail above 50MHz (and I don't have a fast enough scope yet to check what's going on there)
<TheSeven> half an hour (~2 million DMA ops) and it still hasn't crashed, this is starting to look promising
<TheSeven> but what I'm doing right now is wrapping the SPI and DMA peripherals into a userspace I/O device (that also exposes a contiguous coherent buffer), then using that to pump data to an FPGA from userspace
<TheSeven> hmm so far it's going strong with TX and RX dma watermarks shifted apart by 16 (half a burst)
<TheSeven> maybe I can offset the TX vs. RX DMA bursts by adding half a burst to the RX watermark
<BenG83> I have the problem on RK3328 that SPI DMA is completely broken
<TheSeven> let me play with the DMA trigger thresholds...
<TheSeven> hmm I'm wondering if this may be TX DMA clashing with RX DMA somehow while competing for the SPI peripheral on the bus
<TheSeven> it's always the same resulting state though: TX DMA is finished, SPI TX buffer is empty, SPI transfer size says 4 bytes left (where did those go missing?), SPI RX buffer contains 16 bytes (and would only trigger DMA at 32), RX DMA still wants to receive 52 bytes
<TheSeven> and I don't mean bytes but actual DMA operations
<TheSeven> neither DMA nor SPI really have any error conditions
<TheSeven> it looks like the DMA fails to increment an internal counter or is doing it twice in some race condition
<BenG83> are there flags for DMA errors or sth?
<TheSeven> seems to happen every couple thousand DMA transfers
<TheSeven> hmm I'm having some issues with DMA losing bursts of data


<wens> dma is not supported with sunxi-musb
<DonkeyHotei> is there a dma mode i need to enable?


<Net147> mirko: if you are using x11, you would use x11_dma_buf
<mirko> i see. now i'm still confused with the mali blobs - there is x11_dma_buf, x11_ump and fbdev. using fbdev for all i assume?


<Pe3ucTop> willmore: testing on LicheePi zero = V3s = Sun8iw8p1 , trying to implement SPI DMA , mostly work, but have issues at receive, sometimes firsts 63bytes of 80 byte buffer get random data..
<Pe3ucTop> hi, could anybody comment about DMA - in datasheet for SPI I see Normal and Dedicated DMA , what does this mean and which to chose ??


<amonakov> I'm looking at berlin2 video and dma ip, they use all kinds of unusual TLAs like HBO, BCM, BCH... aargh :)
<wens> basically it signals the DMA controller to continue to transfer data
<amonakov> "dma request"?
<Pe3ucTop> Question about DMA channels : do RX and TX could be at the same channel at one time ?? It's a bit unclear for me.


<Pe3ucTop> mripard: thanks, so if I use spidev for example 2kb transfer, it going use DMA when it's possible ? Is it correct ?
<Pe3ucTop> mripard: thanks for respons, I was waiting for such answer :) , I understand that DMA is at kernel level and is used by drivers directly. I would like any suggestions for easy testing DMA capability of SPI .
<mripard> whether to use DMA or not is a kernel policy
<Pe3ucTop> small correction, curently using spidev_test and modified version of it, did not find anything related to DMA nor in spidev source, nor in spidev_test .
<Pe3ucTop> Could anybody suggest SPI-DMA test program ? I find spi-test , but I doubt if it could help with DMA transfers ?


<montjoie> argh DMA timeout for crypto engine on H6


<sunxi_fan> .. so does anyone tested the libMali.so "X11_dma_buf flavour" ? could that be a different approach for dual head Qt apps?


<KotCzarny> oliv3r: for me it was dying in eternal wait for dma to sram


<apritzel> in the H6 manual there is obvious direct connection between the EMAC and the DRAM, which hints at the the EMAC DMA only works to DRAM
<icenowy[m]> so you must find some way to bypass the DMA
<KotCzarny> since it uses own dma engine to read


<buZz> does H3 have DMA for SPI?


<wens> vendors will pair it with an external system DMA engine
<wens> btw, the "embedded" DMA engine seems to be shit
<victhor> the A33 reference manual says "support the embedded DMA" for the OTG controller, but that obviously doesn't work, given what I was told and additionally CPU usage is quite high when using that port
<wens> there's no dma with otg


<Pe3ucTop> mripard_: Could you please give a link to SPI-DMA branch, I would like to try use it/experimetn a bit with it.


<anarsoul> Pe3ucTop: if V3S is alike other allwinner socs you need cpudai (which is i2s driver), codec dai (sun4i-codec) and analog codec. Make sure that you have DMA driver working


<wens> so you get really fast playback (because dma is constantly sending stuff) but no audio


<marble_visions> i start to suspect that it is x11_dma_buf, and qt5 xcb platform
<marble_visions> the alternatives are x11_ump and x11_dma_buf


<Guest53353> there is a post on lkml saying dma does not work for nand on A33


<anarsoul> DMA driver seems to be fine, tested it with dmatest
<anarsoul> codekipp1r: tried with your a64 audiocodec driver and tried to hook it up to hdmi, it doesn't even start DMA transfer in either case


<mripard> it's up to the dma maintainer to apply them
<Pe3ucTop> Question is , when I see in linux-sunxi google group : request for patch apply, and then some response - patch applied, where I could find those applies ? In hich tree / Git / etc ?? I'm interested in DMA for sun6i ...


<wens> was just looking at the DMA descriptor format, and it crossed my mind


<chrisf_> I'm struggling to get the DMA to work on an H5. What's the status of DMA in mainline for these parts?


<jbk1> host->dma_tl = SUNXI_DMA_TL_SDMMC2;
<jbk1> //host->dma_tl = (0x3<<28)|(15<<16)|240;


<chrisf_> sun6i-dma.c defines the DMA pause bit as BIT(1) but the reference manual says it should be BIT(0). Am I mistaken or is one of them wrong?


<mripard> and afaik, dma-buf doesn't allow you to allocate buffers, but only to share buffers that have already been allocated
<wens> mripard: looks like the backend needs dma-ranges, but I can't figure out how to not use the DMA mapping API and just get it to translate addresses for me
<wens> looks like a physical vs dma address offset issue :/


<Pe3ucTop> Dual bit mode is ~easy to try, but DMA is unknown/hard for me.
<Pe3ucTop> I'm interested in improving code, would be great to have SPI DMA support and to work in Dual bit mode.


<wens> among them, if the codec mod clock isn't enabled, it won't do conversion, won't consume audio samples, and dma won't happen


<beeble> best case with a patch for sun6i-dma.c :) otherwise someone will read it here later
<JBrooksBSI> I've come across two hardware errata not in TRM, one in SPI, another in DMA
<JBrooksBSI> 0x20 is the secure DMA reg
<JBrooksBSI> k. Linux driver bug is in https://github.com/torvalds/linux/blob/master/drivers/dma/sun6i-dma.c line #48. SUN8I_DMA_GATE reg is 0x28 on H5 (and probably H3 too).
<freemangordon> MoeIcenowy: hi! do you have any clue if USB DMA mode should be disabled on A33 in order USB OTG to function?
<freemangordon> Wizzup: I have some vague memories that PIO only mode ahould be enabled and DMA mode disabled, but not really sure


<Putti> MoeIcenowy, I had to change the DMA CMA memory size to 40MB, more than that 33177600 bytes it was complaining about.
<MoeIcenowy> CONFIG_CMA, and maybe CONFIG_DMA_CMA


<smaeul> on A64, LCJS bit 6 controls DMA_MODE_REG(0) for SPI boot: 0 sets it to 0x0c, 1 sets it to 0x00; bit 7 does something similar for a different boot device, but also overrides LCJS_CUSTOM_DMA_WAIT (sets it to 0 in the DMA descriptor)