From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: "Dwivedi, Avaneesh Kumar (avani)" <akdwived@codeaurora.org>
Cc: sboyd@codeaurora.org, agross@codeaurora.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [RESEND PATCH v4 5/7] remoteproc: qcom: Modify reset sequence for hexagon to support v56 1.5.0
Date: Tue, 13 Dec 2016 14:07:30 -0800 [thread overview]
Message-ID: <20161213220730.GK3439@tuxbot> (raw)
In-Reply-To: <d272fc86-8eb1-61e1-1198-4b1e9dba9743@codeaurora.org>
On Tue 13 Dec 11:45 PST 2016, Dwivedi, Avaneesh Kumar (avani) wrote:
> On 12/13/2016 11:39 PM, Bjorn Andersson wrote:
[..]
> >Either way, using the non-_relaxed version of writel() will be
> >equivalent to what you have now.
> Do you mean if writel is used , udelay() should be removed?
No, I mean that looping writel_relaxed() + wmb() is roughly
equivalent to writel(). So with the overall comment of you replacing
readl_relaxed() and writel_relaxed() with their plain readl/writel
counterparts takes care of the wmb().
> i understand
> writel will not return before register write operation is actually done.
> udelay() is to give enough time so that after writel , there is some time
> available to turn on mem peripheral and data array.
As far as I understand, wmb() will ensure that any cache coherent or
write-back buffered writes are committed before any subsequent writes.
But that this is not the same as the write has finished.
As far as I can see, the downstream code (msm-3.18) do:
for (i = 19; i >= 0; i--) {
val |= BIT(i);
writel_relaxed(val, MEM_PWR_CTL);
val |= readl_relaxed(MEM_PWR_CTL);
udelay(1);
}
I.e. for this particular version it actually does read back the value,
which will cause a wait for the write to be propagated. But I'm not sure
why this is the only version doing this.
Regards,
Bjorn
next prev parent reply other threads:[~2016-12-13 22:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 10:00 [RESEND PATCH v4 0/7]remoteproc: qcom: Add support to hexagon v56 1.5.0 in qcom hexagon rproc driver Avaneesh Kumar Dwivedi
2016-11-24 10:00 ` [RESEND PATCH v4 1/7] remoteproc: qcom: Add and initialize private data for hexagon dsp Avaneesh Kumar Dwivedi
2016-12-08 21:37 ` Bjorn Andersson
2016-12-09 11:42 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-09 19:32 ` Bjorn Andersson
2016-11-24 10:00 ` [RESEND PATCH v4 2/7] remoteproc: qcom: Initialize proxy and active clock's and regulator's Avaneesh Kumar Dwivedi
2016-12-09 2:36 ` Bjorn Andersson
2016-12-09 15:53 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 3/7] remoteproc: qcom: Modify regulator enable and disable interface Avaneesh Kumar Dwivedi
2016-12-09 2:44 ` Bjorn Andersson
2016-12-12 8:21 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 4/7] remoteproc: qcom: Modify clock enable and disable routine Avaneesh Kumar Dwivedi
2016-12-09 2:57 ` Bjorn Andersson
2016-12-12 8:23 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 5/7] remoteproc: qcom: Modify reset sequence for hexagon to support v56 1.5.0 Avaneesh Kumar Dwivedi
2016-12-09 4:35 ` Bjorn Andersson
2016-12-12 12:45 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-13 18:09 ` Bjorn Andersson
2016-12-13 19:45 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-13 22:07 ` Bjorn Andersson [this message]
2016-12-14 15:50 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-14 20:13 ` Bjorn Andersson
2016-11-24 10:00 ` [RESEND PATCH v4 6/7] remoteproc: qcom: Modify stop routine to limit MX current for v56 1.5 Avaneesh Kumar Dwivedi
2016-12-09 4:42 ` Bjorn Andersson
2016-12-12 13:04 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 7/7] clk: qcom: Add GCC_MSS_RESET support to reset MSS in v56 1.5.0 Avaneesh Kumar Dwivedi
2016-12-08 19:51 ` Bjorn Andersson
2016-12-12 13:05 ` Dwivedi, Avaneesh Kumar (avani)
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=20161213220730.GK3439@tuxbot \
--to=bjorn.andersson@linaro.org \
--cc=agross@codeaurora.org \
--cc=akdwived@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=sboyd@codeaurora.org \
/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).