* Re: RFC: replace device_type with new "class" property?
From: Dale Farnsworth @ 2007-10-29 23:03 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359FB6A@az33exm25.fsl.freescale.net>
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
> #4 use "compatible"
>
> ucc@2200 {
> compatible = "fsl,ucc_geth","[official spec],network";
> model = "UCC";
> device-id = <3>;
> reg = <2200 200>;
> interrupts = <22>;
> interrupt-parent = < &qeic >;
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> rx-clock = <19>;
> tx-clock = <1a>;
> phy-handle = < &phy3 >;
> pio-handle = < &pio3 >;
> };
>
> > I don't like this...we are overloading "compatible" with
> > stuff that is not specifying a programming interface. compatible
> > is supposed to be specifying a programming interface which
> > the device complies to.
If your proposed class property doesn't specify a programming interface,
then I agree that we shouldn't put that info in compatible. My point
was that compatible is the one and only property that a driver should
look at to find a node with a suitable programming interface.
But, that begs the question: How will the code use your class property?
Another post implied that it's for human-readable purposes. If that's
all, I'd leave it out, or use a comment instead.
-Dale
^ permalink raw reply
* Re: [PATCH] [powerpc] update xmon slb code
From: Benjamin Herrenschmidt @ 2007-10-29 23:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Will Schmidt, paulus
In-Reply-To: <20071029205254.GA27544@lixom.net>
> Nice, I like it! I wonder if it would make sense to (space) pad the
> ESID/VSID fields so they line up, it'd make output just a little tidier.
>
> (If you end up changing that, please also break the long printf lines
> in two.)
>
> Beside that it looks good to me! :)
Can you also print out the LLP bits ? (I won't ask you to also decode
the page size though that would be useful :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
From: Stephen Rothwell @ 2007-10-29 23:33 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071029183218.19914.51410.stgit@farscape.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hi Will,
Just a trivial comment ...
On Mon, 29 Oct 2007 13:32:19 -0500 Will Schmidt <will_schmidt@vnet.ibm.com> wrote:
>
> +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));
Please use spaces around binary operators (as you have elsewhere). Even
if it pushes the line slightly over 80 characters ...
--
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: boot/wrap assumes a biarch toolchain?
From: Andreas Schwab @ 2007-10-29 23:34 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linuxppc-dev, Jan Dittmer, Anton Blanchard
In-Reply-To: <47265586.1050701@l4x.org>
Jan Dittmer <jdi@l4x.org> writes:
> Same error, you write above that a newer compiler version should
> not need -m32 or --with-cpu=default32 any more?
??? Where did I say that?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] MTD: small physmap_of partition parsing fixes
From: David Gibson @ 2007-10-30 0:10 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20071029202902.GA2200@ru.mvista.com>
On Mon, Oct 29, 2007 at 11:29:02PM +0300, Valentine Barshak wrote:
> Use of_get_next_child for proper ref counting as suggested by Stephen Rothwell
> and remove add_mtd_partitions from parse_partitions to avoid duplicate
> mtd device registration for RedBoot partitions.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Oops, yes. I think the extra add_mtd_partitions() was left over from
an earlier version which always did the add_mtd_partitions() from
within the probe function.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
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 0:23 UTC (permalink / raw)
To: Scott Wood; +Cc: Yoder Stuart-B08248, linuxppc-dev
In-Reply-To: <20071029161140.GA4358@loki.buserror.net>
On Mon, Oct 29, 2007 at 11:11:40AM -0500, Scott Wood wrote:
> On Mon, Oct 29, 2007 at 03:20:56PM +0000, Matt Sealey wrote:
> > I think device_type, compatible and model properties fulfil
> > this already, they simply aren't being used correctly.
>
> device_type has a few drawbacks, though:
>
> 1. You can only specify one type, whereas with a new property we could
> define it as a list (similar to compatible). It's possible for one node to
> comply with multiple class bindings, such as when there's a binding for
> clients of the type of bus it's on as well as the type of device it is, or
> when there are multiple levels of detail (such as complying with both
> simple-bus and some specific bus binding).
>
> 2. We want to avoid any confusion with OF bindings and abused device_type
> entries that have been allowed to become existing practice.
>
> 3. It's the only standard property (AFAIK) with an underscore in it. :-)
>
> > Remember that, while you may want to make FDTs easier to
> > design, OpenFirmware and the requirement on device interfaces
> > through the client interface still exist and are still
> > implemented (from time to time).
>
> Sure -- and we don't want to risk the code thinking it can call into OF
> based on what we put in a flat device tree, right?
>
> > For readability, the name of the device needn't match device_type;
> > for instance on the 5121E it may be that the 'diu' unit be
> > called diu, but be of device_type 'display'
>
> I don't think that's more readable than setting the name to display.
> Something containing "diu" will be in the compatible list.
>
> > Further differentiation should be done through the 'model'
> > property in my opinion. This is optional in the OpenFirmware
> > spec, but that does not mean it should be important. It is
> > currently defined as something to determine the exact model
> > of a chip in order to enable quirks, bugfixes and suchlike,
> > but most implementations switch on something else entirely
> > (like SVR or a heuristic behaviour).
> >
> > Selecting the "model" would be no different to, for example,
> > having a list of PCI IDs that will work with a driver.
>
> It's what we currently do with compatible. Why break it into two
> properties?
>
> The PCI ID thing can be quite a headache, BTW, when you get a new PCI device
> that won't work with the existing driver, for no reason other than that it
> hasn't been updated with the new ID.
Indeed. Replacing the flexible string based matching we have already,
with a limited ID based matching is just silly.
> > There was a little discussion at bplan once that it would be
> > easier to implement a kind of vendor/device id system much
> > like PCI, USB etc. implements in hardware in order to match
> > hardware. I suppose you could use a "class" property to
> > implement this -
>
> No, you should use compatible for that.
Yes. Driver binding should be based on compatible. Period. Drivers
can enable quirks based on 'model' or any other information available
to them (either from the device tree or direct from the hardware).
--
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 0:26 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071029172724.11354.qmail@farnsworth.org>
On Mon, Oct 29, 2007 at 10:27:24AM -0700, Dale Farnsworth wrote:
> Scott wrote:
> > Personally, I'm fine with just using name and compatible, but others such as
> > Stuart have expressed a desire for something to formally indicate compliance
> > with a standard binding. I don't think we should expand the use of
> > device_type in any case.
>
> I agree that the existing compatible property is sufficient to do
> what Stuart wants. All that is required is to define some standard
> bindings and give them well-known names for the compatible property.
> If needed, we could define a prefix that indicates that a compatible
> entry refers to a standards-compliant binding. For example,
> "standard,network", or "standard,display". I don't see the benefit
> of creating a new property similar to device_type.
That would overload the meaning of compatible. A driver which matches
any compatible entry should be able to drive the device, even if it
can't use all the devices features. You can't do that if all you know
is that something is a display.
So, standardised or defacto-standard hardware-level interfaces belong
in compatible, e.g. ohci, uhci, ns16550. The mere fact that something
is a display or network interface (and has *general* properties
related to such devices) doesn't let you drive 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
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 0:29 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359FB6A@az33exm25.fsl.freescale.net>
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
>
> Here's an example of what I'm trying to get at-- take
> a node from a FSL device tree. The ideas I've heard
> for expressing the class are like this--
>
> #1 don't express any class at all:
>
> ucc@2200 {
> compatible = "fsl,ucc_geth";
> model = "UCC";
> device-id = <3>;
> reg = <2200 200>;
> interrupts = <22>;
> interrupt-parent = < &qeic >;
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> rx-clock = <19>;
> tx-clock = <1a>;
> phy-handle = < &phy3 >;
> pio-handle = < &pio3 >;
>
>
> > This is bad IMHO because the human reader has to
> > infer the class of device. Can the human reader
> > tell if it implements a standardized binding or
> > not??
Well... except that by the generic names convention, the node should
be called "ethernet@2200", which makes it rather clearer to a human
reader.
--
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 0:51 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <20071029212213.GA28073@lixom.net>
On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote:
[snip]
> I don't see how switching the property name from "device_type" to
> "class" is going to stop people from misunderstanding it's intended
> use. There's nothing inherently more understandable in calling it
> "class" -- it also invites people to make up their own class names
> as they go along, just as what happened to "device_type".
>
> I also don't understand the people wanting to use "compatible"
> for _everything_. It's just mashing together two separate pieces of
> information into one property, and I seriously don't see how that helps
> anything or anyone. It's absolutely useless for a driver to be able to
> bind to a compatible field of "standard,network" or whatever it might be,
> since there's no way that "standard," will imply that the register layout
> and programming model is somehow the same as all other standard-labelled
> devices.
>
> So yes, there is a problem with the device trees and how people build
> them, and it requires education on how to properly craft one. I don't
> think changing the layout to either be flatter (only using compatible),
> or changing names of a property (device_type->class) will help anything
> at all.
>
> I actually prefer keeping device_type myself, since it means existing
> OF-based device trees will already have some of the labels.
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.
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.
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.
--
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 05/11] [POWERPC] TQM5200 DTS
From: David Gibson @ 2007-10-30 0:58 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Marian Balakowicz, Martin Krause
In-Reply-To: <fa686aa40710290840w41e2ffeo38b9497ce76e155@mail.gmail.com>
On Mon, Oct 29, 2007 at 09:40:23AM -0600, Grant Likely wrote:
> On 10/29/07, Marian Balakowicz <m8@semihalf.com> wrote:
> > David Gibson wrote:
> > > On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
> > >> Grant Likely wrote:
> > >>> On 10/25/07, Martin Krause <Martin.Krause@tqs.de> wrote:
> > > [snip]
> > >>>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
> > >>>> partition could not be used. "big-fs", because the memory is too small
> > >>>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
> > >>>> flash border. So only the first 9 MiB of the flash could be used in Linux.
> > >>>> The remaining 7 MiB couldn't be accessed.
> > >>> Perhaps it would be better to drop the flash layout from the in-kernel
> > >>> dts files entirely since flash layout can be a fluid thing.
> > >> Well, but that would not be really user friendly, I'd rather stick
> > >> with some default config.
> > >
> > > Strictly speaking the device-tree is not the right place for flash
> > > partitioning information. We put it there because it's preferable to
> > > having hardcoded per-board flash layouts in the code itself.
> > >
> > > It only really works well, though, when there are strong conventions
> > > (shared with the firmware) about how to partition the flash.
> > >
> > > Where it's really up to the user to determine how they want to lay out
> > > their flash, putting things in the device tree isn't a really good
> > > idea.
> >
> > In principle, you are right, we should not be putting a user dependent
> > configuration into .dts files. But on the other hand, bindings have
> > been defined for flash-like devices and their partition layouts and
> > physmap_of device driver is expecting to get this information from the
> > blob. So, it is the place for it. But if we are not to put partition
> > layouts into the default kernel .dts files then we should
> > provide/maintain some examples an that may be a even bigger mess.
> >
> > > Incidentally, it's not required that *all* the flash address space be
> > > in partitions, so it is possible only give partitions for those flash
> > > chunks which the firmware needs to know about.
> >
> > That might be nicer solution but different variants of TQM5200 boards
> > do not share the same subset of partitions (default u-boot partitions
> > at least), so it will not help much.
>
> It's probably more appropriate to have the flash partition layout in
> the u-boot environment and have u-boot populate the partition
> information in the device tree.
That sounds like a reasonable idea.
But if the flash partition layout is *not* fixed - but selectable by
the board installer, then it should certainly not be hardcoded into a
fixed dts.
--
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 0/3] Add device-tree aware NDFC driver
From: Thomas Gleixner @ 2007-10-30 1:49 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <20071029201738.GA2022@ru.mvista.com>
On Mon, 29 Oct 2007, Valentine Barshak wrote:
> This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
> The code is based on the original NDFC driver by Thomas Gleixner, but
> since it's been changed much and has initialization/clean-up completely
> reworked it's been put into a separate ndfc_of.c file. This version
> supports both separate mtd devices on each chip attached to NDFC banks and
> single mtd device spread across identical chips (not using mtdconcat) as well.
> The choice is selected with device tree settings. This has been tested
> on PowerPC 440EPx Sequoia board.
> Any comments are greatly appreciated.
Did I express myself not clear enough in my first reply or is this
just a repeated epiphany in my inbox ?
You got plenty of comments to your patches, but you decided to ignore
them silently.
Darn, fix it the right way once and forever and please don't try to
tell me another heartrending "why I did it my way" story.
This all can be done with a nice series of incremental patches
including a fixup to the existing users.
We have enough dump and run shit in the kernel already.
No thanks,
tglx
^ permalink raw reply
* dtc: Remove leftover debugging printf() from mangle-layout
From: David Gibson @ 2007-10-30 2:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
The mangle-layout testcase/utility had a leftover debugging printf().
This patch removes it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/mangle-layout.c
===================================================================
--- dtc.orig/tests/mangle-layout.c 2007-10-29 15:58:55.000000000 +1100
+++ dtc/tests/mangle-layout.c 2007-10-29 15:59:16.000000000 +1100
@@ -96,8 +96,6 @@ void add_block(struct bufstate *buf, int
}
offset = ALIGN(buf->size, align);
- fprintf(stderr, "Moving block %c from %p, to offset %d, size %d\n",
- block, src, offset, size);
expand_buf(buf, offset+size);
--
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
* libfdt: Correctly handle versions > 17
From: David Gibson @ 2007-10-30 2:22 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
If future dtb version > 17 are defined, that are still backwards
compatible with v16, libfdt will of course be able to read and
understand them. However, when modifying such a tree, it can't
guarantee that it won't clobber additional structure from the new
version which it doesn't know about. Therefore, before making
modifications to a tree of version >17, we must change it's version to
be exactly 17.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/fdt_rw.c
===================================================================
--- dtc.orig/libfdt/fdt_rw.c 2007-10-29 16:09:23.000000000 +1100
+++ dtc/libfdt/fdt_rw.c 2007-10-29 16:34:37.000000000 +1100
@@ -61,7 +61,7 @@ static int rw_check_header(void *fdt)
if ((err = fdt_check_header(fdt)))
return err;
- if (fdt_version(fdt) < 0x11)
+ if (fdt_version(fdt) < 17)
return -FDT_ERR_BADVERSION;
if (fdt_off_mem_rsvmap(fdt) < ALIGN(sizeof(struct fdt_header), 8))
return -FDT_ERR_BADLAYOUT;
@@ -74,6 +74,9 @@ static int rw_check_header(void *fdt)
if (fdt_totalsize(fdt) <
(fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)))
return -FDT_ERR_BADLAYOUT;
+ if (fdt_version(fdt) > 17)
+ fdt_set_version(fdt, 17);
+
return 0;
}
--
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: Fix 4xx flush_tlb_page()
From: Kumar Gala @ 2007-10-30 3:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071029224624.68205DE157@ozlabs.org>
On Oct 29, 2007, at 5:46 PM, Benjamin Herrenschmidt wrote:
> On 4xx CPUs, the current implementation of flush_tlb_page() uses
> a low level _tlbie() assembly function that only works for the
> current PID. Thus, invalidations caused by, for example, a COW
> fault triggered by get_user_pages() from a different context will
> not work properly, causing among other things, gdb breakpoints
> to fail.
>
> This patch adds a "pid" argument to _tlbie() on 4xx processors,
> and uses it to flush entries in the right context. FSL BookE
> also gets the argument but it seems they don't need it (their
> tlbivax form ignores the PID when invalidating according to the
> document I have).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> arch/powerpc/kernel/misc_32.S | 23 ++++++++++++++++-------
> arch/powerpc/mm/fault.c | 2 +-
> arch/powerpc/mm/mmu_decl.h | 4 ++--
> arch/ppc/kernel/misc.S | 22 +++++++++++++++-------
> arch/ppc/mm/fault.c | 2 +-
> arch/ppc/mm/mmu_decl.h | 4 ++--
> arch/ppc/platforms/4xx/ebony.c | 2 +-
> arch/ppc/platforms/4xx/ocotea.c | 2 +-
> arch/ppc/platforms/4xx/taishan.c | 2 +-
> include/asm-powerpc/tlbflush.h | 12 ++++++------
> 10 files changed, 46 insertions(+), 29 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
From: Kumar Gala @ 2007-10-30 3:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18213.19469.827909.663373@cargo.ozlabs.ibm.com>
On Oct 28, 2007, at 9:57 PM, Paul Mackerras wrote:
> The decrementer in Book E and 4xx processors interrupts on the
> transition from 1 to 0, rather than on the 0 to -1 transition as on
> 64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors.
>
> This fixes the problem by making set_dec subtract 1 from the count for
> server and classic processors. Since set_dec already had a bunch of
> ifdefs to handle different processor types, there is no net increase
> in ugliness. :)
>
> This also removes a redundant call to set the decrementer to
> 0x7fffffff - it was already set to that earlier in timer_interrupt.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
...
> diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
> index f058955..eed64bd 100644
> --- a/include/asm-powerpc/time.h
> +++ b/include/asm-powerpc/time.h
> @@ -183,6 +183,7 @@ static inline void set_dec(int val)
> #elif defined(CONFIG_8xx_CPU6)
> set_dec_cpu6(val);
> #else
> + --val; /* classic decrementer interrupts when dec goes negative */
> #ifdef CONFIG_PPC_ISERIES
> int cur_dec;
>
Unless I'm reading set_dec() you are getting --val on booke.
- k
^ permalink raw reply
* [PATCH] Fix build failure in platforms/celleb/setup.c which CONFIG_VIRT_CPU_ACCOUNTING is not defined.
From: Tony Breeds @ 2007-10-30 3:55 UTC (permalink / raw)
To: LinuxPPC-dev, cbe-oss-dev
Without this patch I get the following build failure
CC arch/powerpc/platforms/celleb/setup.o
arch/powerpc/platforms/celleb/setup.c:151: error: 'generic_calibrate_decr' undeclared here (not in a function)
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/celleb/setup.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/setup.c b/arch/powerpc/platforms/celleb/setup.c
index 1769d75..ddfb35a 100644
--- a/arch/powerpc/platforms/celleb/setup.c
+++ b/arch/powerpc/platforms/celleb/setup.c
@@ -49,6 +49,7 @@
#include <asm/machdep.h>
#include <asm/cputable.h>
#include <asm/irq.h>
+#include <asm/time.h>
#include <asm/spu_priv1.h>
#include <asm/firmware.h>
#include <asm/of_platform.h>
--
1.5.3.4
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
From: Benjamin Herrenschmidt @ 2007-10-30 4:17 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071029183218.19914.51410.stgit@farscape.rchland.ibm.com>
On Mon, 2007-10-29 at 13:32 -0500, Will Schmidt wrote:
> [Powerpc V2] 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>
^ permalink raw reply
* [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
From: Benjamin Herrenschmidt @ 2007-10-30 5:16 UTC (permalink / raw)
To: linuxppc-dev
The 44x family has an interesting "feature" which is a virtually
tagged instruction cache (yuck !). So far, we haven't dealt with
it properly, which means we've been mostly lucky or people didn't
report the problems, unless people have been running custom patches
in their distro...
This is an attempt at fixing it properly. I chose to do it by
setting a global flag whenever we change a PTE that was previously
marked executable, and flush the entire instruction cache upon
return to user space when that happens.
This is a bit heavy handed, but it's hard to do more fine grained
flushes as the icbi instruction, on those processor, for some very
strange reasons (since the cache is virtually mapped) still requires
a valid TLB entry for reading in the target address space, which
isn't something I want to deal with.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Fortunately, we don't support SMP on these or this solution wouldn't
work.
It does mean we do a bit of over-flushing on swap but on the
other hand, the code is simple. Another option would have been
to do the iccci after any syscall that potentially unmaps or
changes a mapping, like sys_munmap, sys_mremap, sys_sbrk, but
also the shmem stuff etc... I decided there was just too many
and was worried I would miss one.
This not very tested as I don't have a test case at hand showing the
problem and didn't feel like writing one today :-) It boots though.
Careful eyes will notice I didn't do the flush on fast_exception_return,
which shouldn't be necessary.
arch/powerpc/kernel/entry_32.S | 25 +++++++++++++++++++++++++
arch/powerpc/kernel/misc_32.S | 9 +++++++++
arch/powerpc/mm/44x_mmu.c | 1 +
include/asm-powerpc/pgtable-ppc32.h | 13 +++++++++++++
4 files changed, 48 insertions(+)
Index: linux-work/arch/powerpc/kernel/entry_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/entry_32.S 2007-10-15 11:19:35.000000000 +1000
+++ linux-work/arch/powerpc/kernel/entry_32.S 2007-10-30 16:09:51.000000000 +1100
@@ -244,6 +244,13 @@ syscall_exit_cont:
andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ bne- 2f
+1:
+#endif /* CONFIG_44x */
stwcx. r0,0,r1 /* to clear the reservation */
lwz r4,_LINK(r1)
lwz r5,_CCR(r1)
@@ -259,6 +266,13 @@ syscall_exit_cont:
SYNC
RFI
+#ifdef CONFIG_44x
+2: li r7,0
+ iccci r0,r0
+ stw r7,icache_44x_need_flush@l(r4)
+ b 1b
+#endif /* CONFIG_44x */
+
66: li r3,-ENOSYS
b ret_from_syscall
@@ -683,6 +697,17 @@ resume_kernel:
/* interrupts are hard-disabled at this point */
restore:
+#ifdef CONFIG_44x
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+ beq+ 1f
+ iccci r0,r0
+ li r6,0
+ iccci r0,r0
+ stw r6,icache_44x_need_flush@l(r4)
+1:
+#endif /* CONFIG_44x */
lwz r0,GPR0(r1)
lwz r2,GPR2(r1)
REST_4GPRS(3, r1)
Index: linux-work/arch/powerpc/mm/44x_mmu.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/44x_mmu.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/powerpc/mm/44x_mmu.c 2007-10-30 15:30:50.000000000 +1100
@@ -35,6 +35,7 @@
*/
unsigned int tlb_44x_index; /* = 0 */
unsigned int tlb_44x_hwater = PPC44x_TLB_SIZE - 1 - PPC44x_EARLY_TLBS;
+int icache_44x_need_flush;
/*
* "Pins" a 256MB TLB entry in AS0 for kernel lowmem
Index: linux-work/include/asm-powerpc/pgtable-ppc32.h
===================================================================
--- linux-work.orig/include/asm-powerpc/pgtable-ppc32.h 2007-09-28 11:42:10.000000000 +1000
+++ linux-work/include/asm-powerpc/pgtable-ppc32.h 2007-10-30 15:30:50.000000000 +1100
@@ -11,6 +11,11 @@
extern unsigned long va_to_phys(unsigned long address);
extern pte_t *va_to_pte(unsigned long address);
extern unsigned long ioremap_bot, ioremap_base;
+
+#ifdef CONFIG_44x
+extern int icache_44x_need_flush;
+#endif
+
#endif /* __ASSEMBLY__ */
/*
@@ -562,6 +567,10 @@ static inline unsigned long pte_update(p
: "=&r" (old), "=&r" (tmp), "=m" (*p)
: "r" (p), "r" (clr), "r" (set), "m" (*p)
: "cc" );
+#ifdef CONFIG_44x
+ if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC))
+ icache_44x_need_flush = 1;
+#endif
return old;
}
#else
@@ -582,6 +591,10 @@ static inline unsigned long long pte_upd
: "=&r" (old), "=&r" (tmp), "=m" (*p)
: "r" (p), "r" ((unsigned long)(p) + 4), "r" (clr), "r" (set), "m" (*p)
: "cc" );
+#ifdef CONFIG_44x
+ if ((old & _PAGE_USER) && (old & _PAGE_HWEXEC))
+ icache_44x_need_flush = 1;
+#endif
return old;
}
#endif
Index: linux-work/arch/powerpc/kernel/misc_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-10-30 15:15:03.000000000 +1100
+++ linux-work/arch/powerpc/kernel/misc_32.S 2007-10-30 15:30:50.000000000 +1100
@@ -543,12 +543,21 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_I
addi r3,r3,L1_CACHE_BYTES
bdnz 0b
sync
+#ifndef CONFIG_44x
+ /* We don't flush the icache on 44x. Those have a virtual icache
+ * and we don't have access to the virtual address here (it's
+ * not the page vaddr but where it's mapped in user space). The
+ * flushing of the icache on these is handled elsewhere, when
+ * a change in the address space occurs, before returning to
+ * user space
+ */
mtctr r4
1: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 1b
sync
isync
+#endif /* CONFIG_44x */
blr
/*
^ permalink raw reply
* [Fwd: mpc8xx, i2c read DB busy issue]
From: Ankur Maheshwari @ 2007-10-30 5:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: mpc8xx, i2c read DB busy issue.eml --]
[-- Type: message/rfc822, Size: 1421 bytes --]
From: Ankur Maheshwari <ankur_maheshwari@procsys.com>
To: linuxppc-embedded@ozlabs.org
Subject: mpc8xx, i2c read DB busy issue
Date: Fri, 26 Oct 2007 15:00:31 +0530
Message-ID: <4721B3B7.8070602@procsys.com>
Hi all,
I am trying to use mpc860 as i2c-SLAVE. Kernel, I am using is
Linux-2.4.4, which I can't change due to some reasons.
I am able to do I2C read/write operations on mpc8xx-i2c slave only after
re-insmoding my driver module (i2c-algo-8xx.c, and adapter layer drive,
code I took form i2c-rpx/r360.c ).
The issue I am facing is when I insmod i2c-driver on fresh Linux boot,
any i2c-mpc860 as slave read/write operation gives me busy status (which
is for Rx BD not available) in Controller's i2c Event Registers. When I
get busy status I have to do force_close() and re-init of bd, then only
busy status goes off.
I tried calling cpm_iic_init(); twice while __init but with no change in
busy status.
After some initial try, i2c slave write works but i2c read gives no data
to the master. After re-insmoding driver, read/write works with some
times (1 out of 15 times) i2c-read failing.
But still I can't understand why busy is coming....
Any help or suggestions are highly appreciated.
thanks,
Ankur Maheshwari
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: Grant Likely @ 2007-10-30 5:58 UTC (permalink / raw)
To: Grant Likely, Marian Balakowicz, linuxppc-dev, Martin Krause
In-Reply-To: <20071030005833.GI29263@localhost.localdomain>
On 10/29/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Oct 29, 2007 at 09:40:23AM -0600, Grant Likely wrote:
> > It's probably more appropriate to have the flash partition layout in
> > the u-boot environment and have u-boot populate the partition
> > information in the device tree.
>
> That sounds like a reasonable idea.
>
> But if the flash partition layout is *not* fixed - but selectable by
> the board installer, then it should certainly not be hardcoded into a
> fixed dts.
Exactly my point! :-)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Jan Dittmer @ 2007-10-30 7:30 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <je640pebqn.fsf@sykes.suse.de>
Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
>
>> Same error, you write above that a newer compiler version should
>> not need -m32 or --with-cpu=default32 any more?
>
> ??? Where did I say that?
Your mail from 2007-10-29 4:39 pm (CET)
>> Your compiler still needs -m32 to generate 32-bit code (or use
>> --with-cpu=default32 to make that the default).
See the 'still' ? I just assumed that it must have been changed
in newer versions.
But to sum up. I've to compile with '--with-cpu=default32' and all
should be fine? Because I have no idea how to pass the -m32 flag
just to the 32-bit code generation. Passing it via CFLAGS obviously
does not work as it also passes it to the 64 bit code generation.
Jan
^ permalink raw reply
* Re: compile warning
From: Sergej Stepanov @ 2007-10-30 7:43 UTC (permalink / raw)
To: linux-ppc, Kumar Gala
In-Reply-To: <77CDBB94-A21E-4A84-9818-4622CB2F572C@kernel.crashing.org>
thanks for your reply.
> >
> > WARNING: vmlinux.o(.text+0x10f5c): Section mismatch: reference
> > to .init.text:cpm_muram_init (between 'cpm2_reset' and
> > 'cpm2_smc_clk_setup')
> >
> It should be fixed, but its highly unlikely you'll see a problem
> unless you start trying to build core parts of the CPM code as modules.
>
> - k
we have no modules for CPM.
Fix it i could with :
diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c
index f8a621e..f507ada 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -61,7 +61,7 @@ cpm2_map_t __iomem *cpm2_immr;
of space for CPM as it is larger
than on PQ2 */
-void
+void __init
cpm2_reset(void)
{
#ifdef CONFIG_PPC_85xx
------------------
I am not sure it is ok.
But i have other 2 warnings (no modules).
WARNING: vmlinux.o(.exit.text+0x5da): Section mismatch: reference to .init.data:of_platform_serial_driver (between 'of_platform_serial_exit' and 'phy_exit')
WARNING: vmlinux.o(.exit.text+0x5e2): Section mismatch: reference to .init.data:of_platform_serial_driver (between 'of_platform_serial_exit' and 'phy_exit')
Regards.
--
Sergej Stepanov
IDS GmbH
Nobelstr. 18, Zim. 2.1.05
D-76275 Ettlingen
T +49 (0) 72 43/2 18-615
F +49 (0) 72 43/2 18-400
http://www.ids.de
Email: Sergej.Stepanov@ids.de
^ permalink raw reply related
* Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Luis R. Rodriguez @ 2007-10-30 7:44 UTC (permalink / raw)
To: Dale Farnsworth
Cc: netdev, Tzachi Perelstein, Lennert Buytenhek, Jeff Garzik,
linuxppc-dev
In-Reply-To: <20071029223900.GA7097@xyzzy.farnsworth.org>
On 10/29/07, Dale Farnsworth <dale@farnsworth.org> wrote:
> On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> > This commit made an incorrect assumption:
> > --
> > Author: Lennert Buytenhek <buytenh@wantstofly.org>
> > Date: Fri Oct 19 04:10:10 2007 +0200
> >
> > mv643xx_eth: Move ethernet register definitions into private header
> >
> > Move the mv643xx's ethernet-related register definitions from
> > include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
> > they aren't of any use outside the ethernet driver.
> >
> > Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> > Acked-by: Tzachi Perelstein <tzachi@marvell.com>
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > --
> >
> > arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
> >
> > mcgrof@pogo:~/devel/wireless-2.6$ git-describe
> >
> > v2.6.24-rc1-138-g0119130
> >
> > This patch fixes this by internalizing 3 defines onto pegasos which are
> > simply no longer available elsewhere. Without this your compile will fail
>
> That compile failure was fixed in commit
> 30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro.
>
> However, as I examine that commit, I see that it defines offsets from
> the eth block in the chip, rather than the full chip registeri block
> as the Pegasos 2 code expects. So, I think it fixes the compile
> failure, but leaves the Pegasos 2 broken.
>
> Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that
> the following patch is needed for the Pegasos 2?
Nope, sorry.
Luis
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Christoph Raisch @ 2007-10-30 8:39 UTC (permalink / raw)
To: michael
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <1193610737.9637.1.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> wrote on 28.10.2007 23:32:17:
>
>
> How do you plan to support kdump?
>
When kexec is fully supported kdump should work out of the box
as for any other ethernet card (if you load the right eth driver).
There's nothing specific to kdump you have to handle in
ethernet device drivers.
Hope I didn't miss anything here...
Gruss / Regards
Christoph R
^ permalink raw reply
* RE: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
From: Zhang Wei-r63237 @ 2007-10-30 8:40 UTC (permalink / raw)
To: Kumar Gala, pterry; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <B485F0BB-A5C5-4059-8BE1-7020701EB818@kernel.crashing.org>
Yes, I'm working on it. Do not worry about it.
Wei.=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Tuesday, October 30, 2007 4:31 AM
> To: pterry@micromemory.com
> Cc: Zhang Wei-r63237; mporter@kernel.crashing.org;=20
> paulus@samba.org; linuxppc-dev@ozlabs.org;=20
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/5 v3] Porting RapidIO driver from ppc=20
> to powerpc architecture and adding memory mapped RapidIO driver.
>=20
>=20
> On Oct 29, 2007, at 2:38 PM, Phil Terry wrote:
>=20
> > Can anyone tell me what the status of these are? What kernel =20
> > release are
> > they targetted for? Currently I'm trying to work with 2.6.23 plus =20
> > these
> > patches locally.
>=20
> hopefully 2.6.25. I'd like to get the documentation updates in =20
> 2.6.24 if we have agreement on them.
>=20
> - k
>=20
^ 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