* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Kumar Gala @ 2007-06-01 5:08 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B96294322F7D458F9648B60E15112C30777C@zch01exm26.fsl.freescale.net>
On May 31, 2007, at 9:01 PM, Zhang Wei-r63237 wrote:
> Hi, Kumar,
>
>>
>> Can this be fixed by just setting hose->bus_offset in add_bridge?
>>
>> Doing this in exclude is very bad.
>
> That's my original doing. If there a PCI bridge card be pluged into
> PCI
> slot of hose0, I can not ensue the bus_offset number of hose1.
Ok, but can't we use hose0's last_busno and use that set hose1-
>first_busno & hose1->bus_offset?
- k
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Paul Mackerras @ 2007-06-01 6:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <A7C2B8A9-AE89-4E00-9771-F3C21A610121@kernel.crashing.org>
Kumar Gala writes:
> > That's my original doing. If there a PCI bridge card be pluged into
> > PCI
> > slot of hose0, I can not ensue the bus_offset number of hose1.
>
> Ok, but can't we use hose0's last_busno and use that set hose1-
> >first_busno & hose1->bus_offset?
Why do the bus numbers for hose0 and hose1 have to have any relation
to each other at all? Aren't they separate PCI domains?
Paul.
^ permalink raw reply
* RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Zhang Wei-r63237 @ 2007-06-01 6:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus
In-Reply-To: <A7C2B8A9-AE89-4E00-9771-F3C21A610121@kernel.crashing.org>
Hi, Kumar,=20
>=20
> On May 31, 2007, at 9:01 PM, Zhang Wei-r63237 wrote:
>=20
> > Hi, Kumar,
> >
> >>
> >> Can this be fixed by just setting hose->bus_offset in add_bridge?
> >>
> >> Doing this in exclude is very bad.
> >
> > That's my original doing. If there a PCI bridge card be=20
> pluged into =20
> > PCI
> > slot of hose0, I can not ensue the bus_offset number of hose1.
>=20
> Ok, but can't we use hose0's last_busno and use that set hose1-=20
> >first_busno & hose1->bus_offset?
When in add_bridge(), the pci bus scan is not start, so we do not know
hose0's last_busno.
Thanks!
Wei.
^ permalink raw reply
* Re: Where is initial console initialized ?
From: Domen Puncer @ 2007-06-01 6:35 UTC (permalink / raw)
To: Daniel Schnell; +Cc: linuxppc-embedded
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB01F550A7@is-hdq-exchange.marel.net>
On 31/05/07 13:42 -0000, Daniel Schnell wrote:
> Hi,
>
> I am trying to bring up 2.6.20.3 on a MPC5200B based custom board. This
> Kernel is based on the Phytec phyCore MPC5200B Mini BSP kernel and
> adapted to my board.
> So far I have troubles to get console output working when booting Linux.
> Uboot console output is fine. Linux begins to run (I can set breakpoints
> with the BDI2000 in the early initialization code) so I probably have a
> misconfiguration of the console output inside the fdt.
>
> The major difference between the Phytec phyCore 5200B mini fdt and mine
> is that we use PSC1 instead of PSC3/6 for serial. Accordingly I changed
> the fdt (or dts) values.
>
> To get some more insights, I would like to know, in which Linux function
> the console output is initialised ?
>
>
...
> If I dump the flat device tree inside uboot, I get the following
> entries:
...
the dump with:
reg = <8>;
in most of nodes, which looks just wrong.
Domen
^ permalink raw reply
* RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Zhang Wei-r63237 @ 2007-06-01 6:45 UTC (permalink / raw)
To: Paul Mackerras, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <18015.48278.312517.781244@cargo.ozlabs.ibm.com>
Hi, Paul,=20
> -----Original Message-----
> From: Paul Mackerras [mailto:paulus@samba.org]=20
>=20
> Kumar Gala writes:
>=20
> > > That's my original doing. If there a PCI bridge card be=20
> pluged into =20
> > > PCI
> > > slot of hose0, I can not ensue the bus_offset number of hose1.
> >=20
> > Ok, but can't we use hose0's last_busno and use that set hose1-=20
> > >first_busno & hose1->bus_offset?
>=20
> Why do the bus numbers for hose0 and hose1 have to have any relation
> to each other at all? Aren't they separate PCI domains?
There are lots of lagacy PCI codes in kernel, such as
pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
pci_bus_to_hose() can not return the correct hose. And there will effect
/proc/pci and lspci tools.
Thanks!
Wei.
^ permalink raw reply
* [PATCH 1/1] Use NO_IRQ not IRQ_NONE
From: Michael Ellerman @ 2007-06-01 7:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
There is a thinko in the irq code, it uses IRQ_NONE to indicate no irq,
whereas it should be using NO_IRQ. IRQ_NONE is returned from irq handlers
to say "not handled".
As it happens they currently have the same value (0), so this is just for
future proof-ness.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/irq.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 068377a..42c8ed6 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -489,7 +489,7 @@ struct irq_host *irq_alloc_host(unsigned int revmap_type,
case IRQ_HOST_MAP_LINEAR:
rmap = (unsigned int *)(host + 1);
for (i = 0; i < revmap_arg; i++)
- rmap[i] = IRQ_NONE;
+ rmap[i] = NO_IRQ;
host->revmap_data.linear.size = revmap_arg;
smp_wmb();
host->revmap_data.linear.revmap = rmap;
@@ -614,7 +614,7 @@ unsigned int irq_create_mapping(struct irq_host *host,
* host->ops->map() to update the flags
*/
virq = irq_find_mapping(host, hwirq);
- if (virq != IRQ_NONE) {
+ if (virq != NO_IRQ) {
if (host->ops->remap)
host->ops->remap(host, virq, hwirq);
pr_debug("irq: -> existing mapping on virq %d\n", virq);
@@ -741,7 +741,7 @@ void irq_dispose_mapping(unsigned int virq)
switch(host->revmap_type) {
case IRQ_HOST_MAP_LINEAR:
if (hwirq < host->revmap_data.linear.size)
- host->revmap_data.linear.revmap[hwirq] = IRQ_NONE;
+ host->revmap_data.linear.revmap[hwirq] = NO_IRQ;
break;
case IRQ_HOST_MAP_TREE:
/* Check if radix tree allocated yet */
--
1.5.1.3.g7a33b
^ permalink raw reply related
* RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Benjamin Herrenschmidt @ 2007-06-01 7:44 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46B96294322F7D458F9648B60E15112C30780F@zch01exm26.fsl.freescale.net>
On Fri, 2007-06-01 at 14:45 +0800, Zhang Wei-r63237 wrote:
> There are lots of lagacy PCI codes in kernel, such as
> pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
> pci_bus_to_hose() can not return the correct hose. And there will
> effect
> /proc/pci and lspci tools.
More specifically...
Overlapping bus numbers on separate domains work... on 64 bits :-) The
32 bits PCI code assumes non-overlapping numbers. The main reason for
that historically was that back then, domains didn't work well.
The second reasons why I didn't actually fix it is that turning on full
domain support had (and probably still has) the nasty habit of breaking
the X server :-( X is full of most horrible hacks for PCI and it will be
terminally broken until they finally merge the pci-rework branch that
Ian Romanick's been working on for some time now.
One of these days, one of us will finally tackle merging 32 and 64 bits
PCI code (and fix both of them while at it to better use the generic
code, which involves fixing issues in the said generic code too :-) at
which point I'll enable full domain support for 32 bits as well, with an
option to degrade it to bus number remapping.
Ben.
^ permalink raw reply
* Re: [PATCH 1/1] Use NO_IRQ not IRQ_NONE
From: Benjamin Herrenschmidt @ 2007-06-01 7:47 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <526423a25b0e40c03678f4bb1d56e4b5719ab74d.1180682602.git.michael@ellerman.id.au>
On Fri, 2007-06-01 at 17:23 +1000, Michael Ellerman wrote:
> There is a thinko in the irq code, it uses IRQ_NONE to indicate no irq,
> whereas it should be using NO_IRQ. IRQ_NONE is returned from irq handlers
> to say "not handled".
>
> As it happens they currently have the same value (0), so this is just for
> future proof-ness.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
My fault actually :-) Mostly a typo, it's right elsewhere in the code
except in those 3 occurences. Brown paper bag time for me.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Zhang Wei-r63237 @ 2007-06-01 7:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1180683854.19517.419.camel@localhost.localdomain>
Hi, Ben,
> One of these days, one of us will finally tackle merging 32=20
> and 64 bits
> PCI code (and fix both of them while at it to better use the generic
> code, which involves fixing issues in the said generic code too :-) at
> which point I'll enable full domain support for 32 bits as=20
> well, with an
> option to degrade it to bus number remapping.
>=20
Do you want to implement vbus such as virq? :)
Cheers!
Wei.
^ permalink raw reply
* RE: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Benjamin Herrenschmidt @ 2007-06-01 8:00 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46B96294322F7D458F9648B60E15112C307837@zch01exm26.fsl.freescale.net>
On Fri, 2007-06-01 at 15:53 +0800, Zhang Wei-r63237 wrote:
>
> Do you want to implement vbus such as virq? :)
Not really :-)
We do remap on powermac today, or rather, re-assign, though, to ensure
numbers don't overlap (powermacs have up to 3 domains that the firmware
set to overlapping bus numbers)
Ben
^ permalink raw reply
* [patch] powerpc: Remove redundant pci_read_irq_line() function for 85xx platform
From: Zang Roy-r61911 @ 2007-06-01 8:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
From: Roy Zang <tie-fei.zang@freescale.com>
Remove redundant pci_read_irq_line() function for
85xx CDS board.
This function has been realized in common pci_32.c.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 76 +++++++++++++----------------
1 files changed, 34 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 1490eb3..27b81ff 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -78,52 +78,44 @@ static int mpc85xx_exclude_device(u_char bus, u_char devfn)
return PCIBIOS_SUCCESSFUL;
}
-static void __init mpc85xx_cds_pcibios_fixup(void)
+static void __init mpc85xx_cds_pci_irq_fixup(struct pci_dev *dev)
{
- struct pci_dev *dev;
- u_char c;
-
- if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_82C586_1, NULL))) {
+ u_char c;
+ if (dev->vendor == PCI_VENDOR_ID_VIA) {
+ switch (dev->device) {
+ case PCI_DEVICE_ID_VIA_82C586_1:
+ /*
+ * U-Boot does not set the enable bits
+ * for the IDE device. Force them on here.
+ */
+ pci_read_config_byte(dev, 0x40, &c);
+ c |= 0x03; /* IDE: Chip Enable Bits */
+ pci_write_config_byte(dev, 0x40, c);
+
+ /*
+ * Since only primary interface works, force the
+ * IDE function to standard primary IDE interrupt
+ * w/ 8259 offset
+ */
+ dev->irq = 14;
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
+ break;
/*
- * U-Boot does not set the enable bits
- * for the IDE device. Force them on here.
+ * Force legacy USB interrupt routing
*/
- pci_read_config_byte(dev, 0x40, &c);
- c |= 0x03; /* IDE: Chip Enable Bits */
- pci_write_config_byte(dev, 0x40, c);
-
- /*
- * Since only primary interface works, force the
- * IDE function to standard primary IDE interrupt
- * w/ 8259 offset
+ case PCI_DEVICE_ID_VIA_82C586_2:
+ /* There are two USB controllers.
+ * Identify them by functon number
*/
- dev->irq = 14;
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
- pci_dev_put(dev);
- }
-
- /*
- * Force legacy USB interrupt routing
- */
- if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_82C586_2, NULL))) {
- dev->irq = 10;
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 10);
- pci_dev_put(dev);
- }
-
- if ((dev = pci_get_device(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_82C586_2, dev))) {
- dev->irq = 11;
- pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 11);
- pci_dev_put(dev);
+ if (PCI_FUNC(dev->devfn))
+ dev->irq = 11;
+ else
+ dev->irq = 10;
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
+ default:
+ break;
+ }
}
-
- /* Now map all the PCI irqs */
- dev = NULL;
- for_each_pci_dev(dev)
- pci_read_irq_line(dev);
}
#ifdef CONFIG_PPC_I8259
@@ -259,7 +251,7 @@ static void __init mpc85xx_cds_setup_arch(void)
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
add_bridge(np);
- ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
+ ppc_md.pci_irq_fixup = mpc85xx_cds_pci_irq_fixup;
ppc_md.pci_exclude_device = mpc85xx_exclude_device;
#endif
}
--
1.5.1
^ permalink raw reply related
* Kernel and rootfs in ONE image?
From: Frank Prepelica @ 2007-06-01 11:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Hi all,
in normal case you have got a kernel image and a rootfs image. Place
that images into flash memory, set correct bootargs and it should work.
But, is it possible to generate one image which includes the linux
kernel
and a rootfs, place that single image into flash memory and it should
also work?
Thanks in advance!
Beste regrads
Frank
[-- Attachment #2: Type: text/html, Size: 3235 bytes --]
^ permalink raw reply
* RE: Where is initial console initialized ?
From: Daniel Schnell @ 2007-06-01 12:14 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070601063507.GA23294@moe.telargo.com>
Hmm, this is a bug in the U-Boot print-data() function. Normally you =
should see a 8 bytes field for "reg =3D ", so I changed that function =
to dump the hexadecimal contents when data length is =3D=3D 8 and these =
reg =3D values look much better now:
Still no go to boot Linux.
Booting using flat device tree at 0x400000
{
model =3D "v38c";
compatible =3D [76 33 38 63 00 6d 70 63 35 32 30 30 62 00 6d 70 63 =
35 32 78 78 00];
#address-cells =3D <1>;
#size-cells =3D <1>;
cpus {
#cpus =3D <1>;
#address-cells =3D <1>;
#size-cells =3D <0>;
PowerPC,5200@0 {
device_type =3D "cpu";
reg =3D <0>;
d-cache-line-size =3D <20>;
i-cache-line-size =3D <20>;
d-cache-size =3D <4000>;
i-cache-size =3D <4000>;
timebase-frequency =3D <1f78a40>;
bus-frequency =3D <7de2900>;
clock-frequency =3D <179a7b00>;
32-bit;
};
};
memory {
device_type =3D "memory";
reg =3D [00 00 00 00 08 00 00 00];
};
soc5200@f0000000 {
#interrupt-cells =3D <3>;
device_type =3D "soc";
ranges =3D [00 00 00 00 f0 00 00 00 f0 01 00 00];
reg =3D [f0 00 00 00 00 01 00 00];
bus-frequency =3D <3ef1480>;
cdm@200 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 63 64 6d 00 6d 70 =
63 35 32 78 78 2d 63 64 6d 00];
reg =3D [00 00 02 00 00 00 00 38];
};
pic@500 {
linux,phandle =3D <500>;
interrupt-controller;
#interrupt-cells =3D <3>;
device_type =3D "interrupt-controller";
compatible =3D [6d 70 63 35 32 30 30 62 2d 70 69 63 00 6d 70 =
63 35 32 78 78 2d 70 69 63 00];
reg =3D [00 00 05 00 00 00 00 80];
built-in;
};
gpt@600 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 00 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 09 00 00 00 00];
interrupt-parent =3D <500>;
};
gpt@610 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 10 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 0a 00 00 00 00];
interrupt-parent =3D <500>;
};
gpt@620 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 20 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 0b 00 00 00 00];
interrupt-parent =3D <500>;
};
gpt@630 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 30 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 0c 00 00 00 00];
interrupt-parent =3D <500>;
};
gpt@640 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 40 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 0d 00 00 00 00];
interrupt-parent =3D <500>;
};
gpt@650 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 50 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 0e 00 00 00 00];
interrupt-parent =3D <500>;
};
gpt@660 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 60 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 0f 00 00 00 00];
interrupt-parent =3D <500>;
};
gpt@670 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 74 00 6d 70 =
63 35 32 78 78 2d 67 70 74 00];
device_type =3D "gpt";
reg =3D [00 00 06 70 00 00 00 10];
interrupts =3D [00 00 00 01 00 00 00 10 00 00 00 00];
interrupt-parent =3D <500>;
};
rtc@800 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 72 74 63 00 6d 70 =
63 35 32 78 78 2d 72 74 63 00];
device_type =3D "rtc";
reg =3D [00 00 08 00 00 00 01 00];
interrupts =3D [00 00 00 01 00 00 00 05 00 00 00 00 00 00 00 =
01 00 00 00 06 00 00 00 00];
interrupt-parent =3D <500>;
};
mscan@900 {
device_type =3D "mscan";
compatible =3D [6d 70 63 35 32 30 30 62 2d 6d 73 63 61 6e 00 =
6d 70 63 35 32 78 78 2d 6d 73 63 61 6e 00];
interrupts =3D [00 00 00 02 00 00 00 11 00 00 00 00];
interrupt-parent =3D <500>;
reg =3D [00 00 09 00 00 00 00 80];
};
mscan@980 {
device_type =3D "mscan";
compatible =3D [6d 70 63 35 32 30 30 62 2d 6d 73 63 61 6e 00 =
6d 70 63 35 32 78 78 2d 6d 73 63 61 6e 00];
interrupts =3D [00 00 00 02 00 00 00 12 00 00 00 00];
interrupt-parent =3D <500>;
reg =3D [00 00 09 80 00 00 00 80];
};
gpio@b00 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 69 6f 00 6d =
70 63 35 32 78 78 2d 67 70 69 6f 00];
reg =3D [00 00 0b 00 00 00 00 40];
interrupts =3D [00 00 00 01 00 00 00 07 00 00 00 00];
interrupt-parent =3D <500>;
};
gpio-wkup@b00 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 67 70 69 6f 2d 77 =
6b 75 70 00 6d 70 63 35 32 78 78 2d 67 70 69 6f 2d 77 6b 75 70 00];
reg =3D [00 00 0c 00 00 00 00 40];
interrupts =3D [00 00 00 01 00 00 00 08 00 00 00 00 00 00 00 =
00 00 00 00 03 00 00 00 00];
interrupt-parent =3D <500>;
};
pci@0d00 {
#interrupt-cells =3D <1>;
#size-cells =3D <2>;
#address-cells =3D <3>;
device_type =3D "pci";
compatible =3D [6d 70 63 35 32 30 30 62 2d 70 63 69 00 6d 70 =
63 35 32 78 78 2d 70 63 69 00];
reg =3D [00 00 0d 00 00 00 01 00];
interrupt-map-mask =3D [00 00 f8 00 00 00 00 00 00 00 00 00 =
00 00 00 07];
interrupt-map =3D [00 00 c0 00 00 00 00 00 00 00 00 00 00 00 =
00 01 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 c0 00 00 00 =
00 00 00 00 00 00 00 00 00 02 00 00 05 00 00 00 00 01 00 00 00 01 00 00 =
00 03 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 05 00 00 00 =
00 01 00 00 00 02 00 00 00 03 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 =
00 04 00 00 05 00 00 00 00 01 00 00 00 03 00 00 00 03 00 00 c8 00 00 00 =
00 00 00 00 00 00 00 00 00 01 00 00 05 00 00 00 00 01 00 00 00 01 00 00 =
00 03 00 00 c8 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 05 00 00 00 =
00 01 00 00 00 02 00 00 00 03 00 00 c8 00 00 00 00 00 00 00 00 00 00 00 =
00 03 00 00 05 00 00 00 00 01 00 00 00 03 00 00 00 03 00 00 c8 00 00 00 =
00 00 00 00 00 00 00 00 00 04 00 00 05 00 00 00 00 00 00 00 00 00 00 00 =
00 03];
clock-frequency =3D <0>;
interrupts =3D [00 00 00 02 00 00 00 08 00 00 00 00 00 00 00 =
02 00 00 00 09 00 00 00 00 00 00 00 02 00 00 00 0a 00 00 00 00];
interrupt-parent =3D <500>;
bus-range =3D [00 00 00 00 00 00 00 00];
ranges =3D [42 00 00 00 00 00 00 00 80 00 00 00 80 00 00 00 =
00 00 00 00 20 00 00 00 02 00 00 00 00 00 00 00 a0 00 00 00 a0 00 00 00 =
00 00 00 00 10 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 b0 00 00 00 =
00 00 00 00 01 00 00 00];
};
spi@f00 {
device_type =3D "spi";
compatible =3D [6d 70 63 35 32 30 30 62 2d 73 70 69 00 6d 70 =
63 35 32 78 78 2d 73 70 69 00];
reg =3D [00 00 0f 00 00 00 00 20];
interrupts =3D [00 00 00 02 00 00 00 0d 00 00 00 00 00 00 00 =
02 00 00 00 0e 00 00 00 00];
interrupt-parent =3D <500>;
};
usb@1000 {
device_type =3D "usb-ohci-be";
compatible =3D [6d 70 63 35 32 30 30 62 2d 6f 68 63 69 00 6d =
70 63 35 32 78 78 2d 6f 68 63 69 00 6f 68 63 69 2d 62 65 00];
reg =3D [00 00 10 00 00 00 00 ff];
interrupts =3D [00 00 00 02 00 00 00 06 00 00 00 00];
interrupt-parent =3D <500>;
};
bestcomm@1200 {
device_type =3D "dma-controller";
compatible =3D [6d 70 63 35 32 30 30 62 2d 62 65 73 74 63 6f =
6d 6d 00 6d 70 63 35 32 78 78 2d 62 65 73 74 63 6f 6d 6d 00];
reg =3D [00 00 12 00 00 00 00 80];
interrupts =3D [00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 =
03 00 00 00 01 00 00 00 00 00 00 00 03 00 00 00 02 00 00 00 00 00 00 00 =
03 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 00 00 00 00 =
03 00 00 00 05 00 00 00 00 00 00 00 03 00 00 00 06 00 00 00 00 00 00 00 =
03 00 00 00 07 00 00 00 00 00 00 00 03 00 00 00 08 00 00 00 00 00 00 00 =
03 00 00 00 09 00 00 00 00 00 00 00 03 00 00 00 0a 00 00 00 00 00 00 00 =
03 00 00 00 0b 00 00 00 00 00 00 00 03 00 00 00 0c 00 00 00 00 00 00 00 =
03 00 00 00 0d 00 00 00 00 00 00 00 03 00 00 00 0e 00 00 00 00 00 00 00 =
03 00 00 00 0f 00 00 00 00];
interrupt-parent =3D <500>;
};
xlb@1f00 {
compatible =3D [6d 70 63 35 32 30 30 62 2d 78 6c 62 00 6d 70 =
63 35 32 78 78 2d 78 6c 62 00];
reg =3D [00 00 1f 00 00 00 01 00];
};
serial@2000 {
device_type =3D "serial";
compatible =3D [6d 70 63 35 32 30 30 62 2d 70 73 63 2d 75 61 =
72 74 00 6d 70 63 35 32 78 78 2d 70 73 63 2d 75 61 72 74 00];
port-number =3D <0>;
reg =3D [00 00 20 00 00 00 01 00];
interrupts =3D [00 00 00 02 00 00 00 01 00 00 00 00];
interrupt-parent =3D <500>;
};
ethernet@3000 {
device_type =3D "network";
compatible =3D [6d 70 63 35 32 30 30 62 2d 66 65 63 00 6d 70 =
63 35 32 78 78 2d 66 65 63 00];
reg =3D [00 00 30 00 00 00 08 00];
mac-address =3D [00 e0 ee 00 28 0d];
interrupts =3D [00 00 00 02 00 00 00 05 00 00 00 00];
interrupt-parent =3D <500>;
};
i2c@3d00 {
device_type =3D "i2c";
compatible =3D [6d 70 63 35 32 30 30 62 2d 69 32 63 00 6d 70 =
63 35 32 78 78 2d 69 32 63 00];
reg =3D [00 00 3d 00 00 00 00 40];
interrupts =3D [00 00 00 02 00 00 00 0f 00 00 00 00];
interrupt-parent =3D <500>;
};
i2c@3d40 {
device_type =3D "i2c";
compatible =3D [6d 70 63 35 32 30 30 62 2d 69 32 63 00 6d 70 =
63 35 32 78 78 2d 69 32 63 00];
reg =3D [00 00 3d 40 00 00 00 40];
interrupts =3D [00 00 00 02 00 00 00 10 00 00 00 00];
interrupt-parent =3D <500>;
};
sram@8000 {
device_type =3D "sram";
compatible =3D [6d 70 63 35 32 30 30 62 2d 73 72 61 6d 00 6d =
70 63 35 32 78 78 2d 73 72 61 6d 00 73 72 61 6d 00];
reg =3D [00 00 80 00 00 00 40 00];
};
};
chosen {
name =3D "chosen";
bootargs =3D "console=3DttyPSC0,115200 root=3D/dev/nfs ip=3Ddhcp =
nfsroot=3D10.100.11.96:/home/danielsch/downloads/OSELAS.BSP-Phytec-phyCOR=
E-MPC5200B-tiny-5/root,v3,tcp";
linux,platform =3D <600>;
linux,stdout-path =3D "/soc5200@f0000000/serial@2000";
};
};
-----Original Message-----
From: Domen Puncer [mailto:domen.puncer@telargo.com]=20
Sent: 1. j=FAn=ED 2007 06:35
To: Daniel Schnell
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Where is initial console initialized ?
On 31/05/07 13:42 -0000, Daniel Schnell wrote:
> Hi,
> =20
> I am trying to bring up 2.6.20.3 on a MPC5200B based custom board.=20
> This Kernel is based on the Phytec phyCore MPC5200B Mini BSP kernel=20
> and adapted to my board.
> So far I have troubles to get console output working when booting =
Linux.
> Uboot console output is fine. Linux begins to run (I can set=20
> breakpoints with the BDI2000 in the early initialization code) so I=20
> probably have a misconfiguration of the console output inside the fdt.
>=20
> The major difference between the Phytec phyCore 5200B mini fdt and=20
> mine is that we use PSC1 instead of PSC3/6 for serial. Accordingly I=20
> changed the fdt (or dts) values.
>=20
> To get some more insights, I would like to know, in which Linux=20
> function the console output is initialised ?
>=20
>=20
...
> If I dump the flat device tree inside uboot, I get the following
> entries:=20
...
the dump with:
reg =3D <8>;
in most of nodes, which looks just wrong.
Domen
^ permalink raw reply
* RE: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs mount problems
From: Ben Warren @ 2007-06-01 14:51 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Linux PPC Linux PPC
In-Reply-To: <BAY115-W17F1AB35DDD5B358CAC89B22D0@phx.gbl>
--- Mohammad Sadegh Sadri <mamsadegh@hotmail.com> wrote:
>
> Hi all,
>
> thanks for suggestions
> I added rsize=1024,wsize=1024 to CMD LINE. INIT can now be executed from nfs,
> but I think that the problem still exists,
> during the start up process ( from when the rootfs is mounted until user get
> a command prompt ) some times ML403 stops working completely, and generates
> "Segmentation Fault" and similar messages. some other times the system comes
> up with no problem.
>
> I had the same problem when mounting rootfs using nfs via 100mbits link , but
> for gigabit link the probability of reaching this unstable state is much
> higher.
>
> any ideas?
>
Sorry, I don't know anything about your hardware. Stating the obvious,
something's being put where it shouldn't be, maybe because the Ethernet driver
is filling buffers faster than they are being processed? This is of course
stressed with a higher speed link. You'll have much more control over your
debugging if you put rootfs somewhere other than NFS (flash or ramdisk), then
mount remote drives and try various file operations.
regards,
Ben
^ permalink raw reply
* RE: Where is initial console initialized ?
From: Daniel Schnell @ 2007-06-01 15:13 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070601063507.GA23294@moe.telargo.com>
Hi,
Well if one does it right, then things work as expected.
I simply chose the wrong Kernel configuration, the correct console =
driver has not been compiled in.
Now it works as expected.
Sorry for the noise.
Daniel Schnell.
-----Original Message-----
From: Domen Puncer [mailto:domen.puncer@telargo.com]=20
Sent: 1. j=FAn=ED 2007 06:35
To: Daniel Schnell
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Where is initial console initialized ?
On 31/05/07 13:42 -0000, Daniel Schnell wrote:
> Hi,
> =20
> I am trying to bring up 2.6.20.3 on a MPC5200B based custom board.=20
> This Kernel is based on the Phytec phyCore MPC5200B Mini BSP kernel=20
> and adapted to my board.
> So far I have troubles to get console output working when booting =
Linux.
> Uboot console output is fine. Linux begins to run (I can set=20
> breakpoints with the BDI2000 in the early initialization code) so I=20
> probably have a misconfiguration of the console output inside the fdt.
>=20
> The major difference between the Phytec phyCore 5200B mini fdt and=20
> mine is that we use PSC1 instead of PSC3/6 for serial. Accordingly I=20
> changed the fdt (or dts) values.
>=20
> To get some more insights, I would like to know, in which Linux=20
> function the console output is initialised ?
>=20
>=20
...
> If I dump the flat device tree inside uboot, I get the following
> entries:=20
...
the dump with:
reg =3D <8>;
in most of nodes, which looks just wrong.
Domen
^ permalink raw reply
* Re: [PATCH 1/1] Use NO_IRQ not IRQ_NONE
From: Linas Vepstas @ 2007-06-01 16:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1180684052.19517.422.camel@localhost.localdomain>
On Fri, Jun 01, 2007 at 05:47:32PM +1000, Benjamin Herrenschmidt wrote:
> My fault actually :-) Mostly a typo, it's right elsewhere in the code
> except in those 3 occurences. Brown paper bag time for me.
Trying to make the rest of us look bad? By those standards,
I'd be wearing 23 brown paper bags at the same time, all the time.
--linas
^ permalink raw reply
* linux 2.6 driver for tsi148
From: Sivakumar K K @ 2007-06-01 15:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
Hi guys,
i am cirrently working on vme driver integration with linux 2.6 kernel for powerpc based SBC. Tundra giving driver to tsi148 for 2.4kernel , but i required it for 2.6 kernel.
If anybody have the driver in 2.6 kernel, please reply to me.
I tried to convert 2.4 driver to support 2.6 finally i got struc at "kiobuf" structure all other changes i made. kiobuf structure is in iobuf.h, i have searched it in 2.6 kernel but i didn,t get the result. I need a help how to resolve this issue, is there any equivqlent functions and structures are available in 2.6 kerenel? If anybody knows how to resole it please reply to me.
Thanks and Regards
Siva
Firmware Engineer
[-- Attachment #2: Type: text/html, Size: 1454 bytes --]
^ permalink raw reply
* Re: [PATCH] NET: add MAINTAINERS entry for ucc_geth driver
From: Kim Phillips @ 2007-06-01 16:27 UTC (permalink / raw)
To: Li Yang; +Cc: netdev, jeff, linuxppc-embedded
In-Reply-To: <465679FA.8010702@freescale.com>
On Fri, 25 May 2007 13:54:02 +0800
Li Yang <leoli@freescale.com> wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
Acked-by: Kim Phillips <kim.phillips@freescale.com>
Kim
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Matt Sealey @ 2007-06-01 16:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <1180683854.19517.419.camel@localhost.localdomain>
Re enabling proper domain support on 32-bit... now, now, now please!
X guys won't merge in code, we've been punished by both sides on Pegasos
for nearly 12 months now after there's been a bunch of misguided attempts
to 'fix' domain support in X. The real fix is in the kernel to make it
very clear that domains and proper, per-domain bus numbering (not
global bus numbering) and suchlike is the standard like it is on SPARC
and PPC64 and IA64.
If ppc32 suddenly goes the way of these, X guys will fix it, there will
be patches to work against this kernel, even if they have to detect the
kernel version to do it or look at a procfs or sysfs entry to fix up
their dumb pci scanning code.
I don't think stalling on it "because of X" is right. Fix Linux, X will
follow, because it really has to.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-01 at 14:45 +0800, Zhang Wei-r63237 wrote:
>> There are lots of lagacy PCI codes in kernel, such as
>> pci_bus_to_hose(busnr). If two hose's bus number have overlaps,
>> pci_bus_to_hose() can not return the correct hose. And there will
>> effect
>> /proc/pci and lspci tools.
>
> More specifically...
>
> Overlapping bus numbers on separate domains work... on 64 bits :-) The
> 32 bits PCI code assumes non-overlapping numbers. The main reason for
> that historically was that back then, domains didn't work well.
>
> The second reasons why I didn't actually fix it is that turning on full
> domain support had (and probably still has) the nasty habit of breaking
> the X server :-( X is full of most horrible hacks for PCI and it will be
> terminally broken until they finally merge the pci-rework branch that
> Ian Romanick's been working on for some time now.
>
> One of these days, one of us will finally tackle merging 32 and 64 bits
> PCI code (and fix both of them while at it to better use the generic
> code, which involves fixing issues in the said generic code too :-) at
> which point I'll enable full domain support for 32 bits as well, with an
> option to degrade it to bus number remapping.
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 3/5] Float the pci bus number on MPC8641HPCN board.
From: Jon Loeliger @ 2007-06-01 16:47 UTC (permalink / raw)
To: Matt Sealey; +Cc: Wei Zhang, Paul Mackerras, linuxppc-dev@ozlabs.org
In-Reply-To: <46604AE0.5040700@genesi-usa.com>
On Fri, 2007-06-01 at 11:35, Matt Sealey wrote:
> Re enabling proper domain support on 32-bit... now, now, now please!
>
> X guys won't merge in code, we've been punished by both sides on Pegasos
> for nearly 12 months now after there's been a bunch of misguided attempts
> to 'fix' domain support in X. The real fix is in the kernel to make it
> very clear that domains and proper, per-domain bus numbering (not
> global bus numbering) and suchlike is the standard like it is on SPARC
> and PPC64 and IA64.
>
> If ppc32 suddenly goes the way of these, X guys will fix it, there will
> be patches to work against this kernel, even if they have to detect the
> kernel version to do it or look at a procfs or sysfs entry to fix up
> their dumb pci scanning code.
>
> I don't think stalling on it "because of X" is right. Fix Linux, X will
> follow, because it really has to.
OK. Let me interpret this for my (8641) case:
These two lines of quirky code in _exclude_device()
are not ideal, but they adjust for a PCI systemic
problem that isn't going to be fixed any time soon.
Therefore, I will go ahead and repost my PCI patch
series to get PCI-E working again on 8641, and pointed
in the right direction so we can merge in the support
for 8548 and 8544 as follow ups.
We (collectively) will then address the systemic PCI
problem with 32-bit systems later.
Thanks,
jdl
^ permalink raw reply
* [PATCH 0/8] Add Generic PCI-E support to 8641HPCN
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Paul,
This 8-part patch set combines the two previous patch
sets, 5 from Zheng Wei, and 3 from me, along with one
from Wade Farnsworth into one nice-n-happy set, all
designed to re-enable PCI-Express on the MPC8641HPCN board.
Yes, there is one hacky bus number adjusting being done
in _exclude_device(), but I think I read that it will
take some fairly serious effort to rewrite the PPC-32
version of PCI bus numbering to make it "right".
In the meantime, these patches work, and will enable us
to add on the 8548 and 8544 PCI-Express code as well.
These are rebased to your current top-of-master branch.
Thanks,
jdl
^ permalink raw reply
* [PATCH 1/8] Remove the errata fix codes for MPC8641 silicon ver 1.0 which is end of life.
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Zhang Wei <wei.zhang@freescale.com>
Remove the errata fix codes for MPC8641 silicon ver 1.0 which
is end of life.
The MPC8641 silicon ver 1.0 is not fully support PCI/PCI Express
specifications. The revision 2.0 fixes all of these errata
and the rev 1.0 silicon is end of life. So errata codes are removed.
Now, The chip is full compatible with PCI/PCI Express
specifications. The generic PCI code is used.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/Kconfig | 3 +--
arch/powerpc/platforms/86xx/mpc86xx.h | 6 ------
arch/powerpc/platforms/86xx/pci.c | 10 +---------
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 56d3c0d..e683668 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -183,7 +183,6 @@ config PPC_86xx
bool "Freescale 86xx"
select 6xx
select FSL_SOC
- select FSL_PCIE
select PPC_FPU
select ALTIVEC
help
@@ -675,7 +674,7 @@ config FSL_SOC
config FSL_PCIE
bool
- depends on PPC_86xx
+ depends on PPC_85xx
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
diff --git a/arch/powerpc/platforms/86xx/mpc86xx.h b/arch/powerpc/platforms/86xx/mpc86xx.h
index 2834462..740b300 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx.h
+++ b/arch/powerpc/platforms/86xx/mpc86xx.h
@@ -19,12 +19,6 @@ extern int add_bridge(struct device_node *dev);
extern int mpc86xx_exclude_device(u_char bus, u_char devfn);
-extern void setup_indirect_pcie(struct pci_controller *hose,
- u32 cfg_addr, u32 cfg_data);
-extern void setup_indirect_pcie_nomap(struct pci_controller *hose,
- void __iomem *cfg_addr,
- void __iomem *cfg_data);
-
extern void __init mpc86xx_smp_init(void);
#endif /* __MPC86XX_H__ */
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 8235c56..7efae7c 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -133,18 +133,10 @@ mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
early_write_config_word(hose, 0, 0, PCI_COMMAND, cmd);
early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0x80);
-
- /* PCIE Bus, Fix the MPC8641D host bridge's location to bus 0xFF. */
- early_read_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, &temps);
- temps = (temps & 0xff000000) | (0xff) | (0x0 << 8) | (0xfe << 16);
- early_write_config_dword(hose, 0, 0, PCI_PRIMARY_BUS, temps);
}
int mpc86xx_exclude_device(u_char bus, u_char devfn)
{
- if (bus == 0 && PCI_SLOT(devfn) == 0)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
return PCIBIOS_SUCCESSFUL;
}
@@ -178,7 +170,7 @@ int __init add_bridge(struct device_node *dev)
hose->first_busno = bus_range ? bus_range[0] : 0x0;
hose->last_busno = bus_range ? bus_range[1] : 0xfe;
- setup_indirect_pcie(hose, rsrc.start, rsrc.start + 0x4);
+ setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4);
/* Setup the PCIE host controller. */
mpc86xx_setup_pcie(hose, rsrc.start, rsrc.end - rsrc.start + 1);
--
1.5.0.3
^ permalink raw reply related
* [PATCH 2/8] Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Wade Farnsworth <wfarnsworth@mvista.com>
This adds device nodes for the PCI bridges as well as the ISA devices on
the newer revision MPC8641HPCN. It also adds the PCI ranges to the soc
node so that address translation for the ISA devices works properly.
Includes ULI node originally from Zhang Wei <wei.zhang@freescale.com>.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 89 +++++++++++++++++++++++++++----
1 files changed, 77 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 260b264..b2a4734 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -56,7 +56,11 @@
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
- ranges = <0 f8000000 00100000>;
+ ranges = <00000000 f8000000 00100000
+ 80000000 80000000 20000000
+ e2000000 e2000000 00100000
+ a0000000 a0000000 20000000
+ e3000000 e3000000 00100000>;
reg = <f8000000 00100000>; // CCSRBAR 1M
bus-frequency = <0>;
@@ -285,17 +289,78 @@
f800 0 0 3 &i8259 0 0
f800 0 0 4 &i8259 0 0
>;
- i8259: i8259@4d0 {
- clock-frequency = <0>;
- interrupt-controller;
- device_type = "interrupt-controller";
- #address-cells = <0>;
- #interrupt-cells = <2>;
- built-in;
- compatible = "chrp,iic";
- big-endian;
- interrupts = <49 2>;
- interrupt-parent = <&mpic>;
+ uli1575@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 80000000
+ 02000000 0 80000000
+ 0 20000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00100000>;
+
+ pci_bridge@0 {
+ reg = <0 0 0 0 0>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ ranges = <02000000 0 80000000
+ 02000000 0 80000000
+ 0 20000000
+ 01000000 0 00000000
+ 01000000 0 00000000
+ 0 00100000>;
+
+ isa@1e {
+ device_type = "isa";
+ #interrupt-cells = <2>;
+ #size-cells = <1>;
+ #address-cells = <2>;
+ reg = <f000 0 0 0 0>;
+ ranges = <1 0 01000000 0 0
+ 00001000>;
+ interrupt-parent = <&i8259>;
+
+ i8042@60 {
+ reg = <1 60 1 1 64 1>;
+ interrupts = <1 3 c 3>;
+ interrupt-parent =
+ <&i8259>;
+
+ keyboard@0 {
+ compatible = "pnpPNP,303";
+ };
+
+ mouse@1 {
+ compatible = "pnpPNP,f03";
+ };
+ };
+
+ rtc@70 {
+ compatible =
+ "pnpPNP,b00";
+ reg = <1 70 2>;
+ };
+
+ gpio@400 {
+ reg = <1 400 80>;
+ };
+
+ i8259: i8259@4d0 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ big-endian;
+ interrupts = <49 2>;
+ interrupt-parent =
+ <&mpic>;
+ };
+ };
+ };
};
};
--
1.5.0.3
^ permalink raw reply related
* [PATCH 3/8] 8641HPCN: Add PCI-Express link training status check
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Zhang Wei <wei.zhang@freescale.com>
Avoid system halt while the link training is fault.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/pci.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 7efae7c..07ff52c 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -122,7 +122,6 @@ static void __init
mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
{
u16 cmd;
- unsigned int temps;
DBG("PCIE host controller register offset 0x%08x, size 0x%08x.\n",
pcie_offset, pcie_size);
@@ -140,6 +139,9 @@ int mpc86xx_exclude_device(u_char bus, u_char devfn)
return PCIBIOS_SUCCESSFUL;
}
+#define PCIE_LTSSM 0x04000004 /* PCIe Link Training and Status */
+#define PCIE_LTSSM_L0 0x16 /* L0 state */
+
int __init add_bridge(struct device_node *dev)
{
int len;
@@ -148,12 +150,20 @@ int __init add_bridge(struct device_node *dev)
const int *bus_range;
int has_address = 0;
int primary = 0;
+ void *pcicfg_addr;
DBG("Adding PCIE host bridge %s\n", dev->full_name);
/* Fetch host bridge registers address */
has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
+ /* Probe the hose link training status */
+ pcicfg_addr = ioremap(rsrc.start, 0x1000);
+ out_be32(pcicfg_addr, 0x80000000 | PCIE_LTSSM);
+ if (in_le16(pcicfg_addr + 4) < PCIE_LTSSM_L0)
+ return -ENXIO;
+ iounmap(pcicfg_addr);
+
/* Get bus range if any */
bus_range = of_get_property(dev, "bus-range", &len);
if (bus_range == NULL || len < 2 * sizeof(int))
--
1.5.0.3
^ permalink raw reply related
* [PATCH 4/8] Float the PCi bus number assignments on MPC8641HPCN board.
From: Jon Loeliger @ 2007-06-01 17:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Zhang Wei <wei.zhang@freescale.com>
Admittedly this is a non-ideal solution, but fixing it
properly might require systemic PCI bus renumbering
changes that we are not prepared to do yet.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 +
arch/powerpc/platforms/86xx/pci.c | 12 ++++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 1051702..9259788 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -363,6 +363,7 @@ mpc86xx_hpcn_setup_arch(void)
}
#ifdef CONFIG_PCI
+ pci_assign_all_buses = 1;
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
add_bridge(np);
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 07ff52c..c80d8f1 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -136,6 +136,18 @@ mpc86xx_setup_pcie(struct pci_controller *hose, u32 pcie_offset, u32 pcie_size)
int mpc86xx_exclude_device(u_char bus, u_char devfn)
{
+ struct pci_controller *hose;
+
+ hose = pci_bus_to_hose(bus);
+ if (unlikely(!hose))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ /* Correcting the hose->bus_offset value. */
+ out_be32(hose->cfg_addr, 0x80000000 | ((hose->first_busno
+ - hose->bus_offset) << 16));
+ if (unlikely(in_le32(hose->cfg_data) == 0xffffffff))
+ hose->bus_offset = hose->bus_offset ? 0 : hose->first_busno;
+
return PCIBIOS_SUCCESSFUL;
}
--
1.5.0.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox