user/sven/linux.git/drivers/dma/cppi41.c, branch v4.4.29

dmaengine: cppi41: add missing bitfields

2015-04-11T15:42:58Z

Add missing directions, residue_granularity, srd_addr_widths and dst_addr_widths bitfields. Without those we will see a kernel WARN() when loading musb on am335x devices. Signed-off-by: Felipe Balbi Signed-off-by: Vinod Koul

dmaengine: cppi41: Split device_control

2014-12-22T06:58:57Z

Split the device_control callback of the TI CPPI41 DMA driver to make use of the newly introduced callbacks, that will eventually be used to retrieve slave capabilities. Signed-off-by: Maxime Ripard Signed-off-by: Vinod Koul

dma: cppi41: add a delay while setting the TD bit

2014-12-09T09:15:41Z

The manual says that we need to (repeatedly) set the TearDown-bit for the endpoint in order to get the active transfer descriptor released. Doing this "real" quick over and over again seems to work but it also seems that the hardware might not have enough time to breathe. So I though, hey lets add a udelay() between between the individual sets of the bit. This change with the g_zero testcase resulted in a warning about missing transfer descriptor (we got the tear-down one). It seems that if the hardware has some time it manages to release the transfer-descriptor on the completion queue after the teaddown descriptor. With this change, I observe that the transfer descriptor is released after 20-30 retry loops. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Vinod Koul

dma: cppi41: wait longer for the HW to return the descriptor

2014-12-09T09:15:41Z

For a "complete" teardown we have to wait until the teardown descriptor is returned by the hardware. The g_zero testcase "testusb -a -t 9" triggers the following warning quite reliable: |------------[ cut here ]------------ |WARNING: CPU: 0 PID: 0 at drivers/dma/cppi41.c:609 cppi41_dma_control+0x198/0x304() |[] (warn_slowpath_null) from [] |[] (cppi41_dma_control) from [] |[] (cppi41_dma_channel_abort [musb_hdrc]) |[] (nuke.constprop.10 [musb_hdrc]) |[] (musb_gadget_disable [musb_hdrc]) |[] (disable_endpoints [usb_f_ss_lb]) |[] (disable_source_sink [usb_f_ss_lb]) |[] (sourcesink_set_alt [usb_f_ss_lb]) |[] (composite_setup [libcomposite]) |[] (musb_g_ep0_irq [musb_hdrc]) |[] (musb_interrupt [musb_hdrc]) |[] (dsps_interrupt [musb_dsps]) |[] (handle_irq_event_percpu) |[] (handle_irq_event) |[] (handle_level_irq) |[] (generic_handle_irq) |[] (handle_IRQ) |[] (omap3_intc_handle_irq) and complains about a TD descriptor which is not returned. I've been looking at several things and haven't noticed anything unusual that might lead to this. The manual says "to try again" until the descriptor comes out. I limited the amount of retries to 100 retries in order to avoid an infinite number of retries and so a busy-loop. Back then testing revealed that the number of retries were around 20-30 so 100 seemed a good upper limit. This g_zero test reaches without a problem 98 retries and it jumps sometimes to 101 on am335x-evm and so the WARN_ON() triggers. Same test run on beaglebone black and the retries start at 122 and my max value so far was at 128. So lets rise the limit to 500. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Vinod Koul

dmaengine: Remove .owner field for driver

2014-11-06T06:24:18Z

There is no need to init .owner field. Based on the patch from Peter Griffin "mmc: remove .owner field for drivers using module_platform_driver" This patch removes the superflous .owner field for drivers which use the module_platform_driver API, as this is overriden in platform_driver_register anyway." Signed-off-by: Kiran Padwal [for nvidia] Acked-by: Thierry Reding Signed-off-by: Vinod Koul

dma: cppi41: Switch to using managed resource in probe

2014-10-15T14:56:45Z

This change uses managed resource APIs to allocate resources such as, mem, irq in order to simplify the driver unload or failure cases Signed-off-by: Kiran Padwal Signed-off-by: Vinod Koul

dma: cppi41: handle 0-length packets

2014-07-01T06:45:48Z

When a 0-length packet is received on the bus, desc->pd0 yields 1, which confuses the driver's users. This information is clearly wrong and not in accordance to the datasheet, but it's been observed on an AM335x board, very reproducible. Fix this by looking at bit 19 in PD2 of the completed packet. This bit will tell us if a zero-length packet was received on a queue. If it's set, ignore the value in PD0 and report a total length of 0 instead. Signed-off-by: Daniel Mack Signed-off-by: Vinod Koul

dma: cppi41: start tear down only if channel is busy

2014-03-11T10:52:43Z

Start the channel tear down only if the channel is busy, else just bail out. In some cases its seen that by the time the tear down is initiated the cppi completes the DMA, especially in ISOCH transfers. Signed-off-by: George Cherian Signed-off-by: Vinod Koul

drivers/dma: fix error return code

2014-01-20T09:28:03Z

Set the return variable to an error code as done elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Julia Lawall Signed-off-by: Vinod Koul

dma: cppi41: return code > 0 of pm_runtime_get_sync() is not an error

2013-11-12T08:58:25Z

Return code of pm_runtime_get_sync() > 0 is not an error and may happen. Noticed during rmmod & modprobe testing. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Vinod Koul