[PATCH 1/2 V3] clk: sirf: add CSR atlas7 clk and reset support
Barry Song
21cnbao at gmail.com
Thu Jun 11 04:46:27 PDT 2015
2015-06-11 5:33 GMT+08:00 Stephen Boyd <sboyd at codeaurora.org>:
> On 06/11, Barry Song wrote:
>> 2015-05-22 5:33 GMT+08:00 Stephen Boyd <sboyd at codeaurora.org>:
>> > On 05/16, Barry Song wrote:
>> >> 2015-05-16 2:30 GMT+08:00 Stephen Boyd <sboyd at codeaurora.org>:
>> >> > On 05/15, Barry Song wrote:
>> >
>> > It isn't really about making boot time faster, it's about using
>> > the proper linux device model for clock providers. That way when
>> > we want to support things like suspend/resume, deferred probe,
>> > devm_*(), sysfs, etc. we can use the device model instead of
>> > resorting to things like syscore_ops for suspend/resume or
>> > forgoing features entirely.
>> >
>>
>> my feeling is if the clock controller is an internal controller which
>> serve all controllers in the SoC, "deferred probe" might be yes for
>> almost all HW since all HW need clock. so it seems it makes "deferred
>> probe" has no meaning. clock controller seems to be 1st HW which needs
>> to be ready.
>
> That sounds like a probe ordering problem, and I agree most
> likely the clock driver will need to probe first in this case. It
> doesn't do anything about other problems like suspend/resume or
> other features that the device model provides solutions for
> though. Maybe we don't use these features, but it doesn't mean we
> should forgo the device model just because we don't need it.
this is generally done by a earlier init like subsys_init, core_init
etc. i agree it is always good to use the bus/driver/device model if
possible.
actually, moving to platform bus still has some deferred probe issue.
it is probably everyone before clk driver need deferred probe.
do you think we are possible to ask for clk even before platform
devices are extended in machine callbacks?
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
-barry
More information about the linux-arm-kernel
mailing list