From: Ben Dooks <ben.dooks@codethink.co.uk>
To: linux-sh@vger.kernel.org
Subject: mstp10 clock bug
Date: Wed, 12 Feb 2014 19:01:33 +0000 [thread overview]
Message-ID: <52FBC50D.4000907@codethink.co.uk> (raw)
William and I have been looking at the clock bug on mstp10_clks
from the sound.git patch which reverts all the clocks [1]
What happens is that when register the node:
> - mstp10_clks: mstp10_clks@e6150998 {
> - compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks";
> - reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
> - clocks = <&p_clk>, <&mstp10_clks R8A7790_CLK_SSI>,
> - <&mstp10_clks R8A7790_CLK_SSI>, <&mstp10_clks R8A7790_CLK_SSI>,
> - <&mstp10_clks R8A7790_CLK_SSI>, <&mstp10_clks R8A7790_CLK_SSI>,
> - <&mstp10_clks R8A7790_CLK_SSI>, <&mstp10_clks R8A7790_CLK_SSI>,
> - <&mstp10_clks R8A7790_CLK_SSI>, <&mstp10_clks R8A7790_CLK_SSI>,
> - <&mstp10_clks R8A7790_CLK_SSI>;
> - #clock-cells = <1>;
> - renesas,clock-indices = <
> - R8A7790_CLK_SSI R8A7790_CLK_SSI9 R8A7790_CLK_SSI8
> - R8A7790_CLK_SSI7 R8A7790_CLK_SSI6 R8A7790_CLK_SSI5
> - R8A7790_CLK_SSI4 R8A7790_CLK_SSI3 R8A7790_CLK_SSI2
> - R8A7790_CLK_SSI1 R8A7790_CLK_SSI0
> - >;
> - clock-output-names > - "ssi", "ssi9", "ssi8", "ssi7", "ssi6", "ssi5",
> - "ssi4", "ssi3", "ssi2", "ssi1", "ssi0";
> - };
> };
The ssi5 clock is registered with a parent of ssi5, not ssi as described
in the above node.
This is due to of_clk_get_parent_name() reading the clock-output-names
property and _assuming_ a 1:1 correspondence for the clock index to the
clock-output-names position. In the case of the mstp clocks each of
these nodes has sparse entries, which means the following:
<&mstp10_clks R8A7790_CLK_SSI> R8A7790_CLK_SSI becomes <&mstp10_clks 5>
and the 5th entry in clock-output-names is "ssi5".
This means that the entire machine comes to a halt as the clock layer
tries to create a clock with itself as a parent (never a good idea)
Currently we do not know the best way to fix this.
- we could update the of_clk_get_parent_name() to check the presence of
renesas,clock-indices which would be a hack.
- allow the clock driver to register a parent name callback, but that
would assume we never looked up nodes that where not registered yet.
- change all the clock-output-names arrays for rcar dtsi files to have
null entries where needed, which would be not nice.
- add a new property for mapping numbers to clock indicies and moving
the renesas,clock-indices to use that (although that would still end
up causing a number of issues with the clock handling as is)
> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=topic/rcar&idp8d2aa14d1eefef3dd758242787e837485baad7
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
next reply other threads:[~2014-02-12 19:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-12 19:01 Ben Dooks [this message]
2014-02-13 14:51 ` mstp10 clock bug Laurent Pinchart
2014-02-13 17:43 ` Ben Dooks
2014-02-13 23:03 ` Laurent Pinchart
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=52FBC50D.4000907@codethink.co.uk \
--to=ben.dooks@codethink.co.uk \
--cc=linux-sh@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).