* Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-03-31 16:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
I'd like to get these minor fixes into 2.6.25. They aren't critical but
extremely convenient at this point.
to receive the following updates:
arch/powerpc/boot/dts/mpc8377_mds.dts | 4 ++--
arch/powerpc/boot/dts/mpc8377_rdb.dts | 3 +--
arch/powerpc/boot/dts/mpc8378_rdb.dts | 3 +--
arch/powerpc/boot/dts/mpc8379_mds.dts | 8 ++++----
arch/powerpc/boot/dts/mpc8379_rdb.dts | 3 +--
arch/powerpc/configs/mpc832x_mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc834x_mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc836x_mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc837x_rdb_defconfig | 24 +++++++++++++++++++++++-
arch/powerpc/configs/mpc83xx_defconfig | 24 +++++++++++++++++++++++-
arch/powerpc/configs/mpc8544_ds_defconfig | 11 +++--------
arch/powerpc/configs/mpc8568mds_defconfig | 11 +++--------
arch/powerpc/configs/mpc8572_ds_defconfig | 11 +++--------
arch/powerpc/configs/mpc85xx_defconfig | 11 +++--------
arch/powerpc/configs/mpc8641_hpcn_defconfig | 11 +++--------
arch/powerpc/configs/prpmc2800_defconfig | 11 +++--------
arch/powerpc/configs/storcenter_defconfig | 11 +++--------
drivers/ata/sata_fsl.c | 5 +----
drivers/dma/fsldma.c | 8 ++++----
19 files changed, 90 insertions(+), 102 deletions(-)
Anton Vorontsov (1):
[POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts
Kim Phillips (2):
[POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs
[POWERPC] sata_fsl: reduce compatibility to fsl,pq-sata
Kumar Gala (2):
[POWERPC] fsldma: Use compatiable binding as spec
[POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB
^ permalink raw reply
* Re: 8543 console baud rate change problem
From: Dan Wilson @ 2008-03-31 16:56 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <47EEFB5B.3050700@fulcrummicro.com>
Dan Wilson wrote:
> We are using ELDK 4.1, linux kernel 2.6.22 on an 8543 board with a
> Layer 2 switch on it (i.e., the actual packet switching is done in an
> external chip, not by the 8543 itself). One of our customers has
> encountered a strange issue with system console baud rate changes.
> The system console is connected to a UART port on the 8543.
>
>
> Here is the sequence of events:
>
> + powercycle unit at 115200
>
> + have ping session going
> + establish telnet session
> + have L2 traffic traversing the switch
>
> + switch baud rate to any other baud rate beside 38400
> + hit a few returns
> + switch baud rate back to 115200 and no problem
>
> + switch baud rate to 38400
> + type a few char
> + switch baud rate back to 115200
> + console is not responsive
>
> + existing ping session is still going
> + L2 traffic is still OK
> + telnet session disconnected and can not reconnect;
> telnet session is being served by linux ip stack
>
> + Had to power cycle to get everything back
>
Just to follow up on this. We were able to determine that our customer
had shut off the normal telnet daemon and was using their own program to
handle telnet sessions. In addition, they weren't using agetty. We got
them to use agetty, and now things seem to be working for them.
Dan.
^ permalink raw reply
* Re: [PATCHv2] powerpc: Describe memory-mapped RAM&ROM chips OF bindings
From: Sergei Shtylyov @ 2008-03-31 17:06 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803311839.10519.laurentp@cse-semaphore.com>
Hello.
Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 13 ++++++++++++-
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 7b4e8a7..3e1963b 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -57,7 +57,8 @@ Table of Contents
> n) 4xx/Axon EMAC ethernet nodes
> o) Xilinx IP cores
> p) Freescale Synchronous Serial Interface
> - q) USB EHCI controllers
> + q) USB EHCI controllers
> + r) Memory-mapped RAM & ROM
Memory-mapped RA/RO Memory again? Should better drop this. :-)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Josh Boyer @ 2008-03-31 17:07 UTC (permalink / raw)
To: Jerone Young; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <10aea37177130bbe5de7.1206969157@thinkpadL>
On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5@us.ibm.com>
> # Date 1206969060 18000
> # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f
> # Parent 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc
> Add idle power save for ppc 4xx
>
> This patch sets the wait state MSR when power_save is called in cpu_idle loop for ppc4xx. This is mainly to help out virtualization solutions such as KVM. This way the virtualization soultions are able to tell if the guest kernel is idle.
>
> I have tested this on hardware & KVM virtual guest.
I'm not overly thrilled with adding this to all of 4xx. It doesn't
actually save much power at all (1% on a project that actually measured
it with an amp meter recently) and there's really no other benefit to
doing it outside of the virtual guest case.
I'm assuming you pass a dtb to the virtual guest when you start it up.
Could you define a property in the CPU node there that can be parsed to
use the power_save function instead of always making it the default?
> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsy
> obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
> +obj-$(CONFIG_4xx) += idle_4xx.o
> obj-$(CONFIG_TAU) += tau_6xx.o
> obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
> swsusp_$(CONFIG_WORD_SIZE).o
> diff --git a/arch/powerpc/kernel/idle_4xx.c b/arch/powerpc/kernel/idle_4xx.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/powerpc/kernel/idle_4xx.c
Can this be added to sysdev/ppc4xx_soc.c instead?
> +#include <asm/processor.h>
> +#include <asm/machdep.h>
> +
> +void ppc4xx_idle()
> +{
> + unsigned long msr_save;
> +
> + /* set wait state MSR */
> + local_irq_enable();
> + msr_save = mfmsr();
> + mtmsr(msr_save|MSR_WE);
> + local_irq_disable();
> +}
I agree with Hollis on both the MSR_WE|MSR_EE and removing the
local_irq_disable changes.
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -132,6 +132,10 @@ void __init machine_init(unsigned long d
> if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
> cpu_has_feature(CPU_FTR_CAN_NAP))
> ppc_md.power_save = ppc6xx_idle;
> +#endif
> +
> +#ifdef CONFIG_4xx
> + ppc_md.power_save = ppc4xx_idle;
> #endif
I agree this belongs in platform setup code. Finding the right spot for
it might be a bit of a challenge.
josh
^ permalink raw reply
* RE: JFFS2 root-fs
From: Sugathan, Rupesh @ 2008-03-31 17:23 UTC (permalink / raw)
To: Georg Schardt; +Cc: linuxppc-embedded
=20
It seems to me, that the kernel does not find ANY file. because the
/dev/console file is in the image, but the initial console is not found
too
1) You should probably unpack and mount the jffs2 image on your host
directory to ensure that you see all files in place.=20
2) Check to see if your designated flash partition can hold all of your
jffs2 image.
Were you able to use the 'same' rootfs in any other way (nfs mount or
ramdisk) on the target?
Thanks
--
Rupesh Sugathan
^ permalink raw reply
* RE: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in thedevice tree.
From: Rune Torgersen @ 2008-03-31 17:38 UTC (permalink / raw)
To: Scott Wood, Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <20080331153301.GA23806@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> 0x2000 minus sizeof(...) would be a good default for CPM1 and CPM2
> (8280 has its first chunk go up to 0x4000, but for some reason that
> didn't get reflected in the dts for the one 8280 board in-tree).
Except that last time I tested it, it is not from 0 - 0x4000, but the
extra 0x2000 is added from offset 0x9000.....
So 8280 has available muram from 0 - 0x2000 and 0x9000 - 0xb000
^ permalink raw reply
* Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in thedevice tree.
From: Scott Wood @ 2008-03-31 17:42 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B043011C7@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Scott Wood wrote:
>> 0x2000 minus sizeof(...) would be a good default for CPM1 and CPM2
>> (8280 has its first chunk go up to 0x4000, but for some reason that
>> didn't get reflected in the dts for the one 8280 board in-tree).
>
> Except that last time I tested it, it is not from 0 - 0x4000, but the
> extra 0x2000 is added from offset 0x9000.....
> So 8280 has available muram from 0 - 0x2000 and 0x9000 - 0xb000
According to the docs, it has 0 - 0x4000 and 0x9000 - 0xc000.
-Scott
^ permalink raw reply
* RE: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in thedevice tree.
From: Rune Torgersen @ 2008-03-31 17:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47F12287.5030503@freescale.com>
Scott Wood wrote:
> Rune Torgersen wrote:
>> Scott Wood wrote:
>>> 0x2000 minus sizeof(...) would be a good default for CPM1 and CPM2
>>> (8280 has its first chunk go up to 0x4000, but for some reason that
>>> didn't get reflected in the dts for the one 8280 board in-tree).
>>=20
>> Except that last time I tested it, it is not from 0 - 0x4000, but the
>> extra 0x2000 is added from offset 0x9000.....
>> So 8280 has available muram from 0 - 0x2000 and 0x9000 - 0xb000
>=20
> According to the docs, it has 0 - 0x4000 and 0x9000 - 0xc000.
I tried it on out 8280 board inhouse, and any addresses from 0x2000 to
0x3fff does not work with at least the MCC's.
(running ss7 with the extended ss7 microcode)
If I only used 0-0x2000 and 0x9000 to 0xB000 then it is happy.
^ permalink raw reply
* Re: [kvm-ppc-devel] [PATCH] Add idle power save for ppc 4xx
From: Josh Boyer @ 2008-03-31 17:48 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev, Hollis Blanchard
In-Reply-To: <1206982322.9165.7.camel@thinkpadL>
On Mon, 31 Mar 2008 11:52:02 -0500
Jerone Young <jyoung5@us.ibm.com> wrote:
> > void ppc4xx_idle(void)
> >
> > > +{
> > > + unsigned long msr_save;
> > > +
> > > + /* set wait state MSR */
> > > + local_irq_enable();
> > > + msr_save = mfmsr();
> > > + mtmsr(msr_save|MSR_WE);
> >
> > Why don't you |MSR_WE|MSR_EE at the same time?
>
> You technically can do this. But the question is do all 4xx cpus use
> MSR_EE to enable interrupts? I can assume they do (from what I know),
They do for enabling external interrupts of normal priority. MSR_CE
might also be used/needed if someone has the watchdog enabled or has an
external device with the UIC pin mapped as a CE.
josh
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Josh Boyer @ 2008-03-31 18:05 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1206983237.12155.60.camel@vader.jdub.homelinux.org>
On Mon, 31 Mar 2008 12:07:17 -0500
Josh Boyer <jwboyer@gmail.com> wrote:
> On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
> > # HG changeset patch
> > # User Jerone Young <jyoung5@us.ibm.com>
> > # Date 1206969060 18000
> > # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f
> > # Parent 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc
> > Add idle power save for ppc 4xx
> >
> > This patch sets the wait state MSR when power_save is called in cpu_idle loop for ppc4xx. This is mainly to help out virtualization solutions such as KVM. This way the virtualization soultions are able to tell if the guest kernel is idle.
> >
> > I have tested this on hardware & KVM virtual guest.
>
> I'm not overly thrilled with adding this to all of 4xx. It doesn't
> actually save much power at all (1% on a project that actually measured
> it with an amp meter recently) and there's really no other benefit to
> doing it outside of the virtual guest case.
>
> I'm assuming you pass a dtb to the virtual guest when you start it up.
> Could you define a property in the CPU node there that can be parsed to
> use the power_save function instead of always making it the default?
Actually, you probably don't want this as a property in the device
tree. It doesn't describe hardware. A Kconfig option might be
warranted though.
josh
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Jerone Young @ 2008-03-31 18:19 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <20080331130518.2a6b0264@zod.rchland.ibm.com>
On Mon, 2008-03-31 at 13:05 -0500, Josh Boyer wrote:
> On Mon, 31 Mar 2008 12:07:17 -0500
> Josh Boyer <jwboyer@gmail.com> wrote:
>
> > On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
> > > # HG changeset patch
> > > # User Jerone Young <jyoung5@us.ibm.com>
> > > # Date 1206969060 18000
> > > # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f
> > > # Parent 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc
> > > Add idle power save for ppc 4xx
> > >
> > > This patch sets the wait state MSR when power_save is called in cpu_idle loop for ppc4xx. This is mainly to help out virtualization solutions such as KVM. This way the virtualization soultions are able to tell if the guest kernel is idle.
> > >
> > > I have tested this on hardware & KVM virtual guest.
> >
> > I'm not overly thrilled with adding this to all of 4xx. It doesn't
> > actually save much power at all (1% on a project that actually measured
> > it with an amp meter recently) and there's really no other benefit to
> > doing it outside of the virtual guest case.
> >
> > I'm assuming you pass a dtb to the virtual guest when you start it up.
> > Could you define a property in the CPU node there that can be parsed to
> > use the power_save function instead of always making it the default?
>
> Actually, you probably don't want this as a property in the device
> tree. It doesn't describe hardware. A Kconfig option might be
> warranted though.
I'll go with the Kconfig option.
>
> josh
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Jerone Young @ 2008-03-31 18:23 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1206983237.12155.60.camel@vader.jdub.homelinux.org>
On Mon, 2008-03-31 at 12:07 -0500, Josh Boyer wrote:
> On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
> > # HG changeset patch
> > # User Jerone Young <jyoung5@us.ibm.com>
> > # Date 1206969060 18000
> > # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f
> > # Parent 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc
> > Add idle power save for ppc 4xx
> >
> > This patch sets the wait state MSR when power_save is called in cpu_idle loop for ppc4xx. This is mainly to help out virtualization solutions such as KVM. This way the virtualization soultions are able to tell if the guest kernel is idle.
> >
> > I have tested this on hardware & KVM virtual guest.
>
> I'm not overly thrilled with adding this to all of 4xx. It doesn't
> actually save much power at all (1% on a project that actually measured
> it with an amp meter recently) and there's really no other benefit to
> doing it outside of the virtual guest case.
>
> I'm assuming you pass a dtb to the virtual guest when you start it up.
> Could you define a property in the CPU node there that can be parsed to
> use the power_save function instead of always making it the default?
>
> > Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> >
> > diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> > --- a/arch/powerpc/kernel/Makefile
> > +++ b/arch/powerpc/kernel/Makefile
> > @@ -39,6 +39,7 @@ obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsy
> > obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
> > obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> > obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
> > +obj-$(CONFIG_4xx) += idle_4xx.o
> > obj-$(CONFIG_TAU) += tau_6xx.o
> > obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
> > swsusp_$(CONFIG_WORD_SIZE).o
> > diff --git a/arch/powerpc/kernel/idle_4xx.c b/arch/powerpc/kernel/idle_4xx.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/powerpc/kernel/idle_4xx.c
>
> Can this be added to sysdev/ppc4xx_soc.c instead?
Probably. Though the other platforms have there power_save code in
idle_<platform>.S files, as they are in assembly.
Also I don't appear to have ppc4xx_soc.c in my source (using
2.6.25-rc6).
>
> > +#include <asm/processor.h>
> > +#include <asm/machdep.h>
> > +
> > +void ppc4xx_idle()
> > +{
> > + unsigned long msr_save;
> > +
> > + /* set wait state MSR */
> > + local_irq_enable();
> > + msr_save = mfmsr();
> > + mtmsr(msr_save|MSR_WE);
> > + local_irq_disable();
> > +}
>
> I agree with Hollis on both the MSR_WE|MSR_EE and removing the
> local_irq_disable changes.
You mention adding MSR_CE in a followup email. I'll add that to and
remove local_irq_disable.
>
> > diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> > --- a/arch/powerpc/kernel/setup_32.c
> > +++ b/arch/powerpc/kernel/setup_32.c
> > @@ -132,6 +132,10 @@ void __init machine_init(unsigned long d
> > if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
> > cpu_has_feature(CPU_FTR_CAN_NAP))
> > ppc_md.power_save = ppc6xx_idle;
> > +#endif
> > +
> > +#ifdef CONFIG_4xx
> > + ppc_md.power_save = ppc4xx_idle;
> > #endif
>
> I agree this belongs in platform setup code. Finding the right spot for
> it might be a bit of a challenge.
>
> josh
>
^ permalink raw reply
* Re: [PATCHv3 2/4] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram.
From: Scott Wood @ 2008-03-31 19:10 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803311836.08142.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> This patch relocates the buffer descriptors and the SMC parameter RAM at the
> end of the first CPM muram chunk, as described in the device tree. This allows
> device trees to stop excluding SMC parameter ram allocated by the boot loader
> from the CPM muram node.
It's usually a good idea to state that something is untested if that's
the case. :-)
This patch cannot work as is.
> +static int cpm_get_virtual_address(void *devp, void **addr, int ncells)
> +{
> + unsigned long xaddr;
> + int n;
> +
> + n = getprop(devp, "virtual-reg", addr, ncells * sizeof *addr);
> + if (n < ncells * sizeof *addr) {
You must cast the sizeof to a signed int; otherwise, a negative return
from getprop will be "bigger" than the unsigned size, and you'll return
garbage as the address.
> + for (n = 0; n < ncells; n++) {
> + if (!dt_xlate_reg(devp, n, &xaddr, NULL))
> + return -1;
> +
> + addr[n] = (void*)xaddr;
(void *)
> + }
> + }
> +
> + return ncells;
> +}
This could be a generic bootwrapper function. It should return the
number of resources (ncells is a misnomer) actually found, though,
rather than failing if there are fewer than asked for. Let the caller
decide if it's fatal.
> @@ -202,63 +243,62 @@ int cpm_console_init(void *devp, struct serial_console_data *scdp)
> else
> do_cmd = cpm1_cmd;
>
> - n = getprop(devp, "fsl,cpm-command", &cpm_cmd, 4);
> - if (n < 4)
> + if (getprop(devp, "fsl,cpm-command", &cpm_cmd, 4) < sizeof cpm_cmd)
> return -1;
Standard kernel style is sizeof(foo), not sizeof foo.
Plus, if you're going to replace 4 with sizeof(cpm_cmd), do it both
places. I don't really see the need, though; a cell is always 4 bytes.
> - n = getprop(parent, "virtual-reg", reg_virt, sizeof(reg_virt));
> - if (n < (int)sizeof(reg_virt)) {
> - if (!dt_xlate_reg(parent, 0, ®_phys, NULL))
> - return -1;
> -
> - reg_virt[0] = (void *)reg_phys;
> - }
> -
> - cpcr = reg_virt[0];
> + if (cpm_get_virtual_address(devp, &cpcr, 1) < 0)
> + return -1;
s/devp/parent/
> muram = finddevice("/soc/cpm/muram/data");
> if (!muram)
> return -1;
>
> /* For bootwrapper-compatible device trees, we assume that the first
> - * entry has at least 18 bytes, and that #address-cells/#data-cells
> + * entry has at least 128 bytes, and that #address-cells/#data-cells
> * is one for both parent and child.
> */
>
> - n = getprop(muram, "virtual-reg", reg_virt, sizeof(reg_virt));
> - if (n < (int)sizeof(reg_virt)) {
> - if (!dt_xlate_reg(muram, 0, ®_phys, NULL))
> - return -1;
> + if (cpm_get_virtual_address(devp, &muram_addr, 1) < 0)
> + return -1;
s/devp/muram/
> +
> + if (getprop(muram, "reg", reg, sizeof reg) < sizeof reg)
> + return -1;
Should read into array of u32, not void *.
> + if (is_cpm2 && is_smc) {
> + u16 *smc_base = (u16*)param;
(u16 *)
> + u16 pram_offset;
>
> - muram_start = reg_virt[0];
> + pram_offset = cbd_offset - 64;
> + pram_offset = _ALIGN_DOWN(pram_offset, 64);
> + *smc_base = pram_offset;
Use out_be16().
The SMC should be stopped before you do this.
-Scott
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Josh Boyer @ 2008-03-31 19:11 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1206987826.9165.15.camel@thinkpadL>
On Mon, 2008-03-31 at 13:23 -0500, Jerone Young wrote:
> > > diff --git a/arch/powerpc/kernel/idle_4xx.c b/arch/powerpc/kernel/idle_4xx.c
> > > new file mode 100644
> > > --- /dev/null
> > > +++ b/arch/powerpc/kernel/idle_4xx.c
> >
> > Can this be added to sysdev/ppc4xx_soc.c instead?
>
> Probably. Though the other platforms have there power_save code in
> idle_<platform>.S files, as they are in assembly.
No, just two of them do. Cell, pseries, and pasemi all have them under
the platform directory.
> Also I don't appear to have ppc4xx_soc.c in my source (using
> 2.6.25-rc6).
You're working against a very old tree, relatively speaking. Use either
my for-2.6.26 branch in my git tree, or the linux-next tree.
josh
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Hollis Blanchard @ 2008-03-31 19:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080331130518.2a6b0264@zod.rchland.ibm.com>
On Mon, 31 Mar 2008 13:05:18 -0500, Josh Boyer wrote:
> On Mon, 31 Mar 2008 12:07:17 -0500
> Josh Boyer <jwboyer@gmail.com> wrote:
>
>> On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
>> > # HG changeset patch
>> > # User Jerone Young <jyoung5@us.ibm.com> # Date 1206969060 18000
>> > # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f # Parent
>> > 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc Add idle power save for ppc
>> > 4xx
>> >
>> > This patch sets the wait state MSR when power_save is called in
>> > cpu_idle loop for ppc4xx. This is mainly to help out virtualization
>> > solutions such as KVM. This way the virtualization soultions are able
>> > to tell if the guest kernel is idle.
>> >
>> > I have tested this on hardware & KVM virtual guest.
>>
>> I'm not overly thrilled with adding this to all of 4xx. It doesn't
>> actually save much power at all (1% on a project that actually measured
>> it with an amp meter recently) and there's really no other benefit to
>> doing it outside of the virtual guest case.
So it slightly helps hardware, and it helps virtualization a *lot*.
What's the problem?
>> I'm assuming you pass a dtb to the virtual guest when you start it up.
>> Could you define a property in the CPU node there that can be parsed to
>> use the power_save function instead of always making it the default?
>
> Actually, you probably don't want this as a property in the device tree.
> It doesn't describe hardware. A Kconfig option might be warranted
> though.
There will be a device tree binding for hypervisor properties, so if it's
not always enabled, having a hypervisor node (for any hypervisor) in the
device tree would be an indicator. Far better than a Kconfig option, at
any rate.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Josh Boyer @ 2008-03-31 20:28 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <fsrdp7$958$1@ger.gmane.org>
On Mon, 2008-03-31 at 19:24 +0000, Hollis Blanchard wrote:
> On Mon, 31 Mar 2008 13:05:18 -0500, Josh Boyer wrote:
>
> > On Mon, 31 Mar 2008 12:07:17 -0500
> > Josh Boyer <jwboyer@gmail.com> wrote:
> >
> >> On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
> >> > # HG changeset patch
> >> > # User Jerone Young <jyoung5@us.ibm.com> # Date 1206969060 18000
> >> > # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f # Parent
> >> > 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc Add idle power save for ppc
> >> > 4xx
> >> >
> >> > This patch sets the wait state MSR when power_save is called in
> >> > cpu_idle loop for ppc4xx. This is mainly to help out virtualization
> >> > solutions such as KVM. This way the virtualization soultions are able
> >> > to tell if the guest kernel is idle.
> >> >
> >> > I have tested this on hardware & KVM virtual guest.
> >>
> >> I'm not overly thrilled with adding this to all of 4xx. It doesn't
> >> actually save much power at all (1% on a project that actually measured
> >> it with an amp meter recently) and there's really no other benefit to
> >> doing it outside of the virtual guest case.
>
> So it slightly helps hardware, and it helps virtualization a *lot*.
> What's the problem?
There's 0 publicly available documentation on exactly what "Wait State
Enable" means other than the description for the MSR register bit in the
4xx UM. I'm a very paranoid person.
Explain to me what it really provides with some kind of concrete numbers
on real hardware and I'll think about it as the default. Until then, I
think a Kconfig option (or DT property) is acceptable for now. I didn't
say "no", I just said "make it optional."
> >> I'm assuming you pass a dtb to the virtual guest when you start it up.
> >> Could you define a property in the CPU node there that can be parsed to
> >> use the power_save function instead of always making it the default?
> >
> > Actually, you probably don't want this as a property in the device tree.
> > It doesn't describe hardware. A Kconfig option might be warranted
> > though.
>
> There will be a device tree binding for hypervisor properties, so if it's
> not always enabled, having a hypervisor node (for any hypervisor) in the
> device tree would be an indicator. Far better than a Kconfig option, at
> any rate.
But you want this in the guests, right? Not the hypervisor...
josh
^ permalink raw reply
* cpm2.c error in cpm2_clk_setup
From: Matt Gessner @ 2008-03-31 20:32 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I found what I think is an error while looking at the above function,
in the kernel pull from v2.6.25-rc7, today.
The switch(target) contains a case CPM_CLK_SCC1 that sets reg and
shift, and then falls through to teh CPM_CLK_SCC2 case.
I'm not active in this project; I was simply looking at some code
trying to find something, and stumbled across it.
I'm bringing this to the list's attention because I have no way to
test this, but it sure looks like an error.
HTH,
Regards,
Matt Gessner
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Hollis Blanchard @ 2008-03-31 20:34 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1206995288.12155.74.camel@vader.jdub.homelinux.org>
On Mon, 2008-03-31 at 15:28 -0500, Josh Boyer wrote:
> On Mon, 2008-03-31 at 19:24 +0000, Hollis Blanchard wrote:
> > On Mon, 31 Mar 2008 13:05:18 -0500, Josh Boyer wrote:
> >
> > > On Mon, 31 Mar 2008 12:07:17 -0500
> > > Josh Boyer <jwboyer@gmail.com> wrote:
> > >
> > >> On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
> > >> > # HG changeset patch
> > >> > # User Jerone Young <jyoung5@us.ibm.com> # Date 1206969060 18000
> > >> > # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f # Parent
> > >> > 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc Add idle power save for ppc
> > >> > 4xx
> > >> >
> > >> > This patch sets the wait state MSR when power_save is called in
> > >> > cpu_idle loop for ppc4xx. This is mainly to help out virtualization
> > >> > solutions such as KVM. This way the virtualization soultions are able
> > >> > to tell if the guest kernel is idle.
> > >> >
> > >> > I have tested this on hardware & KVM virtual guest.
> > >>
> > >> I'm not overly thrilled with adding this to all of 4xx. It doesn't
> > >> actually save much power at all (1% on a project that actually measured
> > >> it with an amp meter recently) and there's really no other benefit to
> > >> doing it outside of the virtual guest case.
> >
> > So it slightly helps hardware, and it helps virtualization a *lot*.
> > What's the problem?
>
> There's 0 publicly available documentation on exactly what "Wait State
> Enable" means other than the description for the MSR register bit in the
> 4xx UM. I'm a very paranoid person.
>
> Explain to me what it really provides with some kind of concrete numbers
> on real hardware and I'll think about it as the default. Until then, I
> think a Kconfig option (or DT property) is acceptable for now. I didn't
> say "no", I just said "make it optional."
You can be paranoid about all new features, and then new development
ceases.
Did your project that measured it report any suspicious problems?
> > >> I'm assuming you pass a dtb to the virtual guest when you start it up.
> > >> Could you define a property in the CPU node there that can be parsed to
> > >> use the power_save function instead of always making it the default?
> > >
> > > Actually, you probably don't want this as a property in the device tree.
> > > It doesn't describe hardware. A Kconfig option might be warranted
> > > though.
> >
> > There will be a device tree binding for hypervisor properties, so if it's
> > not always enabled, having a hypervisor node (for any hypervisor) in the
> > device tree would be an indicator. Far better than a Kconfig option, at
> > any rate.
>
> But you want this in the guests, right? Not the hypervisor...
Not sure what you mean. The hypervisor will create device tree
properties for the guests, so the guest could use that property to
initialize the power_save hook.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Ethernet Jumbo Frames
From: Darcy Watkins @ 2008-03-31 20:47 UTC (permalink / raw)
To: LinuxPPC-Embedded
Has anyone on this list ever been given a requirement to implement
support for ethernet frames larger than the standard MTU of 1500? ...
... for normal 10/100 Ethernet? ... not gigabit.
The application is to support certain encapsulation protocols without
imposing smaller than 1500 byte MTU restrictions on the innermost
protocol.
I have been tasked to investigate this for a system based on PPC405EP.
Can it be done using the IBM EMAC, Linux drivers, etc?
Regards,
Darcy
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Michael Ellerman @ 2008-04-01 1:04 UTC (permalink / raw)
To: jyoung5; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1206987598.9165.10.camel@thinkpadL>
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
On Mon, 2008-03-31 at 13:19 -0500, Jerone Young wrote:
> On Mon, 2008-03-31 at 13:05 -0500, Josh Boyer wrote:
> > On Mon, 31 Mar 2008 12:07:17 -0500
> > Josh Boyer <jwboyer@gmail.com> wrote:
> >
> > > On Mon, 2008-03-31 at 08:12 -0500, Jerone Young wrote:
> > > > # HG changeset patch
> > > > # User Jerone Young <jyoung5@us.ibm.com>
> > > > # Date 1206969060 18000
> > > > # Node ID 10aea37177130bbe5de7bee6ec06d9010bc5da1f
> > > > # Parent 1506aa38ddabb0bf73fff3ac3f3db5f9ef6458cc
> > > > Add idle power save for ppc 4xx
> > > >
> > > > This patch sets the wait state MSR when power_save is called in cpu_idle loop for ppc4xx. This is mainly to help out virtualization solutions such as KVM. This way the virtualization soultions are able to tell if the guest kernel is idle.
> > > >
> > > > I have tested this on hardware & KVM virtual guest.
> > >
> > > I'm not overly thrilled with adding this to all of 4xx. It doesn't
> > > actually save much power at all (1% on a project that actually measured
> > > it with an amp meter recently) and there's really no other benefit to
> > > doing it outside of the virtual guest case.
> > >
> > > I'm assuming you pass a dtb to the virtual guest when you start it up.
> > > Could you define a property in the CPU node there that can be parsed to
> > > use the power_save function instead of always making it the default?
> >
> > Actually, you probably don't want this as a property in the device
> > tree. It doesn't describe hardware. A Kconfig option might be
> > warranted though.
>
> I'll go with the Kconfig option.
Go with a device-tree check. The pseries kernel supports both bare-metal
and hypervisor in the same kernel image, and it works out which it's
running on by looking at the device-tree. This seems equivalent to me?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/9] [POWERPC] prpmc2800: clean up dts properties
From: Segher Boessenkool @ 2008-04-01 1:17 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <20080331164302.GC13750@farnsworth.org>
> However, I can't resist pointing out that in the existing devtrees
> with a "soc" node, the name is also misleading. That node doesn't
> refer to the SOC itself, but to the part of the SOC containing the
> peripherals. Whether the system is implemented on one or two chips
> is an implementation detail irrelevant to the drivers or device tree.
It's not ideal to call it "the-perhaps-virtual-bus-on-the-soc-that-
contains-all-of-the-register-blocks-for-all-the-devices-on-the-soc-
except-some" either. A better name is welcome of course.
Maybe it's best to name this node with the name _of_ the SoC (or host
bridge, or what ever you want to call it), if that name is not too
unwieldy.
In general, "name" should be as generic as is useful, but not more
generic than that, because it wouldn't be useful anymore.
In any case, it's just "name", it should normally only be looked at
by humans. Use whatever you like best here, and don't use it in the
kernel code.
Segher
^ permalink raw reply
* SecretLab Git Server
From: Sam Karp @ 2008-04-01 1:48 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
Has anyone tried downloading the Linux 2.6 Kernel Git tree lately?
I'm trying to run this: git-clone git://git.secretlab.ca/git/linux-
2.6-virtex.git
and get an error saying that The remote end hung up unexpectedly.
Thanks
-Sam
[-- Attachment #2: Type: text/html, Size: 340 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] [POWERPC] mv64x60: change FDT compatible prefix to mrvl
From: David Gibson @ 2008-04-01 1:53 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080331165605.GD13750@farnsworth.org>
On Mon, Mar 31, 2008 at 09:56:05AM -0700, Dale Farnsworth wrote:
> On Mon, Mar 31, 2008 at 10:44:20AM +1100, David Gibson wrote:
> > On Fri, Mar 28, 2008 at 05:47:25PM -0600, Grant Likely wrote:
> > > On Fri, Mar 28, 2008 at 5:42 PM, Dale Farnsworth <dale@farnsworth.org> wrote:
> > > > From: Dale Farnsworth <dale@farnsworth.org>
> > > >
> > > > Follow the convention that compatible names are prefixed by the
> > > > vendor's stock ticker symbol. For Marvell Technology Group Ltd.,
> > > > that's MRVL.
> > > >
> > > > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > > > Acked-by: Mark A. Greer <mgreer@mvista.com>
> > >
> > > Are there any boards "in the wild" using the old string? If so are
> > > does changing this string risk complicating upgrades to a new kernel
> > > version?
> >
> > In particular are there any pre-flattened-tree real-OF systems in the
> > wild using "marvell" as the vendor prefix (there might be Apple or IBM
> > systems out there with Marvell PHYs for example).
>
> It's difficult to prove a negative. However, I've seen no evidence of
> such systems. When Mark invented the "marvell," prefix, it wasn't based
> on existing practice.
>
> However, I believe that the Genesi Pegasos board uses OF and has a
> Marvell bridge chip. They may have copied the "marvell," prefix.
>
> Matt, can you check whether any of the Genesi boards contain device node
> descriptions for the Marvel 64[34]60, and let us know what prefix is used
> in their compatible properties?
Ok, fair enough. As long as you've been duly diligent about checking
for existing practice I'm happy.
--
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: SecretLab Git Server
From: Grant Likely @ 2008-04-01 2:02 UTC (permalink / raw)
To: Sam Karp; +Cc: linuxppc-embedded
In-Reply-To: <800687fe0803311848l478f6445u77c20cd8c4f71797@mail.gmail.com>
On Mon, Mar 31, 2008 at 7:48 PM, Sam Karp <sam.d.karp@gmail.com> wrote:
> Has anyone tried downloading the Linux 2.6 Kernel Git tree lately?
>
> I'm trying to run this: git-clone
> git://git.secretlab.ca/git/linux-2.6-virtex.git
>
> and get an error saying that The remote end hung up unexpectedly.
Sorry, my git server is down at the moment. I recommend using
Xilinx's git server
g.
>
> Thanks
> -Sam
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 00/11] ppc32 mm init clean and 85xx kernel reloc
From: Kumar Gala @ 2008-04-01 2:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This set of patches cleans up the initialization of various mmu bits on
ppc32 (and a small bit on ppc64 to maintain common code) towards the
goal of having an 85xx (book-e) kernel able to run at non-zero offsets.
These patches exist in my master and ppc32_mm_init branch. I've dropped
them from the powerpc-next as paulus wants them to go via his tree
directly since they touch common code.
- k
^ 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