* Re: [PATCH 1/3] powerpc clk.h interface for platforms
From: Christoph Hellwig @ 2007-07-11 10:36 UTC (permalink / raw)
To: Domen Puncer; +Cc: David Brownell, linuxppc-dev, Sylvain Munaut, linux-mips
In-Reply-To: <20070711093220.GF4375@moe.telargo.com>
On Wed, Jul 11, 2007 at 11:32:20AM +0200, Domen Puncer wrote:
> clk interface for arch/powerpc, platforms should fill
> clk_functions.
Umm, this is about the fifth almost identical implementation of
the clk_ functions. Please, please put it into common code.
And talk to the mips folks which just got a similar comment from me.
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Vitaly Bordug @ 2007-07-10 10:53 UTC (permalink / raw)
To: Olof Johansson; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707150147.GA2202@lixom.net>
On Sat, 7 Jul 2007 10:01:47 -0500
Olof Johansson wrote:
> On Sat, Jul 07, 2007 at 01:48:52PM +0400, Vitaly Bordug wrote:
> >
> > This adds support for MMIO IDE device like CompactFlash
> > in TrueIDE mode.
>
> Doesn't this duplicate most of pata_platform, but as the
> no-longer-preferred legacy IDE device? Did you try using
> pata_platform instead?
>
prolly true,
but as Sergei told upper, that's not an option so far due to internal reasons. But it is likely to be followed-up
that way a little bit later.
>
> -Olof
--
Sincerely, Vitaly
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 1/2] [ide] mmio ide support
From: Vitaly Bordug @ 2007-07-10 11:02 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20070707211306.2ef074cf@the-village.bc.nu>
On Sat, 7 Jul 2007 21:13:06 +0100
Alan Cox wrote:
> On Sat, 07 Jul 2007 13:48:52 +0400
> Vitaly Bordug <vitb@kernel.crashing.org> wrote:
>
> >
> > This adds support for MMIO IDE device like CompactFlash
> > in TrueIDE mode.
>
> Really we should be working towards libata support for all new
> devices. This looks like a candidate for the existing (or a little
> enhanced) pata_platform driver.
>
Yes I am aware of it, yet, the code was created for IDE subsystem due to internal reasons,
and I thought to better make it available for others at least. We'll prolly pick it up to move
to libata/pata_platform but not instantly afaict now.
> > +config BLK_DEV_MMIOIDE
> > + tristate "Memory Mapped IDE support"
>
> Please pick a better description. This isn't a generic option for
> enabling MMIO based IDE as you make it sound.
>
>
> Also we have an accepted match name for ATA platform devices - and
> adding another one messes it up irrespective of whether you want
> libata or legacy IDE support. If you use the same matches then your
> platform code, and everyone elses platform code can work with both
> drivers, except for hotpluggability.
>
> Other bugs
>
> - Your remove code releases the resources before the hwif which means
> it races another user trying to claim the resource
> - Be careful with ide_unregister. It exists and you can call it but
> its actually not very safe and there are lots of unfixed races in the
> IDE layer if you do
>
OK, makes sense.
>
> The "should we have a legacy ide driver that matches the libata
> pata_platform" question I don't really care about. Its a waste of
> effort in many ways but if you've written the code the work is done
> so why not use it.
>
> However it needs to be *compatible* so that platform devices can be
> claimed by either so the kernel build can pick legacy IDE v libata and
> not have to #ifdef all the platform code.
>
Sounds good. I'll look forward to address the issues, thanks.
> Alan
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] mmio ide support for mpc8349-itx target
From: Vitaly Bordug @ 2007-07-10 10:52 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <468FC376.2040405@ru.mvista.com>
On Sat, 07 Jul 2007 20:46:46 +0400
Sergei Shtylyov wrote:
> > +
> > +#ifdef CONFIG_MPC834x_ITX
>
> Erm, isn't this stuff misplaced? Is this really SoC device? I
> remember seeng this in the arch/ppc/ platform code before (in the
> internal tree)...
The point is to declare methods bsp, as mmio access may effectively vary (having bugs or intentionally) from platform to platform. All-in-one driver approach is nice but might be an issue to handle/maintain.
Thanks for looking at it, other notes make sense.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
From: Segher Boessenkool @ 2007-07-11 10:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: Paul Mackerras, linuxppc-dev list
In-Reply-To: <DB462F87-151E-4F21-80CF-209326FCEB67@kernel.crashing.org>
>>> + compatible = "fsl,mpc86xx-pciex","86xx";
>>
>> And "xx" again. Aren't the 85- and 86- PCIe controllers
>> compatible, btw?
>
> They are, but we need to distinguish between 83xx, 85xx, and 86xx
> pci, pciex, pci-x controllers.
Sure, but if 85xx-pcie and 86xx-pcie are compatible, the OS
driver can match on the same "compatible" entry for both.
Just choose one -- "fsl,8641-pcie" or something. It is a
good idea to put the exact name of the controller on the
board in the first "compatible" entry in case it is found
later that some specific model needs a workaround or some
other special treatment, but in general, everything can
just use the generic "grandfather" model to match on.
Segher
^ permalink raw reply
* Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node
From: Segher Boessenkool @ 2007-07-11 10:59 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184121840.22066.24.camel@localhost.localdomain>
>>> pci1: pci@8000 {
>>> interrupt-map-mask = <1f800 0 0 7>;
>>
>> Set the mask to <1800 0 0 7>, and you need only 16
>> entries to encode the swizzle. Except...
>>
>>> + /* bus 1 , idsel 0x2 Tsi310 bridge
>> secondary */
>>
>> ...interrupts on bus 1 should be swizzled on bus 1, not
>> at the PHB. Really. It is a horrible workaround for a
>> non-existing problem to do it here, and I promise you
>> it _will_ come back to hurt you later. Not a threat,
>> just a promise :-)
>
> I just want to make it as a temporary workaround now.
That is fine.
> Extra patches will be provided to fix it.
Looking forward to it!
>>> + pci@a000 {
>>> + interrupt-map-mask = <f800 0 0 7>;
>>> + interrupt-map = <
>>> +
>>> + /* IDSEL 0x0 (PEX) */
>>> + 00000 0 0 1 &mpic 0 1
>>> + 00000 0 0 2 &mpic 1 0
>>> + 00000 0 0 3 &mpic 2 0
>>> + 00000 0 0 4 &mpic 3 0>;
>>
>> Why sense 0 for all but the first entry in this map?
> Now, only the first entry is used.
Sure, but the other three entries are incorrect. Either
provide correct entries, or just leave the unused entries
out of the map; if those three interrupts aren't wired up,
that is the right thing to do, too.
Segher
^ permalink raw reply
* Re: Porting kernel 2.6.11 to WindRiver board.
From: Clemens Koller @ 2007-07-11 11:02 UTC (permalink / raw)
To: linuxdev; +Cc: linuxppc-embedded
In-Reply-To: <11459454.post@talk.nabble.com>
linuxdev schrieb:
> I have to port a linux kernel to Motorola MPC 7447 based WindRiver SBC 7447
> board.
The MPC7447 is one of the G4+ PowerPC processor series.
You shouldn't run into much issues to get Linux running on it.
A good start can be to use the latest ELDK from http://www.denx.de.
I created a native PowerPC environment for embedded use based on the
latest CRUX linux distribution (http://cruxppc.sunsite.dk).
CRUX is also available for x86 (http://crux.nu) which is nice
to work completely platform independent.
> I plan to use Kernel 2.6.11 and Uboot for the same.
It doesn't make sense to use an older than the latest Kernel because
nobody wants to help you in case you run into problems.
Use the latest linux git tree. (or at least some 2.6.22)
And use the latest U-Boot git tree. (also from denx)
> I wanted to know whether
> these two can be used for the board. Also how do I get hold of a BSP for
> this board and kernel? Are there any information resources for the same?
It's all available in the web. It depends on your hardware setup
how complicated your "porting" might be. I hope you good good documentation
for it.
If you have a Harddisk to boot from or some network interface, "porting"
it might be as simple as installing some x86 platform.
> Thanks in advance...
> LinuxDev.
Please use your real name.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [PATCH] do firmware feature fixups after features are initialised
From: Segher Boessenkool @ 2007-07-11 11:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Michael Neuling, paulus, Arnd Bergmann
In-Reply-To: <1184149691.6059.82.camel@localhost.localdomain>
> There are two possibly solutions I see in the long run:
>
> - We could set the FW features earlier on pseries, though that is
> a bit
> annoying because that means doing it before the device-tree is
> unflattened.
>
> - We could constraint lmb_alloc to the first segment until the FW
> fixup
> occurs, either within lmb_alloc itself, or fixup the callers such as
> unflatten_device_tree, to pass an explicit limit.
c) use a different SLB handler during early boot;
d) preload some SLB entries at very early boot to cover
the first 4GB or so.
d) sounds nice and simple, but will it work?
Segher
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-11 11:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070710161121.GA14556@ld0162-tx32.am.freescale.net>
>>> + - compatible : Should be "fsl,mpc8xxx-dma"
>>
>> Should _include_, not should _be_. And none of this xxx
>> business, of course.
>
> Especially since the 85xx/86xx version is not 100% compatible with the
> 83xx version. How about fsl,mpc8349-dma and fsl,mpc8548-dma for
> the two
> variants?
Fine with me. Do put the exact model name in every .dts
file as well, e.g. for a hypothetical MPC8599:
compatible = "fsl,mpc8599-dma", "fsl,mpc8548-dma";
so the kernel can match on the exact name if it needs a
quirk, but can use the more generic name otherwise.
>>> + - extended : Set the DMA channel to work at extended chain
>>> mode.
>>> + If not set, the DMA channel will work at basic
>>> + chain mode.
>>
>> Call it "extended-chain-mode", perhaps?
>
> Or don't call it anything. The ability to do extended chain mode is
> implicit in being compatible with fsl,mpc8548-dma.
Right. I'm not sure having the channels as separate subnodes
buys anything at all, btw.
>>> + - reserved : Reserve the DMA channel to device.
>>
>> What does this do? Reserve it for what device, and where?
>> The OS driver?
>
> Some hardware has DMA channels hardwired to certain peripherals,
> such as
> an audio codec. This keeps them from being used as general purpose
> DMA
> channels.
I think you need this knowledge in the kernel drivers anyway,
or at the very least, the device node for for example that
audio codec needs to refer to the DMA channel in the device
tree, so this "reserved" property is unnecessary.
> I'd rather just treat the different DMA channels as independent
> devices,
> rather than children of a dma "bus", and change the compatible name if
> they're not general purpose. There's only one register that's shared
> among the channels, and it's a superfluous status summary register.
If you make separate nodes for the channels, they need to have
a parent. I don't think it makes sense to have the channel
nodes and the "master" node as siblings -- maybe it all should
be just one node with a "#channels" property or such?
Segher
^ permalink raw reply
* Re: [PATCH] do firmware feature fixups after features are initialised
From: Benjamin Herrenschmidt @ 2007-07-11 11:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Michael Neuling, paulus, Arnd Bergmann
In-Reply-To: <3269B7A5-2D77-4C4D-B28D-397CB73E8568@kernel.crashing.org>
On Wed, 2007-07-11 at 13:06 +0200, Segher Boessenkool wrote:
> > There are two possibly solutions I see in the long run:
> >
> > - We could set the FW features earlier on pseries, though that is
> > a bit
> > annoying because that means doing it before the device-tree is
> > unflattened.
> >
> > - We could constraint lmb_alloc to the first segment until the FW
> > fixup
> > occurs, either within lmb_alloc itself, or fixup the callers such as
> > unflatten_device_tree, to pass an explicit limit.
>
> c) use a different SLB handler during early boot;
> d) preload some SLB entries at very early boot to cover
> the first 4GB or so.
>
> d) sounds nice and simple, but will it work?
Nah, best to limit everything at boot to SLB 0. Thing is, 4G is not
enough, you may have more RAM and have allocations from the top.
Ben.
^ permalink raw reply
* Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts
From: Segher Boessenkool @ 2007-07-11 11:27 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3CE1@zch01exm26.fsl.freescale.net>
>>> + dma@21000{
>>> + compatible = "fsl,mpc8xxx-dma";
>>
>> Please use a real name, not this "xxx" stuff.
>
> Does the "xxx" seems to be an evil name? :-)
You are stating this particular device is compatible to
the "mpc8xxx-dma" device, which doesn't exist. If it is
supposed to mean it is compatible to the DMA controller
on any 8000-series device, that is incorrect; in the future,
there might be many such devices with an incompatible DMA
controller.
Just put in some real device model name.
>>> + reg = <21000 100>;
>>> + ranges = <0 21000 1000>;
>>
>> These overlap, that can't be right; it is just begging for
>> trouble.
>
> There is no overlap. The 'reg' is used for the register of DMA
> controller. And the ranges is used for belows channel registers.
And 21000..210ff is a subset of 21000..21fff. So there _is_
overlap.
> Such as ch0@100, reg=<100 80>, in fact, the ch0 register address is
> 0x21100.
Sure, none of the "reg"s in any of the children overlap the
parent "reg", but the parent "reg" overlaps the "ranges".
>>> + ch0@100{
>>> + reg = <100 80>;
>>> + extended;
>>
>> I think you want a little more detailed property name
>> than "extended" here?
>
> I've explained it in [PATCH 1/4] Add DMA sector to
> Documentation/powerpc/booting-without-of.txt file.
> As below:
> + - extended : Set the DMA channel to work at extended chain mode.
> + If not set, the DMA channel will work at basic
> + chain mode.
Sure it's documented, but it would be good if the property
name itself would say a bit more than just "extended". Property
names can be 31 characters, there's no need to make short names
(terse is good, content-free isn't).
Segher
^ permalink raw reply
* Re: [PATCH] do firmware feature fixups after features are initialised
From: Arnd Bergmann @ 2007-07-11 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Michael Neuling, paulus
In-Reply-To: <1184149691.6059.82.camel@localhost.localdomain>
On Wednesday 11 July 2007, Benjamin Herrenschmidt wrote:
> There are two possibly solutions I see in the long run:
>=20
> =A0- We could set the FW features earlier on pseries, though that is a bit
> annoying because that means doing it before the device-tree is
> unflattened.
>=20
> =A0- We could constraint lmb_alloc to the first segment until the FW fixup
> occurs, either within lmb_alloc itself, or fixup the callers such as
> unflatten_device_tree, to pass an explicit limit.
>=20
> What do you think ?
If I'm understanding this right, the first solution should be something
along the lines of the patch below (not tested), which even removes
more lines than it adds. It doesn't seem that annoying to me, and it
makes sense to assume that the fw_features are set up after returning
from the ppc_md probe.
Arnd <><
Index: linux-2.6/arch/powerpc/platforms/pseries/setup.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- linux-2.6.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6/arch/powerpc/platforms/pseries/setup.c
@@ -327,8 +327,6 @@ static void __init pSeries_init_early(vo
{
DBG(" -> pSeries_init_early()\n");
=20
=2D fw_feature_init();
=2D
if (firmware_has_feature(FW_FEATURE_LPAR))
find_udbg_vterm();
=20
@@ -350,14 +348,21 @@ static int __init pSeries_probe_hypertas
const char *uname, int depth,
void *data)
{
+ const char *hypertas;
+ unsigned long len;
+
if (depth !=3D 1 ||
(strcmp(uname, "rtas") !=3D 0 && strcmp(uname, "rtas@0") !=3D 0))
=2D return 0;
+ return 0;
+
+ hypertas =3D of_get_flat_dt_prop(node, "ibm,hypertas-functions", &len);
+ if (!hypertas)
+ return 1;
=20
=2D if (of_get_flat_dt_prop(node, "ibm,hypertas-functions", NULL) !=3D NULL)
=2D powerpc_firmware_features |=3D FW_FEATURE_LPAR;
+ powerpc_firmware_features |=3D FW_FEATURE_LPAR;
+ fw_feature_init(hypertas, len);
=20
=2D return 1;
+ return 1;
}
=20
static int __init pSeries_probe(void)
Index: linux-2.6/arch/powerpc/platforms/pseries/pseries.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- linux-2.6.orig/arch/powerpc/platforms/pseries/pseries.h
+++ linux-2.6/arch/powerpc/platforms/pseries/pseries.h
@@ -10,7 +10,7 @@
#ifndef _PSERIES_PSERIES_H
#define _PSERIES_PSERIES_H
=20
=2Dextern void __init fw_feature_init(void);
+extern void __init fw_feature_init(const char *, unsigned long);
=20
struct pt_regs;
=20
diff --git a/arch/powerpc/platforms/pseries/firmware.c b/arch/powerpc/platf=
orms/pseries/firmware.c
index 29bf83b..b0c8dbd 100644
=2D-- a/arch/powerpc/platforms/pseries/firmware.c
+++ b/arch/powerpc/platforms/pseries/firmware.c
@@ -66,24 +66,14 @@ firmware_features_table[FIRMWARE_MAX_FEATURES] =3D {
* device-tree/ibm,hypertas-functions. Ultimately this functionality may
* be moved into prom.c prom_init().
*/
=2Dvoid __init fw_feature_init(void)
+void __init fw_feature_init(const char *hypertas, unsigned long len)
{
struct device_node *dn;
const char *hypertas, *s;
=2D int len, i;
+ int i;
=20
DBG(" -> fw_feature_init()\n");
=20
=2D dn =3D of_find_node_by_path("/rtas");
=2D if (dn =3D=3D NULL) {
=2D printk(KERN_ERR "WARNING! Cannot find RTAS in device-tree!\n");
=2D goto out;
=2D }
=2D
=2D hypertas =3D of_get_property(dn, "ibm,hypertas-functions", &len);
=2D if (hypertas =3D=3D NULL)
=2D goto out;
=2D
for (s =3D hypertas; s < hypertas + len; s +=3D strlen(s) + 1) {
for (i =3D 0; i < FIRMWARE_MAX_FEATURES; i++) {
/* check value against table of strings */
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-11 11:40 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F3D20@zch01exm26.fsl.freescale.net>
>>> + - extended : Set the DMA channel to work at extended
>> chain mode.
>>> + If not set, the DMA channel will work at basic
>>> + chain mode.
>>
>> Call it "extended-chain-mode", perhaps?
>
> Is it maybe too long?
Not really no. It's only 19 characters, and it isn't used
all over the place, so that should be fine.
>>> + - reserved : Reserve the DMA channel to device.
>>
>> What does this do? Reserve it for what device, and where?
>> The OS driver?
>>
>
> Yes, it reserve for the special device, which must use the fixed
> channel. Thus, reserve channels requested by that device.
>
> And in the device node of dts file, you can use such as
> "dma-channel=<&dma-ch0>" to reference the below channel:
>
> dma-ch0: ch0@100 {
> ...
> }
Right, so you don't need a "reserved" property, that information
is in the tree already.
Alternatively, for ease of use, you could put a "reserved" bitmap
in the master DMA controller node. I wouldn't make nodes per
channel anyway, just describe the channels using properties -- that
takes care of the "reg" vs. "ranges" thing too, etc.
Segher
^ permalink raw reply
* Re: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
From: Jean Delvare @ 2007-07-11 11:40 UTC (permalink / raw)
To: Domen Puncer; +Cc: i2c, linuxppc-embedded
In-Reply-To: <20070711063335.GB4375@moe.telargo.com>
Hi Domen,
On Wed, 11 Jul 2007 08:33:35 +0200, Domen Puncer wrote:
> On 11/07/07 00:03 -0600, Grant Likely wrote:
> > I don't think it's a great idea to use a link; You should copy the
> > important parts into the .c file. Archives may not be forever, and
> > links cannot be read when offline. If the text is too long for the
> > middle of the C file; then put the documentation at the top right
> > after the header block.
>
> And v4:
> <----------- cut ------------->
>
> Work around a problem reported on:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> Without this patch I2C on mpc5200 becomes unusable after a while.
> Tested on mpc5200 boards by Matthias Fechner and me.
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Applied, thanks.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] do firmware feature fixups after features are initialised
From: Segher Boessenkool @ 2007-07-11 11:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Michael Neuling, paulus, Arnd Bergmann
In-Reply-To: <1184153248.6059.87.camel@localhost.localdomain>
>> d) preload some SLB entries at very early boot to cover
>> the first 4GB or so.
>>
>> d) sounds nice and simple, but will it work?
>
> Nah, best to limit everything at boot to SLB 0. Thing is, 4G is not
> enough, you may have more RAM and have allocations from the top.
Yeah fair enough. You could of course preload the stuff at
the top then, but that could quickly become a nasty hack, too.
Segher
^ permalink raw reply
* Re: [PATCH] Fix mpc7448hpc2 tsi108 device_type bug
From: Segher Boessenkool @ 2007-07-11 11:55 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras, David Gibson
In-Reply-To: <1184135957.23157.6.camel@localhost.localdomain>
> Fix mpc7448hpc2 tsi108 device_type bug.
> Wrong device type will break the board startup.
> - device_type = "tsi108-bridge";
> + device_type = "tsi-bridge";
The OS code shouldn't use "device_type" at all for this,
but "compatible" instead. You might want to fix that.
This patch is fine until you do of course.
Segher
^ permalink raw reply
* Re: [PATCH] Consolidate mm_context_t definition in mmu.h
From: Josh Boyer @ 2007-07-11 12:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, paulus, david
In-Reply-To: <20070711103308.GA15536@lst.de>
On Wed, 2007-07-11 at 12:33 +0200, Christoph Hellwig wrote:
>
> mm_context_id_t isn't actually used anywhere but in te mm_context_t
> definition. So if you kill it you have two common fields and a bunch
> of additional ones for PPC64 leading to a defintion like:
>
> typedef struct {
> unsigned long id;
>
> #ifdef CONFIG_PPC64
> u16 user_psize; /* page size index */
>
> #ifdef CONFIG_PPC_MM_SLICES
> u64 low_slices_psize; /* SLB page size encodings */
> u64 high_slices_psize; /* 4 bits per slice for now */
> #else
> u16 sllp; /* SLB page size encoding */
> #endif
> #endif
>
> unsigned long vdso_base;
> } mm_context_t;
Yes. I did mostly the same thing in version 2 of the patch, just using
mm_context_id_t instead. Paul said the ifdefs made his eyes hurt.
josh
^ permalink raw reply
* Re: MPC82xx ADS SCC ports initialisation
From: Laurent Pinchart @ 2007-07-11 13:13 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20070711143422.6b00620e@localhost.localdomain>
Hi Vitaly,
On Wednesday 11 July 2007 12:34, Vitaly Bordug wrote:
> On Wed, 11 Jul 2007 09:11:18 +0200
>
> Laurent Pinchart wrote:
> > On Tuesday 10 July 2007 20:11, Scott Wood wrote:
> > > On Tue, Jul 10, 2007 at 04:19:51PM +0200, Laurent Pinchart wrote:
> > > > clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 -
> > > > data->clk_tx))); clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038
> > > > << (4 - data->clk_rx))); setbits32(&immap->im_cpmux.cmx_scr,
> > > > ((data->clk_tx - 1) << (4 - data->clk_tx)));
> > > > setbits32(&immap->im_cpmux.cmx_scr,
> > > > ((data->clk_rx - 1) << (4 - data->clk_rx)));
> > > >
> > > > The shift right-hand operand doesn't seem to be correct. Could
> > > > anyone confirm this ?
> > >
> > > You are correct; it's broken.
> >
> > That code should be replaced with calls to cpm2_clk_setup
> > (arch/powerpc/sysdev/cpm2_common.c). cpm2_clk_setup currently
> > supports FCC clock setup only, but I've got a patch to add SCC clock
> > setup support. Should I send it ?
>
> If you have functional approach, please feel free to send it...
I haven't been able to test the patch, as I have no ADS hardware to test it
on. My MPC82xx board is far from being ported to the powerpc architecture.
I'll send the patch anyway. Could you evaluate it ?
> > > > If my assumption is right, could anyone tell me if the MPC82xx
> > > > processors are actually supported by the powerpc architecture, or
> > > > if the MPC82xx ADS code is just a non-functional work in progress.
>
> once my last changes were committed, 82xx was supported and worked fine.
> Pretty long time I had no access to the hardware, hence some minor things
> might require catch-up.
The above code might have been worked by sheer luck though.
> > > I have a bunch of 8xx/82xx changes pending; I hope to get them
> > > cleaned up before the merge window ends.
>
> Since I'm the only person covering 8xx/82xx for a while, I definitely want
> to look at those changes...
>
> > That would be nice. I'll wait for your changes to continue my ppc ->
> > powerpc port.
> >
> > > > I also noticed that U-Boot doesn't have flatten device tree
> > > > support for the MPC82xx family.
>
> At the moment, I have a patch to add such a thing, but no ability to
> validate it still works. If you guys will assist a little, I'll go ahead
> and submit it to the u-boot list.
I'm ready to help, but I'd like to port my board to the powerpc architecture
first. FDT support in U-Boot is pretty useless with the ppc architecture.
> > > No, but cuImage for 82xx is on its way.
> >
> > Ok, nice to know. Adding FDT support to U-Boot for the MPC82xx family
> > will be on my todo-list once I get Linux working with cuImage.
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/2] [POWERPC] Add SCC clock support to cpm2_clk_setup()
From: Laurent Pinchart @ 2007-07-11 13:17 UTC (permalink / raw)
To: linuxppc-embedded
cpm2_clk_setup() supports setting FCC clocks only, even though the
cpm_clk_target enumeration lists SCC clocks. This patch adds SCC clock
support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@technotrade.biz>
---
arch/powerpc/sysdev/cpm2_common.c | 38 ++++++++++++++++++++++++++++++++++--
1 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2_common.c
b/arch/powerpc/sysdev/cpm2_common.c
index 9244129..459fead 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -138,7 +138,39 @@ int cpm2_clk_setup(enum cpm_clk_target target, int clock,
int mode)
cpmux_t *im_cpmux;
u32 *reg;
u32 mask = 7;
- u8 clk_map [24][3] = {
+ u8 clk_map [][3] = {
+ {CPM_CLK_SCC1, CPM_BRG1, 0},
+ {CPM_CLK_SCC1, CPM_BRG2, 1},
+ {CPM_CLK_SCC1, CPM_BRG3, 2},
+ {CPM_CLK_SCC1, CPM_BRG4, 3},
+ {CPM_CLK_SCC1, CPM_CLK5, 4},
+ {CPM_CLK_SCC1, CPM_CLK6, 5},
+ {CPM_CLK_SCC1, CPM_CLK7, 6},
+ {CPM_CLK_SCC1, CPM_CLK8, 7},
+ {CPM_CLK_SCC2, CPM_BRG1, 0},
+ {CPM_CLK_SCC2, CPM_BRG2, 1},
+ {CPM_CLK_SCC2, CPM_BRG3, 2},
+ {CPM_CLK_SCC2, CPM_BRG4, 3},
+ {CPM_CLK_SCC2, CPM_CLK5, 4},
+ {CPM_CLK_SCC2, CPM_CLK6, 5},
+ {CPM_CLK_SCC2, CPM_CLK7, 6},
+ {CPM_CLK_SCC2, CPM_CLK8, 7},
+ {CPM_CLK_SCC3, CPM_BRG1, 0},
+ {CPM_CLK_SCC3, CPM_BRG2, 1},
+ {CPM_CLK_SCC3, CPM_BRG3, 2},
+ {CPM_CLK_SCC3, CPM_BRG4, 3},
+ {CPM_CLK_SCC3, CPM_CLK5, 4},
+ {CPM_CLK_SCC3, CPM_CLK6, 5},
+ {CPM_CLK_SCC3, CPM_CLK7, 6},
+ {CPM_CLK_SCC3, CPM_CLK8, 7},
+ {CPM_CLK_SCC4, CPM_BRG1, 0},
+ {CPM_CLK_SCC4, CPM_BRG2, 1},
+ {CPM_CLK_SCC4, CPM_BRG3, 2},
+ {CPM_CLK_SCC4, CPM_BRG4, 3},
+ {CPM_CLK_SCC4, CPM_CLK5, 4},
+ {CPM_CLK_SCC4, CPM_CLK6, 5},
+ {CPM_CLK_SCC4, CPM_CLK7, 6},
+ {CPM_CLK_SCC4, CPM_CLK8, 7},
{CPM_CLK_FCC1, CPM_BRG5, 0},
{CPM_CLK_FCC1, CPM_BRG6, 1},
{CPM_CLK_FCC1, CPM_BRG7, 2},
@@ -203,13 +235,13 @@ int cpm2_clk_setup(enum cpm_clk_target target, int
clock, int mode)
if (mode == CPM_CLK_RX)
shift +=3;
- for (i=0; i<24; i++) {
+ for (i=0; i<ARRAY_SIZE(clk_map); i++) {
if (clk_map[i][0] == target && clk_map[i][1] == clock) {
bits = clk_map[i][2];
break;
}
}
- if (i == sizeof(clk_map)/3)
+ if (i == ARRAY_SIZE(clk_map))
ret = -EINVAL;
bits <<= shift;
--
1.5.0
^ permalink raw reply related
* [PATCH 2/2] [POWERPC] Use cpm2_clk_setup to configure SCC clocks for the MPC82xx ADS
From: Laurent Pinchart @ 2007-07-11 13:18 UTC (permalink / raw)
To: linuxppc-embedded
Signed-off-by: Laurent Pinchart <laurent.pinchart@technotrade.biz>
---
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 16 ++++------------
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
index 47cb09f..c8a29b9 100644
--- a/arch/powerpc/platforms/82xx/mpc82xx_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc82xx_ads.c
@@ -234,12 +234,8 @@ static void init_scc1_uart_ioports(struct
fs_uart_platform_info *data)
clrbits32(&immap->im_ioport.iop_pdird, 0x00000001);
setbits32(&immap->im_ioport.iop_pdird, 0x00000002);
- clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
- clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
- setbits32(&immap->im_cpmux.cmx_scr,
- ((data->clk_tx - 1) << (4 - data->clk_tx)));
- setbits32(&immap->im_cpmux.cmx_scr,
- ((data->clk_rx - 1) << (4 - data->clk_rx)));
+ cpm2_clk_setup(CPM_CLK_SCC1, data->clk_rx, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_SCC1, data->clk_tx, CPM_CLK_TX);
iounmap(immap);
}
@@ -253,12 +249,8 @@ static void init_scc4_uart_ioports(struct
fs_uart_platform_info *data)
clrbits32(&immap->im_ioport.iop_pdird, 0x00000200);
setbits32(&immap->im_ioport.iop_pdird, 0x00000400);
- clrbits32(&immap->im_cpmux.cmx_scr, (0x00000007 << (4 - data->clk_tx)));
- clrbits32(&immap->im_cpmux.cmx_scr, (0x00000038 << (4 - data->clk_rx)));
- setbits32(&immap->im_cpmux.cmx_scr,
- ((data->clk_tx - 1) << (4 - data->clk_tx)));
- setbits32(&immap->im_cpmux.cmx_scr,
- ((data->clk_rx - 1) << (4 - data->clk_rx)));
+ cpm2_clk_setup(CPM_CLK_SCC4, data->clk_rx, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_SCC4, data->clk_tx, CPM_CLK_TX);
iounmap(immap);
}
--
1.5.0
^ permalink raw reply related
* Re: ask two question about e500 implementation in arch/ppc/kernel/head_fsl_booke.S
From: Kumar Gala @ 2007-07-11 13:41 UTC (permalink / raw)
To: kang shuo; +Cc: linuxppc-embedded
In-Reply-To: <a7f827420707110321scea22beg9505286e00ba79b2@mail.gmail.com>
On Jul 11, 2007, at 5:21 AM, kang shuo wrote:
> hi,galak:
> I have two question about e500 part of linux kernel. I
> can not get reponse from maillist . So I sent the questions to you
> directly.
>
> 1. in arch/ppc/kernel/head_fsl_booke.S
> 603 FIND_PTE
> 604 andi. r13, r11, _PAGE_PRESENT /* Is the page present? */
> 605 beq 2f /* Bail if not present */
>
> That seems _PAGE_PRESENT should be set before enter DataTLBError
> exception handler(Or the following finish_tlb_load function will not
> execute), but in __ioremap function of e500 implementation,
> _PAGE_PRESENT bit is not set for an io address map.Why?
_PAGE_PRESENT is sent when we use the page not when we map it. So on
the first fault we set _PAGE_PRESENT.
> 2. still in arch/ppc/kernel/head_fsl_booke.S
> 791 #ifdef CONFIG_E200
> 792 /* Round robin TLB1 entries assignment */
> 793 mfspr r12, SPRN_MAS0
> 794
> 795 /* Extract TLB1CFG(NENTRY) */
> 796 mfspr r11, SPRN_TLB1CFG
> 797 andi. r11, r11, 0xfff
> 798
> 799 /* Extract MAS0(NV) */
> 800 andi. r13, r12, 0xfff
> 801 addi r13, r13, 1
> 802 cmpw 0, r13, r11
> 803 addi r12, r12, 1
> 804
> 805 /* check if we need to wrap */
> 806 blt 7f
> 807
> 808 /* wrap back to first free tlbcam entry */
> 809 lis r13, tlbcam_index@ha
> 810 lwz r13, tlbcam_index@l(r13)
> 811 rlwimi r12, r13, 0, 20, 31
> 812 7:
> 813 mtspr SPRN_MAS0,r12
> 814 #endif /* CONFIG_E200 */
> 815
> 816 tlbwe
>
> That seems original tlb entry will be overwritten in the above code
> for e500? Why , I thought a free tlb entry should be select and fill
> for e500. Just like CONFIG_E200.
Huh? The above code is for E200 only. Maybe the issue you're missing
is that on E500 the NV bit is updated by HW.
- k
^ permalink raw reply
* [RFC][PATCH 0/8] arch/powerpc support for Walnut Board
From: Josh Boyer @ 2007-07-11 13:52 UTC (permalink / raw)
To: linuxppc-dev
For those interested, here's my current patch set to get PPC405 support
working in arch/powerpc.
Patches 1, 2, 3, 4, and 5 are probably ready to merge whenever. The
patches specific to Walnut need some more work before I would consider
those remotely usable. However, you can use them to build a zImage that
correctly determines the clocking and has a working serial console.
As always, comments welcome.
josh
^ permalink raw reply
* [RFC][PATCH 1/8] 4xx Kconfig cleanup
From: Josh Boyer @ 2007-07-11 13:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184161957.32199.52.camel@weaponx.rchland.ibm.com>
Remove some leftover cruft in the 40x Kconfig file. Also make sure we
select WANT_DEVICE_TREE for 40x.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/4xx/Kconfig | 77 ---------------------------------
arch/powerpc/platforms/Kconfig.cputype | 1
2 files changed, 1 insertion(+), 77 deletions(-)
--- linux-2.6.orig/arch/powerpc/platforms/4xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/4xx/Kconfig
@@ -1,16 +1,3 @@
-config 4xx
- bool
- depends on 40x || 44x
- default y
-
-config BOOKE
- bool
- depends on 44x
- default y
-
-menu "AMCC 40x options"
- depends on 40x
-
#config BUBINGA
# bool "Bubinga"
# depends on 40x
@@ -82,8 +69,6 @@ menu "AMCC 40x options"
# help
# This option enables support for the Xilinx ML300 evaluation board.
-endmenu
-
# 40x specific CPU modules, selected based on the board above.
config NP405H
bool
@@ -126,68 +111,6 @@ config IBM405_ERR77
config IBM405_ERR51
bool
-menu "AMCC 44x options"
- depends on 44x
-
-#config BAMBOO
-# bool "Bamboo"
-# depends on 44x
-# default n
-# select 440EP
-# help
-# This option enables support for the IBM PPC440EP evaluation board.
-
-config EBONY
- bool "Ebony"
- depends on 44x
- default y
- select 440GP
- help
- This option enables support for the IBM PPC440GP evaluation board.
-
-#config LUAN
-# bool "Luan"
-# depends on 44x
-# default n
-# select 440SP
-# help
-# This option enables support for the IBM PPC440SP evaluation board.
-
-#config OCOTEA
-# bool "Ocotea"
-# depends on 44x
-# default n
-# select 440GX
-# help
-# This option enables support for the IBM PPC440GX evaluation board.
-
-endmenu
-
-# 44x specific CPU modules, selected based on the board above.
-config 440EP
- bool
- select PPC_FPU
- select IBM440EP_ERR42
-
-config 440GP
- bool
- select IBM_NEW_EMAC_ZMII
-
-config 440GX
- bool
-
-config 440SP
- bool
-
-config 440A
- bool
- depends on 440GX
- default y
-
-# 44x errata/workaround config symbols, selected by the CPU models above
-config IBM440EP_ERR42
- bool
-
#config XILINX_OCP
# bool
# depends on XILINX_ML300
--- linux-2.6.orig/arch/powerpc/platforms/Kconfig.cputype
+++ linux-2.6/arch/powerpc/platforms/Kconfig.cputype
@@ -40,6 +40,7 @@ config PPC_8xx
config 40x
bool "AMCC 40x"
select PPC_DCR_NATIVE
+ select WANT_DEVICE_TREE
config 44x
bool "AMCC 44x"
^ permalink raw reply
* [RFC][PATCH 2/8] 4xx boot wrapper reworks
From: Josh Boyer @ 2007-07-11 13:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
In-Reply-To: <1184161957.32199.52.camel@weaponx.rchland.ibm.com>
Rename the 44x.c wrapper file to 4xx.c and make the fixup_memsize function
common for all of 4xx. Also adds a common function to reset ethernet and a
40x reset function.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/44x.c | 85 ----------------------------------
arch/powerpc/boot/44x.h | 4 -
arch/powerpc/boot/4xx.c | 111 +++++++++++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/4xx.h | 20 ++++++++
arch/powerpc/boot/Makefile | 4 -
arch/powerpc/boot/dcr.h | 2
arch/powerpc/boot/ebony.c | 3 -
7 files changed, 137 insertions(+), 92 deletions(-)
--- linux-2.6.orig/arch/powerpc/boot/44x.h
+++ linux-2.6/arch/powerpc/boot/44x.h
@@ -10,10 +10,6 @@
#ifndef _PPC_BOOT_44X_H_
#define _PPC_BOOT_44X_H_
-void ibm44x_fixup_memsize(void);
-void ibm4xx_fixup_ebc_ranges(const char *ebc);
-
-void ibm44x_dbcr_reset(void);
void ebony_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/4xx.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright 2007 David Gibson, IBM Corporation.
+ *
+ * Based on earlier code:
+ * Matt Porter <mporter@kernel.crashing.org>
+ * Copyright 2002-2005 MontaVista Software Inc.
+ *
+ * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
+ * Copyright (c) 2003, 2004 Zultys Technologies
+ *
+ * This program 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.
+ */
+#include <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "ops.h"
+#include "reg.h"
+#include "dcr.h"
+
+/* Read the 4xx SDRAM controller to get size of system memory. */
+void ibm4xx_fixup_memsize(void)
+{
+ int i;
+ unsigned long memsize, bank_config;
+
+ memsize = 0;
+ for (i = 0; i < ARRAY_SIZE(sdram_bxcr); i++) {
+ mtdcr(DCRN_SDRAM0_CFGADDR, sdram_bxcr[i]);
+ bank_config = mfdcr(DCRN_SDRAM0_CFGDATA);
+
+ if (bank_config & SDRAM_CONFIG_BANK_ENABLE)
+ memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
+ }
+
+ dt_fixup_memory(0, memsize);
+}
+
+#define DBCR0_RST_SYSTEM 0x30000000
+
+void ibm44x_dbcr_reset(void)
+{
+ unsigned long tmp;
+
+ /* DBCR0 on 44x is SPRN 0x134 */
+ asm volatile (
+ "mfspr %0,%1\n"
+ "oris %0,%0,%2@h\n"
+ "mtspr %1,%0"
+ : "=&r"(tmp) : "i"(0x134), "i"(DBCR0_RST_SYSTEM)
+ );
+
+}
+
+void ibm40x_dbcr_reset(void)
+{
+ unsigned long tmp;
+
+ /* DBCR0 on 4xx is SPRN 0x3F2 */
+ asm volatile (
+ "mfspr %0,%1\n"
+ "oris %0,%0,%2@h\n"
+ "mtspr %1,%0"
+ : "=&r"(tmp) : "i"(0x3F2), "i"(DBCR0_RST_SYSTEM)
+ );
+}
+
+#define EMAC_RESET 0x20000000
+#define MAL_RESET 0x80000000
+void ibm4xx_reset_eth(u32 *emac0, u32 *emac1)
+{
+ /* Reset the MAL and EMAC(s) since PIBS/OpenBIOS don't do this for us */
+ if (emac0)
+ *emac0 = EMAC_RESET;
+ if (emac1)
+ *emac1 = EMAC_RESET;
+
+ mtdcr(DCRN_MAL0_CFG, MAL_RESET);
+}
+
+/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
+ * banks into the OPB address space */
+void ibm4xx_fixup_ebc_ranges(const char *ebc)
+{
+ void *devp;
+ u32 bxcr;
+ u32 ranges[EBC_NUM_BANKS*4];
+ u32 *p = ranges;
+ int i;
+
+ for (i = 0; i < EBC_NUM_BANKS; i++) {
+ mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
+ bxcr = mfdcr(DCRN_EBC0_CFGDATA);
+
+ if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
+ *p++ = i;
+ *p++ = 0;
+ *p++ = bxcr & EBC_BXCR_BAS;
+ *p++ = EBC_BXCR_BANK_SIZE(bxcr);
+ }
+ }
+
+ devp = finddevice(ebc);
+ if (! devp)
+ fatal("Couldn't locate EBC node %s\n\r", ebc);
+
+ setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
+}
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/4xx.h
@@ -0,0 +1,20 @@
+/*
+ * PowerPC 4xx related functions
+ *
+ * Copyright 2007 IBM Corporation.
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#ifndef _POWERPC_BOOT_4XX_H_
+#define _POWERPC_BOOT_4XX_H_
+
+void ibm4xx_fixup_memsize(void);
+void ibm44x_dbcr_reset(void);
+void ibm40x_dbcr_reset(void);
+void ibm4xx_reset_eth(u32 *emac0, u32 *emac1);
+void ibm4xx_fixup_ebc_ranges(const char *ebc);
+
+#endif /* _POWERPC_BOOT_4XX_H_ */
--- linux-2.6.orig/arch/powerpc/boot/dcr.h
+++ linux-2.6/arch/powerpc/boot/dcr.h
@@ -121,4 +121,6 @@ static const unsigned long sdram_bxcr[]
#define DCRN_CPC0_MIRQ1 0x0ed
#define DCRN_CPC0_JTAGID 0x0ef
+#define DCRN_MAL0_CFG 0x180
+
#endif /* _PPC_BOOT_DCR_H_ */
--- linux-2.6.orig/arch/powerpc/boot/ebony.c
+++ linux-2.6/arch/powerpc/boot/ebony.c
@@ -25,6 +25,7 @@
#include "ops.h"
#include "reg.h"
#include "dcr.h"
+#include "4xx.h"
#include "44x.h"
extern char _dtb_start[];
@@ -98,7 +99,7 @@ static void ebony_fixups(void)
unsigned long sysclk = 33000000;
ibm440gp_fixup_clocks(sysclk, 6 * 1843200);
- ibm44x_fixup_memsize();
+ ibm4xx_fixup_memsize();
dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
}
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -31,7 +31,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-$(obj)/44x.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
zlib := inffast.c inflate.c inftrees.c
@@ -44,7 +44,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
- 44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
+ 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c
--- linux-2.6.orig/arch/powerpc/boot/44x.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * Copyright 2007 David Gibson, IBM Corporation.
- *
- * Based on earlier code:
- * Matt Porter <mporter@kernel.crashing.org>
- * Copyright 2002-2005 MontaVista Software Inc.
- *
- * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
- * Copyright (c) 2003, 2004 Zultys Technologies
- *
- * This program 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.
- */
-#include <stddef.h>
-#include "types.h"
-#include "string.h"
-#include "stdio.h"
-#include "ops.h"
-#include "reg.h"
-#include "dcr.h"
-
-/* Read the 44x memory controller to get size of system memory. */
-void ibm44x_fixup_memsize(void)
-{
- int i;
- unsigned long memsize, bank_config;
-
- memsize = 0;
- for (i = 0; i < ARRAY_SIZE(sdram_bxcr); i++) {
- mtdcr(DCRN_SDRAM0_CFGADDR, sdram_bxcr[i]);
- bank_config = mfdcr(DCRN_SDRAM0_CFGDATA);
-
- if (bank_config & SDRAM_CONFIG_BANK_ENABLE)
- memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
- }
-
- dt_fixup_memory(0, memsize);
-}
-
-#define SPRN_DBCR0 0x134
-#define DBCR0_RST_SYSTEM 0x30000000
-
-void ibm44x_dbcr_reset(void)
-{
- unsigned long tmp;
-
- asm volatile (
- "mfspr %0,%1\n"
- "oris %0,%0,%2@h\n"
- "mtspr %1,%0"
- : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
- );
-
-}
-
-/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
- * banks into the OPB address space */
-void ibm4xx_fixup_ebc_ranges(const char *ebc)
-{
- void *devp;
- u32 bxcr;
- u32 ranges[EBC_NUM_BANKS*4];
- u32 *p = ranges;
- int i;
-
- for (i = 0; i < EBC_NUM_BANKS; i++) {
- mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
- bxcr = mfdcr(DCRN_EBC0_CFGDATA);
-
- if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
- *p++ = i;
- *p++ = 0;
- *p++ = bxcr & EBC_BXCR_BAS;
- *p++ = EBC_BXCR_BANK_SIZE(bxcr);
- }
- }
-
- devp = finddevice(ebc);
- if (! devp)
- fatal("Couldn't locate EBC node %s\n\r", ebc);
-
- setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
-}
^ permalink raw reply
* [RFC][PATCH 3/8] 4xx MMU
From: Josh Boyer @ 2007-07-11 13:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184161957.32199.52.camel@weaponx.rchland.ibm.com>
Add MMU definitions for 40x platforms. Also fixes two warnings in 4xx_mmu.c.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/mm/4xx_mmu.c | 4 +-
include/asm-powerpc/mmu-4xx.h | 65 ++++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/mmu.h | 3 +
3 files changed, 70 insertions(+), 2 deletions(-)
--- /dev/null
+++ linux-2.6/include/asm-powerpc/mmu-4xx.h
@@ -0,0 +1,65 @@
+#ifndef _ASM_POWERPC_MMU_4XX_H_
+#define _ASM_POWERPC_MMU_4XX_H_
+
+/*
+ * PPC40x support
+ */
+
+#define PPC4XX_TLB_SIZE 64
+
+/*
+ * TLB entries are defined by a "high" tag portion and a "low" data
+ * portion. On all architectures, the data portion is 32-bits.
+ *
+ * TLB entries are managed entirely under software control by reading,
+ * writing, and searchoing using the 4xx-specific tlbre, tlbwr, and tlbsx
+ * instructions.
+ */
+
+#define TLB_LO 1
+#define TLB_HI 0
+
+#define TLB_DATA TLB_LO
+#define TLB_TAG TLB_HI
+
+/* Tag portion */
+
+#define TLB_EPN_MASK 0xFFFFFC00 /* Effective Page Number */
+#define TLB_PAGESZ_MASK 0x00000380
+#define TLB_PAGESZ(x) (((x) & 0x7) << 7)
+#define PAGESZ_1K 0
+#define PAGESZ_4K 1
+#define PAGESZ_16K 2
+#define PAGESZ_64K 3
+#define PAGESZ_256K 4
+#define PAGESZ_1M 5
+#define PAGESZ_4M 6
+#define PAGESZ_16M 7
+#define TLB_VALID 0x00000040 /* Entry is valid */
+
+/* Data portion */
+
+#define TLB_RPN_MASK 0xFFFFFC00 /* Real Page Number */
+#define TLB_PERM_MASK 0x00000300
+#define TLB_EX 0x00000200 /* Instruction execution allowed */
+#define TLB_WR 0x00000100 /* Writes permitted */
+#define TLB_ZSEL_MASK 0x000000F0
+#define TLB_ZSEL(x) (((x) & 0xF) << 4)
+#define TLB_ATTR_MASK 0x0000000F
+#define TLB_W 0x00000008 /* Caching is write-through */
+#define TLB_I 0x00000004 /* Caching is inhibited */
+#define TLB_M 0x00000002 /* Memory is coherent */
+#define TLB_G 0x00000001 /* Memory is guarded from prefetch */
+
+#ifndef __ASSEMBLY__
+
+typedef unsigned long phys_addr_t;
+
+typedef struct {
+ unsigned long id;
+ unsigned long vdso_base;
+} mm_context_t;
+
+#endif /* !__ASSEMBLY__ */
+
+#endif /* _ASM_POWERPC_MMU_4XX_H_ */
--- linux-2.6.orig/include/asm-powerpc/mmu.h
+++ linux-2.6/include/asm-powerpc/mmu.h
@@ -8,6 +8,9 @@
#elif defined(CONFIG_PPC_STD_MMU)
/* 32-bit classic hash table MMU */
# include <asm/mmu-hash32.h>
+#elif defined(CONFIG_40x)
+/* 40x-style software loaded TLB */
+# include <asm/mmu-4xx.h>
#elif defined(CONFIG_44x)
/* 44x-style software loaded TLB */
# include <asm/mmu-44x.h>
--- linux-2.6.orig/arch/powerpc/mm/4xx_mmu.c
+++ linux-2.6/arch/powerpc/mm/4xx_mmu.c
@@ -108,7 +108,7 @@ unsigned long __init mmu_mapin_ram(void)
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
- pmdp = pmd_offset(pgd_offset_k(v), v);
+ pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
pmd_val(*pmdp++) = val;
pmd_val(*pmdp++) = val;
pmd_val(*pmdp++) = val;
@@ -123,7 +123,7 @@ unsigned long __init mmu_mapin_ram(void)
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
- pmdp = pmd_offset(pgd_offset_k(v), v);
+ pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
pmd_val(*pmdp) = val;
v += LARGE_PAGE_SIZE_4M;
^ 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