lwn.git/arch/arm/mach-omap2/dma.c, branch docs-5.3

ARM: OMAP2+: make omap_dma_dev_info __initdata

2017-10-02T19:48:53+00:00

Make this __initdata as it is only modified only during the initialisation phase in the function omap2_system_dma_init_dev and after this it is not referenced anywhere in the kernel. Signed-off-by: Bhumika Goyal Signed-off-by: Tony Lindgren

ARM: OMAP2+: Remove unused legacy code for DMA

2017-08-10T15:21:40+00:00

We are now booting all mach-omap2 in device tree only mode. Any code that is only called in legacy boot mode where of_have_populated_dt() is not set is safe to remove now. Let's leave the dummy omap2_system_dma_init_dev() check in place for now to avoid a pointless merge conflict with tusb6010 dmaengine conversion as pointed out by Peter Ujfalusi . Signed-off-by: Tony Lindgren

ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines

2017-06-20T03:45:01+00:00

The external request lines are used by tusb6010 on OMAP24xx platforms. Update the map so the driver can use dmaengine API to request the DMA channel. At the same time add temporary map containing only the external DMA request numbers for DT booted case on omap24xx since the tusb6010 stack is not yet supports DT boot. Signed-off-by: Peter Ujfalusi Acked-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

ARM: OMAP2+: DMA: Provide dma_slave_map to omap-dma for legacy boot

2016-02-22T18:00:50+00:00

We still have some boards booting in legacy mode and they will need to have the device/slave -> filter_fn mapping so we can convert the OMAP drivers to use the new dmaengine API for requesting channels. Only some OMAP24xx and OMAP3xxx boards can boot in legacy mode which means we only need to provide the map for these SoCs. Signed-off-by: Peter Ujfalusi Signed-off-by: Tony Lindgren

ARM: OMAP2+: Remove unnessary return statement from the void function, omap2_show_dma_caps

2015-06-01T22:01:51+00:00

This removes the no longer required return statement at the end of the void function, omap2_show_dma_cap due to no need for a return statement due to this function always running successfully. Signed-off-by: Nicholas Krause Signed-off-by: Tony Lindgren

ARM: OMAP2+: DMA: remove requirement of irq for platform-dma driver

2014-07-22T06:32:51+00:00

we have currently 2 DMA drivers that try to co-exist. drivers/dma/omap-dma.c which registers it's own IRQ and is device tree aware and uses arch/arm/plat-omap/dma.c instance created by arch/arm/mach-omap2/dma.c to maintain channel usage (omap_request_dma). Currently both try to register interrupts and mach-omap2/plat-omap dma.c attempts to use the IRQ number registered by hwmod to register it's own interrupt handler. Now, there is no reasonable way of static allocating DMA irq in GIC SPI when we use crossbar. However, since the dma_chan structure is freed as a result of IRQ not being present due to devm allocation, maintaining information of channel by platform code fails at a later point in time when that region of memory is reused. So, if hwmod does not indicate an IRQ number, then, assume that dma-engine will take care of the interrupt handling. Signed-off-by: Nishanth Menon Signed-off-by: Tony Lindgren

ARM: OMAP2+: raw read and write endian fix

2014-05-08T14:09:53+00:00

All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky Signed-off-by: Taras Kondratiuk Signed-off-by: Tony Lindgren

dmaengine: omap-dma: move register read/writes into omap-dma.c

2014-04-03T23:31:49+00:00

Export the DMA register information from the SoC specific data, such that we can access the registers directly in omap-dma.c, mapping the register region ourselves as well. Rather than calculating the DMA channel register in its entirety for each access, we pre-calculate an offset base address for the allocated DMA channel and then just use the appropriate register offset. Acked-by: Tony Lindgren Acked-by: Vinod Koul Signed-off-by: Russell King

ARM: omap: dma: get rid of 'p' allocation and clean up

2014-04-03T23:31:47+00:00

The omap_system_dma_plat_info structure is only seven words, it's not worth the expense of kmalloc()'ing backing store for this only to release it later. Note that platform_device_add_data() copies the data anyway. Clean up the initialisation of this structure - we don't even need code to initialise most of this structure. Acked-by: Tony Lindgren Signed-off-by: Russell King

ARM: omap: move dma channel allocation into plat-omap code

2014-04-03T23:31:46+00:00

This really needs to be there, because otherwise the plat-omap code can kfree() this data structure, and then re-use the pointer later. Acked-by: Tony Lindgren Signed-off-by: Russell King