Hi Paul,
I've been looking at this stuff today, and this will cause pretty huge
changes to the set. This probably means a few weeks delay in
implementation at least.
Some comments on the technical perspectives below.
On 10/14/2013 02:45 AM, Paul Walmsley wrote:
Here you go:
1. Create DT
On Mon, 14 Oct 2013, Tero Kristo wrote:
On 10/14/2013 02:45 AM, Paul Walmsley wrote:
8. A few random comments about the individual clock binding data formats
themselves, based on a quick look:
A. It seems pretty odd and unnecessarily obscure to do something like
this:
On 10/14/2013 09:27 PM, Paul Walmsley wrote:
On Mon, 14 Oct 2013, Tero Kristo wrote:
On 10/14/2013 02:45 AM, Paul Walmsley wrote:
8. A few random comments about the individual clock binding data formats
themselves, based on a quick look:
A. It seems pretty odd and unnecessarily obscure to
Here you go:
1. Create DT nodes for the IP blocks that contain the clock control
registers, underneath the appropriate bus node. So for example OMAP4
would have:
/ocp {
prm@4a306000 {
compatible = xxx;
regs = 0x4a306000 ;
};
cm1@4a004000 {
On 10/12/2013 01:37 AM, Paul Walmsley wrote:
On Fri, 11 Oct 2013, Tero Kristo wrote:
Oh yea, one additional note you probably have missed. Mike asked us to fall
back to vendor specific bindings at around v6 or so of this set. Take a look
at v8, we have dropped the use of generic bindings, we
On Thu, 10 Oct 2013, Tero Kristo wrote:
On 10/09/2013 09:59 PM, Paul Walmsley wrote:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is a misstatement of the issue:
On 10/11/2013 08:54 PM, Paul Walmsley wrote:
On Thu, 10 Oct 2013, Tero Kristo wrote:
On 10/09/2013 09:59 PM, Paul Walmsley wrote:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is
On 10/11/2013 08:54 PM, Paul Walmsley wrote:
On Thu, 10 Oct 2013, Tero Kristo wrote:
On 10/09/2013 09:59 PM, Paul Walmsley wrote:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is
On Fri, 11 Oct 2013, Tero Kristo wrote:
Well, even if you sign something, you can still update it. Writing any
software to true OTP memory is one way to commit suicide IMO. How many nasty
bugs have you seen with ROM code? Also, if people want to make their custom
security solutions which are
On Fri, 11 Oct 2013, Tero Kristo wrote:
Oh yea, one additional note you probably have missed. Mike asked us to fall
back to vendor specific bindings at around v6 or so of this set. Take a look
at v8, we have dropped the use of generic bindings, we are not trying to
declare those with this
* Tero Kristo t-kri...@ti.com [131010 01:25]:
On 10/09/2013 09:55 PM, Paul Walmsley wrote:
So in my view, the right things to do here are to:
1. associate SoC DT clock data with the device node that contains the
clock control registers
So, either cm, prcm, and maybe control_module
On 10/09/2013 09:59 PM, Paul Walmsley wrote:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is a misstatement of the issue: the concern here is that newer
kernels may not boot at all
Hey Paul,
My dibs on this below.
On 10/09/2013 09:55 PM, Paul Walmsley wrote:
On Mon, 7 Oct 2013, Tony Lindgren wrote:
And assuming Paul is OK with these patches in general.
Actually, I have several concerns with this series, as you and I
discussed. Some of us have been talking them over
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is a misstatement of the issue: the concern here is that newer
kernels may not boot at all with older DT data - which could easily be
On Mon, 7 Oct 2013, Tony Lindgren wrote:
And assuming Paul is OK with these patches in general.
Actually, I have several concerns with this series, as you and I
discussed. Some of us have been talking them over with other folks for
the past few months to try to figure out what to do. Most
* Paul Walmsley p...@pwsan.com [131009 12:04]:
On Mon, 7 Oct 2013, Tony Lindgren wrote:
And assuming Paul is OK with these patches in general.
Actually, I have several concerns with this series, as you and I
discussed. Some of us have been talking them over with other folks for
the
* Paul Walmsley p...@pwsan.com [131009 12:07]:
Eh, one correction:
On Wed, 9 Oct 2013, Paul Walmsley wrote:
We could easily wind up with kernels that won't boot at all when used
with newer DT data.
This is a misstatement of the issue: the concern here is that newer
kernels may not
On 10/08/2013 08:40 AM, Mike Turquette wrote:
Quoting Tero Kristo (2013-09-25 01:48:06)
Hi all,
Version 7 contains following high level changes:
- Dropped support for basic bindings from Mike Turquette, instead using
vendor specific bindings for all clocks
- Mux clock + divider clock vendor
* Tero Kristo t-kri...@ti.com [131008 01:26]:
On 10/08/2013 08:40 AM, Mike Turquette wrote:
3) Same concern as above but for the DT clkdev alias stuff. I guess
you'll need to make all of the dependent drivers play nice with DT. Do
you plan to remove it within a reasonable timeframe? It would
On 10/07/2013 05:15 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [131004 08:42]:
Hi,
Just a gentle reminder, anybody have any comments on this series or
should we start queuing stuff?
Well omap4 seems to work for me just fine, and omap3 in legacy
mode. But looks like omap3 device
* Tero Kristo t-kri...@ti.com [131006 23:43]:
On 10/07/2013 05:15 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [131004 08:42]:
Hi,
Just a gentle reminder, anybody have any comments on this series or
should we start queuing stuff?
Well omap4 seems to work for me just fine, and
On 10/07/2013 10:41 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [131006 23:43]:
On 10/07/2013 05:15 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [131004 08:42]:
Hi,
Just a gentle reminder, anybody have any comments on this series or
should we start queuing stuff?
Well
* Tony Lindgren t...@atomide.com [131007 08:49]:
* Tero Kristo t-kri...@ti.com [131006 23:43]:
On 10/07/2013 05:15 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [131004 08:42]:
Hi,
Just a gentle reminder, anybody have any comments on this series or
should we start queuing
Quoting Tero Kristo (2013-09-25 01:48:06)
Hi all,
Version 7 contains following high level changes:
- Dropped support for basic bindings from Mike Turquette, instead using
vendor specific bindings for all clocks
- Mux clock + divider clock vendor specific bindings get rid of use
of the
* Tero Kristo t-kri...@ti.com [131004 08:42]:
Hi,
Just a gentle reminder, anybody have any comments on this series or
should we start queuing stuff?
Well omap4 seems to work for me just fine, and omap3 in legacy
mode. But looks like omap3 device tree based booting is breaking
after I pulled
Hi,
Just a gentle reminder, anybody have any comments on this series or
should we start queuing stuff?
-Tero
On 09/25/2013 11:48 AM, Tero Kristo wrote:
Hi all,
Version 7 contains following high level changes:
- Dropped support for basic bindings from Mike Turquette, instead using
vendor
On 09/25/2013 03:48 AM, Tero Kristo wrote:
[...]
Test branch available here:
https://github.com/t-kristo/linux-pm.git
branch: mainline-3.12-rc2-ti-dt-clks-v7
Testing done:
- am335x-bone : boot only
- omap5-sevm : boot only
- dra7-evm : boot only
- omap3-beagle : boot + suspend/resume
On 09/26/2013 10:21 AM, Nishanth Menon wrote:
On 09/25/2013 03:48 AM, Tero Kristo wrote:
[...]
Test branch available here:
https://github.com/t-kristo/linux-pm.git
branch: mainline-3.12-rc2-ti-dt-clks-v7
Testing done:
- am335x-bone : boot only
- omap5-sevm : boot only
- dra7-evm : boot
Hi all,
Version 7 contains following high level changes:
- Dropped support for basic bindings from Mike Turquette, instead using
vendor specific bindings for all clocks
- Mux clock + divider clock vendor specific bindings get rid of use
of the bit-masks, instead these are generated runtime
29 matches
Mail list logo
