From: kbeldan@baylibre.com (Karl Beldan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/4] ARM: davinci: da8xx-dt: Add ti-aemif lookup for clock matching
Date: Thu, 18 Aug 2016 11:08:14 +0000 [thread overview]
Message-ID: <20160818110814.GA8395@gobelin> (raw)
In-Reply-To: <20160818090437.GR1041@n2100.armlinux.org.uk>
On Thu, Aug 18, 2016 at 10:04:37AM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 18, 2016 at 07:33:19AM +0000, Karl Beldan wrote:
> > Checking clk_get:
> >
> > struct clk *clk_get(struct device *dev, const char *con_id)
> > {
> > [...]
> > if (dev) {
> > struct clk *__of_clk_get_by_name(struct device_node *np,
> > const char *dev_id,
> > const char *name)
> > clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id);
> > [...]
> > }
> > return clk_get_sys(dev_id, con_id);
> > }
> >
> > In DT case the con_id _is_ the clock name, so the assertion "clk_get()
> > does not look up a clock by name" would be false ?
>
> Wrong.
>
> clocks = <&provider 0>, <&provider 1>;
> clock-names = "fck", "ick";
>
> fck = clk_get(dev, "fck");
>
> ick = clk_get(dev, "ick");
>
> Works just the same. The whole point of the string is to identify an
> _individual_ _input_ _to_ _the_ _device_ and not a global clock name.
>
I hope so.
You are matching con_id with _a_ clock name, that's my point.
Maybe my writing 'the clock name' instead of 'a clock name' made you
deduce I was asserting in some way that the clock tree was addressed
by some kind of a unique root namespace via the clock-names ?? It was
not the case ('the' was contextual if that means anything).
> Think what happens if you specify a clock name. Where does that name
> come from? What if the clock is named differently on another SoC?
> With that approach, we need to define a new set of APIs to allow a
> device to determine the global clock name for the clock that it's
> interested in - which is completely absurd when we've already got
> that within clk_get().
>
> The whole point of the clk API is to abstract those differences. That's
> why it takes a _connection_ _id_ and not a clock name.
>
> I really can't understand why people keep getting this wrong in their
> heads. It makes no sense to me for this to take a global clock name.
>
Nope, I am fine with that, it is a convenient scheme.
> > Also, numerous commits refer to *clk_get(*, NULL) as getting an unnamed
> > clock, although it only really is accurate to the point in DT cases.
>
> Table-driven clkdev copes fine with that, and will try to locate an
> appropriate table entry with a NULL connection ID, not matching any
> non-NULL connection ID entry.
>
Yes it does, my change relies on that and I was happy to be able to so.
It is good to see the maintainers like Sekhar and you seizing the
opportunity to throw light on such things.
Karl
> In the DT case, it's always the first specified clock.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
next prev parent reply other threads:[~2016-08-18 11:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-16 22:33 [PATCH v3 0/4] Add DT support for NAND to LCDK via ti-aemif Karl Beldan
2016-08-16 22:33 ` [PATCH v3 1/4] ARM: davinci: da8xx-dt: Add ti-aemif lookup for clock matching Karl Beldan
2016-08-17 14:45 ` Sekhar Nori
2016-08-18 7:33 ` Karl Beldan
2016-08-18 9:04 ` Russell King - ARM Linux
2016-08-18 11:08 ` Karl Beldan [this message]
2016-08-16 22:33 ` [PATCH v3 2/4] ARM: davinci_all_defconfig: Enable AEMIF as a module Karl Beldan
2016-08-17 14:56 ` Sekhar Nori
2016-08-16 22:33 ` [PATCH v3 3/4] ARM: dts: da850, da850-evm: Add an aemif node and use it for the NAND Karl Beldan
2016-08-18 9:25 ` [PATCH v3 3/4] ARM: dts: da850,da850-evm: " Sekhar Nori
2016-08-16 22:33 ` [PATCH v3 4/4] ARM: dts: da850-lcdk: Add NAND to DT Karl Beldan
2016-08-18 17:09 ` [PATCH v3 0/4] Add DT support for NAND to LCDK via ti-aemif Kevin Hilman
2016-08-18 21:15 ` Kevin Hilman
2016-08-19 13:46 ` Karl Beldan
2016-08-19 14:10 ` Sekhar Nori
2016-08-19 17:42 ` Karl Beldan
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=20160818110814.GA8395@gobelin \
--to=kbeldan@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.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).