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 07:33:19 +0000 [thread overview]
Message-ID: <20160818073319.GA18481@gobelin> (raw)
In-Reply-To: <9e47844e-413b-4f85-5fbc-6b73cdd7fade@ti.com>
On Wed, Aug 17, 2016 at 08:15:41PM +0530, Sekhar Nori wrote:
> On Wednesday 17 August 2016 04:03 AM, Karl Beldan wrote:
> > Many davinci boards (da830 and da850 families) don't have their clocks
> > in DT yet and won't be successful in getting an unnamed aemif clock
>
> Actually none of DaVinci platforms have clocks in DT yet.
>
Indeed, I haven't got used to the TI platforms, I mistook some omap SoCs
for davinci ones.
> > without explicitly registering them via clk_lookups, failing the
> > ti-aemif memory driver probe.
>
> I am happy with the patch itself. But I think the terminology used in
> the commit message can be made more accurate. clk_get() does not look up
> a clock by name. It looks up a clock by consumer device and a consumer
> id (used for multiple clocks used by same consumer device). The AEMIF
> clock in DaVinci has a name already. Its assigned in da850.c as "aemif".
> But the clock name itself does not matter in clock lookup.
>
I will be happy to send a more accurate comment, here is my case for the
record and the feedback, although I try to keep my distance from
comments of comments ;).
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 ?
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.
> So, IMO, saying "won't be successful in getting an unnamed aemif clock"
> is inaccurate.
>
You are right, it is innacurate, because in that case it won't try
getting such a clock, ie. by name. Instead it will resort to looking it
up by dev_id / con_id, connecting back with your point.
I will resend the series with this commit message reworded.
Rgds,
Karl
> > The current aemif lookup entry resolving to the same clock:
> > 'CLK(NULL, "aemif", &aemif_clk)'
> > remains, as it is currently used (davinci_nand is getting a named clock
> > "aemif").
>
> So the existing look-up does not recognize the AEMIF as a device (NULL
> device name) and is using a "global" consumer id to look-up
> "device-less" clocks. As you noted, this entry should remain for non-DT
> mode and for backward compatibility.
>
> > This change will allow to switch from the mach-davinci aemif code to
> > the ti-aemif memory driver.
> >
> > Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>
> Thanks,
> Sekhar
next prev parent reply other threads:[~2016-08-18 7:33 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 [this message]
2016-08-18 9:04 ` Russell King - ARM Linux
2016-08-18 11:08 ` Karl Beldan
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=20160818073319.GA18481@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.