From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Georgi Djakov <georgi.djakov@linaro.org>, andy.gross@linaro.org
Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: msm8916: Move smem below hwlock
Date: Tue, 23 Feb 2016 19:28:35 +0000 [thread overview]
Message-ID: <56CCB2E3.9050309@linaro.org> (raw)
In-Reply-To: <56CCA95C.9070207@linaro.org>
On 23/02/16 18:47, Georgi Djakov wrote:
> On 23.02.16 г. 19:29, Srinivas Kandagatla wrote:
>>
>>
>> On 23/02/16 17:21, Georgi Djakov wrote:
>>> When the SMEM is probed it defers as it depends on the hardware lock, which
>>> is not available yet. But the SMD bus and RPM regulators and clocks depend
>>> on SMEM and they defer too. The problem with this is that the order of
>>> registering the devices is not optimal and also we may end with messed
>>> up serial console as the RPM clocks are not registered yet..
>> I noticed the same issue but was wondering why would we end up with messed up serial console?
>>
>> Could you add more details on why serial console is messed up?
>>
>> I thought, serial driver has nothing to do with the rpm clocks directly!
>>
>
> If we don't have the rpm clocks registered, the uart clock is an orphan
> and when clk_get_rate() is called on orphan clocks it returns 0 as rate.
Shouldn't the actual uart clk provider registration fail/defer probe due
to missing parent in this case?
--srini
> In our case the msm_serial driver calls clk_get_rate() and gets 0 rate
> as the parent rpm clock has not registered yet. The result is that the
> baudrate is set incorrectly.
>
> BR,
> Georgi
>
next prev parent reply other threads:[~2016-02-23 19:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 17:21 [PATCH] arm64: dts: msm8916: Move smem below hwlock Georgi Djakov
2016-02-23 17:29 ` Srinivas Kandagatla
2016-02-23 18:47 ` Georgi Djakov
[not found] ` <56CCA95C.9070207-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-02-23 19:03 ` Andy Gross
2016-02-24 10:31 ` Georgi Djakov
2016-02-23 19:28 ` Srinivas Kandagatla [this message]
2016-02-23 20:18 ` Georgi Djakov
2016-02-23 17:39 ` Mark Rutland
2016-02-24 6:00 ` Bjorn Andersson
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=56CCB2E3.9050309@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=andy.gross@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=georgi.djakov@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@vger.kernel.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).