#
b9fe0bd5 |
|
17-Aug-2023 |
Kees Cook <keescook@chromium.org> |
dmaengine: qcom: bam_dma: Annotate struct bam_async_desc with __counted_by Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct bam_async_desc. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Vinod Koul <vkoul@kernel.org> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Cc: linux-arm-msm@vger.kernel.org Cc: dmaengine@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230817235859.49846-7-keescook@chromium.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
8d0f1ca5 |
|
19-Sep-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
dmaengine: qcom: bam_dma: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230919133207.1400430-35-u.kleine-koenig@pengutronix.de Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
8975dd41 |
|
19-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
dmaengine: qcom: bam_dma: allow omitting num-{channels,ees} The bam_dma driver needs to know the number of channels and execution environments (EEs) at probe time. If we are in full control of the BAM controller this information can be obtained from the BAM identification registers (BAM_REVISION/BAM_NUM_PIPES). When the BAM is "controlled remotely" it is more complicated. The BAM might not be on at probe time, so reading the registers could fail. This is why the information must be added to the device tree in this case, using "num-channels" and "qcom,num-ees". However, there are also some BAM instances that are initialized by something else but we still have a clock that allows to turn it on when needed. This can be set up in the DT with "qcom,controlled-remotely" and "clocks" and is already supported by the bam_dma driver. Examples for this are the typical BLSP BAM instances on older SoCs, QPIC BAM (for NAND) and the crypto BAM on some SoCs. In this case, there is no need to read "num-channels" and "qcom,num-ees" from the DT. The BAN can be turned on using the clock so we can just read it from the BAM registers like in the normal case. Check for the BAM clock earlier and skip reading "num-channels" and "qcom,num-ees" if it is present to allow simplifying the DT description a bit. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20230518-bamclk-dt-v2-1-a1a857b966ca@gerhold.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
4b23603a |
|
10-Nov-2022 |
Tudor Ambarus <tudor.ambarus@linaro.org> |
dmaengine: drivers: Use devm_platform_ioremap_resource() platform_get_resource() and devm_ioremap_resource() are wrapped up in the devm_platform_ioremap_resource() helper. Use the helper and get rid of the local variable for struct resource *. We now have a function call less. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20221110152528.7821-1-tudor.ambarus@microchip.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
0ac9c3dd |
|
29-Jun-2022 |
Caleb Connolly <caleb.connolly@linaro.org> |
dmaengine: qcom: bam_dma: fix runtime PM underflow Commit dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") caused unbalanced pm_runtime_get/put() calls when the bam is controlled remotely. This commit reverts it and just enables pm_runtime in all cases, the clk_* functions already just nop when the clock is NULL. Also clean up a bit by removing unnecessary bamclk null checks. Suggested-by: Stephan Gerhold <stephan@gerhold.net> Fixes: dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20220629140559.118537-1-caleb.connolly@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
9502ffcd |
|
17-Oct-2021 |
Stephan Gerhold <stephan@gerhold.net> |
dmaengine: qcom: bam_dma: Add "powered remotely" mode In some configurations, the BAM DMA controller is set up by a remote processor and the local processor can simply start making use of it without setting up the BAM. This is already supported using the "qcom,controlled-remotely" property. However, for some reason another possible configuration is that the remote processor is responsible for powering up the BAM, but we are still responsible for initializing it (e.g. resetting it etc). This configuration is quite challenging to handle properly because the power control is handled through separate channels (e.g. device-specific SMSM interrupts / smem-states). Great care must be taken to ensure the BAM registers are not accessed while the BAM is powered off since this results in a bus stall. Attempt to support this configuration with minimal device-specific code in the bam_dma driver by tracking the number of requested channels. Consumers of DMA channels are responsible to only request DMA channels when the BAM was powered on by the remote processor, and to release them before the BAM is powered off. When the first channel is requested the BAM is initialized (reset) and it is also put into reset when the last channel was released. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20211018102421.19848-3-stephan@gerhold.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
123935a4 |
|
26-Jan-2021 |
Thara Gopinath <thara.gopinath@linaro.org> |
dmaengine: qcom: bam_dma: Manage clocks when controlled_remotely is set When bam dma is "controlled remotely", thus far clocks were not controlled from the Linux. In this scenario, Linux was disabling runtime pm in bam dma driver and not doing any clock management in suspend/resume hooks. With introduction of crypto engine bam dma, the clock is a rpmh resource that can be controlled from both Linux and TZ/remote side. Now bam dma clock is getting enabled during probe even though the bam dma can be "controlled remotely". But due to clocks not being handled properly, bam_suspend generates a unbalanced clk_unprepare warning during system suspend. To fix the above issue and to enable proper clock-management, this patch enables runtim-pm and handles bam dma clocks in suspend/resume hooks if the clock node is present irrespective of controlled_remotely property. Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20210126211859.790892-1-thara.gopinath@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
ba42f61b |
|
16-Dec-2020 |
Zheng Yongjun <zhengyongjun3@huawei.com> |
qcom: bam_dma: Delete useless kfree code The parameter of kfree function is NULL, so kfree code is useless, delete it. Therefore, goto expression is no longer needed, so simplify it. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20201216130649.13979-1-zhengyongjun3@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
4421fe53 |
|
06-Dec-2020 |
Parth Y Shah <sparth1292@gmail.com> |
dmaengine: bam_dma: fix return of bam_dma_irq() While performing suspend/resume, we were getting below kernel crash. [ 54.541672] [FTS][Info]gesture suspend... [ 54.605256] [FTS][Error][GESTURE]Enter into gesture(suspend) failed! [ 54.605256] [ 58.345850] irq event 10: bogus return value fffffff3 ...... [ 58.345966] [<ffff0000080830f0>] el1_irq+0xb0/0x124 [ 58.345971] [<ffff000008085360>] arch_cpu_idle+0x10/0x18 [ 58.345975] [<ffff0000081077f4>] do_idle+0x1ac/0x1e0 [ 58.345979] [<ffff0000081079c8>] cpu_startup_entry+0x20/0x28 [ 58.345983] [<ffff000008a80ed0>] rest_init+0xd0/0xdc [ 58.345988] [<ffff0000091c0b48>] start_kernel+0x390/0x3a4 [ 58.345990] handlers: [ 58.345994] [<ffff0000085120d0>] bam_dma_irq The reason for the crash we found is, bam_dma_irq() was returning negative value when the device resumes in some conditions. In addition, the irq handler should have one of the below return values. IRQ_NONE interrupt was not from this device or was not handled IRQ_HANDLED interrupt was handled by this device IRQ_WAKE_THREAD handler requests to wake the handler thread Therefore, to resolve this crash, we have changed the return value to IRQ_NONE. Signed-off-by: Parth Y Shah <sparth1292@gmail.com> Link: https://lore.kernel.org/r/1607322820-7450-1-git-send-email-sparth1292@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
a5e399a5 |
|
07-Oct-2020 |
Vinod Koul <vkoul@kernel.org> |
dmaengine: qcom: bam_dma: fix kernel-doc style for tasklet Commit 00c4747a2f64 ("dmaengine: qcom: convert tasklets to use new tasklet_setup() API") updated driver to use new tasklet_setup() API but missed to update the documentation for the tasklet function. Fixes: 00c4747a2f64 ("dmaengine: qcom: convert tasklets to use new tasklet_setup() API") Link: https://lore.kernel.org/r/20201007083113.567559-3-vkoul@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
00c4747a |
|
31-Aug-2020 |
Allen Pais <allen.lkml@gmail.com> |
dmaengine: qcom: convert tasklets to use new tasklet_setup() API In preparation for unconditionally passing the struct tasklet_struct pointer to all tasklet callbacks, switch to using the new tasklet_setup() and from_tasklet() to pass the tasklet pointer explicitly. Signed-off-by: Romain Perier <romain.perier@gmail.com> Signed-off-by: Allen Pais <allen.lkml@gmail.com> Link: https://lore.kernel.org/r/20200831103542.305571-23-allen.lkml@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
4e06de43 |
|
03-Sep-2020 |
Robin Murphy <robin.murphy@arm.com> |
dmaengine: qcom: bam_dma: Drop local dma_parms Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices"), struct platform_device already provides a dma_parms structure, so we can save allocating another one. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/60ac2ef17e242dbf631db29ebde9d64d6df67030.1599164692.git.robin.murphy@arm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
c18b5bde |
|
08-May-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
dmaengine: qcom: bam_dma: Replace zero-length array with flexible-array The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200508210707.GA24136@embeddedor Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
76678193 |
|
17-Oct-2019 |
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> |
dmaengine: qcom: bam_dma: Fix resource leak bam_dma_terminate_all() will leak resources if any of the transactions are committed to the hardware (present in the desc fifo), and not complete. Since bam_dma_terminate_all() does not cause the hardware to be updated, the hardware will still operate on any previously committed transactions. This can cause memory corruption if the memory for the transaction has been reassigned, and will cause a sync issue between the BAM and its client(s). Fix this by properly updating the hardware in bam_dma_terminate_all(). Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver") Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
f6034225 |
|
28-Jun-2019 |
Sricharan R <sricharan@codeaurora.org> |
dmaengine: qcom: bam_dma: Fix completed descriptors count One space is left unused in circular FIFO to differentiate 'full' and 'empty' cases. So take that in to account while counting for the descriptors completed. Fixes the issue reported here, https://lkml.org/lkml/2019/6/18/669 Cc: stable@vger.kernel.org Reported-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Sricharan R <sricharan@codeaurora.org> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
97fb5e8d |
|
29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 284 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 and only version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 294 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141900.825281744@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
edd3c389 |
|
04-Jan-2019 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
dmaengine: qcom: bam_dma: use struct_size() in kzalloc() One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
9c3655cb |
|
17-May-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
dmaengine: qcom: bam_dma: fix some doc warnings. Building kernel with W=1 throws up below warnings: bam_dma.c:459: warning: Function parameter or member 'dir' not described in 'bam_chan_init_hw' bam_dma.c:697: warning: Function parameter or member 'chan' not described in 'bam_dma_terminate_all' bam_dma.c:697: warning: Excess function parameter 'bchan' description in 'bam_dma_terminate_all' bam_dma.c:964: warning: Function parameter or member 'bchan' not described in 'bam_start_dma' Fix these!. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
5c63de1e |
|
17-May-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
dmaengine: qcom: bam_dma: fix invalid assignment warning Building kernel with W=1 throws below invalid assignment warnings. bam_dma.c:676:44: warning: invalid assignment: += bam_dma.c:676:44: left side has type unsigned long bam_dma.c:676:44: right side has type restricted __le16 bam_dma.c:921:41: warning: invalid assignment: += bam_dma.c:921:41: left side has type unsigned long bam_dma.c:921:41: right side has type restricted __le16 Fix them!. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
dbad41e7 |
|
17-May-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
dmaengine: qcom: bam_dma: check if the runtime pm enabled Disabling pm runtime at probe is not sufficient to get BAM working on remotely controller instances. pm_runtime_get_sync() would return -EACCES in such cases. So check if runtime pm is enabled before returning error from bam functions. Fixes: 5b4a68952a89 ("dmaengine: qcom: bam_dma: disable runtime pm on remote controlled") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
#
5b4a6895 |
|
14-Feb-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
dmaengine: qcom: bam_dma: disable runtime pm on remote controlled Remotely controlled BAM instance should not do any power management from CPU side, as cpu can not reliably say if the BAM is busy or not. Disable it for such instances. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
54eb5e26 |
|
14-Feb-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
dmaengine: qcom: bam_dma: do not write to global regs in remote mode BAM_DESC_CNT_TRSHLD register is global register, which can only be written when BAM is in master mode, So check the mode of operation before writing it. Without this check SOC's xPU would catch such access and crash the system. First noticed on DB820c while testing SLIMBus BAM. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
48d163b1 |
|
14-Feb-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
dmaengine: qcom: bam_dma: get num-channels and num-ees from dt When Linux is master of BAM, it can directly read registers to know number of supported channels, however when its remotely controlled reading these registers would trigger a crash if the BAM is not yet initialized or powered up on the remote side. This patch allows driver to read num-channels and num-ees from Device Tree for remotely controlled BAM. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
9d31821f |
|
14-Feb-2018 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
dmaengine: qcom: bam_dma: make bam clk optional When BAM is remotely controlled it does not sound correct to control its clk on Linux side. Make it optional, so that its not mandatory for remote controlled BAM instances. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
6b4faeac |
|
28-Aug-2017 |
Sricharan R <sricharan@codeaurora.org> |
dmaengine: qcom-bam: Process multiple pending descriptors The bam dmaengine has a circular FIFO to which we add hw descriptors that describes the transaction. The FIFO has space for about 4096 hw descriptors. Currently we add one descriptor and wait for it to complete with interrupt and then add the next pending descriptor. In this way, the FIFO is underutilized since only one descriptor is processed at a time, although there is space in FIFO for the BAM to process more. Instead keep adding descriptors to FIFO till its full, that allows BAM to continue to work on the next descriptor immediately after signalling completion interrupt for the previous descriptor. Also when the client has not set the DMA_PREP_INTERRUPT for a descriptor, then do not configure BAM to trigger a interrupt upon completion of that descriptor. This way we get a interrupt only for the descriptor for which DMA_PREP_INTERRUPT was requested and there signal completion of all the previous completed descriptors. So we still do callbacks for all requested descriptors, but just that the number of interrupts are reduced. CURRENT: ------ ------- --------------- |DES 0| |DESC 1| |DESC 2 + INT | ------ ------- --------------- | | | | | | INTERRUPT: (INT) (INT) (INT) CALLBACK: (CB) (CB) (CB) MTD_SPEEDTEST READ PAGE: 3560 KiB/s MTD_SPEEDTEST WRITE PAGE: 2664 KiB/s IOZONE READ: 2456 KB/s IOZONE WRITE: 1230 KB/s bam dma interrupts (after tests): 96508 CHANGE: ------ ------- ------------- |DES 0| |DESC 1 |DESC 2 + INT | ------ ------- -------------- | | (INT) (CB for 0, 1, 2) MTD_SPEEDTEST READ PAGE: 3860 KiB/s MTD_SPEEDTEST WRITE PAGE: 2837 KiB/s IOZONE READ: 2677 KB/s IOZONE WRITE: 1308 KB/s bam dma interrupts (after tests): 58806 Signed-off-by: Sricharan R <sricharan@codeaurora.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Tested-by: Abhishek Sahu <absahu@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
749d0d4b |
|
01-Aug-2017 |
Abhishek Sahu <absahu@codeaurora.org> |
dmaengine: qcom: bam_dma: add command descriptor flag If DMA_PREP_CMD flag is passed in prep_slave_sg then peripheral driver has passed the data is in BAM command descriptor format and BAM driver should set CMD bit for each of the HW descriptors. Signed-off-by: Abhishek Sahu <absahu@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
184f337e |
|
04-Jul-2016 |
Arnd Bergmann <arnd@arndb.de> |
dmaengine: qcom-bam-dma: add __maybe_unused annotations for PM The bam_dma driver gained runtime PM support, but that causes build warnings whenever CONFIG_PM is disabled: drivers/dma/qcom/bam_dma.c:1324:12: error: 'bam_dma_runtime_resume' defined but not used [-Werror=unused-function] static int bam_dma_runtime_resume(struct device *dev) ^~~~~~~~~~~~~~~~~~~~~~ drivers/dma/qcom/bam_dma.c:1315:12: error: 'bam_dma_runtime_suspend' defined but not used [-Werror=unused-function] static int bam_dma_runtime_suspend(struct device *dev) This removes the incomplete #ifdef guard and instead marks all four PM functions as __maybe_unused, which avoids this kind of warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 7d2545599f5b ("dmaengine: qcom-bam-dma: Add pm_runtime support") Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
7d254559 |
|
17-Jun-2016 |
Pramod Gurav <pramod.gurav@linaro.org> |
dmaengine: qcom-bam-dma: Add pm_runtime support Adds pm_runtime support for BAM DMA so that clock is enabled only when there is a transaction going on to help save power. Signed-off-by: Pramod Gurav <pramod.gurav@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
5ad3f29f |
|
11-Apr-2016 |
Stanimir Varbanov <stanimir.varbanov@linaro.org> |
dmaengine: qcom: bam_dma: rename BAM_MAX_DATA_SIZE define It seems that the define has not been with acurate name and makes confusion while reading the code. The more acurate name should be BAM_FIFO_SIZE. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
2a663ed9 |
|
11-Apr-2016 |
Stanimir Varbanov <stanimir.varbanov@linaro.org> |
dmaengine: qcom: bam_dma: use correct pipe FIFO size The pipe fifo size register must instruct the bam hw how many hw descriptors can be pushed to fifo. Currently we instruct the hw with 32KBytes but wrap the tail in bam_start_dma in BAM_P_EVNT_REG on 4095 i.e. 32760. This leads to stalled transactions when the tail wraps. Fix this by use the correct fifo size in BAM_P_FIFO_SIZES register i.e. 32K - 8. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
5172c9eb |
|
11-Apr-2016 |
Stanimir Varbanov <stanimir.varbanov@linaro.org> |
dmaengine: qcom: bam_dma: add controlled-remotely dt property Some of the peripherals has bam which is controlled by remote processor, thus the bam dma driver must avoid register writes which initialise bam hw block. Those registers are protected from xPU block and any writes to them will lead to secure violation and system reboot. Adding the contolled_remotely flag in bam driver to avoid not permitted register writes in bam_init function. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Tested-by: Pramod Gurav <gpramod@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
f89117c0 |
|
11-Apr-2016 |
Stanimir Varbanov <stanimir.varbanov@linaro.org> |
dmaengine: qcom: bam_dma: clear BAM interrupt only if it is raised Currently we write BAM_IRQ_CLR register with zero even when no BAM_IRQ occured. This write has some bad side effects when the BAM instance is for the crypto engine. In case of crypto engine some of the BAM registers are xPU protected and they cannot be controlled by the driver. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Tested-by: Pramod Gurav <gpramod@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
f139f978 |
|
11-Apr-2016 |
Stanimir Varbanov <stanimir.varbanov@linaro.org> |
dmaengine: qcom: bam_dma: fix dma free memory on remove Building the driver as a module and when removing the already inserted module gives below: [ 1389.392788] Unable to handle kernel paging request at virtual address ffffffbdc000001c [ 1389.421321] pgd = ffffffc02fa87000 [ 1389.447899] [ffffffbdc000001c] *pgd=0000000000000000, *pud=0000000000000000 [ 1389.460142] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 1389.466963] Modules linked in: qcom_bam_dma(-) [ 1389.486608] CPU: 2 PID: 2442 Comm: rmmod Not tainted 4.2.0+ #407 [ 1389.493885] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 1389.501196] task: ffffffc035bae2c0 ti: ffffffc0368a8000 task.ti: ffffffc0368a8000 [ 1389.508566] PC is at __free_pages+0xc/0x40 [ 1389.515893] LR is at free_pages.part.93+0x30/0x38 [ 1389.523141] pc : [<ffffffc00016180c>] lr : [<ffffffc00016197c>] pstate: 80000145 [ 1389.530602] sp : ffffffc0368abc20 [ 1389.537931] x29: ffffffc0368abc20 x28: ffffffc0368a8000 [ 1389.549153] x27: 0000000000000000 x26: 0000000000000000 [ 1389.560412] x25: ffffffc000cb2000 x24: 0000000000000170 [ 1389.571530] x23: 0000000000000004 x22: ffffffc036bc5010 [ 1389.582721] x21: ffffffc036bc5010 x20: 0000000000000000 [ 1389.593981] x19: 0000000000000002 x18: 0000007fcbc8e8b0 [ 1389.605301] x17: 0000007f9b8226ec x16: ffffffc0002089e8 [ 1389.616647] x15: 0000007f9b8a0588 x14: 0ffffffffffffffc [ 1389.628039] x13: 0000000000000030 x12: 0000000000000000 [ 1389.639436] x11: 0000000000000008 x10: ffffffc000ecc000 [ 1389.650872] x9 : ffffffc035bae2c0 x8 : ffffffc035bae9a8 [ 1389.662367] x7 : ffffffc035bae9a0 x6 : 0000000000000000 [ 1389.673906] x5 : ffffffbdc000001c x4 : 0000000080000000 [ 1389.685475] x3 : ffffffbdc0000000 x2 : 0000004080000000 [ 1389.697049] x1 : 0000000000000003 x0 : ffffffbdc0000000 The memory has been already freed by bam_free_chan() so fix this by skiping already freed memory. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
#
d9b31efc |
|
04-Feb-2016 |
Sinan Kaya <okaya@codeaurora.org> |
dmaengine: qcom_bam_dma: move to qcom directory Creating a QCOM directory for all QCOM DMA source files. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> Reviewed-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|