- 09 Dec, 2014 4 commits
-
-
Prarit Bhargava authored
Several systems are showing the following stack trace: WARNING: CPU: 0 PID: 2352 at lib/dma-debug.c:1140 check_unmap+0x4ee/0x9e0() ioatdma 0000:00:04.0: DMA-API: device driver failed to check map error[device address=0x0000000465bad000] [size=4096 bytes] [mapped as page] Modules linked in: ioatdma(E+) nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel cdc_ether ses ghash_clmulni_intel usbnet mii enclosure aesni_intel lrw gf128mul glue_helper iTCO_wdt shpchp ablk_helper iTCO_vendor_support cryptd pcspkr ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si i2c_i801 wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt drm_kms_helper ttm igb drm ptp pps_core dca i2c_algo_bit i2ccore megaraid_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ioatdma] CPU: 0 PID: 2352 Comm: insmod Tainted: G E 3.17.0-rc4+ #14 Hardware name: HP ProLiant m300 Server Cartridge/, BIOS H02 01/30/2014 0000000000000009 ffff88007994b7d8 ffffffff816e7225 ffff88007994b820 ffff88007994b810 ffffffff8107e51d ffff88045fc56c00 ffff88046643ee90 ffffffff8338ccd0 0000000000000286 ffffffff81956629 ffff88007994b870 Call Trace: [<ffffffff816e7225>] dump_stack+0x4d/0x66 [<ffffffff8107e51d>] warn_slowpath_common+0x7d/0xa0 [<ffffffff8107e58c>] warn_slowpath_fmt+0x4c/0x50 [<ffffffff81381e6e>] check_unmap+0x4ee/0x9e0 [<ffffffff813823bf>] debug_dma_unmap_page+0x5f/0x70 [<ffffffffa04546d8>] ioat_xor_val_self_test+0x498/0xcf0 [ioatdma] [<ffffffff81204f0a>] ? kfree+0xda/0x2b0 [<ffffffffa044d510>] ? ioat_dma_setup_interrupts+0x120/0x2d0 [ioatdma] [<ffffffffa0454f4e>] ioat3_dma_self_test+0x1e/0x30 [ioatdma] [<ffffffffa044f904>] ioat_probe+0xf4/0x110 [ioatdma] [<ffffffffa04550f8>] ioat3_dma_probe+0x198/0x3a0 [ioatdma] [<ffffffffa044d18e>] ioat_pci_probe+0x11e/0x1b0 [ioatdma] [<ffffffff81393a15>] local_pci_probe+0x45/0xa0 [<ffffffff81394be5>] ? pci_match_device+0xe5/0x110 [<ffffffff81394d29>] pci_device_probe+0xd9/0x130 [<ffffffff81462860>] driver_probe_device+0x90/0x3c0 [<ffffffff81462c63>] __driver_attach+0x93/0xa0 [<ffffffff81462bd0>] ? __device_attach+0x40/0x40 [<ffffffff8146080b>] bus_for_each_dev+0x6b/0xb0 [<ffffffff814622ce>] driver_attach+0x1e/0x20 [<ffffffff81461ed8>] bus_add_driver+0x188/0x260 [<ffffffffa0423000>] ? 0xffffffffa0423000 [<ffffffff81463734>] driver_register+0x64/0xf0 [<ffffffff813933a0>] __pci_register_driver+0x60/0x70 [<ffffffffa0423089>] ioat_init_module+0x89/0x1000 [ioatdma] [<ffffffff8100212c>] do_one_initcall+0xbc/0x200 [<ffffffff811e8b22>] ? __vunmap+0xd2/0x120 [<ffffffff8111e73c>] load_module+0x14ec/0x1b50 [<ffffffff81119970>] ? store_uevent+0x40/0x40 [<ffffffff8111ef36>] SyS_finit_module+0x86/0xb0 [<ffffffff816f1469>] system_call_fastpath+0x16/0x1b ---[ end trace 1052ccbbc3db4d08 ]--- Mapped at: [<ffffffff81380be1>] debug_dma_map_page+0x91/0x140 [<ffffffffa045440e>] ioat_xor_val_self_test+0x1ce/0xcf0 [ioatdma] [<ffffffffa0454f4e>] ioat3_dma_self_test+0x1e/0x30 [ioatdma] [<ffffffffa044f904>] ioat_probe+0xf4/0x110 [ioatdma] [<ffffffffa04550f8>] ioat3_dma_probe+0x198/0x3a0 [ioatdma] This happens because the current ioatdma DMA test code does not check the return value of dma_map_page() calls with dma_mapping_error(). In addition, it was noticed that mapping for the variable dest_dma is free'd before the last use. This patch fixes these errors by initializing the dma_srcs[] array and checking the returns with dma_mapping_error(). Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Sebastian Andrzej Siewior authored
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 <bigeasy@linutronix.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Sebastian Andrzej Siewior authored
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() |[<c003f84c>] (warn_slowpath_null) from [<c02be8d8>] |[<c02be8d8>] (cppi41_dma_control) from [<bf08d25c>] |[<bf08d25c>] (cppi41_dma_channel_abort [musb_hdrc]) |[<bf08bc38>] (nuke.constprop.10 [musb_hdrc]) |[<bf08bd08>] (musb_gadget_disable [musb_hdrc]) |[<bf252524>] (disable_endpoints [usb_f_ss_lb]) |[<bf2525d8>] (disable_source_sink [usb_f_ss_lb]) |[<bf25260c>] (sourcesink_set_alt [usb_f_ss_lb]) |[<bf23ad24>] (composite_setup [libcomposite]) |[<bf08a2f4>] (musb_g_ep0_irq [musb_hdrc]) |[<bf085ec4>] (musb_interrupt [musb_hdrc]) |[<bf0aeaf4>] (dsps_interrupt [musb_dsps]) |[<c0080ea8>] (handle_irq_event_percpu) |[<c008112c>] (handle_irq_event) |[<c008348c>] (handle_level_irq) |[<c00807a8>] (generic_handle_irq) |[<c000ee80>] (handle_IRQ) |[<c00085f0>] (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 <bigeasy@linutronix.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Jingchang Lu authored
The offset of all 8-/16-bit registers in big-endian eDMA model are swapped in a 32-bit size opposite those in the little-endian model. The hardware Scatter/Gather requires the subsequent TCDs stored in memory in little endian independent of the register endian model, the eDMA engine will do the swap if need. This patch also use regular assignment for tcd variables r/w instead of with io function previously that may not always be true. Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
- 08 Dec, 2014 1 commit
-
-
Stefan Agner authored
If the current transfer control descriptor (TCD) was not yet started, the address will be the same as the initial address. Hence test if the current address is less than or equal to the start address of each TCD. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
- 05 Dec, 2014 7 commits
-
-
Michele Curti authored
pch_dma_id_table is used in pch_dma.c only, so declare it as static Signed-off-by: Michele Curti <michele.curti@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Julia Lawall authored
Return a negative error code on failure. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e1,e2; @@ ( if (\(ret < 0\|ret != 0\)) { ... return ret; } | ret = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Sascha Hauer authored
When a firmware cannot be found for the SDMA engine then we can continue with the internal ROM firmware. The meaning of this message is frequently asked for, so make clear that the driver still works with the internal ROM firmware and reduce the loglevel from err to info. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Andreas Färber authored
The specification requires xlnx,data-width, but example and driver use xlnx,datawidth. Change the specification to match the implementation. Reviewed-by: Michal Simek <michal.simek@xilinx.com> Fixes: eebeac03 ("dma: Add Xilinx Video DMA DT Binding Documentation") Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Jassi Brar authored
Update email-id to a personal one, as I have changed employment. Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Vinod Koul authored
Although Documentation explicitly mentions the expectations, the comment in header can be lead to different expectation so clear up the confusion Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Vinod Koul authored
-
- 17 Nov, 2014 22 commits
-
-
Ludovic Desroches authored
same issue as commit 7f5ae355: "Without DMA_PRIVATE the driver is not able to allocate more than one channel. Since it uses dma_get_any_slave_channel that calls private_candidate, the second allocation fails at /* some channels are already publicly allocated */ " Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Ludovic Desroches authored
The dma-cells value in the example was 2 instead of 1. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Ludovic Desroches authored
Lock taken when entering the function but unlock missing before it returns. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Cyrille Pitchen authored
The total size of the transfer was wrong in at_xdmac_prep_slave_sg() resulting in bad computation of the transfer residue by at_xdmac_tx_status(). Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Cyrille Pitchen authored
According to the Atmel eXtended DMA controller datasheet, requesting a DMA transfer flush for a channel is only revelant when this transfer is source peripheral synchronized. So we have to check this condition before requesting a channel flush by writing the channel bit into the Global channel SoftWare Flush (GSWF) register then waiting for flush to complete by monitoring the end of Flush Interrupt Status (FIS) bit in the Channel Interrupt Status (CIS) register. Indeed, for non source peripheral synchronized transfer, writing the channel bit into the GSWF register does nothing. Especially, the FIS bit is never set into the CIS register. The former code looped forever waiting for this bit to be set. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Ludovic Desroches authored
Remove chancnt affectation since it is done in dma_async_device_regiser. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Ludovic Desroches authored
_relaxed version of readl and writel are not implemented on all architecture so COMPILE_TEST has to be removed in order to not cause some build failures. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Vinod Koul authored
As documented in printk-formats.txt the dma_addr_t should be printed with %pad specfiers. This way it works on all archs. make.cross ARCH=s390 All warnings: drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_slave_sg': >> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), ^ >> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] >> drivers/dma/at_xdmac.c:628:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), ^ drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic': >> drivers/dma/at_xdmac.c:663:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), "%s: buf_addr=0x%08x, buf_len=%d, period_len=%d, dir=%s, flags=0x%lx\n", ^ >> drivers/dma/at_xdmac.c:690:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), ^ >> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), ^ >> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] >> drivers/dma/at_xdmac.c:716:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), >> drivers/dma/at_xdmac.c:731:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), ^ drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy': >> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), "%s: src=0x%08x, dest=0x%08x, len=%d, flags=0x%lx\n", ^ >> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), "%s: remaining_size=%u\n", __func__, remaining_size); ^ >> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), ^ >> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] >> drivers/dma/at_xdmac.c:852:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), ^ drivers/dma/at_xdmac.c: In function 'at_xdmac_tx_status': >> drivers/dma/at_xdmac.c:929:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=] dev_dbg(chan2dev(chan), Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Vinod Koul authored
As documented in printk-formats.txt the size_t should be printed with %zu/%zd specfiers. This way it works on all archs. make.cross ARCH=avr32 All warnings: drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic': >> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 6 has type 'size_t' >> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 7 has type 'size_t' drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy': >> drivers/dma/at_xdmac.c:765: warning: format '%d' expects type 'int', but argument 7 has type 'size_t' >> drivers/dma/at_xdmac.c:794: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t' >> drivers/dma/at_xdmac.c:815: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t' Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Vinod Koul authored
This driver uses read_relaxed and writel_relaxed to read, write to IO memory. the config defines COMPILE_TEST so gets compiled on different archs. This causes issue as few archs like x86 etc don't define it. So use readl/writel which is defined in all archs Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
kbuild test robot authored
drivers/dma/at_xdmac.c:702:3-4: Unneeded semicolon Removes unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Jingoo Han authored
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/dma/k3dma.c:790:12: warning: 'k3_dma_suspend' defined but not used [-Wunused-function] drivers/dma/k3dma.c:806:12: warning: 'k3_dma_resume' defined but not used [-Wunused-function] Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Jingoo Han authored
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SET_SYSTEM_SLEEP_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/dma/sirf-dma.c:838:12: warning: 'sirfsoc_dma_pm_suspend' defined but not used [-Wunused-function] drivers/dma/sirf-dma.c:879:12: warning: 'sirfsoc_dma_pm_resume' defined but not used [-Wunused-function] Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Nicolin Chen authored
This patch simply adds a new DMATYPE for SAI which's included in i.MX6 Solo X. Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Yoshihiro Shimoda authored
This patch fixes a race condition about a list of shdma-base driver. If we don't apply this patch, a dma slave driver (especially a usb peripheral driver) may not be able to start the transfer. If a dma slave driver has a callback, __ld_cleanup() will call the callback before this driver removes the list. After the callback, since the return value of __ld_cleanup() is not zero, shdma_chan_ld_cleanup() calls __ld_cleanup() again. And, __ld_clean() will removes the list. At this time, if a dma slave driver calls dmaengine_submit() before this driver removes the list, this driver will set schan->pm_state to SHDMA_PM_PENDING in shdma_tx_submit(). And then, even if a dma slave driver calls dma_async_issue_pending(), this driver don't start the transfer because the schan->pm_state is SHDMA_PM_PENDING in shdma_issue_pending(). So, this patch adds a new condition in __ld_clean() to check if the schan->pm_state is SHDMA_PM_PENDING or not. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Archit Taneja authored
Add compatible string for BAM v1.3.0 in the DT bindings documentation. Mentioned a few more SoCs which have BAM v1.4.0 in them. Reviewed-by: Kumar Gala <galak@codeaurora.org> Reviewed-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Archit Taneja authored
We currently have register offset information only for BAM IPs with revision 1.4.0. We add register offset table entries for the legacy (v1.3.0) version of BAM IPs found on SoCs like APQ8064 and MSM8960. The register offset table pointers are stored in DT data corresponding to the BAM IP version specified in the compatible string. Reviewed-by: Kumar Gala <galak@codeaurora.org> Reviewed-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Archit Taneja authored
The BAM DMA IP comes in different versions. The register offset layout varies among these versions. The layouts depend on which generation/family of SoCs they belong to. The current SoCs(like 8084, 8074) have a layout where the Top level registers come in the beginning of the address range, followed by pipe and event registers. The BAM revision numbers fall above 1.4.0. The older SoCs (like 8064, 8960) have a layout where the pipe registers come first, and the top level come later. These have BAM revision numbers lesser than 1.4.0. It isn't suitable to have macros provide the register offsets with the layouts changed. Future BAM revisions may have different register layouts too. The register addresses are now calculated by referring a table which contains a base offset and multipliers for pipe/evnt/ee registers. We have a common function bam_addr() which computes addresses for all the registers. When computing address of top level/ee registers, we pass 0 to the pipe argument in addr() since they don't have any multiple instances. Some of the unused register definitions are removed. We can add new registers as we need them. Reviewed-by: Kumar Gala <galak@codeaurora.org> Reviewed-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Chen-Yu Tsai authored
The A23 SoC has the same dma engine as the A31 (sun6i), with a reduced amount of endpoints and physical channels. Add the proper config data and compatible string to support it. A slight difference in sun8i is an undocumented register needs to be toggled for dma to function. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Chen-Yu Tsai authored
This patch adds support for hardware parameters tied to compatible strings, so similar hardware can reuse the driver. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Jingoo Han authored
When platform_driver_probe() is not used, sdma_probe() can be called by bind/unbind via sysfs. In addition, sdma_init() can be called by sdma_probe(). Thus, __init annotation should be removed from sdma_init(), Also, this patch fixes section mismatch warning. WARNING: drivers/dma/built-in.o(.text+0xd6e4): Section mismatch in reference from the function sdma_probe() to the function .init.text:sdma_init() The function sdma_probe() references the function __init sdma_init(). This is often because sdma_probe lacks a __init annotation or the annotation of sdma_init is wrong. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Andrew Jackson authored
Commit f6f2421c removed pl330_info structure by embedding it into pl330_dmac structure, but did not ensure that the dmac->ddma.dev pointer gets initialised before use. When dma_alloc_coherent() gets called on arm64 a WARN() gets triggered due to dev being NULL. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at arch/arm64/mm/dma-mapping.c:49 __dma_alloc_coherent+0xd0/0xe0() Use an actual device structure for DMA allocation Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0+ #5 Call trace: [<ffffffc000087f24>] dump_backtrace+0x0/0x130 [<ffffffc000088064>] show_stack+0x10/0x1c [<ffffffc0004e8af8>] dump_stack+0x74/0xb8 [<ffffffc0000aa444>] warn_slowpath_common+0x8c/0xb4 [<ffffffc0000aa4b8>] warn_slowpath_fmt+0x4c/0x58 [<ffffffc000092580>] __dma_alloc_coherent+0xcc/0xe0 [<ffffffc000092734>] __dma_alloc_noncoherent+0x64/0x158 [<ffffffc000312cd8>] pl330_probe+0x650/0x8f0 [<ffffffc00030e1d4>] amba_probe+0xa0/0xc8 [<ffffffc000350240>] really_probe+0xc4/0x22c [<ffffffc0003504b4>] __driver_attach+0xa0/0xa8 [<ffffffc00034e5fc>] bus_for_each_dev+0x54/0x98 [<ffffffc00034fd8c>] driver_attach+0x1c/0x28 [<ffffffc00034fa08>] bus_add_driver+0x14c/0x204 [<ffffffc000350b84>] driver_register+0x64/0x130 [<ffffffc00030dcf8>] amba_driver_register+0x50/0x5c [<ffffffc0006a60d0>] pl330_driver_init+0x10/0x1c [<ffffffc0000814ac>] do_one_initcall+0x88/0x19c [<ffffffc00068dab8>] kernel_init_freeable+0x140/0x1e0 [<ffffffc0004e5e18>] kernel_init+0x10/0xd4 ---[ end trace 76f2d47a444e523e ]--- (NULL device *): dmac_alloc_resources:1821 Can't allocate memory! (NULL device *): Unable to create channels for DMAC This patch will also ensure that any dev_err messages are printed with the appropriate device name. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
- 06 Nov, 2014 6 commits
-
-
Srikanth Thokala authored
This patch modifies the icg field to match the description as mentioned in the DMA Linux framework. Signed-off-by: Srikanth Thokala <sthokal@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Srikanth Thokala authored
This patch adds a sanity check to see if frame_size is 1. Signed-off-by: Srikanth Thokala <sthokal@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Srikanth Thokala authored
The segment list in a descriptor should be checked for empty, else it will try to access invalid address for the first call. This patch fixes this issue. Signed-off-by: Srikanth Thokala <sthokal@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Kiran Padwal authored
There is no need to init .owner field. Based on the patch from Peter Griffin <peter.griffin@linaro.org> "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 <kiran.padwal@smartplayin.com> [for nvidia] Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Maxime Ripard authored
chanctnt is already filled by dma_async_device_register, which uses the channel list to know how much channels there is. Since it's already filled, we can safely remove it from the drivers' probe function. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-
Maxime Ripard authored
chanctnt is already filled by dma_async_device_register, which uses the channel list to know how much channels there is. Since it's already filled, we can safely remove it from the drivers' probe function. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-