* 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
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-27 14:31 UTC (permalink / raw)
To: David Gibson; +Cc: ben, linux-mtd, linuxppc-dev
In-Reply-To: <20080327100304.GC10397@localhost.localdomain>
On Thursday 27 March 2008 11:03, David Gibson wrote:
> 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).
> >=20
> > 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 :-)
>=20
> 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.
>=20
> 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.
>=20
> > Could we agree on a name ? I'd like to submit a new patch.
>=20
> 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.
What about "storage-ram", "auxiliary-ram", "secondary-ram", "application-ra=
m",
"user-ram" or "ramdisk" ?
=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
* [PATCH] [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
From: Stefan Roese @ 2008-03-27 14:43 UTC (permalink / raw)
To: linuxppc-dev
This patch creates a common system reset routine for all 40x and 44x
systems. Previously only a 44x routine existed. But since this system
reset via the debug control register is common for 40x and 44x let's
share this code for all those platforms in ppc4xx_soc.c.
This patch also enables CONFIG_4xx_SOC for all 40x and 44x platforms.
Tested on Kilauea (405EX) and Canyonlands (440EX).
Signed-off-by: Stefan Roese <sr@denx.de>
---
This patch applies to the linux-next tree of today (2008-03-27).
arch/powerpc/platforms/40x/ep405.c | 2 ++
arch/powerpc/platforms/40x/kilauea.c | 4 +++-
arch/powerpc/platforms/40x/makalu.c | 2 ++
arch/powerpc/platforms/40x/virtex.c | 2 ++
arch/powerpc/platforms/40x/walnut.c | 4 +++-
arch/powerpc/platforms/44x/44x.h | 1 -
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/44x/bamboo.c | 15 +++++++--------
arch/powerpc/platforms/44x/canyonlands.c | 5 ++---
arch/powerpc/platforms/44x/ebony.c | 5 ++---
arch/powerpc/platforms/44x/katmai.c | 5 ++---
arch/powerpc/platforms/44x/misc_44x.S | 11 -----------
arch/powerpc/platforms/44x/rainier.c | 4 ++--
arch/powerpc/platforms/44x/sequoia.c | 4 +---
arch/powerpc/platforms/44x/taishan.c | 5 ++---
arch/powerpc/platforms/44x/warp.c | 6 ++----
arch/powerpc/platforms/Kconfig.cputype | 2 ++
arch/powerpc/sysdev/ppc4xx_soc.c | 11 +++++++++++
include/asm-powerpc/ppc4xx.h | 18 ++++++++++++++++++
19 files changed, 63 insertions(+), 44 deletions(-)
create mode 100644 include/asm-powerpc/ppc4xx.h
diff --git a/arch/powerpc/platforms/40x/ep405.c b/arch/powerpc/platforms/40x/ep405.c
index 13d1345..ae2e7f6 100644
--- a/arch/powerpc/platforms/40x/ep405.c
+++ b/arch/powerpc/platforms/40x/ep405.c
@@ -29,6 +29,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
static struct device_node *bcsr_node;
static void __iomem *bcsr_regs;
@@ -119,5 +120,6 @@ define_machine(ep405) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
index f9206a7..1dd24ff 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -1,7 +1,7 @@
/*
* Kilauea board specific routines
*
- * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ * Copyright 2007-2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
*
* Based on the Walnut code by
* Josh Boyer <jwboyer@linux.vnet.ibm.com>
@@ -20,6 +20,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -54,5 +55,6 @@ define_machine(kilauea) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/40x/makalu.c b/arch/powerpc/platforms/40x/makalu.c
index 4e4df72..a6a1d60 100644
--- a/arch/powerpc/platforms/40x/makalu.c
+++ b/arch/powerpc/platforms/40x/makalu.c
@@ -20,6 +20,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id makalu_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -54,5 +55,6 @@ define_machine(makalu) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
index 0422590..fc7fb00 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -14,6 +14,7 @@
#include <asm/prom.h>
#include <asm/time.h>
#include <asm/xilinx_intc.h>
+#include <asm/ppc4xx.h>
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
{ .compatible = "xlnx,plb-v46-1.00.a", },
@@ -48,5 +49,6 @@ define_machine(virtex) {
.probe = virtex_probe,
.init_IRQ = xilinx_intc_init_tree,
.get_irq = xilinx_intc_get_irq,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/40x/walnut.c b/arch/powerpc/platforms/40x/walnut.c
index b8b257e..335df91 100644
--- a/arch/powerpc/platforms/40x/walnut.c
+++ b/arch/powerpc/platforms/40x/walnut.c
@@ -26,6 +26,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id walnut_of_bus[] = {
{ .compatible = "ibm,plb3", },
@@ -61,5 +62,6 @@ define_machine(walnut) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .calibrate_decr = generic_calibrate_decr,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
index 42eabf8..dbc4d2b 100644
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -3,6 +3,5 @@
extern u8 as1_readb(volatile u8 __iomem *addr);
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
-extern void ppc44x_reset_system(char *cmd);
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 5fc28aa..6abe913 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -129,7 +129,6 @@ config 440GP
config 440GX
bool
- select 4xx_SOC
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII #test only
diff --git a/arch/powerpc/platforms/44x/bamboo.c b/arch/powerpc/platforms/44x/bamboo.c
index fb9a22a..cef169e 100644
--- a/arch/powerpc/platforms/44x/bamboo.c
+++ b/arch/powerpc/platforms/44x/bamboo.c
@@ -22,8 +22,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
-
-#include "44x.h"
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id bamboo_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -53,11 +52,11 @@ static int __init bamboo_probe(void)
}
define_machine(bamboo) {
- .name = "Bamboo",
- .probe = bamboo_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .name = "Bamboo",
+ .probe = bamboo_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
index dac5b32..3949289 100644
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -23,8 +23,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
-
-#include "44x.h"
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id canyonlands_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -59,6 +58,6 @@ define_machine(canyonlands) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/ebony.c b/arch/powerpc/platforms/44x/ebony.c
index 1a8d467..a0e8fe4 100644
--- a/arch/powerpc/platforms/44x/ebony.c
+++ b/arch/powerpc/platforms/44x/ebony.c
@@ -26,8 +26,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
-
-#include "44x.h"
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id ebony_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -66,6 +65,6 @@ define_machine(ebony) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/katmai.c b/arch/powerpc/platforms/44x/katmai.c
index 1113412..44f4b3a 100644
--- a/arch/powerpc/platforms/44x/katmai.c
+++ b/arch/powerpc/platforms/44x/katmai.c
@@ -22,8 +22,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
-
-#include "44x.h"
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id katmai_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -58,6 +57,6 @@ define_machine(katmai) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/misc_44x.S b/arch/powerpc/platforms/44x/misc_44x.S
index 3bce71d..dc12b80 100644
--- a/arch/powerpc/platforms/44x/misc_44x.S
+++ b/arch/powerpc/platforms/44x/misc_44x.S
@@ -44,14 +44,3 @@ _GLOBAL(as1_writeb)
sync
isync
blr
-
-/*
- * void ppc44x_reset_system(char *cmd)
- *
- * At present, this routine just applies a system reset.
- */
-_GLOBAL(ppc44x_reset_system)
- mfspr r13,SPRN_DBCR0
- oris r13,r13,DBCR0_RST_SYSTEM@h
- mtspr SPRN_DBCR0,r13
- b . /* Just in case the reset doesn't work */
diff --git a/arch/powerpc/platforms/44x/rainier.c b/arch/powerpc/platforms/44x/rainier.c
index a7fae1c..4f1ff84 100644
--- a/arch/powerpc/platforms/44x/rainier.c
+++ b/arch/powerpc/platforms/44x/rainier.c
@@ -22,7 +22,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
-#include "44x.h"
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id rainier_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -57,6 +57,6 @@ define_machine(rainier) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
index d279db4..1782d41 100644
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ b/arch/powerpc/platforms/44x/sequoia.c
@@ -23,8 +23,6 @@
#include <asm/uic.h>
#include <asm/pci-bridge.h>
-#include "44x.h"
-
static __initdata struct of_device_id sequoia_of_bus[] = {
{ .compatible = "ibm,plb4", },
{ .compatible = "ibm,opb", },
@@ -58,6 +56,6 @@ define_machine(sequoia) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/taishan.c b/arch/powerpc/platforms/44x/taishan.c
index 28ab7e2..49c78b2 100644
--- a/arch/powerpc/platforms/44x/taishan.c
+++ b/arch/powerpc/platforms/44x/taishan.c
@@ -29,8 +29,7 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
-
-#include "44x.h"
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id taishan_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -68,6 +67,6 @@ define_machine(taishan) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index da5b7b7..39cf615 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -18,9 +18,7 @@
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
-
-#include "44x.h"
-
+#include <asm/ppc4xx.h>
static __initdata struct of_device_id warp_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -49,7 +47,7 @@ define_machine(warp) {
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
- .restart = ppc44x_reset_system,
+ .restart = ppc4xx_reset_system,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 0c3face..5fc7fac 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -41,11 +41,13 @@ config 40x
bool "AMCC 40x"
select PPC_DCR_NATIVE
select PPC_UDBG_16550
+ select 4xx_SOC
config 44x
bool "AMCC 44x"
select PPC_DCR_NATIVE
select PPC_UDBG_16550
+ select 4xx_SOC
config E200
bool "Freescale e200"
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
index 4b8617e..5b32adc 100644
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -23,6 +23,7 @@
#include <asm/dcr.h>
#include <asm/dcr-regs.h>
+#include <asm/reg.h>
static u32 dcrbase_l2c;
@@ -187,3 +188,13 @@ static int __init ppc4xx_l2c_probe(void)
return 0;
}
arch_initcall(ppc4xx_l2c_probe);
+
+/*
+ * At present, this routine just applies a system reset.
+ */
+void ppc4xx_reset_system(char *cmd)
+{
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_RST_SYSTEM);
+ while (1)
+ ; /* Just in case the reset doesn't work */
+}
diff --git a/include/asm-powerpc/ppc4xx.h b/include/asm-powerpc/ppc4xx.h
new file mode 100644
index 0000000..033039a
--- /dev/null
+++ b/include/asm-powerpc/ppc4xx.h
@@ -0,0 +1,18 @@
+/*
+ * PPC4xx Prototypes and definitions
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#ifndef __ASM_POWERPC_PPC4xx_H__
+#define __ASM_POWERPC_PPC4xx_H__
+
+extern void ppc4xx_reset_system(char *cmd);
+
+#endif /* __ASM_POWERPC_PPC4xx_H__ */
--
1.5.4.4
^ permalink raw reply related
* [PATCH] ibm_newemac: emac_tx_csum typo fix
From: Valentine Barshak @ 2008-03-27 14:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jeff, netdev
In-Reply-To: <20080327085353.6ac04886@zod.rchland.ibm.com>
Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
emac_has_feature parameters.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-21 16:45:36.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-22 19:55:29.000000000 +0300
@@ -1235,8 +1235,8 @@ static int emac_close(struct net_device
static inline u16 emac_tx_csum(struct emac_instance *dev,
struct sk_buff *skb)
{
- if (emac_has_feature(dev, EMAC_FTR_HAS_TAH &&
- skb->ip_summed == CHECKSUM_PARTIAL)) {
+ if (emac_has_feature(dev, EMAC_FTR_HAS_TAH) &&
+ (skb->ip_summed == CHECKSUM_PARTIAL)) {
++dev->stats.tx_packets_csum;
return EMAC_TX_CTRL_TAH_CSUM;
}
^ permalink raw reply
* [PATCH 2/2] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
From: Valentine Barshak @ 2008-03-27 14:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jeff, netdev
In-Reply-To: <20080327085353.6ac04886@zod.rchland.ibm.com>
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>
---
drivers/net/ibm_newemac/core.c | 34 ++++++++++++++++++++++++++++++++--
drivers/net/ibm_newemac/core.h | 6 +++++-
2 files changed, 37 insertions(+), 3 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-26 16:32:33.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-26 16:37:52.000000000 +0300
@@ -129,10 +129,29 @@ static struct device_node *emac_boot_lis
static inline void emac_report_timeout_error(struct emac_instance *dev,
const char *error)
{
- if (net_ratelimit())
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX |
+ EMAC_FTR_440EP_PHY_CLK_FIX))
+ DBG(dev, "%s" NL, error);
+ else if (net_ratelimit())
printk(KERN_ERR "%s: %s\n", dev->ndev->name, error);
}
+/* EMAC PHY clock workaround:
+ * 440EP/440GR has more sane SDR0_MFR register implementation than 440GX,
+ * which allows controlling each EMAC clock
+ */
+static inline void emac_rx_clk_tx(struct emac_instance *dev)
+{
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS >> dev->cell_index);
+}
+
+static inline void emac_rx_clk_default(struct emac_instance *dev)
+{
+ if (emac_has_feature(dev, EMAC_FTR_440EP_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, SDR0_MFR_ECS >> dev->cell_index, 0);
+}
+
/* PHY polling intervals */
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
@@ -1089,9 +1112,11 @@ static int emac_open(struct net_device *
int link_poll_interval;
if (dev->phy.def->ops->poll_link(&dev->phy)) {
dev->phy.def->ops->read_link(&dev->phy);
+ emac_rx_clk_default(dev);
netif_carrier_on(dev->ndev);
link_poll_interval = PHY_POLL_LINK_ON;
} else {
+ emac_rx_clk_tx(dev);
netif_carrier_off(dev->ndev);
link_poll_interval = PHY_POLL_LINK_OFF;
}
@@ -1169,6 +1194,7 @@ static void emac_link_timer(struct work_
if (dev->phy.def->ops->poll_link(&dev->phy)) {
if (!netif_carrier_ok(dev->ndev)) {
+ emac_rx_clk_default(dev);
/* Get new link parameters */
dev->phy.def->ops->read_link(&dev->phy);
@@ -1181,6 +1207,7 @@ static void emac_link_timer(struct work_
link_poll_interval = PHY_POLL_LINK_ON;
} else {
if (netif_carrier_ok(dev->ndev)) {
+ emac_rx_clk_tx(dev);
netif_carrier_off(dev->ndev);
netif_tx_disable(dev->ndev);
emac_reinitialize(dev);
@@ -2325,9 +2352,12 @@ static int __devinit emac_init_phy(struc
dev->phy.mdio_read = emac_mdio_read;
dev->phy.mdio_write = emac_mdio_write;
- /* Enable internal clock source */
+ /* EMAC PHY clock workaround */
if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ /* Enable internal clock source */
dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
+ else
+ emac_rx_clk_tx(dev);
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
@@ -2495,6 +2525,10 @@ static int __devinit emac_init_config(st
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-440gx"))
dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ } else {
+ if (of_device_is_compatible(np, "ibm,emac-440ep") ||
+ of_device_is_compatible(np, "ibm,emac-440gr"))
+ dev->features |= EMAC_FTR_440EP_PHY_CLK_FIX;
}
/* Fixup some feature bits based on the device tree */
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.h linux-2.6/drivers/net/ibm_newemac/core.h
--- linux-2.6.orig/drivers/net/ibm_newemac/core.h 2008-02-26 16:32:33.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.h 2008-02-26 16:37:52.000000000 +0300
@@ -305,6 +305,10 @@ struct emac_instance {
* Set if we need phy clock workaround for 440gx
*/
#define EMAC_FTR_440GX_PHY_CLK_FIX 0x00000080
+/*
+ * Set if we need phy clock workaround for 440ep or 440gr
+ */
+#define EMAC_FTR_440EP_PHY_CLK_FIX 0x00000100
/* Right now, we don't quite handle the always/possible masks on the
@@ -328,7 +332,7 @@ enum {
#ifdef CONFIG_IBM_NEW_EMAC_RGMII
EMAC_FTR_HAS_RGMII |
#endif
- 0,
+ EMAC_FTR_440EP_PHY_CLK_FIX,
};
static inline int emac_has_feature(struct emac_instance *dev,
^ permalink raw reply
* [PATCH 1/2] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
From: Valentine Barshak @ 2008-03-27 14:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jeff, netdev
In-Reply-To: <20080327085353.6ac04886@zod.rchland.ibm.com>
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
if there's no link. Because of that it fails to find PHY chip. The older ibm_emac
driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros,
which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
does the same for "ibm,emac-440gx" compatible chips. The workaround forces
clock on -all- EMACs, so we select clock under global emac_phy_map_lock.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 16 +++++++++++++++-
drivers/net/ibm_newemac/core.h | 8 ++++++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-22 19:56:26.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-22 20:38:47.000000000 +0300
@@ -43,6 +43,8 @@
#include <asm/io.h>
#include <asm/dma.h>
#include <asm/uaccess.h>
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
#include "core.h"
@@ -2323,6 +2325,10 @@ static int __devinit emac_init_phy(struc
dev->phy.mdio_read = emac_mdio_read;
dev->phy.mdio_write = emac_mdio_write;
+ /* Enable internal clock source */
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
+
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2355,6 +2361,11 @@ static int __devinit emac_init_phy(struc
if (!emac_mii_phy_probe(&dev->phy, i))
break;
}
+
+ /* Enable external clock source */
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, SDR0_MFR_ECS, 0);
+
mutex_unlock(&emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING "%s: can't find PHY!\n", np->full_name);
@@ -2480,8 +2491,11 @@ static int __devinit emac_init_config(st
}
/* Check EMAC version */
- if (of_device_is_compatible(np, "ibm,emac4"))
+ if (of_device_is_compatible(np, "ibm,emac4")) {
dev->features |= EMAC_FTR_EMAC4;
+ if (of_device_is_compatible(np, "ibm,emac-440gx"))
+ dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ }
/* Fixup some feature bits based on the device tree */
if (of_get_property(np, "has-inverted-stacr-oc", NULL))
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.h linux-2.6/drivers/net/ibm_newemac/core.h
--- linux-2.6.orig/drivers/net/ibm_newemac/core.h 2008-02-21 16:45:36.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.h 2008-02-22 19:57:44.000000000 +0300
@@ -301,6 +301,10 @@ struct emac_instance {
* Set if we have new type STACR with STAOPC
*/
#define EMAC_FTR_HAS_NEW_STACR 0x00000040
+/*
+ * Set if we need phy clock workaround for 440gx
+ */
+#define EMAC_FTR_440GX_PHY_CLK_FIX 0x00000080
/* Right now, we don't quite handle the always/possible masks on the
@@ -312,8 +316,8 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
- EMAC_FTR_STACR_OC_INVERT |
+ EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_TAH
EMAC_FTR_HAS_TAH |
^ permalink raw reply
* ksoftirqd_CPU0 uses 100% CPU
From: Wojciech Kromer @ 2008-03-27 14:50 UTC (permalink / raw)
To: linuxppc-embedded
Hello.
When I plug off ethernet cable ksoftirqd_CPU0 starts using 100% od CPU.
After pluging it back or downing eth0 interface it comes back to normal load.
Any sollution?
I'm using 2.4.25 on ppc 8250.
Regards.
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: Only reset PCIe PHY on 405EX systems when no link is detected
From: Stefan Roese @ 2008-03-27 15:34 UTC (permalink / raw)
To: linuxppc-dev
Since the arch/powerpc PCI subsystem now does a complete re-assignment of
the resources, we can move from the unconditional PCIe PHY reset to the
conditional version. Now the PHY is only reset, if no link is established yet.
An additional PHY reset (one is already done in U-Boot) leads to problems
with some Atheros PCIe boards and some HP FPGA PCIe designs.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 5abfcd1..9e633f8 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -830,17 +830,9 @@ static int ppc405ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
* PCIe boards don't show this problem.
* This has to be re-tested and fixed in a later release!
*/
-#if 0 /* XXX FIXME: Not resetting the PHY will leave all resources
- * configured as done previously by U-Boot. Then Linux will currently
- * not reassign them. So the PHY reset is now done always. This will
- * lead to problems with the Atheros PCIe board again.
- */
val = mfdcri(SDR0, port->sdr_base + PESDRn_LOOP);
if (!(val & 0x00001000))
ppc405ex_pcie_phy_reset(port);
-#else
- ppc405ex_pcie_phy_reset(port);
-#endif
dcr_write(port->dcrs, DCRO_PEGPL_CFG, 0x10000000); /* guarded on */
--
1.5.4.4
^ permalink raw reply related
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