On 07/01/2014 10:48 PM, Felipe Balbi wrote:
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
Quoting Tero Kristo (2014-07-03 00:41:22)
On 07/01/2014 10:48 PM, Felipe Balbi wrote:
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes
On Tue, 17 Jun 2014, Tero Kristo wrote:
On 06/17/2014 11:19 AM, Paul Walmsley wrote:
The only case that approached this was with PLLs. PLLs would
automatically be placed into bypass if the PLL rate was set to the bypass
rate.
Someone could argue that this is rather strange approach
On Tue, 17 Jun 2014, Mike Turquette wrote:
Quoting Paul Walmsley (2014-06-17 01:15:09)
On Tue, 17 Jun 2014, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
On Wed, 18 Jun 2014, Paul Walmsley wrote:
I don't disagree that some platforms might want this behavior. But it's
not a safe default, the flag should be the other way around. Rare is the
software engineer that knows whether the clock muxes on their platform are
glitchless.
(beyond all
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes problems on AM43x when
using display and
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes
On Tue, 17 Jun 2014, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
That is just insane.
This is a rather
On Tue, 17 Jun 2014, Tero Kristo wrote:
I am fine with this approach, as it seems pretty much all the other mux-clock
users are setting this flag also. The TI clocks have had this way of using mux
clocks from the legacy times... might just be a design flaw.
The non-CCF clock framework never
On 06/17/2014 11:19 AM, Paul Walmsley wrote:
On Tue, 17 Jun 2014, Tero Kristo wrote:
I am fine with this approach, as it seems pretty much all the other mux-clock
users are setting this flag also. The TI clocks have had this way of using mux
clocks from the legacy times... might just be a
On Tue, Jun 17, 2014 at 11:04:32AM +0300, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous
Quoting Paul Walmsley (2014-06-17 01:15:09)
On Tue, 17 Jun 2014, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
Quoting Tero Kristo (2014-06-17 01:23:31)
On 06/17/2014 11:19 AM, Paul Walmsley wrote:
On Tue, 17 Jun 2014, Tero Kristo wrote:
I am fine with this approach, as it seems pretty much all the other
mux-clock
users are setting this flag also. The TI clocks have had this way of using
mux
15 matches
Mail list logo
