* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 22:58 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F278B@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
>
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the properties of a "duck" class device node, it's "duck"
> > class compliant.
>
> Don't know how cute it is, but I think it is practically
> helpful. Take another example:
>
> Say you-- a human reader-- see this in a device
> tree:
>
> ...
> interrupts = <b 8>;
> interrupt-parent = < &mpic >;
> ...
>
> What does the 'b' and '8' mean? You look
> at the interrupt controller node--
>
> mpic: pic@40000 {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <40000 40000>;
> compatible = "fsl,xyz";
> big-endian;
> }
>
> Note-- I removed the device_type property and changed
> compatible somewhat. How are you going to find where
> the meaning interrupt controller's interrupt cells are
> defined? What spec will you look at?
>
> device_type = "open-pic"; makes it perfectly clear.
> It's an open-pic type controller and follows that
> binding.
That's an extremely contrived example - it only works because for
historical reasons the "open-pic" device_type describes a programming
model as well as an OF method interface. In general, you always need
to look at a node's "compatible" and the binding for that to work out
what it's properties mean, or if it's an interrupt controller what the
format of its interrupt specifiers is.
open-pic is the *only* example I can think of where device_type will
tell you this. In fact, "open-pic" really belongs in compatible.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 23:02 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F2872@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote:
>
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 30, 2007 11:34 AM
> > To: Yoder Stuart-B08248
> > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> > Subject: Re: RFC: replace device_type with new "class" property?
> >
> > On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> > > mpic: pic@40000 {
> > > clock-frequency = <0>;
> > > interrupt-controller;
> > > #address-cells = <0>;
> > > #interrupt-cells = <2>;
> > > reg = <40000 40000>;
> > > compatible = "fsl,xyz";
> > > big-endian;
> > > }
> > >
> > > Note-- I removed the device_type property and changed
> > > compatible somewhat. How are you going to find where
> > > the meaning interrupt controller's interrupt cells are
> > > defined? What spec will you look at?
> >
> > The binding for fsl,xyz.
>
> Not every string listed in compatible has a spec
> backing it (or should be required to). You would
> have to go look at the source code and cross your
> fingers that the comments were sufficient.
But that's true in general. open-pic is practically the only time
device_type will let you avoid that.
> Another good reason for device_type-- it helps
> distinguish between two similar classes of devices.
> Both "open-pic" and "isa-pic" look very similar but
> have different encodings of their interrupt cells.
> Without a device_type it may be difficult or impossible
> to distinguish them unless the "name" and
> "compatible" are luckily clear enough.
This is a totally misleading argument. There may be one or two cases
where the device_type is useful, but in most cases device_type will be
either not specific enough to give you the information you need, or it
we add lots of new device_type values, it will be so specific that it
suffers the same problem as looking at name or compatible - you have
to find the finding that goes with a particular device_type.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: David Gibson @ 2007-10-30 23:08 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030165650.GA22107@ru.mvista.com>
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> PowerPC 440GRx Rainier DTS.
[snip]
> + SDRAM0: sdram {
> + device_type = "memory-controller";
How many times do we need to say it...
Don't make up random device_type values. This does not belong here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 23:27 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F26EE@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote:
[snip]
> > Yeah.. what he said.
> >
> > The *only* substantive change with the "class" proposal is the fact
> > that multiple classes can be specified. That's nice, but I don't
> > think it's worth the trouble of attempting to define a whole new chunk
> > of standard for.
>
> I tend to agree, but I think device_type serves a useful
> purpose. I don't think we should deprecate it.
>
> > Stuart, I think you overestimate the value of this class property to a
> > human reader. The generic names convention (not followed as much as
> > it should be) means the name should give the reader some idea of what
> > the device is, in most cases. For trickier cases, if we really want
> > something for humans reading the tree, we could add an optional
> > "comment" or "description" property with purely human readable
> > information.
> >
> > I think we should leave existing IEEE1275 defined uses of device_type,
> > in order not to make flat trees gratuitously different from real-OF
> > trees, but we should avoid any new use of device_type.
>
> I'm fine with keeping device_type, but there are a few
> of things I don't like about the 'no new use'.
>
> 1. There are types of nodes that don't have a programming
> inteface per se and thus no compatible.
> "cpu", "memory", "cache" are 3 that come to mind.
Well, yes, this is why I suggested treating these "fundamental" nodes
as a special case in an earlier mail.
> What if there is a _new_ class of nodes of this type?
> What is wrong with a new use of device_type for something
> say like "i2c"?
Memory and cpu are pretty clearly special cases - if they're not
there, you don't have a computer at all. The programming model for
"memory" is always the same", and the programming model for the cpu
has to be known before reading the device tree anyway. I don't think
we need to worry about new classes of such things - i2c is *certainly*
not an example of such.
cache is a bit weird, because although there can be different types,
the programming model is essentially determined by the cpu to which it
is attached, and the nodes for cache are really just to give details
of sizes and levels.
> Conceptually and ideally, what _is_ the right way to
> represent these types of devices.
>
> 2. 'Existing IEEE1275 defined uses' of device_type is
> actually very vague. There are a conglomeration of
> old bindings, recommended practices, proposals and
> it is not clear at all which are useful or not. What
> are the existing IEEE1275 uses??? I actually went
> through all the OF documents and there are dozens
> of device types that have no practical use.
>
> Also, many 'real-OF' trees seem to follow no published
> binding at all.
>
> Conceptually, I'd like to a crisp list of 'official'
> bindings and hope that the current ePAPR work in
> power.org will establish this list.
Yeah, sorry, I am being a bit vauge here and we do need to be more
specific. My point is that if you take a tree from a real OF, with
lots of device_type values representing programming interfaces, then
flatten it, it shouldn't be considered "bad" as a flattened tree.
It's fine if most or all of the device_type values are optional in the
flattened tree, so that it's ok whether or not they're present.
> 3. You're advocating deprecating device_class, but still
> requiring it for certain node types. So a "network"
> node is _required_ to have the deprecated
> device_type="network". But a "i2c" node is required
> _not_ to have device_type. Long term, I'd like to see
> any inconsitency be removed. If device_type is
> deprecated, it's use should be optional in flat
> device trees. That goes for "cpu", "memory", etc.
>
> I think what we should do is keep device_type, including
> permitting new uses of it in a limited way-- only permitting
> the use of device_type when there is an official binding
> (like in the power.org ePAPR) defined.
That's what I was thinking when we first started defining flat tree
bindings. But the more time I've spent thinking about it, and the
more time I've spent reviewing people's proposed bindings, the less
useful I think it is.
The *only* reason I'm suggesting leaving device_type values for
IEEE1275 defined classes is so that flat trees written as flat trees
look more similar to OF derived trees.
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the properties of a "duck" class device node, it's "duck"
> > class compliant.
> >
> > Or to look at it another way, "class bindings" aren't really bindings,
> > but rather a set of conventions that device bindings for specific
> > devices in that class ought to follow.
>
> I tend to think of a 'binding' as a 'set of conventions'.
Well, whatever. My point is that conventions are most flexible if you
don't have to explicitly announce that you're following them - you
just go ahead and follow as many conventions as make sense for your
device.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: libfdt as its own repo and submodule of dtc?
From: David Gibson @ 2007-10-30 23:40 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linux-ppc list, Jon Loeliger
In-Reply-To: <4727665E.1070109@ge.com>
On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
> Jon Loeliger wrote:
>> So, like, the other day Kumar Gala mumbled:
>>> Jon,
>>>
>>> It seems like have libfdt as a unique git repo that is a submodule of
>>> the things that need it (dtc, u-boot, etc.) might make some sense and it
>>> easier for the projects that need to pull it in.
>>>
>>> Is this something you can take a look at? (or have other ideas on).
>> I would be fine with making libfdt a git repository separate
>> from the DTC repository if that makes it easier to integrate
>> it with other projects.
I don't think it's a good idea to make dtc and libfdt entirely
seperate repositories (again). Being able to use both together in
their combined testsuite is very useful (libfdt is used to check trees
generated by dtc, dtc is used to generate example trees for libfdt
testing).
I'm not sure how submodules/subrepositories work so I don't know if
that makes sense.
> That sounds like a good idea to me. I would really prefer pulling patches
> out of a libfdt repo into the u-boot repo rather than trying to kerchunk
> upgrade lumps. While we can do this with a dtc repo, it potentially makes
> it a lot more difficult.
I don't think upgrading embedded copies by diff is a good way to go.
The upgrade method I had in mind was to pull out a whole new copy of
libfdt, drop that into the embedding project verbatim and generate a
new diff there in whatever their source tracking system is. I set out
the repository to make this easy.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
From: Benjamin Herrenschmidt @ 2007-10-31 0:55 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071030185932.6368.7796.stgit@farscape.rchland.ibm.com>
On Tue, 2007-10-30 at 13:59 -0500, Will Schmidt wrote:
> [Powerpc] fix switch_slb handling of 1T ESID values
>
> Now that we have 1TB segment size support, we need to be using the
> GET_ESID_1T macro when comparing ESID values for pc,stack, and
> unmapped_base within switch_slb(). A new helper function called
> esids_match() contains the logic for deciding when to call GET_ESID
> and GET_ESID_1T.
>
> This also happens to fix a duplicate-slb-entry inspired machine-check
> exception I was seeing when trying to run java on a power6 partition.
>
> Tested on power6 and power5.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
>
> ---
>
> Just a bit of whitespace cosmetic touchup in this version, as suggested
> by Stephen Rothwell.
> ---
>
> arch/powerpc/mm/slb.c | 34 +++++++++++++++++++++++++++++++---
> 1 files changed, 31 insertions(+), 3 deletions(-)
>
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index bbd2c51..8cbbfab 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
> slb_flush_and_rebolt();
> }
>
> +/* Helper function to compare esids. There are four cases to handle.
> + * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
> + * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID compare.
> + * 3. The system is 1T capable, only one of the two addresses is > 1T. This is not a match.
> + * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T macro to compare.
> + */
> +static inline int esids_match(unsigned long addr1, unsigned long addr2)
> +{
> + int esid_1t_count;
> +
> + /* System is not 1T segment size capable. */
> + if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + esid_1t_count = (((addr1 >> SID_SHIFT_1T) != 0) +
> + ((addr2 >> SID_SHIFT_1T) != 0));
> +
> + /* both addresses are < 1T */
> + if (esid_1t_count == 0)
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + /* One address < 1T, the other > 1T. Not a match */
> + if (esid_1t_count == 1)
> + return 0;
> +
> + /* Both addresses are > 1T. */
> + return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
> +}
> +
> /* Flush all user entries from the segment table of the current processor. */
> void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> {
> @@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> return;
> slb_allocate(pc);
>
> - if (GET_ESID(pc) == GET_ESID(stack))
> + if (esids_match(pc,stack))
> return;
>
> if (is_kernel_addr(stack))
> return;
> slb_allocate(stack);
>
> - if ((GET_ESID(pc) == GET_ESID(unmapped_base))
> - || (GET_ESID(stack) == GET_ESID(unmapped_base)))
> + if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
> return;
>
> if (is_kernel_addr(unmapped_base))
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] [powerpc v2] update xmon slb code
From: Benjamin Herrenschmidt @ 2007-10-31 0:57 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071030215037.12776.73871.stgit@farscape.rchland.ibm.com>
On Tue, 2007-10-30 at 16:50 -0500, Will Schmidt wrote:
> [powerpc] update xmon slb code
>
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from power6 (1T segment support):
.../....
>
> Tested on power5 and power6.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> This version adds padding around the ESID and VSID fields, and the LLP bits
> are displayed too. (Per request from Olof and Ben).
> I'll try to follow up sometime later with code that will handle decoding page
> sizes. I dont have a testcase handy to properly exercise that yet. :-)
> ---
>
> arch/powerpc/xmon/xmon.c | 27 +++++++++++++++++++++------
> 1 files changed, 21 insertions(+), 6 deletions(-)
>
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 121b04d..93c26c3 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address, const char *mid,
> static void dump_slb(void)
> {
> int i;
> - unsigned long tmp;
> + unsigned long esid,vsid,valid;
> + unsigned long llp_bits;
>
> printf("SLB contents of cpu %x\n", smp_processor_id());
>
> for (i = 0; i < SLB_NUM_ENTRIES; i++) {
> - asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
> - printf("%02d %016lx ", i, tmp);
> -
> - asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
> - printf("%016lx\n", tmp);
> + asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
> + asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
> + valid = (esid & SLB_ESID_V);
> + if (valid | esid | vsid) {
> + printf("%02d %016lx %016lx", i, esid, vsid);
> + if (valid) {
> + llp_bits = vsid & SLB_VSID_LLP;
> + if (vsid & SLB_VSID_B_1T) {
> + printf(" 1T ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
> + GET_ESID_1T(esid),vsid >> SLB_VSID_SHIFT_1T,
> + llp_bits);
> + } else {
> + printf(" 256M ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
> + GET_ESID(esid),vsid >> SLB_VSID_SHIFT,
> + llp_bits);
> + }
> + } else
> + printf("\n");
> + }
> }
> }
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] [powerpc v2] update xmon slb code
From: Olof Johansson @ 2007-10-31 1:26 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071030215037.12776.73871.stgit@farscape.rchland.ibm.com>
On Tue, Oct 30, 2007 at 04:50:39PM -0500, Will Schmidt wrote:
>
> [powerpc] update xmon slb code
>
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from power6 (1T segment support):
>
> 00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID=40004f7ca3 LLP bits:100
> 01 d000000008000000 4000eb71b0000400 1T ESID= d00000 VSID=4000eb71b0 LLP bits: 0
> 03 0000000008000000 0000628021c6ac80 256M ESID= 0 VSID= 628021c6a LLP bits: 0
> 04 00000f0008000000 400095c1e8000c80 1T ESID= f VSID=400095c1e8 LLP bits: 0
> 22 cf00000008000000 400011b260000500 1T ESID= cf0000 VSID=400011b260 LLP bits:100
> 62 0000040008000000 40005d488d000c80 1T ESID= 4 VSID=40005d488d LLP bits: 0
> 63 0000000018000000 0000633f90285c80 256M ESID= 1 VSID= 633f90285 LLP bits: 0
>
> sample output from power5 (notice the non-valid but non-zero entries)
>
> 00 c000000008000000 0000408f92c94500 256M ESID=c00000000 VSID= 408f92c94 LLP bits:100
> 01 d000000008000000 0000f09b89af5400 256M ESID=d00000000 VSID= f09b89af5 LLP bits: 0
> 03 0000000010000000 0000136eafb0bc80
> 11 0000000008000000 00005928811f2c80 256M ESID= 0 VSID= 5928811f2 LLP bits: 0
> 12 00000000f8000000 0000645ff8d87c80 256M ESID= f VSID= 645ff8d87 LLP bits: 0
> 13 0000000048000000 00005c263aa5ec80 256M ESID= 4 VSID= 5c263aa5e LLP bits: 0
> 14 0000000018000000 000059e7ef80dc80 256M ESID= 1 VSID= 59e7ef80d LLP bits: 0
> 15 0000000010000000 000059e7ef80dc80
>
> Tested on power5 and power6.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: Olof Johansson <olof@lixom.net>
This makes the output wider than 80 characters, but that's fine with me.
Thanks!
-Olof
^ permalink raw reply
* Re: PPC405GP Walnut irq patch
From: Josh Boyer @ 2007-10-31 1:40 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <4727A507.10309@harris.com>
On Tue, 30 Oct 2007 17:41:27 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:
> From: "Steven A. Falco" <sfalco@harris.com>
> To: linuxppc-dev@ozlabs.org
> Subject: Re: PPC405GP Walnut irq patch
> Date: Tue, 30 Oct 2007 17:41:27 -0400
> Sender: linuxppc-dev-bounces+jwboyer=gmail.com@ozlabs.org
> User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
>
> I realized that I should have done this from the root level. So here is
> the corrected patch.
>
> Signed-off-by: Steve Falco <sfalco at harris.com>
>
>
> Steven A. Falco wrote:
> > Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
> > the ethernet interrupts in the walnut.dts file doesn't match the
> > documentation. I discovered this when porting the BSP to a custom
> > board - the ethernet would not work. The attached patch corrects that.
> >
> > This is the first patch I am submitting, so please advise me if there
> > is anything I should do differently.
> >
> > Signed-off-by: Steve Falco <sfalco at harris.com>
> >
> >
>
> diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
> index 27bef06..dd65115 100644
> --- a/arch/powerpc/boot/dts/walnut.dts
> +++ b/arch/powerpc/boot/dts/walnut.dts
> @@ -67,7 +67,7 @@
> num-tx-chans = <2>;
> num-rx-chans = <1>;
> interrupt-parent = <&UIC0>;
> - interrupts = <a 4 b 4 c 4 d 4 e 4>;
> + interrupts = <b 4 c 4 a 4 d 4 e 4>;
> };
I fixed this part already. Seems your tree is slightly old.
>
> POB0: opb {
> @@ -117,7 +117,7 @@
> device_type = "network";
> compatible = "ibm,emac-405gp", "ibm,emac";
> interrupt-parent = <&UIC0>;
> - interrupts = <9 4 f 4>;
> + interrupts = <f 4 9 4>;
Could you redo the patch with just this bit and send it again?
josh
^ permalink raw reply
* Re: [PATCH] [powerpc v2] update xmon slb code
From: Paul Mackerras @ 2007-10-31 1:42 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev
In-Reply-To: <20071030215037.12776.73871.stgit@farscape.rchland.ibm.com>
Will Schmidt writes:
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from power6 (1T segment support):
>
> 00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID=40004f7ca3 LLP bits:100
The "4" at the top of the VSID is actually the B (segment size) field,
isn't it? Shouldn't that get masked off, since you have already
printed the segment size separately?
Also, if you removed the "bits" text, it would just about fit into 80
columns. I think "LLP" is sufficient, the "bits" is redundant.
Apart from that it looks good.
Regards,
Paul,
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Olof Johansson @ 2007-10-31 1:56 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20071030230805.GC2784@localhost.localdomain>
On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > PowerPC 440GRx Rainier DTS.
> [snip]
> > + SDRAM0: sdram {
> > + device_type = "memory-controller";
>
> How many times do we need to say it...
>
> Don't make up random device_type values. This does not belong here.
Maybe there should be something like checkpatch.pl that warns about
these kinds of things so people can check for it without getting flamed
first. :-)
Lots of people base their dts'es on other ones, so until the kernel has
bene clean a while, this will happen all the time. I'm saying "a while"
because people tend to base them on what's fresh when they do the work,
but it might take a few months between then and when they post, etc.
-Olof
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Josh Boyer @ 2007-10-31 2:09 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071031015651.GB19318@lixom.net>
On Tue, 30 Oct 2007 20:56:51 -0500
Olof Johansson <olof@lixom.net> wrote:
> On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > PowerPC 440GRx Rainier DTS.
> > [snip]
> > > + SDRAM0: sdram {
> > > + device_type = "memory-controller";
> >
> > How many times do we need to say it...
> >
> > Don't make up random device_type values. This does not belong here.
>
> Maybe there should be something like checkpatch.pl that warns about
> these kinds of things so people can check for it without getting flamed
> first. :-)
That's actually a decent idea. We could even have this thing that
takes DTS files and processes them... oh wait.
So why can't we make a whitelist of "allowed" device_types in DTC and
make it whine about anything outside of that?
josh
^ permalink raw reply
* Re: Merge dtc
From: David Gibson @ 2007-10-31 2:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: ppcdev, Paul Mackerras, Milton Miller
In-Reply-To: <20071019184249.GA32015@uranus.ravnborg.org>
On Fri, Oct 19, 2007 at 08:42:49PM +0200, Sam Ravnborg wrote:
> Hi David.
>
> > > Give me a day or two then I shall give it a try and see what I can
> > > do about it. I will use the previsous posted URL as basis if you do
> > > not tell me otherwise.
> >
> > Thank you. The previous URL should be fine, I've made no changes
> > since then.
>
> I decided to go for a kbuild specific version integrated
> in boot/Makefile.
> This is much more readable because this syntax is explicit.
> We do not favour 3 levels of variabls to avoid rewriting the same
> filename two times.
Well, yes, on consideration the substitutions in Makefile.dtc are a
bit over-involved. Although I still find describing its dozen or so
lines as unreadable when set next to the intricate wonders of Kbuild a
little... bemusing.
> I have tested the change only with a O=.. crosscompile build.
>
> I have tested the patch with and without DTC_GENPARSER=1.
> It does not rebuild if not needed and is OK with -j10 builds.
>
> Please consider this version in favour of your old version.
Ok. I'll use this version in my next spin; except for adding one
dependency you missed, and removing one which should never have been
there (unneccessary #include, which I've already fixed in dtc
upstream).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports
From: Stephen Rothwell @ 2007-10-31 2:50 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1193760559.6244.25.camel@p60635-ste.ids.de>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Tue, 30 Oct 2007 17:09:19 +0100 Sergej Stepanov <Sergej.Stepanov@ids.de> wrote:
>
> static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
> struct device_node *np)
> {
> - struct resource res;
> + struct resource res[2];
Why not just reuse the same resource structure? You don't seem to need
them both at the same time.
> + if( !of_address_to_resource(np, 1, &res[1]))
> + {
> + bitbang->mdio.dir = ioremap(res[1].start, res[1].end - res[1].start + 1);
> + if (!bitbang->mdio.dir)
> + {
> + iounmap(bitbang->mdc.dir);
> + return -ENOMEM;
> + }
> + bitbang->mdio.dat = bitbang->mdio.dir + 4;
> + }
> + else{
Formatting:
if () {
} else {
}
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
No spaces after (, please. Here and elsewhere.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: David Gibson @ 2007-10-31 2:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20071030210917.42cfb88b@vader.jdub.homelinux.org>
On Tue, Oct 30, 2007 at 09:09:17PM -0500, Josh Boyer wrote:
> On Tue, 30 Oct 2007 20:56:51 -0500
> Olof Johansson <olof@lixom.net> wrote:
>
> > On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > > PowerPC 440GRx Rainier DTS.
> > > [snip]
> > > > + SDRAM0: sdram {
> > > > + device_type = "memory-controller";
> > >
> > > How many times do we need to say it...
> > >
> > > Don't make up random device_type values. This does not belong here.
> >
> > Maybe there should be something like checkpatch.pl that warns about
> > these kinds of things so people can check for it without getting flamed
> > first. :-)
I'd be gentler; except that I know Valentine has been active on this
list recently, so has almost certainly seen similar comments before.
> That's actually a decent idea. We could even have this thing that
> takes DTS files and processes them... oh wait.
>
> So why can't we make a whitelist of "allowed" device_types in DTC and
> make it whine about anything outside of that?
Well, that sort of thing is the idea for dtc to check, when it has
checks enabled anyway. Getting it so that it doesn't have too many
false positives is the tricky bit, as we've seen with some of the
existing checks (where "too many" is "almost any").
Patches welcome...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
From: Stephen Rothwell @ 2007-10-31 3:11 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030165739.GA22126@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30 18:00:15.000000000 +0300
> +#include <linux/init.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/time.h>
> +#include <asm/uic.h>
> +#include <asm/of_platform.h>
You want <linux/of_platform.h>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [0/2] Embed a copy of dtc in the kernel source
From: David Gibson @ 2007-10-31 3:24 UTC (permalink / raw)
To: linuxppc-dev
These two patches are a respin of my previous patch to merge a copy of
dtc into the kernel tree, so that kernel builds no longer depend on an
externally installed copy of dtc.
This respin embeds a newer revision of dtc, and incorporates Sam
Ravnborg's preferred approach to Makefile integration. Also, since so
many people whinged about it last time, I've split the patch into two
parts, the first is the too-large-for-the-list patch just verbatim
adding files and the second has the changes to existing kernel files
to build and use the embedded code.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [1/2] Merge dtc
From: David Gibson @ 2007-10-31 3:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
This very large patch incorporates a copy of dtc into the kernel
source, in arch/powerpc/boot/dtc-src. This patch only imports the dtc
sources verbatim, another patch coming to actually link it into the
kernel Makefiles and use the embedded copy of dtc for kernel builds.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Too big for this list. Full patch at:
http://ozlabs.org/~dgibson/home/merge-dtc.patch
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [2/2] Use embedded dtc in kernel builds
From: David Gibson @ 2007-10-31 3:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
This patch alters the kernel makefiles to build dtc from the sources
embedded in the previous patch. It also changes the
arch/powerpc/boot/wrapper script to use the embedded dtc, rather than
expecting a copy of dtc already installed on the system.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/boot/Makefile 2007-10-22 13:55:49.000000000 +1000
+++ working-2.6/arch/powerpc/boot/Makefile 2007-10-31 14:02:40.000000000 +1100
@@ -108,17 +108,52 @@ $(patsubst %.S,%.o, $(filter %.S, $(src-
$(obj)/wrapper.a: $(obj-wlib) FORCE
$(call if_changed,bootar)
-hostprogs-y := addnote addRamDisk hack-coff mktree
+hostprogs-y := addnote addRamDisk hack-coff mktree dtc
targets += $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds
wrapper :=$(srctree)/$(src)/wrapper
-wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
+wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \
$(wrapper) FORCE
#############
+# Bits for building dtc
+# DTC_GENPARSER := 1 # Uncomment to rebuild flex/bison output
+
+dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o
+dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
+dtc-objs := $(addprefix dtc-src/, $(dtc-objs))
+
+# prerequisites on generated files needs to be explicit
+$(obj)/dtc-src/dtc-parser.tab.o: $(obj)/dtc-src/dtc-parser.tab.c $(obj)/dtc-src/dtc-parser.tab.h
+$(obj)/dtc-src/dtc-lexer.lex.o: $(obj)/dtc-src/dtc-lexer.lex.c $(obj)/dtc-src/dtc-parser.tab.h
+
+HOSTCFLAGS += -I$(src)/dtc-src/
+
+targets += dtc-src/dtc-parser.tab.c
+targets += dtc-src/dtc-lexer.lex.c
+
+ifdef DTC_GENPARSER
+BISON = bison
+FLEX = flex
+
+quiet_cmd_bison = BISON $@
+ cmd_bison = $(BISON) -o$@ -d $<; cp $@ $@_shipped
+quiet_cmd_flex = FLEX $@
+ cmd_flex = $(FLEX) -o$@ $<; cp $@ $@_shipped
+
+$(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE
+ $(call if_changed,bison)
+
+$(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c
+
+$(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE
+ $(call if_changed,flex)
+endif
+
+#############
# Bits for building various flavours of zImage
ifneq ($(CROSS32_COMPILE),)
@@ -236,7 +271,7 @@ install: $(CONFIGURE) $(addprefix $(obj)
# anything not in $(targets)
clean-files += $(image-) $(initrd-) zImage zImage.initrd cuImage.* treeImage.* \
- otheros.bld
+ otheros.bld $(dtc-clean-files)
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin
Index: working-2.6/arch/powerpc/boot/wrapper
===================================================================
--- working-2.6.orig/arch/powerpc/boot/wrapper 2007-10-22 13:55:50.000000000 +1000
+++ working-2.6/arch/powerpc/boot/wrapper 2007-10-31 14:02:40.000000000 +1100
@@ -111,7 +111,7 @@ if [ -n "$dts" ]; then
if [ -z "$dtb" ]; then
dtb="$platform.dtb"
fi
- dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+ $object/dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
fi
if [ -z "$kernel" ]; then
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [0/2] Embed a copy of dtc in the kernel source
From: Kumar Gala @ 2007-10-31 4:37 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071031032401.GD7772@localhost.localdomain>
On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
> These two patches are a respin of my previous patch to merge a copy of
> dtc into the kernel tree, so that kernel builds no longer depend on an
> externally installed copy of dtc.
>
> This respin embeds a newer revision of dtc, and incorporates Sam
> Ravnborg's preferred approach to Makefile integration. Also, since so
> many people whinged about it last time, I've split the patch into two
> parts, the first is the too-large-for-the-list patch just verbatim
> adding files and the second has the changes to existing kernel files
> to build and use the embedded code.
What about doing part of this via git-submodule?
- k
^ permalink raw reply
* Re: [0/2] Embed a copy of dtc in the kernel source
From: David Gibson @ 2007-10-31 4:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <DFBF9FAC-012A-47C6-9EC0-CDD365F67A97@kernel.crashing.org>
On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote:
>
> On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
>
> > These two patches are a respin of my previous patch to merge a copy of
> > dtc into the kernel tree, so that kernel builds no longer depend on an
> > externally installed copy of dtc.
> >
> > This respin embeds a newer revision of dtc, and incorporates Sam
> > Ravnborg's preferred approach to Makefile integration. Also, since so
> > many people whinged about it last time, I've split the patch into two
> > parts, the first is the too-large-for-the-list patch just verbatim
> > adding files and the second has the changes to existing kernel files
> > to build and use the embedded code.
>
> What about doing part of this via git-submodule?
Uh.. where do I find out what that does? My version of git (Ubuntu
gutsy) doesn't seem to know anything about it...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* ring on PowerPC
From: Bai Shuwei @ 2007-10-31 5:05 UTC (permalink / raw)
To: linuxppc-embedded, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
Hi, everyone
As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
3) and the linux kernel run in the ring 0 and user program in the ring 3.
And now I want to know wether there is a simple mechanism on the PowerPC
architecture? thx all!
best regards!
Buroc
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 675 bytes --]
^ permalink raw reply
* Re: ring on PowerPC
From: Grant Likely @ 2007-10-31 5:18 UTC (permalink / raw)
To: Bai Shuwei; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <f3566d60710302205g2dd867bbk8a3494ceeda569f0@mail.gmail.com>
On 10/30/07, Bai Shuwei <baishuwei@gmail.com> wrote:
> Hi, everyone
> As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> And now I want to know wether there is a simple mechanism on the PowerPC
> architecture? thx all!
Powerpc has 2 privilege levels; user and supervisor. The kernel runs
in supervisor mode, and user-space runs in user mode.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: KAMEZAWA Hiroyuki @ 2007-10-31 5:28 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <1193771951.8904.22.camel@dyn9047017100.beaverton.ibm.com>
On Tue, 30 Oct 2007 11:19:11 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> Hi KAME,
>
> As I mentioned while ago, ppc64 does not export information about
> "system RAM" in /proc/iomem. Looking at the code and usage
> scenerios I am not sure what its really serving. Could you
> explain what its purpose & how the range can be invalid ?
>
Hm, I added walk_memory_resource() for hot-add, at first.
Size of memory section is fixed and just depend on architecture, but
any machine can have any memory-hole within continuous memory-section-size
range of physical memory. Then we have to detect which page can be
target of online_page() and which are leaved as Reserved.
ioresource was good structure for remembering "which memory is conventional
memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
when I posted patch. (just say "System Ram" is not for memory hotplug.)
I used walk_memory_resource() again in memory hotremove.
(If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add.
than our ia64 box.
In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some
"for firmware" area in newly-added node.)
> At least on ppc64, all the memory ranges we get passed comes from
> /sysfs memblock information and they are guaranteed to match
> device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
> and it will be part of the /proc/device-tree entry. Since we do
> "online" or "offline" to /sysfs entries to add/remove pages -
> these ranges are guaranteed to be valid.
>
ok.
> Since this check is redundant for ppc64, I propose following patch.
> Is this acceptable ? If some one really really wants, I can code
> up this to walk lmb or /proc/device-tree and verify the range &
> adjust the entries for overlap (I don't see how that can happen).
>
ok. If ppc64 guarantees "there is no memory hole in section", please try.
I have no objection.
I just would like to ask to add some text to explain
"ppc64 doesn't need to care memory hole in a section."
Thanks,
-Kame
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: KAMEZAWA Hiroyuki @ 2007-10-31 5:34 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-mm, Paul Mackerras, anton, Badari Pulavarty, linuxppc-dev
In-Reply-To: <20071031142846.aef9c545.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 31 Oct 2007 14:28:46 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch. (just say "System Ram" is not for memory hotplug.)
>
If I remember correctly, System RAM is for kdump (to know which memory should
be dumped.) Then, memory-hotadd/remove has to modify it anyway.
Thanks,
-Kame
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox