Hi Gregory,
El 18/02/14 06:47, Gregory CLEMENT escribió:
(snip)
(...) what would be an acceptable
version would be the something like the patch attached. There will be still
an issue if old dtb is used with recent kernel, but at least the user will
be warned.
The patch you attached is similar
On Tue, Feb 18, 2014 at 10:47:00AM +0100, Gregory CLEMENT wrote:
> On 17/02/2014 19:19, Ezequiel Garcia wrote:
> > On Mon, Feb 17, 2014 at 04:59:01PM +0100, Gregory CLEMENT wrote:
> > [..]
> >>>
> >>> Right. If you think it adds a regression, then that's a perfectly valid
> >>> reasons
> >>> for
On Tue, Feb 18, 2014 at 10:47:00AM +0100, Gregory CLEMENT wrote:
On 17/02/2014 19:19, Ezequiel Garcia wrote:
On Mon, Feb 17, 2014 at 04:59:01PM +0100, Gregory CLEMENT wrote:
[..]
Right. If you think it adds a regression, then that's a perfectly valid
reasons
for nacking.
However,
Hi Gregory,
El 18/02/14 06:47, Gregory CLEMENT escribió:
(snip)
(...) what would be an acceptable
version would be the something like the patch attached. There will be still
an issue if old dtb is used with recent kernel, but at least the user will
be warned.
The patch you attached is similar
On 17/02/2014 19:19, Ezequiel Garcia wrote:
> On Mon, Feb 17, 2014 at 04:59:01PM +0100, Gregory CLEMENT wrote:
> [..]
>>>
>>> Right. If you think it adds a regression, then that's a perfectly valid
>>> reasons
>>> for nacking.
>>>
>>> However, I'd like to double-check we have such a regression. I
On 17/02/2014 19:19, Ezequiel Garcia wrote:
On Mon, Feb 17, 2014 at 04:59:01PM +0100, Gregory CLEMENT wrote:
[..]
Right. If you think it adds a regression, then that's a perfectly valid
reasons
for nacking.
However, I'd like to double-check we have such a regression. I guess you're
On Mon, Feb 17, 2014 at 04:59:01PM +0100, Gregory CLEMENT wrote:
[..]
> >
> > Right. If you think it adds a regression, then that's a perfectly valid
> > reasons
> > for nacking.
> >
> > However, I'd like to double-check we have such a regression. I guess you're
> > talking about the "tclk"
On 17/02/2014 16:44, Ezequiel Garcia wrote:
> On Mon, Feb 17, 2014 at 04:28:41PM +0100, Gregory CLEMENT wrote:
>> On 17/02/2014 16:21, Ezequiel Garcia wrote:
>>> On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
On 17/02/2014 15:13, Ezequiel Garcia wrote:
> On Wed, Feb 05,
On Mon, Feb 17, 2014 at 04:28:41PM +0100, Gregory CLEMENT wrote:
> On 17/02/2014 16:21, Ezequiel Garcia wrote:
> > On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
> >> On 17/02/2014 15:13, Ezequiel Garcia wrote:
> >>> On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
>
Hi,
El 17/02/14 12:04, Gregory CLEMENT escribió:
(snip)
Please read what I have written: "if there is no output-name, which is our
default case) this proposal just ignored the parent clock given by the device
tree".
Extract of your code from the link you pointed:
const char *default_parent =
On 17/02/2014 16:21, Ezequiel Garcia wrote:
> On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
>> On 17/02/2014 15:13, Ezequiel Garcia wrote:
>>> On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth
On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
> On 17/02/2014 15:13, Ezequiel Garcia wrote:
> > On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
> >> On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
> >>> This patch set fixes clk init order
On 17/02/2014 15:42, Emilio López wrote:
> Hi Gregory, Ezequiel,
>
> >> Are we still in time to consider Emilio's oneline proposal?
>>> (Emilio: would you mind preparing a suitable patch against dove,
>>> kirkwood, armada370/xp, so we can see the real thing?).
>
> The patch is in a common file,
Hi Gregory, Ezequiel,
>> Are we still in time to consider Emilio's oneline proposal?
(Emilio: would you mind preparing a suitable patch against dove,
kirkwood, armada370/xp, so we can see the real thing?).
The patch is in a common file, so it does not need patching anything for
each
On 17/02/2014 15:13, Ezequiel Garcia wrote:
> On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
>> On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
>>> This patch set fixes clk init order that went upside-down with
>>> v3.14. I haven't really investigated what
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
> On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
> > This patch set fixes clk init order that went upside-down with
> > v3.14. I haven't really investigated what caused this, but I assume
> > it is related with
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node
On 17/02/2014 15:13, Ezequiel Garcia wrote:
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this,
Hi Gregory, Ezequiel,
Are we still in time to consider Emilio's oneline proposal?
(Emilio: would you mind preparing a suitable patch against dove,
kirkwood, armada370/xp, so we can see the real thing?).
The patch is in a common file, so it does not need patching anything for
each platform.
On 17/02/2014 15:42, Emilio López wrote:
Hi Gregory, Ezequiel,
Are we still in time to consider Emilio's oneline proposal?
(Emilio: would you mind preparing a suitable patch against dove,
kirkwood, armada370/xp, so we can see the real thing?).
The patch is in a common file, so it does
On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
On 17/02/2014 15:13, Ezequiel Garcia wrote:
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went
On 17/02/2014 16:21, Ezequiel Garcia wrote:
On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
On 17/02/2014 15:13, Ezequiel Garcia wrote:
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
This
Hi,
El 17/02/14 12:04, Gregory CLEMENT escribió:
(snip)
Please read what I have written: if there is no output-name, which is our
default case) this proposal just ignored the parent clock given by the device
tree.
Extract of your code from the link you pointed:
const char *default_parent =
On Mon, Feb 17, 2014 at 04:28:41PM +0100, Gregory CLEMENT wrote:
On 17/02/2014 16:21, Ezequiel Garcia wrote:
On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
On 17/02/2014 15:13, Ezequiel Garcia wrote:
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat,
On 17/02/2014 16:44, Ezequiel Garcia wrote:
On Mon, Feb 17, 2014 at 04:28:41PM +0100, Gregory CLEMENT wrote:
On 17/02/2014 16:21, Ezequiel Garcia wrote:
On Mon, Feb 17, 2014 at 03:25:22PM +0100, Gregory CLEMENT wrote:
On 17/02/2014 15:13, Ezequiel Garcia wrote:
On Wed, Feb 05, 2014 at
On Mon, Feb 17, 2014 at 04:59:01PM +0100, Gregory CLEMENT wrote:
[..]
Right. If you think it adds a regression, then that's a perfectly valid
reasons
for nacking.
However, I'd like to double-check we have such a regression. I guess you're
talking about the tclk name being
On Thu, Feb 06, 2014 at 02:08:39PM -0300, Ezequiel Garcia wrote:
> On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
> > On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
> > > This patch set fixes clk init order that went upside-down with
> > > v3.14. I haven't
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
> On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
> > This patch set fixes clk init order that went upside-down with
> > v3.14. I haven't really investigated what caused this, but I assume
> > it is related with
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node
On Thu, Feb 06, 2014 at 02:08:39PM -0300, Ezequiel Garcia wrote:
On Wed, Feb 05, 2014 at 01:34:57PM -0500, Jason Cooper wrote:
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
>
> Anyway, with v3.14 for MVEBU
On Wed, Feb 05, 2014 at 06:08:02AM -0800, Mike Turquette wrote:
> Quoting Sebastian Hesselbarth (2014-01-25 10:19:06)
> > This patch set fixes clk init order that went upside-down with
> > v3.14. I haven't really investigated what caused this, but I assume
> > it is related with DT node reordering
Quoting Sebastian Hesselbarth (2014-01-25 10:19:06)
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
>
> Anyway, with v3.14 for MVEBU SoCs, the clock gating
Quoting Sebastian Hesselbarth (2014-01-25 10:19:06)
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
Anyway, with v3.14 for MVEBU SoCs, the clock gating
On Wed, Feb 05, 2014 at 06:08:02AM -0800, Mike Turquette wrote:
Quoting Sebastian Hesselbarth (2014-01-25 10:19:06)
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
Anyway, with v3.14 for MVEBU SoCs, the
Hello,
On Tue, 04 Feb 2014 15:58:44 +0100, Gregory CLEMENT wrote:
> > @Jason, Andrew, Gregory, Thomas:
> > Now that v3.14 is out, anything against taking this in as fixes for rc1?
>
> I am not found of this solution I still think it should be done
> at framework level. However we still have
On 04/02/2014 00:36, Sebastian Hesselbarth wrote:
> On 02/04/2014 12:16 AM, Willy Tarreau wrote:
>> On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
>>> On 01/30/14 11:24, Gregory CLEMENT wrote:
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
> This patch set fixes
On 04/02/2014 00:36, Sebastian Hesselbarth wrote:
On 02/04/2014 12:16 AM, Willy Tarreau wrote:
On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
On 01/30/14 11:24, Gregory CLEMENT wrote:
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
This patch set fixes clk init order
Hello,
On Tue, 04 Feb 2014 15:58:44 +0100, Gregory CLEMENT wrote:
@Jason, Andrew, Gregory, Thomas:
Now that v3.14 is out, anything against taking this in as fixes for rc1?
I am not found of this solution I still think it should be done
at framework level. However we still have this very
On 02/04/2014 12:16 AM, Willy Tarreau wrote:
On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
On 01/30/14 11:24, Gregory CLEMENT wrote:
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't
Hi Sebastian,
On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
> On 01/30/14 11:24, Gregory CLEMENT wrote:
> >On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
> >>This patch set fixes clk init order that went upside-down with
> >>v3.14. I haven't really investigated what
Hi Sebastian,
On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
On 01/30/14 11:24, Gregory CLEMENT wrote:
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused
On 02/04/2014 12:16 AM, Willy Tarreau wrote:
On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
On 01/30/14 11:24, Gregory CLEMENT wrote:
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't
On 01/30/14 11:24, Gregory CLEMENT wrote:
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
Can you explain
Hi Sebastian,
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
Can you explain what kind of issue do you
Hi Sebastian,
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
Can you explain what kind of issue do you
On 01/30/14 11:24, Gregory CLEMENT wrote:
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
Can you explain
On Mon, Jan 27, 2014 at 07:21:38PM +0100, Sebastian Hesselbarth wrote:
> On 01/27/14 15:39, Thomas Petazzoni wrote:
> >On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
> >>This patch set fixes clk init order that went upside-down with
> >>v3.14. I haven't really investigated what
On 01/27/14 15:39, Thomas Petazzoni wrote:
On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
Dear Sebastian Hesselbarth,
On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
>
> Anyway,
Dear Sebastian Hesselbarth,
On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
Anyway, with
On 01/27/14 15:39, Thomas Petazzoni wrote:
On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
On Mon, Jan 27, 2014 at 07:21:38PM +0100, Sebastian Hesselbarth wrote:
On 01/27/14 15:39, Thomas Petazzoni wrote:
On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused
Hi Emilio,
Thanks for your help with this.
On Sat, Jan 25, 2014 at 07:11:07PM -0300, Emilio López wrote:
[..]
> >
> > Ok, I'll look if using of_clk_get_parent_name will help here. But again,
> > I can see that clk-gating driver gets registered before core-clk driver.
> > There may be no code to
Sebastian,
El 25/01/14 18:44, Sebastian Hesselbarth escribió:
On 01/25/2014 10:32 PM, Emilio López wrote:
El 25/01/14 15:19, Sebastian Hesselbarth escribió:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is
Hello Sebastian,
El 25/01/14 15:19, Sebastian Hesselbarth escribió:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
The framework should be able to deal with
On 01/25/2014 10:32 PM, Emilio López wrote:
El 25/01/14 15:19, Sebastian Hesselbarth escribió:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
The framework
On 01/25/2014 10:32 PM, Emilio López wrote:
El 25/01/14 15:19, Sebastian Hesselbarth escribió:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
The framework
Hello Sebastian,
El 25/01/14 15:19, Sebastian Hesselbarth escribió:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.
The framework should be able to deal with
Sebastian,
El 25/01/14 18:44, Sebastian Hesselbarth escribió:
On 01/25/2014 10:32 PM, Emilio López wrote:
El 25/01/14 15:19, Sebastian Hesselbarth escribió:
This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is
Hi Emilio,
Thanks for your help with this.
On Sat, Jan 25, 2014 at 07:11:07PM -0300, Emilio López wrote:
[..]
Ok, I'll look if using of_clk_get_parent_name will help here. But again,
I can see that clk-gating driver gets registered before core-clk driver.
There may be no code to give you
62 matches
Mail list logo
