David Gibson wrote:
On Wed, Apr 22, 2009 at 11:41:31PM -0500, Kumar Gala wrote:
Lets say I had an error driver for our MCM (core to soc coherency
module). It was getting the base address by using get_immrbase().
Today I proposed a proper device node for the MCM block as it doesn't
On Wed, Apr 22, 2009 at 11:41:31PM -0500, Kumar Gala wrote:
On Apr 22, 2009, at 11:06 PM, David Gibson wrote:
Well, yes, I guess I agree. How immutable you consider the device
tree blob to be is a judgement call based on the specific details of
platform/board in question. If it is indeed a
On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
David Gibson wrote:
It's not so much point of view as situation. Putting the device tree
in the firmware and putting the device tree in the kernel are both
valid choices, with their own distinct advantages and drawbacks.
I
On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
David Gibson wrote:
It's not so much point of view as situation. Putting the device tree
in the firmware and putting the device tree in the kernel are both
On Thu, Apr 23, 2009 at 07:53:11AM -0600, Grant Likely wrote:
On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala ga...@kernel.crashing.org wrote:
On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
Scott Wood wrote:
Timur Tabi wrote:
these two are related and seem like we could look for
We've run into plenty of situations where customers will update the
kernel, but insist that U-Boot and the device tree remain unchanged.
when? I'm not aware of any significant # of cases that
customer is willing to update kernel not dts. Usually if
they are willing to update kernel
David Gibson wrote:
It's not so much point of view as situation. Putting the device tree
in the firmware and putting the device tree in the kernel are both
valid choices, with their own distinct advantages and drawbacks.
I was under the impression that the reason we put the device trees in
Kumar Gala wrote:
Until we meet the most basic level of properly describing 95% of the
HW I don't see the value you guys prescribe to FW compatibility.
Additionally I believe for embedded developers its perfectly
reasonable to expect them (if they are using u-boot) to possibly have
On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala ga...@kernel.crashing.org wrote:
On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
Scott Wood wrote:
Timur Tabi wrote:
these two are related and seem like we could look for fsl,cpm2
That's okay, as long as you don't break compatibility with
On Wed, Apr 22, 2009 at 3:39 PM, Kumar Gala ga...@kernel.crashing.org wrote:
On Apr 22, 2009, at 4:33 PM, Timur Tabi wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
Is this a
Anton Vorontsov wrote:
And note that most developers are using up-to-date firmwares
(U-Boots), device trees, and kernels.
Developers? Yes.
End-users? No.
Updating U-Boot itself is often unacceptable for end-users. There's
also a strong connection between U-Boot and the device tree. That
On Thu, Apr 23, 2009 at 07:53:11AM -0600, Grant Likely wrote:
On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala ga...@kernel.crashing.org wrote:
On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
Scott Wood wrote:
Timur Tabi wrote:
these two are related and seem like we could look for
On Apr 23, 2009, at 9:02 AM, Timur Tabi wrote:
We've run into plenty of situations where customers will update the
kernel, but insist that U-Boot and the device tree remain unchanged.
when? I'm not aware of any significant # of cases that customer is
willing to update kernel not dts.
Kumar Gala wrote:
when? I'm not aware of any significant # of cases that customer is
willing to update kernel not dts. Usually if they are willing to
update kernel they tend to be willing to update everything.
Well, now that you ask, I can't give you specifics, because I don't
On Thu, Apr 23, 2009 at 09:02:49AM -0500, Timur Tabi wrote:
Anton Vorontsov wrote:
And note that most developers are using up-to-date firmwares
(U-Boots), device trees, and kernels.
Developers? Yes.
End-users? No.
If end-users upgraded the kernel on some FSL board, then there
should
On Wednesday 22 April 2009, Kumar Gala wrote:
First of all, thanks for bringing this up, I'd love to see get_immrbase() gone.
arch/powerpc/sysdev/cpm1.c: mpc8xx_immr = ioremap(get_immrbase(),
0x4000);
not sure? ideas?
Nobody has commented on this, so I've taken a brief look at
On Wed, Apr 22, 2009 at 10:36:36PM -0500, Kumar Gala wrote:
I think this all sounds great in theory but in reality the vast
majority (I'd say over 80-90%) we are talking about embedded reference
boards.
I've handled plenty of support e-mails from people using custom 82xx
boards with device
On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
As for Freescale parts, all the reference board I've seen were
very friendly wrt upgrading their device-trees, i.e. none of
the boards were shipping with device-tree soldered into the
firmware.
But many of them have broken when
On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
As for Freescale parts, all the reference board I've seen were
very friendly wrt upgrading their device-trees, i.e. none of
the boards were shipping with device-tree
Anton Vorontsov wrote:
On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
Even if the given change may not break the firmware, it could force an
update in which a prior change breaks the firmware.
I'm not sure I'm following here. Could you give an example?
1. U-boot X1 is used with
On Thu, Apr 23, 2009 at 12:03:06PM -0500, Scott Wood wrote:
Anton Vorontsov wrote:
On Thu, Apr 23, 2009 at 11:00:48AM -0500, Scott Wood wrote:
Even if the given change may not break the firmware, it could force an
update in which a prior change breaks the firmware.
I'm not sure I'm following
Anton Vorontsov wrote:
This is exactly what we should try to avoid. We should not accept
any changes that might break older firmwares. That is, keep the
device tree workable with X1 and X2, by any means.
I think that's a much bigger restriction than trying to keep the kernel
compatible with
I'm not sure if we can actually get away with completely removing
get_immrbase() but I figured I'd give everyone something to flame me
about. The current users are:
CPM/QE related users.
arch/powerpc/include/asm/cpm1.h:#define IMAP_ADDR (get_immrbase())
only used
On Wed, Apr 22, 2009 at 1:38 PM, Kumar Gala ga...@kernel.crashing.org wrote:
I'm not sure if we can actually get away with completely removing
get_immrbase() but I figured I'd give everyone something to flame me about.
The current users are:
CPM/QE related users.
I'm okay with doing
Kumar Gala wrote:
I'm not sure if we can actually get away with completely removing
get_immrbase() but I figured I'd give everyone something to flame me
about. The current users are:
I think we want to keep it for an eventual re-introduction of a large
TLB entry to cover IMMR (but no longer
On Apr 22, 2009, at 2:44 PM, Scott Wood wrote:
CPM/QE related users.
arch/powerpc/include/asm/cpm1.h:#define IMAP_ADDR
(get_immrbase())
only used drivers/net/fs_enet/fs_enet-main.c which seems evil.
That driver *is* evil. :-)
It looks like the only remaining user of
Scott Wood wrote:
Timur Tabi wrote:
these two are related and seem like we could look for fsl,cpm2
That's okay, as long as you don't break compatibility with older
device trees that don't have that property, unless you can demonstrate
that these trees would never work with the current
On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
Scott Wood wrote:
Timur Tabi wrote:
these two are related and seem like we could look for
fsl,cpm2
That's okay, as long as you don't break compatibility with older
device trees that don't have that property, unless you can
demonstrate
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
Is this a new policy? I was under the impression that supporting older
device trees, if not too inconvenient, is desirable. I've nack'd
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
No. The device tree is a means to pass information from the firmware to
the kernel. It is part of the firmware. That the repository of
On Apr 22, 2009, at 4:33 PM, Timur Tabi wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
Is this a new policy? I was under the impression that supporting
older
device trees,
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your
device tree (thus we have .dts in the kernel tree and not somewhere
else).
No. The device tree is a means to pass information from the
firmware to the kernel.
Scott Wood wrote:
That is indeed the case. A demonstration of that for the tree you
quote is that the reg address changed -- if you tried feeding the old
tree into the new kernel, it would not find the CPM command register.
There is no code in the kernel that looks for the command-proc
On Apr 22, 2009, at 4:57 PM, Timur Tabi wrote:
Kumar Gala wrote:
New nodes. For example I've proposed a local access window node.
Once I add it I plan on changing code to use it. This will break an
old device tree booting with the new kernel and I'm completely ok
with
that.
Are we
On Wed, Apr 22, 2009 at 04:55:42PM -0500, Kumar Gala wrote:
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your device
tree (thus we have .dts in the kernel tree and not somewhere else).
No. The device tree is a
On Apr 22, 2009, at 9:26 PM, David Gibson wrote:
On Wed, Apr 22, 2009 at 04:55:42PM -0500, Kumar Gala wrote:
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should update your
device
tree (thus we have .dts in the kernel tree
On Wed, Apr 22, 2009 at 10:36:36PM -0500, Kumar Gala wrote:
On Apr 22, 2009, at 9:26 PM, David Gibson wrote:
On Wed, Apr 22, 2009 at 04:55:42PM -0500, Kumar Gala wrote:
On Apr 22, 2009, at 4:38 PM, Scott Wood wrote:
Kumar Gala wrote:
I disagree. If you update your kernel you should
On Apr 22, 2009, at 11:06 PM, David Gibson wrote:
Well, yes, I guess I agree. How immutable you consider the device
tree blob to be is a judgement call based on the specific details of
platform/board in question. If it is indeed a reference platform, in
the early stages of development where
38 matches
Mail list logo
