[PATCH v13 3/6] clk: Make clk API return per-user struct clk instances

[Russell King - ARM Linux]

On Thu, Feb 19, 2015 at 01:32:33PM -0800, Mike Turquette wrote:
> Quoting Stephen Boyd (2015-02-06 11:30:18)
> > On 02/06/15 05:39, Russell King - ARM Linux wrote:
> > > On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> > >
> > >> From what I can tell this code is
> > >> now broken because we made all clk getting functions (there's quite a
> > >> few...) return unique pointers every time they're called. It seems that
> > >> the driver wants to know if extclk and clk are the same so it can do
> > >> something differently in kirkwood_set_rate(). Do we need some sort of
> > >> clk_equal(struct clk *a, struct clk *b) function for drivers like this?
> > > Well, the clocks in question are the SoC internal clock (which is more or
> > > less fixed, but has a programmable divider) and an externally supplied
> > > clock, and the IP has a multiplexer on its input which allows us to select
> > > between those two sources.
> > >
> > > If it were possible to bind both to the same clock, it wouldn't be a
> > > useful configuration - nothing would be gained from doing so in terms of
> > > available rates.
> > >
> > > What the comparison is there for is to catch the case with legacy lookups
> > > where a clkdev lookup entry with a NULL connection ID results in matching
> > > any connection ID passed to clk_get().  If the patch changes this, then
> > > we will have a regression - and this is something which needs fixing
> > > _before_ we do this "return unique clocks".
> > >
> > 
> > Ok. It seems that we might need a clk_equal() or similar API after all.
> > My understanding is that this driver is calling clk_get() twice with
> > NULL for the con_id and then "extclk" in attempts to get the SoC
> > internal clock and the externally supplied clock. If we're using legacy
> > lookups then both clk_get() calls may map to the same clk_lookup entry
> > and before Tomeu's patch that returns unique clocks the driver could
> > detect this case and know that there isn't an external clock. Looking at
> > arch/arm/mach-dove/common.c it seems that there is only one lookup per
> > device and it has a wildcard NULL for con_id so both clk_get() calls
> > here are going to find the same lookup and get a unique struct clk pointer.
> > 
> > Why don't we make the legacy lookup more specific and actually indicate
> > "internal" for the con_id? Then the external clock would fail to be
> > found, but we can detect that case and figure out that it's not due to
> > probe defer, but instead due to the fact that there really isn't any
> > mapping. It looks like the code is already prepared for this anyway.
> > 
> > ----8<----
> > 
> > From: Stephen Boyd <sboyd at codeaurora.org>
> > Subject: [PATCH] ARM: dove: Remove wildcard from mvebu-audio device clk lookup
> > 
> > This i2s driver is using the wildcard nature of clkdev lookups to
> > figure out if there's an external clock or not. It does this by
> > calling clk_get() twice with NULL for the con_id first and then
> > "external" for the con_id the second time around and then
> > compares the two pointers. With DT the wildcard feature of
> > clk_get() is gone and so the driver has to handle an error from
> > the second clk_get() call as meaning "no external clock
> > specified". Let's use that logic even with clk lookups to
> > simplify the code and remove the struct clk pointer comparisons
> > which may not work in the future when clk_get() returns unique
> > pointers.
> > 
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> 
> Russell et al,
> 
> I'm happy to take this patch through the clock tree (where the problem
> shows up) with an ack.

It's not up to me - I don't maintain this driver.  I'm just an interested
party.

Note that much more than just this has now broken.  The iMX6 code has
broken as well, and it's not going to take such a simple fix there to
fix it either.

Please either revert the patches creating this breakage (and have another
attempt at the next merge window) or supply fixes for these places.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.