Re: [PATCH 1/2] clk: sunxi: delay protected clocks until arch initcall

["Heiko Stübner" <heiko@sntech.de>]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

Am Mittwoch, 27. Januar 2016, 21:38:16 schrieb Maxime Ripard:
> Hi,
> 
> On Wed, Jan 27, 2016 at 05:14:17PM +0100, Heiko Stübner wrote:
> > Hi,
> > 
> > Am Mittwoch, 27. Januar 2016, 16:37:22 schrieb Maxime Ripard:
> > > I thought the patches were simply dropped and the
> > > rockchip people just took another approach.
> > 
> > nope still on track ... especially as it was Stephen's believe that
> > orphans
> > shouldn't even be usable to general clock users :-).
> > 
> > I just remember that the proposed general solution was based on Mike's
> > upcoming generic critical clock handling (the handoff thingy), which would
> > move critical clock handling out of architecture-specific code, so I've
> > been prodding Mike mainly.
> > 
> > Another option might be to allow clock-controllers to handle orphans and
> > only deny orphan usage to outside clock users, maybe expanding on what I
> > did with the clock-conf part in patch2.
> 
> I'm not sure that would solve anything in our case. All our clocks
> drivers are different ones, so I'm not sure how we could handle that.

the core issue is, that a clk_get on an orphan is going to return EPROBE_DEFER 
after the second patch, which is also true for sunxi critical clocks.

The clock-conf has the same issue in the case where you know on the board-
level that a clock will stay orphaned indefinitly and want to reparent it away 
to some sane parent.

That's why I added of_clk_get_from_provider_with_orphans() (limited to use in 
the ccf) in the second patch to allow orphans to be reparented via assigned-
clocks foo. In theory one could argue that clock controller generally know 
what they're doing and add something like clk_get_with_orphans() or whatever 
that might be called then.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]