From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Vinod Koul <vinod.koul@intel.com>
Cc: Andy Gross <andy.gross@linaro.org>,
dmaengine@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
David Brown <david.brown@linaro.org>,
Dan Williams <dan.j.williams@intel.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
yanhe@quicinc.com, ramkri@qti.qualcomm.com, sdharia@quicinc.com
Subject: Re: [PATCH 0/4] dmaengine: qcom: bam_dma: fixes for remotely controlled bam
Date: Wed, 17 Jan 2018 10:55:34 +0000 [thread overview]
Message-ID: <d40a9ecb-c620-034a-8e88-e9254bb95305@linaro.org> (raw)
In-Reply-To: <20180117101835.GM18649@localhost>
On 17/01/18 10:18, Vinod Koul wrote:
> On Tue, Jan 16, 2018 at 07:02:32PM +0000, srinivas.kandagatla@linaro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>
>> Hi Andy,
>>
>> I did hit few issues while trying out SLIMBus BAM on DB820c, this BAM instance
>> is remotely controlled and powered up after ADSP is booted using QMI commands.
>
> What do you mean by "remotely controlled" in this series?
DMA controller is controlled by the remote processor, which is a DSP in
this case.
Linux side is in remote mode in this setup, this can setup transfer
descriptors and start/stop a transfer. But all the
initialization/powerup part will be done in the remote processor.
--srini
>
>>
>> Firstly some of the master registers are written even when the BAM is remotely
>> controlled, and secondly reading registers when bam is not ready yet.
>>
>> These 4 patches address these issues, there are few more issues like doing PM
>> in simillar usecase, these will be addressed soon.
>>
>> Thanks,
>> Srini
>>
>> Srinivas Kandagatla (4):
>> dmaengine: qcom: bam_dma: make bam clk optional
>> dmaengine: qcom: bam_dma: add num-channels binding for remotely
>> controlled
>> dmaengine: qcom: bam_dma: do not write to global regs in remote mode
>> dmaengine: qcom: bam_dma: Add num-ees dt binding for remotely
>> controlled
>>
>> .../devicetree/bindings/dma/qcom_bam_dma.txt | 4 ++
>> drivers/dma/qcom/bam_dma.c | 56 +++++++++++++++-------
>> 2 files changed, 43 insertions(+), 17 deletions(-)
>>
>> --
>> 2.15.1
>>
>
next prev parent reply other threads:[~2018-01-17 10:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-16 19:02 [PATCH 0/4] dmaengine: qcom: bam_dma: fixes for remotely controlled bam srinivas.kandagatla
2018-01-16 19:02 ` [PATCH 1/4] dmaengine: qcom: bam_dma: make bam clk optional srinivas.kandagatla
2018-01-16 19:38 ` Sagar Dharia
2018-01-17 9:46 ` Srinivas Kandagatla
2018-01-19 5:52 ` Vinod Koul
2018-01-22 9:55 ` Srinivas Kandagatla
[not found] ` <8dfa8ba1-6e98-a8e4-614c-592861cef571-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-23 9:19 ` Vinod Koul
2018-01-23 9:20 ` Srinivas Kandagatla
2018-01-16 19:02 ` [PATCH 3/4] dmaengine: qcom: bam_dma: do not write to global regs in remote mode srinivas.kandagatla
2018-01-16 19:02 ` [PATCH 4/4] dmaengine: qcom: bam_dma: Add num-ees dt binding for remotely controlled srinivas.kandagatla
[not found] ` <20180116190236.14558-5-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-29 16:21 ` Rob Herring
2018-01-30 9:18 ` Srinivas Kandagatla
[not found] ` <20180116190236.14558-1-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-16 19:02 ` [PATCH 2/4] dmaengine: qcom: bam_dma: add num-channels " srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A
2018-01-19 5:55 ` Vinod Koul
2018-01-22 9:55 ` Srinivas Kandagatla
[not found] ` <20180116190236.14558-3-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2018-01-29 16:19 ` Rob Herring
2018-01-17 10:18 ` [PATCH 0/4] dmaengine: qcom: bam_dma: fixes for remotely controlled bam Vinod Koul
2018-01-17 10:55 ` Srinivas Kandagatla [this message]
2018-01-17 15:59 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d40a9ecb-c620-034a-8e88-e9254bb95305@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=andy.gross@linaro.org \
--cc=dan.j.williams@intel.com \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ramkri@qti.qualcomm.com \
--cc=robh+dt@kernel.org \
--cc=sdharia@quicinc.com \
--cc=vinod.koul@intel.com \
--cc=yanhe@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).