* Re: [PATCH 2/3] Bamboo platform support
From: Stephen Rothwell @ 2007-05-15 0:58 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1179154743.3420.25.camel@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Hi Josh,
On Mon, 14 May 2007 09:59:03 -0500 Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> @@ -35,6 +35,7 @@ config 440EP
> bool
> select PPC_FPU
> select IBM440EP_ERR42
> +# select IBM_NEW_EMAC_ZMII
This bit belongs in a separate patch (I assume it slipped in by accident).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] Bamboo platform support
From: Josh Boyer @ 2007-05-15 1:03 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070515105837.204d080f.sfr@canb.auug.org.au>
On Tue, 2007-05-15 at 10:58 +1000, Stephen Rothwell wrote:
> Hi Josh,
>
> On Mon, 14 May 2007 09:59:03 -0500 Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> >
> > @@ -35,6 +35,7 @@ config 440EP
> > bool
> > select PPC_FPU
> > select IBM440EP_ERR42
> > +# select IBM_NEW_EMAC_ZMII
>
> This bit belongs in a separate patch (I assume it slipped in by accident).
Wasn't by accident. I was following the lead of what was done for
Ebony/440GP (which is actually broken at the moment but has a patch
pending to comment it out as above).
There is no ethernet period without the new EMAC rewrite and I'd like to
leave the select there but commented out to serve as a placeholder if
nothing else. Of course, if there are lots of objections it can be
pulled.
josh
^ permalink raw reply
* Re: [PATCH] Add -msoft-float to BOOTCFLAGS
From: Benjamin Herrenschmidt @ 2007-05-15 1:08 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1179190345.3420.74.camel@zod.rchland.ibm.com>
On Mon, 2007-05-14 at 19:52 -0500, Josh Boyer wrote:
> We want to avoid any float instructions that may occur in the wrapper that
> may be generated if the compiler isn't told not to.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/boot/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.orig/arch/powerpc/boot/Makefile
> +++ linux-2.6/arch/powerpc/boot/Makefile
> @@ -24,7 +24,7 @@ all: $(obj)/zImage
>
> HOSTCC := gcc
> BOOTCFLAGS := $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
> - $(shell $(CROSS32CC) -print-file-name=include) -fPIC
> + $(shell $(CROSS32CC) -print-file-name=include) -fPIC -msoft-float
> BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
>
> ifeq ($(call cc-option-yn, -fstack-protector),y)
^ permalink raw reply
* Re: Small fixes for the Ebony device tree
From: David Gibson @ 2007-05-15 1:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <3af16d1a6c09901f10dca3b6a3f8c698@kernel.crashing.org>
On Mon, May 14, 2007 at 02:59:31PM +0200, Segher Boessenkool wrote:
> > - i-cache-size = <0>;
> > - d-cache-size = <0>;
> > + i-cache-size = <2000000>; /* 32 kB */
> > + d-cache-size = <2000000>; /* 32 kB */
>
> That's 32MB, not 32kB. Better fix this :-)
Duh. Fixed.
> > UIC0: interrupt-controller0 {
>
> > UIC1: interrupt-controller1 {
>
> It's a shame you can't use unit addresses for these since
> you use "dcr-reg" instead of "reg". Oh well.
>
> > SDRAM0: sdram {
> > - device_type = "memory-controller";
> > compatible = "ibm,sdram-440gp", "ibm,sdram";
>
> Maybe rename the node to "memory-controller"?
Hmm, yeah, I guess so.
> > + SRAM0: sram {
> > + compatible = "ibm,sram440gp";
> > + dcr-reg = <020 8 00a 1>;
> > + };
>
> Is this thing _only_ addressable over DCRs? Weird.
Well... the control registers are certainly DCR only. I guess there's
the actual SRAM itself, though whether this belongs in this node, or
elsewhere isn't immediately clear. I haven't yet investigated how the
SRAM is mapped (it depends on DIP switch settings) so I'm certainly
not considering this node complete yet.
> > MAL0: mcmal {
> > - device_type = "mcmal-dma";
> > + device_type = "dma-controller";
> > compatible = "ibm,mcmal-440gp", "ibm,mcmal";
>
> Remove "device_type", change name to "dma-controller"?
Don't really want to remove the device_type, because the MAL driver
looks for it at present. Don't really want to change the name, since
that might encourage confusion with the other (more conventional) DMA
controller.
> > EBC0: ebc {
> > - device_type = "ibm,ebc";
> > compatible = "ibm,ebc-440gp";
>
> You forgot "ibm,ebc" here.
Hmm.. yeah, I guess.
Revised patch coming shortly.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/3] Initial AMCC Bamboo support
From: David Gibson @ 2007-05-15 1:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1179154608.3420.21.camel@zod.rchland.ibm.com>
On Mon, May 14, 2007 at 09:56:48AM -0500, Josh Boyer wrote:
> Hi All,
>
> The following patches add the initial AMCC Bamboo eval board support.
>
> The support for peripheral devices at the moment is rather limited as
> the board is quite complicated in it's muxing of I/O lines. Until the
> bootwrapper can figure out how to setup the EBC peripherals based on the
> dip switch settings, the DTS will lack any EBC devices.
Ick. Can you describe roughly the setup here? It might be that the
simplest approach is to include all options in the DTS, and delete
ones that aren't selected from the bootwrapper.
I have a patch which might help here, which fills in the ebc's
'ranges' property based on the contents of the EBC bridge registers.
I'm using it as part of the code necessary to get the right address
for the Ebony flash depending on DIP switch settings.
--
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 3/3] Bamboo wrapper
From: David Gibson @ 2007-05-15 1:28 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1179154791.3420.26.camel@zod.rchland.ibm.com>
On Mon, May 14, 2007 at 09:59:51AM -0500, Josh Boyer wrote:
> Add a bootwrapper for Bamboo
[snip]
> +#define DCRN_MAL0_CFG 0x180
> +static void ibm440ep_reset_eth(void)
> +{
> + /* reset the MAL and EMACs since PIBS doesn't do this for us */
> + u32 *emac0 = (u32 *)0xef600e00;
> + u32 *emac1 = (u32 *)0xef600f00;
> +
> + *emac0 = 0x20000000;
> + *emac1 = 0x20000000;
> + mtdcr(DCRN_MAL0_CFG, 0x80000000);
> +}
Since a number of 4xx board firmware suffer from this EMAC/MAL reset
problem it would be nice to factor this out into a common file.
> +static void ibm440ep_clear_uics(void)
> +{
> + /* Clear the UIC registers so we don't get spurious interrupts
> + * in the kernel
> + */
> + mtdcr(DCRN_UIC0_ER, 0x0);
> + mtdcr(DCRN_UIC0_SR, 0xffffffff);
> + mtdcr(DCRN_UIC1_ER, 0x0);
> + mtdcr(DCRN_UIC1_SR, 0xffffffff);
> +}
I don't think we should need this. As you suggested I added such a
clear to my UIC driver in the kernel proper.
--
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 3/3] Bamboo wrapper
From: Josh Boyer @ 2007-05-15 1:29 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070515012825.GD565@localhost.localdomain>
On Tue, 2007-05-15 at 11:28 +1000, David Gibson wrote:
> On Mon, May 14, 2007 at 09:59:51AM -0500, Josh Boyer wrote:
> > Add a bootwrapper for Bamboo
>
> [snip]
> > +#define DCRN_MAL0_CFG 0x180
> > +static void ibm440ep_reset_eth(void)
> > +{
> > + /* reset the MAL and EMACs since PIBS doesn't do this for us */
> > + u32 *emac0 = (u32 *)0xef600e00;
> > + u32 *emac1 = (u32 *)0xef600f00;
> > +
> > + *emac0 = 0x20000000;
> > + *emac1 = 0x20000000;
> > + mtdcr(DCRN_MAL0_CFG, 0x80000000);
> > +}
>
> Since a number of 4xx board firmware suffer from this EMAC/MAL reset
> problem it would be nice to factor this out into a common file.
Ok, I can look at doing that. Shouldn't be difficult.
> > +static void ibm440ep_clear_uics(void)
> > +{
> > + /* Clear the UIC registers so we don't get spurious interrupts
> > + * in the kernel
> > + */
> > + mtdcr(DCRN_UIC0_ER, 0x0);
> > + mtdcr(DCRN_UIC0_SR, 0xffffffff);
> > + mtdcr(DCRN_UIC1_ER, 0x0);
> > + mtdcr(DCRN_UIC1_SR, 0xffffffff);
> > +}
>
> I don't think we should need this. As you suggested I added such a
> clear to my UIC driver in the kernel proper.
Ah, true. Leftover cruft from before that was added. I'll remove.
josh
^ permalink raw reply
* Re: [PATCH 0/3] Initial AMCC Bamboo support
From: Josh Boyer @ 2007-05-15 1:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070515012629.GC565@localhost.localdomain>
On Tue, 2007-05-15 at 11:26 +1000, David Gibson wrote:
> On Mon, May 14, 2007 at 09:56:48AM -0500, Josh Boyer wrote:
> > Hi All,
> >
> > The following patches add the initial AMCC Bamboo eval board support.
> >
> > The support for peripheral devices at the moment is rather limited as
> > the board is quite complicated in it's muxing of I/O lines. Until the
> > bootwrapper can figure out how to setup the EBC peripherals based on the
> > dip switch settings, the DTS will lack any EBC devices.
>
> Ick. Can you describe roughly the setup here? It might be that the
> simplest approach is to include all options in the DTS, and delete
> ones that aren't selected from the bootwrapper.
There's 3 switches that directly control the EBC memory map, and a
handful of other pin strap registers add to that. To further complicate
things, there are two passes of the Bamboo board and the settings mean
different things to the individual board revisions.
By comparison, there's about 350 lines of code in U-Boot to do the setup
of the EBC. It's not horrible, but I'm not sure it wants to be
duplicated in the wrapper either.
> I have a patch which might help here, which fills in the ebc's
> 'ranges' property based on the contents of the EBC bridge registers.
> I'm using it as part of the code necessary to get the right address
> for the Ebony flash depending on DIP switch settings.
Ooh... that's actually what I was thinking of doing. Though I was
planning on poking individual nodes' regs properties instead.
josh
^ permalink raw reply
* Re: treeImage.initrd rule is very broken
From: David Gibson @ 2007-05-15 1:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1179154033.3420.13.camel@zod.rchland.ibm.com>
On Mon, May 14, 2007 at 09:47:13AM -0500, Josh Boyer wrote:
> Hi David,
>
> I tried compiling an Ebony kernel wrapped with a DTS and initrd this
> morning but it fails with the following error:
>
> WRAP arch/powerpc/boot/treeImage.initrd.ebony
> DTC: dts->dtb on file "/home/jwboyer/src/linux-2.6/arch/powerpc/boot/dts/ebony.dts"
> powerpc-440-linux-gnu-ld: arch/powerpc/boot/treeboot-initrd.ebony.o: No such file: No such file or directory
> powerpc-440-linux-gnu-nm: 'arch/powerpc/boot/treeImage.initrd.ebony': No such file
> powerpc-440-linux-gnu-objdump: 'arch/powerpc/boot/treeImage.initrd.ebony': No such file
> mv: cannot stat `arch/powerpc/boot/treeImage.initrd.ebony': No such file or directory
> stat: No such file or directory
> ln: accessing `arch/powerpc/boot/treeImage.initrd.ebony': No such file or directory
> make[1]: *** [arch/powerpc/boot/zImage.initrd] Error 1
> make: *** [zImage.initrd] Error 2
>
> At first glance, it should be looking for treeboot-ebony.o, not
> treeboot-initrd.ebony.o. On a whim, I symlinked treeboot-initrd.ebony.o
> to treeboot-ebony.o and the compile worked, however the wrapper wasn't
> called with the ramdisk.image.gz file:
>
> /bin/sh /home/jwboyer/src/linux-2.6/arch/powerpc/boot/wrapper -c -o arch/powerpc/boot/treeImage.initrd.ebony -p treeboot-initrd.ebony -C "powerpc-440-linux-gnu-" -s /home/jwboyer/src/linux-2.6/arch/powerpc/boot/dts/ebony.dts vmlinux
> DTC: dts->dtb on file "/home/jwboyer/src/linux-2.6/arch/powerpc/boot/dts/ebony.dts"
>
> So something is very broken with this rule. I poked at it for a while,
> but I apparently don't have the make-fu to figure out how to un-break
> it.
>
> Help?
Bother. I think the problem is that make is selecting the treeImage.%
rule (which does match), instead of the more specific
treeImage.initrd.%. I think the very simple patch below, which just
reverses the order of the rules, might fix it. Can you give it a
whirl?
Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/boot/Makefile 2007-05-15 11:39:18.000000000 +1000
+++ working-2.6/arch/powerpc/boot/Makefile 2007-05-15 11:39:27.000000000 +1000
@@ -204,12 +204,12 @@ dts = $(if $(shell echo $(CONFIG_DEVICE_
$(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,$(dts))
-$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts))
-
$(obj)/treeImage.initrd.%: vmlinux $(dts) $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dts))
+
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/3] Initial AMCC Bamboo support
From: David Gibson @ 2007-05-15 1:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1179193113.3420.95.camel@zod.rchland.ibm.com>
On Mon, May 14, 2007 at 08:38:33PM -0500, Josh Boyer wrote:
> On Tue, 2007-05-15 at 11:26 +1000, David Gibson wrote:
> > On Mon, May 14, 2007 at 09:56:48AM -0500, Josh Boyer wrote:
> > > Hi All,
> > >
> > > The following patches add the initial AMCC Bamboo eval board support.
> > >
> > > The support for peripheral devices at the moment is rather limited as
> > > the board is quite complicated in it's muxing of I/O lines. Until the
> > > bootwrapper can figure out how to setup the EBC peripherals based on the
> > > dip switch settings, the DTS will lack any EBC devices.
> >
> > Ick. Can you describe roughly the setup here? It might be that the
> > simplest approach is to include all options in the DTS, and delete
> > ones that aren't selected from the bootwrapper.
>
> There's 3 switches that directly control the EBC memory map, and a
> handful of other pin strap registers add to that. To further complicate
> things, there are two passes of the Bamboo board and the settings mean
> different things to the individual board revisions.
>
> By comparison, there's about 350 lines of code in U-Boot to do the setup
> of the EBC. It's not horrible, but I'm not sure it wants to be
> duplicated in the wrapper either.
>
> > I have a patch which might help here, which fills in the ebc's
> > 'ranges' property based on the contents of the EBC bridge registers.
> > I'm using it as part of the code necessary to get the right address
> > for the Ebony flash depending on DIP switch settings.
>
> Ooh... that's actually what I was thinking of doing. Though I was
> planning on poking individual nodes' regs properties instead.
You may need to do both. At least if you use the same format for the
ebc binding as I have on Ebony: in the reg properties of the
individual nodes I directly encode the ebc chip select value and
offset within the peripheral bank. The ebc node's 'ranges' gives the
mappings into the OPB space. So, in practice, the low 20 bits of
address are determined by the individual peripheral's reg properties,
and the upper 12 bits are determined by the ranges property at the EBC
node.
--
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: treeImage.initrd rule is very broken
From: Josh Boyer @ 2007-05-15 1:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070515014044.GE565@localhost.localdomain>
On Tue, 2007-05-15 at 11:40 +1000, David Gibson wrote:
>
> Bother. I think the problem is that make is selecting the treeImage.%
> rule (which does match), instead of the more specific
> treeImage.initrd.%. I think the very simple patch below, which just
> reverses the order of the rules, might fix it. Can you give it a
> whirl?
Of course it would have to be that simple. Yep, switched the order of
the rules and the zImage.initrd creation worked wonderfully.
Thanks.
josh
^ permalink raw reply
* Small fixes for the Ebony device tree
From: David Gibson @ 2007-05-15 2:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This patch corrects a number of minor errors in the Ebony device tree:
- Missing (given as 0) cache sizes are added to the CPU node
- device_type properties are removed from nodes which don't
have a reasonably well defined device_type binding. This does require
a very small code change to locate the busses to be probed for
of_platform devices by 'compatible' instead of 'device_type'.
- A node is added for the SRAM controller
- The unit address of the small-flash node is adjusted to
correctly reflect the reg property.
- device_type values for the MAL and ZMII are updated to
reflected more up-to-date versions of the binding.
- An incorrect offset in the partition map for the large-flash
node is corrected.
- Some redundant values, already commented out are removed
entirely.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Revised based on feedback from Segher et al.
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-05-15 11:16:28.000000000 +1000
@@ -33,8 +33,8 @@
timebase-frequency = <0>; // Filled in by zImage
i-cache-line-size = <32>;
d-cache-line-size = <32>;
- i-cache-size = <0>;
- d-cache-size = <0>;
+ i-cache-size = <8000>; /* 32 kB */
+ d-cache-size = <8000>; /* 32 kB */
dcr-controller;
dcr-access-method = "native";
};
@@ -46,7 +46,6 @@
};
UIC0: interrupt-controller0 {
- device_type = "ibm,uic";
compatible = "ibm,uic-440gp", "ibm,uic";
interrupt-controller;
cell-index = <0>;
@@ -58,7 +57,6 @@
};
UIC1: interrupt-controller1 {
- device_type = "ibm,uic";
compatible = "ibm,uic-440gp", "ibm,uic";
interrupt-controller;
cell-index = <1>;
@@ -71,36 +69,37 @@
};
CPC0: cpc {
- device_type = "ibm,cpc";
compatible = "ibm,cpc-440gp";
dcr-reg = <0b0 003 0e0 010>;
// FIXME: anything else?
};
plb {
- device_type = "ibm,plb";
compatible = "ibm,plb-440gp", "ibm,plb4";
#address-cells = <2>;
#size-cells = <1>;
ranges;
clock-frequency = <0>; // Filled in by zImage
- SDRAM0: sdram {
- device_type = "memory-controller";
+ SDRAM0: memory-controller {
compatible = "ibm,sdram-440gp", "ibm,sdram";
dcr-reg = <010 2>;
// FIXME: anything else?
};
+ SRAM0: sram {
+ compatible = "ibm,sram440gp";
+ dcr-reg = <020 8 00a 1>;
+ };
+
DMA0: dma {
// FIXME: ???
- device_type = "ibm,dma-4xx";
compatible = "ibm,dma-440gp", "ibm,dma-4xx";
dcr-reg = <100 027>;
};
MAL0: mcmal {
- device_type = "mcmal-dma";
+ device_type = "dma-controller";
compatible = "ibm,mcmal-440gp", "ibm,mcmal";
dcr-reg = <180 62>;
num-tx-chans = <4>;
@@ -119,7 +118,6 @@
};
POB0: opb {
- device_type = "ibm,opb";
compatible = "ibm,opb-440gp", "ibm,opb";
#address-cells = <1>;
#size-cells = <1>;
@@ -133,8 +131,7 @@
clock-frequency = <0>; // Filled in by zImage
EBC0: ebc {
- device_type = "ibm,ebc";
- compatible = "ibm,ebc-440gp";
+ compatible = "ibm,ebc-440gp", "ibm,ebc";
dcr-reg = <012 2>;
#address-cells = <2>;
#size-cells = <1>;
@@ -147,7 +144,7 @@
interrupts = <5 4>;
interrupt-parent = <&UIC1>;
- small-flash@0,0 {
+ small-flash@0,80000 {
device_type = "rom";
compatible = "direct-mapped";
probe-type = "JEDEC";
@@ -159,7 +156,6 @@
ds1743@1,0 {
/* NVRAM & RTC */
- device_type = "nvram";
compatible = "ds1743";
reg = <1 0 2000>;
};
@@ -170,7 +166,7 @@
probe-type = "JEDEC";
bank-width = <1>;
partitions = <0 380000
- 280000 80000>;
+ 380000 80000>;
partition-names = "fs", "firmware";
reg = <2 0 400000>;
};
@@ -226,13 +222,12 @@
GPIO0: gpio@40000700 {
/* FIXME */
- device_type = "gpio";
compatible = "ibm,gpio-440gp";
reg = <40000700 20>;
};
ZMII0: emac-zmii@40000780 {
- device_type = "emac-zmii";
+ device_type = "zmii-interface";
compatible = "ibm,zmii-440gp", "ibm,zmii";
reg = <40000780 c>;
};
@@ -299,9 +294,5 @@
chosen {
linux,stdout-path = "/plb/opb/serial@40000200";
-// linux,initrd-start = <0>; /* FIXME */
-// linux,initrd-end = <0>;
-// bootargs = "";
};
};
-
Index: working-2.6/arch/powerpc/platforms/44x/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/platforms/44x/ebony.c 2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/platforms/44x/ebony.c 2007-05-15 11:12:15.000000000 +1000
@@ -27,9 +27,9 @@
#include "44x.h"
static struct of_device_id ebony_of_bus[] = {
- { .type = "ibm,plb", },
- { .type = "ibm,opb", },
- { .type = "ibm,ebc", },
+ { .compatible = "ibm,plb", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
{},
};
--
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/3] Bamboo platform support
From: Stephen Rothwell @ 2007-05-15 2:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1179191003.3420.78.camel@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On Mon, 14 May 2007 20:03:23 -0500 Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> Wasn't by accident. I was following the lead of what was done for
> Ebony/440GP (which is actually broken at the moment but has a patch
> pending to comment it out as above).
>
> There is no ethernet period without the new EMAC rewrite and I'd like to
> leave the select there but commented out to serve as a placeholder if
> nothing else. Of course, if there are lots of objections it can be
> pulled.
Sorry, I misunderstood. That's fine.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Fix make rules rules for treeImage.initrd
From: David Gibson @ 2007-05-15 2:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
At present attempting to build treeImage.initrd.* boot images will
fail, because make will select the treeImage.% rule which also matches
instead of the correct and more specific treeImage.initrd.% rule.
This patch corrects the problem by listing the more specific rule
first.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/boot/Makefile
===================================================================
--- working-2.6.orig/arch/powerpc/boot/Makefile 2007-05-15 11:39:18.000000000 +1000
+++ working-2.6/arch/powerpc/boot/Makefile 2007-05-15 11:39:27.000000000 +1000
@@ -204,12 +204,12 @@ dts = $(if $(shell echo $(CONFIG_DEVICE_
$(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,$(dts))
-$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts))
-
$(obj)/treeImage.initrd.%: vmlinux $(dts) $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dts))
+
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
--
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/3] Bamboo platform support
From: Josh Boyer @ 2007-05-15 2:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070515120321.8385a60f.sfr@canb.auug.org.au>
On Tue, 2007-05-15 at 12:03 +1000, Stephen Rothwell wrote:
> On Mon, 14 May 2007 20:03:23 -0500 Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> >
> > Wasn't by accident. I was following the lead of what was done for
> > Ebony/440GP (which is actually broken at the moment but has a patch
> > pending to comment it out as above).
> >
> > There is no ethernet period without the new EMAC rewrite and I'd like to
> > leave the select there but commented out to serve as a placeholder if
> > nothing else. Of course, if there are lots of objections it can be
> > pulled.
>
> Sorry, I misunderstood. That's fine.
Thanks Stephen. I can see how it would be misleading without some sort
of explanation. I'll be sure to note it in future revisions.
josh
^ permalink raw reply
* Re: [patch 4/4] powerpc 2.6.21-rt1: reduce scheduling latency by changing tlb flush size
From: Tsutomu OWA @ 2007-05-15 4:12 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Thomas Gleixner, mingo, linux-kernel
In-Reply-To: <200705141640.02561.arnd@arndb.de>
At Mon, 14 May 2007 16:40:02 +0200, Arnd Bergmann wrote:
>=20
> On Monday 14 May 2007, Tsutomu OWA wrote:
> > --- linux-2.6.21-rt1/include/asm-powerpc/tlbflush.h=A0=A0=A0=A0=A02007-=
04-26 12:08:32.000000000 +0900
> > +++ rt/include/asm-powerpc/tlbflush.h=A0=A0=A02007-05-14 16:12:47.00000=
0000 +0900
> > @@ -25,7 +25,12 @@ struct mm_struct;
> > =A0#include <linux/percpu.h>
> > =A0#include <asm/page.h>
> > =A0
> > +#if defined(CONFIG_PPC_CELLEB) && defined(CONFIG_PREEMPT_RT)
> > +/* Since tlb flush takes long time on Celleb, reduce it to 1 when Cell=
eb && RT */
> > +#define PPC64_TLB_BATCH_NR 1
> With this code, you get silent side-effects of enabling PPC_CELLEB
> along with another platform.
Yeah, thank you for pointing it out.
I'll send revised patch later.
> Maybe instead you should change the hpte_need_flush() to always flush
> when running on the celleb platform and PREEMPT_RT is enabled.
Hmm... Is it in linux-2.6.21? grep'ing it did not help...=20
Is http://patchwork.ozlabs.org/linuxppc/patch?id=3D10361 is the first pla=
ce
where the hpte_need_flush() appears?
-- owa
^ permalink raw reply
* [PATCH 1/2] powerpc: Add spinlock to request_phb_iospace()
From: Benjamin Herrenschmidt @ 2007-05-15 4:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
request_phb_iospace() can be called from different CPUs at init
time (at least with my next patch) and thus needs a spinlock. As
for the next patch, this is a temporary workaround for 2.6.22
issues until my rewrite of IO mappings is ready (for 2.6.23)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
arch/powerpc/mm/pgtable_64.c | 4 ++++
1 file changed, 4 insertions(+)
Index: linux-cell/arch/powerpc/mm/pgtable_64.c
===================================================================
--- linux-cell.orig/arch/powerpc/mm/pgtable_64.c 2007-05-15 13:17:59.000000000 +1000
+++ linux-cell/arch/powerpc/mm/pgtable_64.c 2007-05-15 13:18:32.000000000 +1000
@@ -322,6 +322,8 @@ EXPORT_SYMBOL(__ioremap);
EXPORT_SYMBOL(iounmap);
EXPORT_SYMBOL(__iounmap);
+static DEFINE_SPINLOCK(phb_io_lock);
+
void __iomem * reserve_phb_iospace(unsigned long size)
{
void __iomem *virt_addr;
@@ -329,8 +331,10 @@ void __iomem * reserve_phb_iospace(unsig
if (phbs_io_bot >= IMALLOC_BASE)
panic("reserve_phb_iospace(): phb io space overflow\n");
+ spin_lock(&phb_io_lock);
virt_addr = (void __iomem *) phbs_io_bot;
phbs_io_bot += size;
+ spin_unlock(&phb_io_lock);
return virt_addr;
}
^ permalink raw reply
* [PATCH 2/2] powerpc: Fix IO space on PCI busses created from of_platform
From: Benjamin Herrenschmidt @ 2007-05-15 4:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
This changes the way of_platform_pci creates PCI host bridges such
that it uses request_phb_iospace() for mapping the IO ports, instead
of using the dynamic hotplug stuff. That guarantees the IO space
stays within the 2GB limit and thus doesn't break half of the legacy
drivers around.
Fixes a couple of warnings due to missing IO space while at it.
This patch is a temporary workaround for 2.6.22 before a more complete
rewrite of IO mappings is merged in 2.6.23
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
arch/powerpc/kernel/of_platform.c | 10 ++++++----
arch/powerpc/kernel/pci_64.c | 23 ++++++++++++++++++++++-
2 files changed, 28 insertions(+), 5 deletions(-)
Index: linux-cell/arch/powerpc/kernel/of_platform.c
===================================================================
--- linux-cell.orig/arch/powerpc/kernel/of_platform.c 2007-05-15 14:13:21.000000000 +1000
+++ linux-cell/arch/powerpc/kernel/of_platform.c 2007-05-15 14:13:48.000000000 +1000
@@ -427,11 +427,13 @@ static int __devinit of_pci_phb_probe(st
/* Process "ranges" property */
pci_process_bridge_OF_ranges(phb, dev->node, 0);
- /* Setup IO space.
- * This will not work properly for ISA IOs, something needs to be done
- * about it if we ever generalize that way of probing PCI brigdes
+ /* Setup IO space. We use the non-dynamic version of that code here,
+ * which doesn't quite support unplugging. Next kernel release will
+ * have a better fix for this.
+ * Note also that we don't do ISA, this will also be fixed with a
+ * more massive rework.
*/
- pci_setup_phb_io_dynamic(phb, 0);
+ pci_setup_phb_io(phb, 0);
/* Init pci_dn data structures */
pci_devs_phb_init_dynamic(phb);
Index: linux-cell/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-cell.orig/arch/powerpc/kernel/pci_64.c 2007-05-15 14:13:21.000000000 +1000
+++ linux-cell/arch/powerpc/kernel/pci_64.c 2007-05-15 14:13:48.000000000 +1000
@@ -41,6 +41,7 @@
unsigned long pci_probe_only = 1;
int pci_assign_all_buses = 0;
+static int pci_initial_scan;
static void fixup_resource(struct resource *res, struct pci_dev *dev);
static void do_bus_setup(struct pci_bus *bus);
@@ -604,6 +605,8 @@ static int __init pcibios_init(void)
/* map in PCI I/O space */
phbs_remap_io();
+ pci_initial_scan = 1;
+
printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
return 0;
@@ -1042,13 +1045,16 @@ void __devinit pci_process_bridge_OF_ran
}
}
-void __init pci_setup_phb_io(struct pci_controller *hose, int primary)
+void __devinit pci_setup_phb_io(struct pci_controller *hose, int primary)
{
unsigned long size = hose->pci_io_size;
unsigned long io_virt_offset;
struct resource *res;
struct device_node *isa_dn;
+ if (size == 0)
+ return;
+
hose->io_base_virt = reserve_phb_iospace(size);
DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
hose->global_number, hose->io_base_phys,
@@ -1069,6 +1075,15 @@ void __init pci_setup_phb_io(struct pci_
res = &hose->io_resource;
res->start += io_virt_offset;
res->end += io_virt_offset;
+
+ /* If this is called after the initial PCI scan, then we need to
+ * proceed to IO mappings now
+ */
+ if (pci_initial_scan)
+ __ioremap_explicit(hose->io_base_phys,
+ (unsigned long)hose->io_base_virt,
+ hose->pci_io_size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED);
}
void __devinit pci_setup_phb_io_dynamic(struct pci_controller *hose,
@@ -1078,6 +1093,9 @@ void __devinit pci_setup_phb_io_dynamic(
unsigned long io_virt_offset;
struct resource *res;
+ if (size == 0)
+ return;
+
hose->io_base_virt = __ioremap(hose->io_base_phys, size,
_PAGE_NO_CACHE | _PAGE_GUARDED);
DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
@@ -1106,6 +1124,9 @@ static int get_bus_io_range(struct pci_b
/* Root Bus */
res = &hose->io_resource;
+ if (res->end == 0 && res->start == 0)
+ return 1;
+
*start_virt = pci_io_base + res->start;
*start_phys = *start_virt + hose->io_base_phys
- (unsigned long) hose->io_base_virt;
^ permalink raw reply
* [PATCH] powerpc: Fix warning in pci_64.c
From: Benjamin Herrenschmidt @ 2007-05-15 4:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Fix a warning due to unused result from device_create_file
in arch/powerpc/kernel/pci_64.c
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
arch/powerpc/kernel/pci_64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-cell/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-cell.orig/arch/powerpc/kernel/pci_64.c 2007-05-15 14:14:15.000000000 +1000
+++ linux-cell/arch/powerpc/kernel/pci_64.c 2007-05-15 14:14:54.000000000 +1000
@@ -878,7 +878,8 @@ static DEVICE_ATTR(devspec, S_IRUGO, pci
void pcibios_add_platform_entries(struct pci_dev *pdev)
{
- device_create_file(&pdev->dev, &dev_attr_devspec);
+ int rc = device_create_file(&pdev->dev, &dev_attr_devspec);
+ WARN_ON(rc != 0);
}
#define ISA_SPACE_MASK 0x1
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Fix IO space on PCI busses created from of_platform
From: Olof Johansson @ 2007-05-15 4:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070515041656.41CE7DDECA@ozlabs.org>
On Tue, May 15, 2007 at 02:16:26PM +1000, Benjamin Herrenschmidt wrote:
> Index: linux-cell/arch/powerpc/kernel/pci_64.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/pci_64.c 2007-05-15 14:13:21.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/pci_64.c 2007-05-15 14:13:48.000000000 +1000
> @@ -41,6 +41,7 @@
>
> unsigned long pci_probe_only = 1;
> int pci_assign_all_buses = 0;
> +static int pci_initial_scan;
>
> static void fixup_resource(struct resource *res, struct pci_dev *dev);
> static void do_bus_setup(struct pci_bus *bus);
> @@ -604,6 +605,8 @@ static int __init pcibios_init(void)
> /* map in PCI I/O space */
> phbs_remap_io();
>
> + pci_initial_scan = 1;
> +
> printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
>
> return 0;
> @@ -1042,13 +1045,16 @@ void __devinit pci_process_bridge_OF_ran
> }
> }
>
> -void __init pci_setup_phb_io(struct pci_controller *hose, int primary)
> +void __devinit pci_setup_phb_io(struct pci_controller *hose, int primary)
> {
> unsigned long size = hose->pci_io_size;
> unsigned long io_virt_offset;
> struct resource *res;
> struct device_node *isa_dn;
>
> + if (size == 0)
> + return;
> +
> hose->io_base_virt = reserve_phb_iospace(size);
> DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
> hose->global_number, hose->io_base_phys,
> @@ -1069,6 +1075,15 @@ void __init pci_setup_phb_io(struct pci_
> res = &hose->io_resource;
> res->start += io_virt_offset;
> res->end += io_virt_offset;
> +
> + /* If this is called after the initial PCI scan, then we need to
> + * proceed to IO mappings now
> + */
> + if (pci_initial_scan)
> + __ioremap_explicit(hose->io_base_phys,
> + (unsigned long)hose->io_base_virt,
> + hose->pci_io_size,
> + _PAGE_NO_CACHE | _PAGE_GUARDED);
The code and comment seems contradictory to me. Maybe name it pci_initial_scan_done? The
way I read it otherwise is:
if (pci_initial_scan_going_on_now)
:-)
Otherwise it looks OK.
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add spinlock to request_phb_iospace()
From: Stephen Rothwell @ 2007-05-15 4:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Bergmann, Arnd
In-Reply-To: <20070515041655.BDD98DDEC6@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Tue, 15 May 2007 14:16:26 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> request_phb_iospace() can be called from different CPUs at init
> time (at least with my next patch) and thus needs a spinlock. As
> for the next patch, this is a temporary workaround for 2.6.22
> issues until my rewrite of IO mappings is ready (for 2.6.23)
What problem is this solving?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v2] pcmcia: ppc64 needs 32-bit ioaddr_t
From: Olof Johansson @ 2007-05-15 4:33 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <20070512143105.GA12890@lixom.net>
ppc64 really needs ioaddr_t to be 32-bit, since I/O beyond the
first PCI bus might be mapped at a higher range.
While the type is exported to userspace, there hasn't been any platforms
with PCMCIA on 64-bit powerpc until now, so changing it won't regress
any existing users. Besides, those interfaces are overdue for removal
already.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6.21/include/pcmcia/cs_types.h
===================================================================
--- 2.6.21.orig/include/pcmcia/cs_types.h
+++ 2.6.21/include/pcmcia/cs_types.h
@@ -21,7 +21,7 @@
#include <sys/types.h>
#endif
-#if defined(__arm__) || defined(__mips__)
+#if defined(__arm__) || defined(__mips__) || defined(__powerpc64__)
/* This (ioaddr_t) is exposed to userspace & hence cannot be changed. */
typedef u_int ioaddr_t;
#else
^ permalink raw reply
* Re: [PATCH] powerpc: Fix warning in pci_64.c
From: Stephen Rothwell @ 2007-05-15 4:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070515041705.CCC00DDFC9@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
On Tue, 15 May 2007 14:16:35 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> void pcibios_add_platform_entries(struct pci_dev *pdev)
> {
> - device_create_file(&pdev->dev, &dev_attr_devspec);
> + int rc = device_create_file(&pdev->dev, &dev_attr_devspec);
> + WARN_ON(rc != 0);
If we really don't care if the file is not created, then it is probably
worth a comment as to why ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] pasemi: Electra CF driver
From: Olof Johansson @ 2007-05-15 4:45 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Russell King, linux-pcmcia, linux-kernel
Driver for the CompactFlash slot on the PA Semi Electra eval board. It's
a simple device sitting on localbus, with interrupts and detect/voltage
control over GPIO.
The driver is implemented as an of_platform driver, and adds localbus
as a bus being probed by the of_platform framework.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Updated based on review comments from Russell, as well as retooled for
the I/O space changes (as discussed with Arnd/BenH).
This patch depends on the PCMCIA pcmcia_bus_type export to compile:
http://lists.infradead.org/pipermail/linux-pcmcia/2007-May/004628.html
and on the ioaddr_t change to work at runtime:
http://patchwork.ozlabs.org/linuxppc/patch?id=11147
Also, had to switch to bool config option since the iospace functions
aren't exported (starting with .23 we should be able to switch back to
tristate). Keep all the module init/remove calls for now.
Index: powerpc/drivers/pcmcia/Kconfig
===================================================================
--- powerpc.orig/drivers/pcmcia/Kconfig
+++ powerpc/drivers/pcmcia/Kconfig
@@ -270,6 +270,13 @@ config AT91_CF
Say Y here to support the CompactFlash controller on AT91 chips.
Or choose M to compile the driver as a module named "at91_cf".
+config ELECTRA_CF
+ bool "Electra CompactFlash Controller"
+ depends on PCMCIA=y && PPC_PASEMI
+ help
+ Say Y here to support the CompactFlash controller on the
+ PA Semi Electra eval board.
+
config PCCARD_NONSTATIC
tristate
Index: powerpc/drivers/pcmcia/Makefile
===================================================================
--- powerpc.orig/drivers/pcmcia/Makefile
+++ powerpc/drivers/pcmcia/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_PCMCIA_VRC4171) += vrc417
obj-$(CONFIG_PCMCIA_VRC4173) += vrc4173_cardu.o
obj-$(CONFIG_OMAP_CF) += omap_cf.o
obj-$(CONFIG_AT91_CF) += at91_cf.o
+obj-$(CONFIG_ELECTRA_CF) += electra_cf.o
sa11xx_core-y += soc_common.o sa11xx_base.o
pxa2xx_core-y += soc_common.o pxa2xx_base.o
Index: powerpc/drivers/pcmcia/electra_cf.c
===================================================================
--- /dev/null
+++ powerpc/drivers/pcmcia/electra_cf.c
@@ -0,0 +1,382 @@
+/*
+ * Copyright (C) 2007 PA Semi, Inc
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on drivers/pcmcia/omap_cf.c
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/platform_device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+
+#include <pcmcia/ss.h>
+#include <asm/of_platform.h>
+
+static const char driver_name[] = "electra-cf";
+
+struct electra_cf_socket {
+ struct pcmcia_socket socket;
+
+ struct timer_list timer;
+ unsigned present:1;
+ unsigned active:1;
+
+ struct of_device *ofdev;
+ unsigned long mem_phys;
+ void __iomem * mem_base;
+ unsigned long mem_size;
+ void __iomem * io_virt;
+ unsigned int io_base;
+ unsigned int io_size;
+ u_int irq;
+ struct resource iomem;
+ void __iomem * gpio_base;
+ int gpio_detect;
+ int gpio_vsense;
+ int gpio_3v;
+ int gpio_5v;
+};
+
+#define POLL_INTERVAL (2 * HZ)
+
+
+static int electra_cf_present(struct electra_cf_socket *cf)
+{
+ unsigned int gpio;
+
+ gpio = in_le32(cf->gpio_base+0x40);
+ return !(gpio & (1 << cf->gpio_detect));
+}
+
+static int electra_cf_ss_init(struct pcmcia_socket *s)
+{
+ return 0;
+}
+
+/* the timer is primarily to kick this socket's pccardd */
+static void electra_cf_timer(unsigned long _cf)
+{
+ struct electra_cf_socket *cf = (void *) _cf;
+ int present = electra_cf_present(cf);
+
+ if (present != cf->present) {
+ cf->present = present;
+ pcmcia_parse_events(&cf->socket, SS_DETECT);
+ }
+
+ if (cf->active)
+ mod_timer(&cf->timer, jiffies + POLL_INTERVAL);
+}
+
+static irqreturn_t electra_cf_irq(int irq, void *_cf)
+{
+ electra_cf_timer((unsigned long)_cf);
+ return IRQ_HANDLED;
+}
+
+static int electra_cf_get_status(struct pcmcia_socket *s, u_int *sp)
+{
+ struct electra_cf_socket *cf;
+
+ if (!sp)
+ return -EINVAL;
+
+ cf = container_of(s, struct electra_cf_socket, socket);
+
+ /* NOTE CF is always 3VCARD */
+ if (electra_cf_present(cf)) {
+ struct electra_cf_socket *cf;
+
+ *sp = SS_READY | SS_DETECT | SS_POWERON | SS_3VCARD;
+ cf = container_of(s, struct electra_cf_socket, socket);
+ s->pci_irq = cf->irq;
+ } else
+ *sp = 0;
+ return 0;
+}
+
+static int electra_cf_set_socket(struct pcmcia_socket *sock,
+ struct socket_state_t *s)
+{
+ unsigned int gpio;
+ unsigned int vcc;
+ struct electra_cf_socket *cf;
+
+ cf = container_of(sock, struct electra_cf_socket, socket);
+
+ /* "reset" means no power in our case */
+ vcc = (s->flags & SS_RESET) ? 0 : s->Vcc;
+
+ switch (vcc) {
+ case 0:
+ gpio = 0;
+ break;
+ case 33:
+ gpio = (1 << cf->gpio_3v);
+ break;
+ default:
+ /* CF is 3.3V only */
+ return -EINVAL;
+ }
+
+ gpio |= 1 << (cf->gpio_3v + 16); /* enwr */
+ gpio |= 1 << (cf->gpio_5v + 16); /* enwr */
+ out_le32(cf->gpio_base+0x90, gpio);
+
+ pr_debug("%s: Vcc %d, io_irq %d, flags %04x csc %04x\n",
+ driver_name, s->Vcc, s->io_irq, s->flags, s->csc_mask);
+
+ return 0;
+}
+
+static int electra_cf_set_io_map(struct pcmcia_socket *s,
+ struct pccard_io_map *io)
+{
+ return 0;
+}
+
+static int electra_cf_set_mem_map(struct pcmcia_socket *s,
+ struct pccard_mem_map *map)
+{
+ struct electra_cf_socket *cf;
+
+ if (map->card_start)
+ return -EINVAL;
+ cf = container_of(s, struct electra_cf_socket, socket);
+ map->static_start = cf->mem_phys;
+ map->flags &= MAP_ACTIVE|MAP_ATTRIB;
+ if (!(map->flags & MAP_ATTRIB))
+ map->static_start += 0x800;
+ return 0;
+}
+
+static struct pccard_operations electra_cf_ops = {
+ .init = electra_cf_ss_init,
+ .get_status = electra_cf_get_status,
+ .set_socket = electra_cf_set_socket,
+ .set_io_map = electra_cf_set_io_map,
+ .set_mem_map = electra_cf_set_mem_map,
+};
+
+static int __devinit electra_cf_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device *device = &ofdev->dev;
+ struct device_node *np = ofdev->node;
+ struct electra_cf_socket *cf;
+ struct resource mem, io;
+ int status;
+ const unsigned int *prop;
+ int err;
+
+ err = of_address_to_resource(np, 0, &mem);
+ if (err)
+ return -EINVAL;
+
+ err = of_address_to_resource(np, 1, &io);
+ if (err)
+ return -EINVAL;
+
+ cf = kzalloc(sizeof *cf, GFP_KERNEL);
+ if (!cf)
+ return -ENOMEM;
+
+ init_timer(&cf->timer);
+ cf->timer.function = electra_cf_timer;
+ cf->timer.data = (unsigned long) cf;
+
+ cf->ofdev = ofdev;
+ cf->mem_phys = mem.start;
+ cf->mem_base = ioremap(mem.start, mem.end - mem.start);
+ cf->io_size = PAGE_ALIGN(io.end - io.start);
+
+ cf->io_virt = reserve_phb_iospace(cf->io_size);
+
+ cf->gpio_base = ioremap(0xfc103000, 0x1000);
+ dev_set_drvdata(device, cf);
+
+ if (!cf->mem_base || !cf->io_virt || !cf->gpio_base) {
+ dev_err(device, "can't ioremap ranges\n");
+ status = -ENOMEM;
+ goto fail1;
+ }
+
+ __ioremap_explicit(io.start, (unsigned long)cf->io_virt, cf->io_size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED);
+
+ cf->io_base = (unsigned long)cf->io_virt - VMALLOC_END;
+
+ cf->iomem.start = (unsigned long)cf->mem_base;
+ cf->iomem.end = (unsigned long)cf->mem_base + (mem.end - mem.start);
+ cf->iomem.flags = IORESOURCE_MEM;
+
+ cf->irq = irq_of_parse_and_map(np, 0);
+
+ status = request_irq(cf->irq, electra_cf_irq, IRQF_SHARED,
+ driver_name, cf);
+ if (status < 0) {
+ dev_err(device, "request_irq failed\n");
+ goto fail1;
+ }
+
+ cf->socket.pci_irq = cf->irq;
+
+ prop = get_property(np, "card-detect-gpio", NULL);
+ cf->gpio_detect = *prop;
+ prop = get_property(np, "card-vsense-gpio", NULL);
+ cf->gpio_vsense = *prop;
+ prop = get_property(np, "card-3v-gpio", NULL);
+ cf->gpio_3v = *prop;
+ prop = get_property(np, "card-5v-gpio", NULL);
+ cf->gpio_5v = *prop;
+
+ cf->socket.io_offset = cf->io_base;
+
+ /* reserve chip-select regions */
+ if (!request_mem_region(mem.start, mem.end + 1 - mem.start,
+ driver_name)) {
+ status = -ENXIO;
+ dev_err(device, "Can't claim memory region\n");
+ goto fail1;
+ }
+
+ if (!request_region(cf->io_base, cf->io_size, driver_name)) {
+ status = -ENXIO;
+ dev_err(device, "Can't claim I/O region\n");
+ goto fail2;
+ }
+
+ cf->socket.owner = THIS_MODULE;
+ cf->socket.dev.parent = &ofdev->dev;
+ cf->socket.ops = &electra_cf_ops;
+ cf->socket.resource_ops = &pccard_static_ops;
+ cf->socket.features = SS_CAP_PCCARD | SS_CAP_STATIC_MAP |
+ SS_CAP_MEM_ALIGN;
+ cf->socket.map_size = 0x800;
+
+ status = pcmcia_register_socket(&cf->socket);
+ if (status < 0) {
+ dev_err(device, "pcmcia_register_socket failed\n");
+ goto fail3;
+ }
+
+ dev_info(device, "at mem 0x%lx io 0x%lx irq %d\n",
+ mem.start, io.start, cf->irq);
+
+ cf->active = 1;
+ electra_cf_timer((unsigned long)cf);
+ return 0;
+
+fail3:
+ release_mem_region(io.start, io.end + 1 - io.start);
+fail2:
+ release_mem_region(mem.start, mem.end + 1 - mem.start);
+fail1:
+ /* XXX No way to undo the io reservation at this time */
+ if (cf->mem_base)
+ iounmap(cf->mem_base);
+ if (cf->gpio_base)
+ iounmap(cf->gpio_base);
+ device_init_wakeup(&ofdev->dev, 0);
+ kfree(cf);
+ return status;
+
+}
+
+static int __devexit electra_cf_remove(struct of_device *ofdev)
+{
+ struct device *device = &ofdev->dev;
+ struct electra_cf_socket *cf;
+
+ cf = dev_get_drvdata(device);
+
+ cf->active = 0;
+ pcmcia_unregister_socket(&cf->socket);
+ free_irq(cf->irq, cf);
+ del_timer_sync(&cf->timer);
+
+ iounmap(cf->mem_base);
+ iounmap(cf->gpio_base);
+ release_mem_region(cf->mem_phys, cf->mem_size);
+ release_region(cf->io_base, cf->io_size);
+
+ kfree(cf);
+
+ return 0;
+}
+
+static int bus_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct device *dev = data;
+
+ printk("bus notify called\n");
+
+ /* We are only intereted in device addition */
+ if (action != BUS_NOTIFY_ADD_DEVICE)
+ return 0;
+
+ /* We use the direct ops for localbus */
+ dev->archdata.dma_ops = &dma_direct_ops;
+
+ return 0;
+}
+
+static struct notifier_block bus_notifier = {
+ .notifier_call = bus_notify,
+};
+
+static struct of_device_id electra_cf_match[] =
+{
+ {
+ .compatible = "electra-cf",
+ },
+ {},
+};
+
+static struct of_platform_driver electra_cf_driver =
+{
+ .name = (char *)driver_name,
+ .match_table = electra_cf_match,
+ .probe = electra_cf_probe,
+ .remove = electra_cf_remove,
+};
+
+static int __init electra_cf_init(void)
+{
+ bus_register_notifier(&pcmcia_bus_type, &bus_notifier);
+ return of_register_platform_driver(&electra_cf_driver);
+}
+module_init(electra_cf_init);
+
+static void __exit electra_cf_exit(void)
+{
+ bus_unregister_notifier(&pcmcia_bus_type, &bus_notifier);
+ of_unregister_platform_driver(&electra_cf_driver);
+}
+module_exit(electra_cf_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR ("Olof Johansson <olof@lixom.net>");
+MODULE_DESCRIPTION("PA Semi Electra CF driver");
+
Index: powerpc/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- powerpc.orig/arch/powerpc/platforms/pasemi/setup.c
+++ powerpc/arch/powerpc/platforms/pasemi/setup.c
@@ -205,6 +205,7 @@ static void __init pas_init_early(void)
}
static struct of_device_id pasemi_bus_ids[] = {
+ { .type = "localbus", },
{ .type = "sdc", },
{},
};
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Rewrite IO allocation & mapping on powerpc64
From: Segher Boessenkool @ 2007-05-15 4:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <17992.64515.797925.855510@cargo.ozlabs.ibm.com>
>> This is wrong -- there are systems with ISA that
>> also have PCI devices that require 16-bit legacy
>> I/O windows (e.g., systems with the AMD8111 chip,
>> like Maple).
>
> If they are PCI devices and their drivers use a pci_dev's resources
> to get to the device's I/O resources, then they are fine.
>
> The only reason for reserving the low 64k is to cater for drivers that
> use a hard-coded port number, e.g. video drivers using the VGA port
> numbers. We have been gradually getting rid of the hard coded port
> numbers in drivers but I don't think they're all gone yet.
Yes, I misunderstood (that teaches me for reading the
patch description only, not the patch itself :-) ).
Ben, can we have a config option to _not_ create a
mapping for the legacy hardcoded stuff, even if there
is an "isa" device node? Some platforms do not need
it or want it, and it can help find the remaining
drivers that do this x86 nastiness.
Segher
^ 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