Hi Geert,
On 09/17/2014 06:03 PM, Geert Uytterhoeven wrote:
>
> On Tue, Sep 9, 2014 at 3:41 PM, Grygorii Strashko
> wrote:
>>> Since you're essentially gutting clock_ops, have you considered
>>> migrating to genpd and having your own pm_domain ops that manage your
>>> clocks?
>>
>> Yes. I've th
Hi Grygorii,
On Tue, Sep 9, 2014 at 3:41 PM, Grygorii Strashko
wrote:
>> Since you're essentially gutting clock_ops, have you considered
>> migrating to genpd and having your own pm_domain ops that manage your clocks?
>
> Yes. I've thought about using genpd. But:
> - PM domain is not merged in 3.
Hi Grygorii,
On Tue, Sep 9, 2014 at 3:41 PM, Grygorii Strashko
wrote:
>>> Also, It updates Keystone 2 platform code to provide custom
>>> callback which fills list of clocks for Device with all clocks assigned to
>>> this
>>> Device in DT.
>>> More over, It's safe for Keystone 2 to perform CLK P
Hi Kevin,
On 09/09/2014 12:37 AM, Kevin Hilman wrote:
> Grygorii Strashko writes:
>
>> The CLK PM domain (clock_ops.c) assumes that platform code should always
>> provide
>> list of Connection IDs of the clock (con_id) in pm_clk_notifier_block
>> structure.
>> Then CLK PM domain uses these con
Grygorii Strashko writes:
> The CLK PM domain (clock_ops.c) assumes that platform code should always
> provide
> list of Connection IDs of the clock (con_id) in pm_clk_notifier_block
> structure.
> Then CLK PM domain uses these con_ids to setup list of clocks per device.
>
> Such approach is in
Hi,
The CLK PM domain (clock_ops.c) assumes that platform code should always provide
list of Connection IDs of the clock (con_id) in pm_clk_notifier_block structure.
Then CLK PM domain uses these con_ids to setup list of clocks per device.
Such approach is inconvenient when devices can have diffe
6 matches
Mail list logo
