On Thu, Feb 19, 2015 at 01:32:33PM -0800, Mike Turquette wrote:
> Quoting Stephen Boyd (2015-02-06 11:30:18)
> > On 02/06/15 05:39, Russell King - ARM Linux wrote:
> > > On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> > >
> > >> From what I can tell this code is
> > >> now broken
On Thu, Feb 19, 2015 at 01:32:33PM -0800, Mike Turquette wrote:
Quoting Stephen Boyd (2015-02-06 11:30:18)
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made
Quoting Stephen Boyd (2015-02-06 11:30:18)
> On 02/06/15 05:39, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> >
> >> From what I can tell this code is
> >> now broken because we made all clk getting functions (there's quite a
> >> few...)
Quoting Stephen Boyd (2015-02-06 11:30:18)
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique
On 02/06/15 11:37, Russell King - ARM Linux wrote:
> On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
>> Why don't we make the legacy lookup more specific and actually indicate
>> "internal" for the con_id? Then the external clock would fail to be
>> found, but we can detect that case
On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
> Why don't we make the legacy lookup more specific and actually indicate
> "internal" for the con_id? Then the external clock would fail to be
> found, but we can detect that case and figure out that it's not due to
> probe defer, but
On 02/06/15 05:39, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
>
>> From what I can tell this code is
>> now broken because we made all clk getting functions (there's quite a
>> few...) return unique pointers every time they're called. It seems
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
> On 02/05/15 16:42, Russell King - ARM Linux wrote:
> > On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
> >> Actually we can bury the __clk_create_clk() inside
> >> __of_clk_get_from_provider(). We should also move
On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
Why don't we make the legacy lookup more specific and actually indicate
internal for the con_id? Then the external clock would fail to be
found, but we can detect that case and figure out that it's not due to
probe defer, but
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique pointers every time they're called. It seems that
the
On 02/06/15 11:37, Russell King - ARM Linux wrote:
On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote:
Why don't we make the legacy lookup more specific and actually indicate
internal for the con_id? Then the external clock would fail to be
found, but we can detect that case and
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
On 02/05/15 16:42, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
Actually we can bury the __clk_create_clk() inside
__of_clk_get_from_provider(). We should also move __clk_get()
On 02/05/15 16:42, Russell King - ARM Linux wrote:
> On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
>> Actually we can bury the __clk_create_clk() inside
>> __of_clk_get_from_provider(). We should also move __clk_get() into there
>> because right now we have a hole where whoever
On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
> Actually we can bury the __clk_create_clk() inside
> __of_clk_get_from_provider(). We should also move __clk_get() into there
> because right now we have a hole where whoever calls
> of_clk_get_from_provider() never calls __clk_get()
On 02/05/15 12:07, Stephen Boyd wrote:
> On 02/05/15 11:44, Sylwester Nawrocki wrote:
>> Hi Tomeu,
>>
>> On 23/01/15 12:03, Tomeu Vizoso wrote:
>>> int __clk_get(struct clk *clk)
>>> {
>>> - if (clk) {
>>> - if (!try_module_get(clk->owner))
>>> + struct clk_core *core = !clk ? NULL
On 02/05/15 11:44, Sylwester Nawrocki wrote:
> Hi Tomeu,
>
> On 23/01/15 12:03, Tomeu Vizoso wrote:
>> int __clk_get(struct clk *clk)
>> {
>> -if (clk) {
>> -if (!try_module_get(clk->owner))
>> +struct clk_core *core = !clk ? NULL : clk->core;
>> +
>> +if (core) {
>> +
On 05/02/15 20:44, Sylwester Nawrocki wrote:
>> +void __clk_put(struct clk *clk)
>> > +{
>> > + if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
>> > + return;
>> > +
>> > + clk_core_put(clk->core);
>> > + kfree(clk);
>
> Why do we have kfree() here? clk_get() doesn't allocate the data structure
Hi Tomeu,
On 23/01/15 12:03, Tomeu Vizoso wrote:
> int __clk_get(struct clk *clk)
> {
> - if (clk) {
> - if (!try_module_get(clk->owner))
> + struct clk_core *core = !clk ? NULL : clk->core;
> +
> + if (core) {
> + if (!try_module_get(core->owner))
>
On 02/05/15 12:07, Stephen Boyd wrote:
On 02/05/15 11:44, Sylwester Nawrocki wrote:
Hi Tomeu,
On 23/01/15 12:03, Tomeu Vizoso wrote:
int __clk_get(struct clk *clk)
{
- if (clk) {
- if (!try_module_get(clk-owner))
+ struct clk_core *core = !clk ? NULL : clk-core;
+
+ if
On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
Actually we can bury the __clk_create_clk() inside
__of_clk_get_from_provider(). We should also move __clk_get() into there
because right now we have a hole where whoever calls
of_clk_get_from_provider() never calls __clk_get() on
On 02/05/15 16:42, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
Actually we can bury the __clk_create_clk() inside
__of_clk_get_from_provider(). We should also move __clk_get() into there
because right now we have a hole where whoever calls
Hi Tomeu,
On 23/01/15 12:03, Tomeu Vizoso wrote:
int __clk_get(struct clk *clk)
{
- if (clk) {
- if (!try_module_get(clk-owner))
+ struct clk_core *core = !clk ? NULL : clk-core;
+
+ if (core) {
+ if (!try_module_get(core-owner))
On 05/02/15 20:44, Sylwester Nawrocki wrote:
+void __clk_put(struct clk *clk)
+{
+ if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
+ return;
+
+ clk_core_put(clk-core);
+ kfree(clk);
Why do we have kfree() here? clk_get() doesn't allocate the data structure
being freed here.
On 02/05/15 11:44, Sylwester Nawrocki wrote:
Hi Tomeu,
On 23/01/15 12:03, Tomeu Vizoso wrote:
int __clk_get(struct clk *clk)
{
-if (clk) {
-if (!try_module_get(clk-owner))
+struct clk_core *core = !clk ? NULL : clk-core;
+
+if (core) {
+if
* Tero Kristo [150203 00:49]:
> On 02/03/2015 09:03 AM, Tomeu Vizoso wrote:
> >
> >I think you got it right, just wanted to mention that we can and
> >probably should make the clk_get_parent_* calls in the consumer API to
> >return per-user clk instances but that we need to make sure first that
>
On 02/03/2015 09:03 AM, Tomeu Vizoso wrote:
On 02/02/2015 11:41 PM, Mike Turquette wrote:
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as
* Tero Kristo t-kri...@ti.com [150203 00:49]:
On 02/03/2015 09:03 AM, Tomeu Vizoso wrote:
I think you got it right, just wanted to mention that we can and
probably should make the clk_get_parent_* calls in the consumer API to
return per-user clk instances but that we need to make sure first
On 02/03/2015 09:03 AM, Tomeu Vizoso wrote:
On 02/02/2015 11:41 PM, Mike Turquette wrote:
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as
On 02/02/2015 11:41 PM, Mike Turquette wrote:
> Quoting Tero Kristo (2015-02-02 11:32:01)
>> On 02/01/2015 11:24 PM, Mike Turquette wrote:
>>> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
* Mike Turquette [150202 14:51]:
> Quoting Tony Lindgren (2015-02-02 12:44:02)
> >
> > Thanks Tero, looks like your fix fixes all the issues I'm seeing with
> > commit 59cf3fcf9baf. That is noisy dmesg, dpll_abe_ck not locking
> > on 4430sdp, and off-idle not working for omap3.
> >
> > I could
On 02/02/15 14:41, Mike Turquette wrote:
> Quoting Tero Kristo (2015-02-02 11:32:01)
>> On 02/01/2015 11:24 PM, Mike Turquette wrote:
>>>
>>> AFAICT this doesn't break anything, but booting on OMAP3+ results in
>>> noisy WARNs.
>>>
>>> I think the correct fix is to replace clk_bypass and clk_ref
Quoting Stephen Boyd (2015-02-02 14:35:59)
> On 02/02/15 13:31, Julia Lawall wrote:
> >
> > On Mon, 2 Feb 2015, Stephen Boyd wrote:
> >
> >> Julia,
> >>
> >> Is there a way we can write a coccinelle script to check for this? The
> >> goal being to find all drivers that are comparing struct clk
Quoting Tony Lindgren (2015-02-02 12:44:02)
> * Tero Kristo [150202 11:35]:
> > On 02/01/2015 11:24 PM, Mike Turquette wrote:
> > >Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> > >
> > >AFAICT this doesn't break anything, but booting on OMAP3+ results in
> > >noisy WARNs.
> > >
> > >I think the
Quoting Tero Kristo (2015-02-02 11:32:01)
> On 02/01/2015 11:24 PM, Mike Turquette wrote:
> > Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> >> Moves clock state to struct clk_core, but takes care to change as little
> >> API as
> >> possible.
> >>
> >> struct clk_hw still has a pointer to a struct
On 02/02/15 13:31, Julia Lawall wrote:
>
> On Mon, 2 Feb 2015, Stephen Boyd wrote:
>
>> Julia,
>>
>> Is there a way we can write a coccinelle script to check for this? The
>> goal being to find all drivers that are comparing struct clk pointers or
>> attempting to dereference them. There are
On Mon, 2 Feb 2015, Stephen Boyd wrote:
> On 02/01/15 13:24, Mike Turquette wrote:
> > Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> >> Moves clock state to struct clk_core, but takes care to change as little
> >> API as
> >> possible.
> >>
> >> struct clk_hw still has a pointer to a struct
* Tero Kristo [150202 11:35]:
> On 02/01/2015 11:24 PM, Mike Turquette wrote:
> >Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> >
> >AFAICT this doesn't break anything, but booting on OMAP3+ results in
> >noisy WARNs.
> >
> >I think the correct fix is to replace clk_bypass and clk_ref pointers
>
On 02/01/15 13:24, Mike Turquette wrote:
> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
>> Moves clock state to struct clk_core, but takes care to change as little API
>> as
>> possible.
>>
>> struct clk_hw still has a pointer to a struct clk, which is the
>> implementation's per-user clk instance,
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for
* Mike Turquette [150201 13:27]:
> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> > Moves clock state to struct clk_core, but takes care to change as little
> > API as
> > possible.
> >
> > struct clk_hw still has a pointer to a struct clk, which is the
> > implementation's per-user clk instance,
* Tero Kristo t-kri...@ti.com [150202 11:35]:
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct fix is to replace clk_bypass and clk_ref pointers
On 02/01/15 13:24, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API
as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for
On Mon, 2 Feb 2015, Stephen Boyd wrote:
On 02/01/15 13:24, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
* Mike Turquette mturque...@linaro.org [150202 14:51]:
Quoting Tony Lindgren (2015-02-02 12:44:02)
Thanks Tero, looks like your fix fixes all the issues I'm seeing with
commit 59cf3fcf9baf. That is noisy dmesg, dpll_abe_ck not locking
on 4430sdp, and off-idle not working for omap3.
On 02/02/15 14:41, Mike Turquette wrote:
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct fix is to replace clk_bypass and clk_ref pointers
with a
On 02/02/15 13:31, Julia Lawall wrote:
On Mon, 2 Feb 2015, Stephen Boyd wrote:
Julia,
Is there a way we can write a coccinelle script to check for this? The
goal being to find all drivers that are comparing struct clk pointers or
attempting to dereference them. There are probably other
Quoting Tony Lindgren (2015-02-02 12:44:02)
* Tero Kristo t-kri...@ti.com [150202 11:35]:
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
Quoting Stephen Boyd (2015-02-02 14:35:59)
On 02/02/15 13:31, Julia Lawall wrote:
On Mon, 2 Feb 2015, Stephen Boyd wrote:
Julia,
Is there a way we can write a coccinelle script to check for this? The
goal being to find all drivers that are comparing struct clk pointers or
On 02/02/2015 11:41 PM, Mike Turquette wrote:
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
struct clk_hw still
* Mike Turquette mturque...@linaro.org [150201 13:27]:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
> Moves clock state to struct clk_core, but takes care to change as little API
> as
> possible.
>
> struct clk_hw still has a pointer to a struct clk, which is the
> implementation's per-user clk instance, for backwards compatibility.
>
> The struct
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API
as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that
54 matches
Mail list logo
