Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-04 Thread Michael Turquette
Quoting Tero Kristo (2016-01-03 23:36:05) > On 01/01/2016 07:48 AM, Michael Turquette wrote: > > Hi Tero, > > > > Quoting Tero Kristo (2015-12-18 05:58:58) > >> Previously, hwmod core has been used for controlling the hwmod level > >> clocks. This has certain drawbacks, like being unable to share t

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-04 Thread Michael Turquette
Quoting Tero Kristo (2016-01-04 11:15:36) > On 01/04/2016 06:37 PM, Tony Lindgren wrote: > > * Russell King - ARM Linux [160104 06:43]: > >> On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote: > >>> On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote: > FWIW, there are small loops with

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-04 Thread Tero Kristo
On 01/04/2016 06:37 PM, Tony Lindgren wrote: * Russell King - ARM Linux [160104 06:43]: On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote: On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote: FWIW, there are small loops with just a cpu_relax() in various clock drivers under drivers/clk

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-04 Thread Tony Lindgren
* Russell King - ARM Linux [160104 06:43]: > On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote: > > On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote: > > >FWIW, there are small loops with just a cpu_relax() in various clock > > >drivers > > >under drivers/clk/shmobile/. > > > > Just di

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-04 Thread Russell King - ARM Linux
On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote: > On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote: > >FWIW, there are small loops with just a cpu_relax() in various clock drivers > >under drivers/clk/shmobile/. > > Just did a quick profiling round, and the clk_enable/disable delay lo

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-04 Thread Tero Kristo
On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote: Hi Tero, On Mon, Jan 4, 2016 at 8:36 AM, Tero Kristo wrote: On 01/01/2016 07:48 AM, Michael Turquette wrote: Quoting Tero Kristo (2015-12-18 05:58:58) +static int _omap4_hwmod_clk_enable(struct clk_hw *hw) +{ + struct clk_hw_omap *clk =

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-04 Thread Geert Uytterhoeven
Hi Tero, On Mon, Jan 4, 2016 at 8:36 AM, Tero Kristo wrote: > On 01/01/2016 07:48 AM, Michael Turquette wrote: >> Quoting Tero Kristo (2015-12-18 05:58:58) >>> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw) >>> +{ >>> + struct clk_hw_omap *clk = to_clk_hw_omap(hw); >>> + u32 v

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2016-01-03 Thread Tero Kristo
On 01/01/2016 07:48 AM, Michael Turquette wrote: Hi Tero, Quoting Tero Kristo (2015-12-18 05:58:58) Previously, hwmod core has been used for controlling the hwmod level clocks. This has certain drawbacks, like being unable to share the clocks for multiple users, missing usecounting and generall

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2015-12-31 Thread Michael Turquette
Hi Tero, Quoting Tero Kristo (2015-12-18 05:58:58) > Previously, hwmod core has been used for controlling the hwmod level > clocks. This has certain drawbacks, like being unable to share the > clocks for multiple users, missing usecounting and generally being > totally incompatible with common clo

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

2015-12-18 Thread Tony Lindgren
* Tero Kristo [151218 05:57]: > Previously, hwmod core has been used for controlling the hwmod level > clocks. This has certain drawbacks, like being unable to share the > clocks for multiple users, missing usecounting and generally being > totally incompatible with common clock framework. > > Ad

[RFC 6/9] clk: ti: add support for omap4 module clocks

2015-12-18 Thread Tero Kristo
Previously, hwmod core has been used for controlling the hwmod level clocks. This has certain drawbacks, like being unable to share the clocks for multiple users, missing usecounting and generally being totally incompatible with common clock framework. Add support for new clock type under the TI c