* Re: DTS question
From: Sean MacLennan @ 2008-03-27 3:42 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080326234043.GC8005@localhost.localdomain>
On Thu, 27 Mar 2008 10:40:43 +1100
"David Gibson" <david@gibson.dropbear.id.au> wrote:
> >>> Note that a stock symbol needs to be written in uppercase; in
> >>> lowercase, it is just a random name that has no collision
> >>> protection.
> >>
> >> Um.. bit too late for that. AFAIK, uppercase has been used by
> >> *no-one* for stock ticker derived vendor IDs.
> >
> > No, it's used quite a lot actually. Not in DTS files though ;-)
>
> Sorry, yes, I was meaning specifically in recent, flattened-device
> tree practice (which is the context in which the "use stock ticker"
> recommendation has been made.
>
> > It doesn't matter a lot, lowercase names are perfectly valid, you
> > just don't get the nice non-collision reassurance you would get if
> > you used a name in one of the namespaces reserved for that purpose.
> >
> > It's probably best to not use an uppercase stock symbol if you don't
> > have approval from the company in question anyway -- we use a
> > lowercase name (i.e. in the "free-for-all" space) for our messed up
> > bindings, the companies use an uppercase name (in the stock-ticker
> > namespace) for their own, incompatible, messed-up bindings, and
> > everyone is happy. Or something like that.
Ack, now I am confused. Should I use lower or upper case?
To be honest the upper case looks weird since none of the other names
have any uppercase characters.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] [POWERPC] Remove CONFIG_PCI_LEGACY from pasemi_defconfig
From: Stephen Rothwell @ 2008-03-27 3:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: ppc-dev
In-Reply-To: <20080327034103.GA31504@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Wed, 26 Mar 2008 22:41:03 -0500 Olof Johansson <olof@lixom.net> wrote:
>
> I've already requested Paul to pull a defconfig update that includes
> all changes besides the PCI_LEGACY disabling. Since it's not critical,
> I'll do the same change in the for-2.6.26 branch but let the pull request
> for 2.6.25 be as-is, if that's OK with you. This is of course with the
> hopes that Paul will pull and push it before the .25 release.
Yeah, that's fine - I missed your pull request. I'll redo the patch
based on your tree.
--
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
* [PATCH] [POWERPC] htab_remove_mapping is only used by MEMORY_HOTPLUG
From: Stephen Rothwell @ 2008-03-27 5:08 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
This eliminates a warning in builds that don't define
CONFIG_MEMORY_HOTPLUG.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/mm/hash_utils_64.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index c2e5f61..96a5790 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -192,6 +192,7 @@ int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
return ret < 0 ? ret : 0;
}
+#ifdef CONFIG_MEMORY_HOTPLUG
static void htab_remove_mapping(unsigned long vstart, unsigned long vend,
int psize, int ssize)
{
@@ -209,6 +210,7 @@ static void htab_remove_mapping(unsigned long vstart, unsigned long vend,
for (vaddr = vstart; vaddr < vend; vaddr += step)
ppc_md.hpte_removebolted(vaddr, psize, ssize);
}
+#endif /* CONFIG_MEMORY_HOTPLUG */
static int __init htab_dt_scan_seg_sizes(unsigned long node,
const char *uname, int depth,
--
1.5.4.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] [POWERPC] Remove CONFIG_PCI_LEGACY from some configs
From: Stephen Rothwell @ 2008-03-27 5:36 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
This will remove some build warnings and doesn't stop us building any
drivers that we were building previously with these configs.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/configs/chrp32_defconfig | 7 +++----
arch/powerpc/configs/g5_defconfig | 7 +++----
arch/powerpc/configs/iseries_defconfig | 7 +++----
arch/powerpc/configs/pmac32_defconfig | 7 +++----
arch/powerpc/configs/ppc64_defconfig | 8 ++++----
arch/powerpc/configs/pseries_defconfig | 8 ++++----
6 files changed, 20 insertions(+), 24 deletions(-)
I have built all these configs.
diff --git a/arch/powerpc/configs/chrp32_defconfig b/arch/powerpc/configs/chrp32_defconfig
index 38b85b2..d7fd298 100644
--- a/arch/powerpc/configs/chrp32_defconfig
+++ b/arch/powerpc/configs/chrp32_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc6
-# Thu Mar 20 10:33:36 2008
+# Thu Mar 27 13:55:37 2008
#
# CONFIG_PPC64 is not set
@@ -74,8 +74,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
-# CONFIG_USER_SCHED is not set
-# CONFIG_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
@@ -243,7 +241,7 @@ CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
-CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
@@ -1328,6 +1326,7 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
#
# Kernel hacking
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 0f82f66..a20501f 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc6
-# Thu Mar 20 10:36:41 2008
+# Thu Mar 27 13:55:43 2008
#
CONFIG_PPC64=y
@@ -77,8 +77,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
-# CONFIG_USER_SCHED is not set
-# CONFIG_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
@@ -276,7 +274,7 @@ CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
-CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
@@ -1596,6 +1594,7 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
#
# Kernel hacking
diff --git a/arch/powerpc/configs/iseries_defconfig b/arch/powerpc/configs/iseries_defconfig
index 8d9a84f..b3128fb 100644
--- a/arch/powerpc/configs/iseries_defconfig
+++ b/arch/powerpc/configs/iseries_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc6
-# Thu Mar 20 10:43:46 2008
+# Thu Mar 27 13:55:45 2008
#
CONFIG_PPC64=y
@@ -77,8 +77,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
-# CONFIG_USER_SCHED is not set
-# CONFIG_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
@@ -261,7 +259,7 @@ CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
-CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
@@ -1065,6 +1063,7 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
#
# Kernel hacking
diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
index 558b0d3..fca1142 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc6
-# Thu Mar 20 11:05:14 2008
+# Thu Mar 27 13:56:21 2008
#
# CONFIG_PPC64 is not set
@@ -77,8 +77,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
-# CONFIG_USER_SCHED is not set
-# CONFIG_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
@@ -272,7 +270,7 @@ CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
-CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
@@ -1895,6 +1893,7 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
#
# Kernel hacking
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 880ab7a..970282b 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc6
-# Thu Mar 20 11:06:28 2008
+# Thu Mar 27 13:56:24 2008
#
CONFIG_PPC64=y
@@ -84,8 +84,6 @@ CONFIG_CGROUPS=y
# CONFIG_CGROUP_NS is not set
CONFIG_CPUSETS=y
# CONFIG_GROUP_SCHED is not set
-# CONFIG_USER_SCHED is not set
-# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_SYSFS_DEPRECATED=y
@@ -289,6 +287,7 @@ CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
+# CONFIG_PHYP_DUMP is not set
CONFIG_IRQ_ALL_CPUS=y
# CONFIG_NUMA is not set
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
@@ -335,7 +334,7 @@ CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
-CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
@@ -1881,6 +1880,7 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
#
# Kernel hacking
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 755aca7..3e2593c 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc6
-# Thu Mar 20 11:08:01 2008
+# Thu Mar 27 13:56:28 2008
#
CONFIG_PPC64=y
@@ -83,8 +83,6 @@ CONFIG_CGROUPS=y
CONFIG_CGROUP_NS=y
CONFIG_CPUSETS=y
# CONFIG_GROUP_SCHED is not set
-# CONFIG_USER_SCHED is not set
-# CONFIG_CGROUP_SCHED is not set
CONFIG_CGROUP_CPUACCT=y
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_SYSFS_DEPRECATED=y
@@ -237,6 +235,7 @@ CONFIG_ARCH_HAS_WALK_MEMORY=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
+# CONFIG_PHYP_DUMP is not set
CONFIG_IRQ_ALL_CPUS=y
CONFIG_NUMA=y
CONFIG_NODES_SHIFT=4
@@ -283,7 +282,7 @@ CONFIG_PCI_SYSCALL=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
-CONFIG_PCI_LEGACY=y
+# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=m
@@ -1519,6 +1518,7 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
+CONFIG_HAVE_LMB=y
#
# Kernel hacking
--
1.5.4.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 1/2 v3] Driver for Freescale 8610 and 5121 DIU
From: Andrew Morton @ 2008-03-27 7:54 UTC (permalink / raw)
To: York Sun
Cc: linux-fbdev-devel, a.p.zijlstra, linux-kernel, linuxppc-dev,
Timur Tabi
In-Reply-To: <12064804383051-git-send-email-yorksun@freescale.com>
On Tue, 25 Mar 2008 16:27:17 -0500 York Sun <yorksun@freescale.com> wrote:
> +#if defined(CONFIG_NOT_COHERENT_CACHE)
> +unsigned int *coherence_data;
> +phys_addr_t *coherence_data_phy;
> +#endif
These identifiers are too general for use as global symbols. I'd suggest
renaming them to diu_coherence_data and diu_coherence_data_phy. Or make
them static - I didn't check.
I'll duck this version of the patches, as Scott's comments looked rather
substantial.
^ permalink raw reply
* Re: [patch 3/6] PS3: Bootwrapper improvements
From: Geert Uytterhoeven @ 2008-03-27 8:13 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <47EAEC76.7000006@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1499 bytes --]
On Wed, 26 Mar 2008, Geoff Levand wrote:
> --- a/arch/powerpc/boot/ps3.c
> +++ b/arch/powerpc/boot/ps3.c
> }
>
> -void platform_init(void)
> +void platform_init(unsigned long null_check)
^^^^^^^^^^^^^^^^^^^^^^^^
> {
> const u32 heapsize = 0x1000000 - (u32)_end; /* 16MiB */
> void *chosen;
> @@ -151,6 +152,10 @@ void platform_init(void)
>
> printf(" flat tree at 0x%lx\n\r", ft_addr);
>
> + if (*(unsigned long *)0 != null_check)
> + printf("null check failed: %lx != %lx\n\r", *(unsigned long *)0,
> + (unsigned long)null_check);
^^^^^^^^^^^^^^^
This cast is not needed, as null_check has the correct type.
BTW, what about writing it like
unsigned long val;
val = *(unsigned long *)0;
if (val != null_check)
printf("null check failed: %lx != %lx\n\r", val, null_check);
to kill a duplicate cast and avoid splitting the printf() line?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Help on MPC82XX USB Host controller Development using m82xx-hcd.
From: Laurent Pinchart @ 2008-03-27 8:56 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Amarendra_Reddy
In-Reply-To: <16304553.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
Hi Amarendra,
On Wednesday 26 March 2008 17:11, Amarendra_Reddy wrote:
>
> Hi all,
>
> We are working on implementation of the USB host controller driver for the
> MPC8272ADS (eval board).
>
> The USB Host controller on MPC8272 chip is neither UHCI nor OHCI compliant.
>
> We downloaded the project cpm2usb and the patches created by Mr.Mike
> Rapoport from http://cpm2usb.sourceforge.net
>
> We integrated the 'm82xx-hcd' into the 2.6.10 source with few changes to usb
> data structures (usb_hcd,usb_device,usb_host_endpoint) and to struct
> hc_driver. Also updated the function ''tx_err' present in m82xx-hcd.c.
The cpm2usb project isn't maintained. If possible you should upgrade to a more
recent kernel and switch to the powerpc architecture where a new USB driver
called fhci is available.
The MPC872ADS is supported in recent kernels so switching shouldn't be too
difficult.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
From: Laurent Pinchart @ 2008-03-27 9:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080326155741.GA3460@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
On Wednesday 26 March 2008 16:57, Scott Wood wrote:
> On Wed, Mar 26, 2008 at 12:20:42PM +0100, Laurent Pinchart wrote:
> > diff --git a/arch/powerpc/boot/dts/ep8248e.dts
b/arch/powerpc/boot/dts/ep8248e.dts
> > index 5d2fb76..756758f 100644
> > --- a/arch/powerpc/boot/dts/ep8248e.dts
> > +++ b/arch/powerpc/boot/dts/ep8248e.dts
> > @@ -121,8 +121,7 @@
> >
> > data@0 {
> > compatible = "fsl,cpm-muram-data";
> > - reg = <0 0x1100 0x1140
> > - 0xec0 0x9800 0x800>;
> > + reg = <0 0x2000 0x9800 0x800>;
> > };
>
> Can we leave this as reserved, so that udbg still works?
Ok. Should I add a comment to the DTS to explain additional muram can be
reclaimed if udbg isn't used ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
From: Laurent Pinchart @ 2008-03-27 9:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47EA80ED.1030202@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Wednesday 26 March 2008 17:59, Scott Wood wrote:
> Laurent Pinchart wrote:
> > @@ -138,7 +137,7 @@
> > device_type = "serial";
> > compatible = "fsl,mpc8248-smc-uart",
> > "fsl,cpm2-smc-uart";
> > - reg = <0x11a80 0x20 0x1100 0x40>;
> > + reg = <0x11a80 0x20 0x87fc 2>;
> > interrupts = <4 8>;
> > interrupt-parent = <&PIC>;
> > fsl,cpm-brg = <7>;
>
> This breaks the bootwrapper console.
And of course I forgot about that :-)
The boot wrapper code doesn't have any dpram allocator. Any objection against
using a chunk of dpram at a fixed location ? What about at the beginning of
the dpram ? The DTS muram node would then exclude a chunk of dpram at offset
0x0000 instead of 0x1100.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-27 9:13 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <47EA4741.2050402@ru.mvista.com>
On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:
> Laurent Pinchart wrote:
>=20
> >>>Regarding non-volatility nothing prevents a user from using a=20
> >>>volatile RAM as an MTD device, but there's little point in doing so.
> >>>Would it be acceptable for the "linear-nvram" specification
> >>>not to include > volatile RAM ? ROM chips would be excluded too. Is
>=20
> >>that an issue ?
>=20
> >>We actually use a volatile ram (SRAM) as an MTD device. We use it to
> >>store info from bootloader and system specific values between resets.
>=20
> > So we're left with two main options.
>=20
> > - Reusing the nvram device type from the Device Support Extensions.=20
Volatile=20
> > devices wouldn't be supported, and we'd need a separate device=20
specification=20
> > for linear-mapped volatile RAMs. I'm not very happy with that.
>=20
> > - Using another device node with a compatible value set to "linear-ram"=
=20
(or=20
> > something similar). This would support both volatile and non-volatile=20
> > devices, and a property could be added to specify if the device is=20
volatile=20
> > or not.
>=20
> > I'd go for the second option, and I'd specify a "linear-rom" compatible=
=20
value=20
> > as well while we're at it.
>=20
> > Both volatile and non-volatile RAMs can be handled by the physmap_of MT=
D=20
> > driver. They both use the same map probe type ("map_ram"). Volatility=20
isn't=20
> > handled there.
>=20
> > ROMs should be handled by the same driver and should use the "mtd_rom" =
map=20
> > probe type.
>=20
> OK, let's go with it.
>=20
> > As all those devices use the physmap_of MTD driver, what about=20
> > using "physmap-ram" and "physmap-rom" as compatibility names ?
>=20
> Heh, we've gone thru "physmap" before -- it was labelled Linux-specif=
ic=20
> name (well, I'd agree with that).
physmap stands for physically mapped. That doesn't sound Linux-specific to =
me,=20
the fact that the MTD driver has the same name is a pure coincidence.=20
linmap-rom and linmap-rom sound even more Linux-specific :-)
Could we agree on a name ? I'd like to submit a new patch.
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-27 9:24 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <47EA6E88.5050109@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
On Wednesday 26 March 2008 16:40, Sergei Shtylyov wrote:
> Segher Boessenkool wrote:
>
> >> - Using another device node with a compatible value set to
> >> "linear-ram" (or
> >> something similar). This would support both volatile and non-volatile
> >> devices, and a property could be added to specify if the device is
> >> volatile
> >> or not.
>
> > "memory-mapped-memory" perhaps :-)
>
> > Or, just "memory". Although that one might play havoc with some
>
> I'd suggest "ram" and "rom" then. Luckily the device trees don't contain
> binding for the real RAM chips yet. :-)
And when it will we'll be in trouble.
Here are a few names. I like physmap-r[ao]m better. Does anyone have another
suggestion ? I'd like to send a revised patch.
linear-r[ao]m
linear-mapped-r[ao]m
mapped-r[ao]m
memory-mapped-r[ao]m
physmap-r[ao]m
> > not-quite-correct main memory probing code.
>
> You mean the there's parsers that search the "compatible" prop for
> "memory" as well as "device_type" prop?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: Laurent Pinchart @ 2008-03-27 9:26 UTC (permalink / raw)
To: linux-mtd; +Cc: ben, David Gibson, linuxppc-dev
In-Reply-To: <777c028aa41fe870542afdb4fa7d2db6@kernel.crashing.org>
On Wednesday 26 March 2008 16:34, Segher Boessenkool wrote:
> >>> {
> >>> + .compatible =3D "physmap-ram",
> >>> + .data =3D (void *)"map_ram",
> >>> + },
> >>> + {
> >>> + .compatible =3D "physmap-rom",
> >>> + .data =3D (void *)"map_rom",
> >>> + },
> >
> >> Why the cast? It's redundant afaics.
> >
> > To be in line with the surrounding code...
>=20
> I see _that_, but it's not a great argument IMNSHO. Could I trick
> you into preceding this patch with a cleanup patch for the existing
> casts?
Ok. I'll submit a new patch as soon as we agree on a compatible name.
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Describe memory-mapped RAM&ROM chips of bindings
From: Laurent Pinchart @ 2008-03-27 9:37 UTC (permalink / raw)
To: linux-mtd; +Cc: ben, linuxppc-dev, David Gibson
In-Reply-To: <d195a61e876d685ea04b29474da187cc@kernel.crashing.org>
On Wednesday 26 March 2008 15:52, Segher Boessenkool wrote:
> > + Dedicated RAM and ROM chips are often used as storage for=20
> > temporary or
> > + permanent data in embedded devices. Possible usage include=20
> > non-volatile
> > + storage in battery-backed SRAM, semi-permanent storage in=20
> > dedicated SRAM
> > + to preserve data accross reboots and firmware storage in=20
> > dedicated ROM.
> > +
> > + - compatible : should contain the specific model of RAM/ROM=20
> > chip(s)
> > + used, if known, followed by either "physmap-ram" or=20
> > "physmap-rom"
> > + - reg : Address range of the RAM/ROM chip
> > + - bank-width : Width (in bytes) of the RAM/ROM bank. Equal to the
> > + device width times the number of interleaved chips.
> > + - device-width : (optional) Width of a single RAM/ROM chip. If
> > + omitted, assumed to be equal to 'bank-width'.
>=20
> Maybe I'm rehashing some old discussion here, if so, sorry; but why
> do you have bank-width and device-width here? What useful information
> does it provide? If this is about saying what the preferred (or only
> possible) access width is, better names are in order.
device-width isn't used so we can get rid of it. bank-width is used by the=
=20
map_ram driver for erase operations (mapram_erase in=20
drivers/mtd/chips/map_ram.c). To be honest I'm not sure why it uses such an=
=20
inefficient approach instead of memsetting the whole area.
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Describe memory-mapped RAM&ROM chips of bindings
From: David Gibson @ 2008-03-27 9:44 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd
In-Reply-To: <200803271037.17654.laurentp@cse-semaphore.com>
On Thu, Mar 27, 2008 at 10:37:17AM +0100, Laurent Pinchart wrote:
> On Wednesday 26 March 2008 15:52, Segher Boessenkool wrote:
> > > + Dedicated RAM and ROM chips are often used as storage for
> > > temporary or
> > > + permanent data in embedded devices. Possible usage include
> > > non-volatile
> > > + storage in battery-backed SRAM, semi-permanent storage in
> > > dedicated SRAM
> > > + to preserve data accross reboots and firmware storage in
> > > dedicated ROM.
> > > +
> > > + - compatible : should contain the specific model of RAM/ROM
> > > chip(s)
> > > + used, if known, followed by either "physmap-ram" or
> > > "physmap-rom"
> > > + - reg : Address range of the RAM/ROM chip
> > > + - bank-width : Width (in bytes) of the RAM/ROM bank. Equal to the
> > > + device width times the number of interleaved chips.
> > > + - device-width : (optional) Width of a single RAM/ROM chip. If
> > > + omitted, assumed to be equal to 'bank-width'.
> >
> > Maybe I'm rehashing some old discussion here, if so, sorry; but why
> > do you have bank-width and device-width here? What useful information
> > does it provide? If this is about saying what the preferred (or only
> > possible) access width is, better names are in order.
>
> device-width isn't used so we can get rid of it. bank-width is used by the
> map_ram driver for erase operations (mapram_erase in
> drivers/mtd/chips/map_ram.c). To be honest I'm not sure why it uses such an
> inefficient approach instead of memsetting the whole area.
Sounds like bank-width is meaningless then, and doesn't belong in the
device tree. The shim which instantiates the mtd device from the
device tree can make something up.
--
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: OF compatible MTD platform RAM driver ?
From: David Gibson @ 2008-03-27 10:03 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linux-mtd, linuxppc-dev
In-Reply-To: <200803271013.32612.laurentp@cse-semaphore.com>
On Thu, Mar 27, 2008 at 10:13:32AM +0100, Laurent Pinchart wrote:
> On Wednesday 26 March 2008 13:53, Sergei Shtylyov wrote:
> > Laurent Pinchart wrote:
[snip]
> > Heh, we've gone thru "physmap" before -- it was labelled Linux-specific
> > name (well, I'd agree with that).
>
> physmap stands for physically mapped. That doesn't sound
> Linux-specific to me, the fact that the MTD driver has the same name
> is a pure coincidence. linmap-rom and linmap-rom sound even more
> Linux-specific :-)
It may not be Linux specific per se, but it's a bad name, because the
fact that the device is physically direct mapped isn't a useful
distinguishing feature of the device. Main memory is also direct
physically mapped, after all, but that's not what you want to cover
with this description. In general how a device is wired is described
by where it sits in the tree, not by its properties.
It only seems like a usefully distinguishing name because it's the
Linux "physmap_of" driver that uses it. So in this sense it is a
Linux specific name after all. In fact, physmap_of is itself very
badly named - right now it only handles direct mapped mtds, but that's
not inherent; it could be trivially extended to also instantiate a
non-direct-mapped device (as long as the underlying mtd layer
supported it, of course). It bears no relation at all to the
"physmap" driver, except historical accident.
> Could we agree on a name ? I'd like to submit a new patch.
For ROMs I think just plain "rom" should be sufficient. For RAMs we
need something to indicate that it's memory but intended for secondary
storage, not as main memory. Unfortunately, I'm finding myself unable
to think of something.
--
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/11] cell: generalize io-workarounds code
From: Ishizaki Kou @ 2008-03-27 11:02 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1206355474.7197.35.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I may have missed something in your patch but if the workarounds are
> specific to a given bridge, they may as well set the top level
> indirections once straight to the right workarounds.
>
> Also, my understanding is that we are pretty much using the same
> bridge on the cell blades, so is there any way that can be
> consolidated rather than having function pointers ?
Celleb has two different bus bridges such as PCI and PCI-Express, and
they have different bus access methods. Cell blades support only one
PCI, so you may have only one indirect access method. That is why I
introduced second level indirect function.
Considering to embed 'second level' indirect function into first level
macros, it may break iSeries.
> I'll try to have a closer look next week, but I'm a bit worried by
> having all IO go through 2 level of function pointers, the PPE isn't
> very good at it and this will slow things down more than they already
> are.
Only on celleb, all IO go through 2 level of function pointers.
On cell blades, you can set global variable "ppc_pci_io" up at function
spider_pci_workaround_init() directly instead of calling function
io_workaround_init(), so all IO on cell blades use only one level of
function pointer which is stored in ppc_pci_io.
> > I may have missed something in your patch but if the workarounds are
> > specific to a given bridge, they may as well set the top level
> > indirections once straight to the right workarounds.
>
> Looking more closely, I wonder if a good solution would be to move the
> function pointers away from globals, to the dev_archdata structure,
> and thus make them per-device (like the DMA ops)
As you said, if read/write/in/out functions take device parameter,
taking I/O function pointers into the dev_archdata structure should be
the best solution. But they don't take device parameter, and they must
search I/O function pointers with address parameter. I think it's
better they search pointers from bus bridges, because access mothod
for a device on its parent bus bridge, not device itself.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-27 12:23 UTC (permalink / raw)
To: David Gibson; +Cc: ben, linux-mtd, linuxppc-dev
In-Reply-To: <20080327100304.GC10397@localhost.localdomain>
Hello.
David Gibson wrote:
>>>Laurent Pinchart wrote:
> [snip]
>>> Heh, we've gone thru "physmap" before -- it was labelled Linux-specific
>>>name (well, I'd agree with that).
>>physmap stands for physically mapped. That doesn't sound
>>Linux-specific to me, the fact that the MTD driver has the same name
>>is a pure coincidence. linmap-rom and linmap-rom sound even more
>>Linux-specific :-)
> It may not be Linux specific per se, but it's a bad name, because the
> fact that the device is physically direct mapped isn't a useful
> distinguishing feature of the device.
Yeah, it's not a propery of a device itself (yet, the device would be
useless if this information is not supplied in the tree somehow). Yet remember
the now ungoing discussion about "reg-shift" property for UARTs -- some people
said that the fact that this property may not be a feature of device is
irrelevant WRT the binding. :-)
> Main memory is also direct physically mapped, after all, but that's not what you want to cover
> with this description.
Haven't ever seen the description of memory as a device (unless you mean
the "memory" node which can hardly be considered proper device -- mainly
because of their usual placement at the top of the tree, and not where a RAM
device logically should be in the bus hierarchy).
> In general how a device is wired is described by where it sits in the tree, not by its properties.
Oh, another argument against "reg-shift" in the Xilinx UART quarry... :-)
> It only seems like a usefully distinguishing name because it's the
> Linux "physmap_of" driver that uses it. So in this sense it is a
> Linux specific name after all. In fact, physmap_of is itself very
> badly named - right now it only handles direct mapped mtds, but that's
Yeah, because that's what is what it has been written for.
> not inherent; it could be trivially extended to also instantiate a
> non-direct-mapped device (as long as the underlying mtd layer
> supported it, of course). It bears no relation at all to the
> "physmap" driver, except historical accident.
This driver resides on the "top", device mapping layer of the MTD
hierarchy, and I don't see a point of cramming support for all the possible
mappings into one driver vs doing it as the *separate* specific drivers in
drivers/mtd/mapps/ -- as it has been done in the MTD tree before "the great OF
revolution". This is really strange idea...
WBR, Sergei
^ permalink raw reply
* Please pull 'for-2.6.26' branch of 4xx tree
From: Josh Boyer @ 2008-03-27 12:24 UTC (permalink / raw)
To: paulus, linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26
to pick up the first round of 4xx patches for 2.6.26. There are a few
new board ports, some Xilinx driver updates, and some DCR helper
macros.
Grant has two bootwrapper patches that I would like to see go in as
well, but I need to test them a bit more first.
josh
David Gibson (1):
[POWERPC] Start removing linux,network-index in favour of aliases
Josh Boyer (3):
[POWERPC] 4xx: Add AMCC 440EP Yosemite DTS
[POWERPC] 4xx: Add platform support for the AMCC Yosemite board
[POWERPC] 4xx: Add bootwrapper for AMCC Yosemite board
Stefan Roese (10):
[POWERPC] 4xx: Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S
[POWERPC] 4xx: Add AMCC Canyonlands 460EX eval board support to platforms/44x
[POWERPC] 4xx: Add Canyonlands DTS
[POWERPC] 4xx: Add 460EX PCIe support to 4xx pci driver
[POWERPC] 4xx: Add Canyonlands defconfig file
[POWERPC] 4xx: Add TAH support to taishan dts
[POWERPC] 4xx: Add AMCC Glacier 460GT eval board dts
[POWERPC] 4xx: Add "amcc, haleakala" to the toplevel compatible property
[POWERPC] 4xx: Add PPC4xx L2-cache support (440GX)
[POWERPC] 4xx: Add L2 cache node to AMCC Taishan dts file
Stephen Neuendorffer (3):
[POWERPC] Xilinx: hwicap: Refactor status handling code.
[POWERPC] Xilinx: hwicap: Verify sync before reading idcode.
[POWERPC] Xilinx: hwicap: Use fixed device major.
Valentine Barshak (2):
[POWERPC] 4xx: Add dcri_clrset() for locked read/modify/write functionality
[POWERPC] 4xx: Use dcri_clrset() for PCIe indirect dcr read/modify/write access
Documentation/powerpc/booting-without-of.txt | 16 -
arch/powerpc/Kconfig | 3 +
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/bamboo.c | 3 +-
arch/powerpc/boot/cuboot-rainier.c | 3 +-
arch/powerpc/boot/cuboot-sequoia.c | 3 +-
arch/powerpc/boot/cuboot-taishan.c | 3 +-
arch/powerpc/boot/cuboot-warp.c | 2 +-
arch/powerpc/boot/cuboot-yosemite.c | 44 ++
arch/powerpc/boot/dts/bamboo.dts | 2 -
arch/powerpc/boot/dts/canyonlands.dts | 391 ++++++++++++++
arch/powerpc/boot/dts/ebony.dts | 2 -
arch/powerpc/boot/dts/glacier.dts | 464 +++++++++++++++++
arch/powerpc/boot/dts/haleakala.dts | 2 +-
arch/powerpc/boot/dts/rainier.dts | 2 -
arch/powerpc/boot/dts/sequoia.dts | 2 -
arch/powerpc/boot/dts/taishan.dts | 27 +-
arch/powerpc/boot/dts/walnut.dts | 1 -
arch/powerpc/boot/dts/warp.dts | 1 -
arch/powerpc/boot/dts/yosemite.dts | 304 +++++++++++
arch/powerpc/boot/ebony.c | 3 +-
arch/powerpc/boot/treeboot-walnut.c | 2 +-
arch/powerpc/configs/canyonlands_defconfig | 721 ++++++++++++++++++++++++++
arch/powerpc/kernel/cpu_setup_44x.S | 5 +-
arch/powerpc/kernel/cputable.c | 28 +-
arch/powerpc/platforms/44x/Kconfig | 28 +
arch/powerpc/platforms/44x/Makefile | 2 +
arch/powerpc/platforms/44x/canyonlands.c | 64 +++
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_pci.c | 127 +++++-
arch/powerpc/sysdev/ppc4xx_pci.h | 59 +++
arch/powerpc/sysdev/ppc4xx_soc.c | 189 +++++++
drivers/char/xilinx_hwicap/buffer_icap.c | 22 +-
drivers/char/xilinx_hwicap/buffer_icap.h | 5 +-
drivers/char/xilinx_hwicap/fifo_icap.c | 31 +-
drivers/char/xilinx_hwicap/fifo_icap.h | 1 +
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 63 ++-
drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +
include/asm-powerpc/dcr-native.h | 17 +
include/asm-powerpc/dcr-regs.h | 78 +++
40 files changed, 2643 insertions(+), 105 deletions(-)
^ permalink raw reply
* RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
From: Joakim Tjernlund @ 2008-03-27 12:43 UTC (permalink / raw)
To: Li Yang; +Cc: Netdev, Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <989B956029373F45A0B8AF029708189001D198BC@zch01exm26.fsl.freescale.net>
On Wed, 2008-03-26 at 20:43 +0800, Li Yang wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Tuesday, March 25, 2008 5:18 PM
> > To: Li Yang
> > Cc: Netdev; Linuxppc-Embedded@Ozlabs.Org
> > Subject: Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> >
> >
> > On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:
> > > >> -----Original Message-----
> > > >> From: netdev-owner@vger.kernel.org
> > > >> [mailto:netdev-owner@vger.kernel.org] On Behalf Of
> > Joakim Tjernlund
> > > > Sent: Tuesday, March 18, 2008 11:11 PM
> > > >> To: Netdev; Li Yang
> > > >> Cc: Joakim Tjernlund
> > > >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> > > >>
> > > >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to the
> > > >> frame and the HW controller is not prepared to TX a frame bigger
> > > >> than 1518 bytes which is 4 bytes too small for a full
> > VLAN frame.
> > > >> Also add 4 extra bytes for future expansion.
> > > >
> > > > IMO, VLAN and Jumbo packet support is not general case of
> > Ethernet.
> > > > Could you make this change optional? Thanks.
> > > >
> > > > - Leo
> > >
> > > hmm, I do not agree. VLAN is common today.
> > >
> > > If you were to enable HW support for VLAN then the ethernet
> > controller
> > > would inject an extra 4 bytes into the frame.
> > > This change does not change the visible MTU for the user.
> > As is now,
> > > soft VLAN is silently broken. Do you really want the user
> > to find and
> > > turn on a controller specific feature to use VLAN?
> > >
> > > What does netdev people think?
> > >
> > > Jocke
> >
> > hmm, I misread the HW specs. The change has nothing to do
> > with TX, it is the MAX RX frame size that was too small for
> > VLAN and that is what the patch addresses. I see that tg3.c
> > adds 4 bytes to MAX RX pkgs:
> > /* MTU + ethernet header + FCS + optional VLAN tag */
> > tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8); So
> > I don't think this change should be hidden behind a new
> > CONFIG option. Updated patch below with changed description.
>
> Hi Jocke,
>
> QUICC engine supports dynamic maximum frame length. If you are not
> expecting to receive only tagged frames, I recommend to use this feature
> by setting dynamicMaxFrameLength and dynamicMinFrameLength in ug_info
> instead of increasing the MaxLength for both tagged and untagged frames.
> See the following part from the reference manual.
>
> The MFLR entry in the Global Parameter RAM defines the length of the
> largest frame, excluding Q TAG
> but including FCS, that is still valid. When REMODER[DXE]=1, a tagged
> frame that has length equals
> MaxLength+4 considered valid, and a non tagged frame that has length
> equals MaxLength is the longest
> that is still considered valid. When REMODER[DXE]=0, any frame longer
> than MaxLength consider
> erroneous frame.
> For systems with only tagged frames, set REMODER[DXE]=0 and set
> MaxLength = Max LLC size+4.
>
> - Leo
Interesting, that should also work although QinQ will not. I will have
a closer look but I still don't see how my orginal patch would
harm anything. One could add my patch on top but with only 4 bytes
extra.
Jocke
^ permalink raw reply
* Re: [PATCH] [POWERPC] Remove CONFIG_PCI_LEGACY from some configs
From: Kumar Gala @ 2008-03-27 12:45 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20080327163608.81f87de2.sfr@canb.auug.org.au>
On Mar 27, 2008, at 12:36 AM, Stephen Rothwell wrote:
> This will remove some build warnings and doesn't stop us building any
> drivers that we were building previously with these configs.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Doesn't this hide issues on the defconfigs most often built for PPC?
- k
^ permalink raw reply
* Re: MPC8641D PCI-Express problem
From: Kumar Gala @ 2008-03-27 12:52 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47E8F836.9060603@coritel.it>
On Mar 25, 2008, at 8:03 AM, Marco Stornelli wrote:
> Kumar Gala ha scritto:
>> On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote:
>>> Hi,
>>>
>>> do you remember my problem with the pci-express? I have an
>>> mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the
>>> Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm
>>> observing this strange behavior:
>>>
>>> 1) I turn on the board and I stop the U-boot
>>> 2) I load the FPGA microcode
>>> 3) I start the system
>>> 4) I load the driver module and I read a version register in the
>>> FPGA
>>> 5) The system crashes with a "machine check exception: transfer
>>> error ack signal"
>>> 6) reboot
>>> 7) same procedure (without load the FPGA again)
>>> 8) now I can read the registers!
>>>
>>> If I repeat the procedure again it doesn't work anymore. I think
>>> it's a problem with pci-express controller. Have you got any
>>> suggestions?
>>>
>>> Thanks.
>> Where are you loading the FPGA microcode (linux, u-boot)? Also, is
>> the FPGA the only device connected over PCIe?
>> - k
> I load the FPGA with JTAG and with a Xilinx program without a
> specific linux driver or u-boot. Yes, it is the only device
> connected over PCIe.
The issue may be related to the PCIe link training. Are you able to
access the FPGA in u-boot? Can you try reseting the PCIe controller
after you've loaded up the FPGA (see u-boot code in drivers/pci/
fsl_pci_init.c and look for CONFIG_FSL_PCIE_RESET)
- k
^ permalink raw reply
* Re: Missing patch for MPC5200B register definitions?
From: Grant Likely @ 2008-03-27 13:25 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <47EA7E72.3010502@genesi-usa.com>
On Wed, Mar 26, 2008 at 10:48 AM, Matt Sealey <matt@genesi-usa.com> wrote:
> Oh yes, I forgot.. also, the new MPC5121E stuff includes a lot of unions and
> defines to make using both PSC formats easier.
>
> Since the MPC5200 and MPC5200B PSC structures are different (CCR size), can the
> original suggestion (in that thread) to support both with a union and some
> defines to make supporting both CCR sizes, be implemented, or do we still think
> that MPC5200 (not B) is not worth supporting?
Until someone writes a driver actually using it; let's pretend it
doesn't exist. :-) It's not too difficult to add it back in at a
later date if someone does decide to support it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Missing patch for MPC5200B register definitions?
From: Grant Likely @ 2008-03-27 13:27 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <47EA7687.5000102@genesi-usa.com>
On Wed, Mar 26, 2008 at 10:15 AM, Matt Sealey <matt@genesi-usa.com> wrote:
> I've just been looking into the MPC5200B AC97 driver breakage with the
> latest Git kernel, and found the following patch;
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035952.html
>
> Is not in the latest tree. As such anything which uses the new MPC5200B
> registers (especially important on AC97 and probably not used otherwise)
> has not or was not applied.
>
> Since the latest kernel source from git actually includes the MPC5121E
> differences, I assume this is a regression?
>
> How do we go about fixing this?
Write a patch to apply that change in arch/powerpc and post it to the
list. If it looks good, I'll pick it up.
BTW, did you figure out if the AC97 driver is being picked up by the
ALSA maintainers?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Valentine Barshak @ 2008-03-27 13:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080326073554.1d8229d6@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, 25 Mar 2008 10:22:15 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Thu, 2008-03-06 at 16:43 +0300, Valentine Barshak wrote:
>>> This patch adds ibm_newemac PHY clock workaround for 440EP/440GR EMAC
>>> attached to a PHY which doesn't generate RX clock if there is no link.
>>> The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
>>> allows controlling each EMAC clock separately as opposed to global clock
>>> selection for 440GX.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> This never went to netdev or Jeff from what I can see.
>
> josh
Do I need to resend these and the other one from
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052114.html
cc'ing Jeff?
I thought it was decided that Ben collects and sends all emac patches to
netdev.
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH 2/2] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Josh Boyer @ 2008-03-27 13:53 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47EBA616.9070705@ru.mvista.com>
On Thu, 27 Mar 2008 16:50:14 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> Josh Boyer wrote:
> > On Tue, 25 Mar 2008 10:22:15 +1100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> >> On Thu, 2008-03-06 at 16:43 +0300, Valentine Barshak wrote:
> >>> This patch adds ibm_newemac PHY clock workaround for 440EP/440GR EMAC
> >>> attached to a PHY which doesn't generate RX clock if there is no link.
> >>> The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
> >>> allows controlling each EMAC clock separately as opposed to global clock
> >>> selection for 440GX.
> >>>
> >>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> >> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > This never went to netdev or Jeff from what I can see.
> >
> > josh
>
> Do I need to resend these and the other one from
> http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052114.html
> cc'ing Jeff?
Can't hurt.
> I thought it was decided that Ben collects and sends all emac patches to
> netdev.
So did I.
josh
^ 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