* Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: David Gibson @ 2007-08-09 4:18 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070809041632.GA13921@localdomain>
On Wed, Aug 08, 2007 at 11:16:32PM -0500, Nathan Lynch wrote:
> David Gibson wrote:
> > On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
> > > The maple pci configuration space write methods read the written
> > > location immediately after the write is performed, presumably in order
> > > to flush the write. However, configuration space writes are not
> > > allowed to be posted, making these reads gratuitous.
> >
> > It might be worth checking that there isn't a particular reason for
> > these. Just because posting writes are forbidden doesn't mean a
> > particular bridge won't screw it up...
>
> Well, I had already checked with Ben, who wrote the code, and my
> understanding is that the reads are intended to work around some
> misbehaving Apple bridges, but that a sync after the write (implied by
> releasing pci_lock in the generic pci code) should suffice for
> those.
Ah, ok then.
--
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: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: Nathan Lynch @ 2007-08-09 4:16 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070809030555.GA8261@localhost.localdomain>
David Gibson wrote:
> On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
> > The maple pci configuration space write methods read the written
> > location immediately after the write is performed, presumably in order
> > to flush the write. However, configuration space writes are not
> > allowed to be posted, making these reads gratuitous.
>
> It might be worth checking that there isn't a particular reason for
> these. Just because posting writes are forbidden doesn't mean a
> particular bridge won't screw it up...
Well, I had already checked with Ben, who wrote the code, and my
understanding is that the reads are intended to work around some
misbehaving Apple bridges, but that a sync after the write (implied by
releasing pci_lock in the generic pci code) should suffice for those.
^ permalink raw reply
* Re: Sequoia 440EPx patches not working
From: David Gibson @ 2007-08-09 3:08 UTC (permalink / raw)
To: Jerone Young; +Cc: linuxppc-dev, vbarshark
In-Reply-To: <1186598710.5459.7.camel@laptop>
On Wed, Aug 08, 2007 at 01:45:10PM -0500, Jerone Young wrote:
> Using the Sequoia (AMCC 440EPx) patches recently submitted to the list I
> am unable to boot to fully boot a uImage built with these patches under
> Uboot. It appears to hang in very early boot.
I'm guessing this is an old version of u-boot, that's not device tree
aware. That would need a cuImage, not a uImage, and IIRC the posted
patches didn't yet have cuboot support for Sequoia.
--
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 v3 1/2] [POWERPC] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: David Gibson @ 2007-08-09 3:07 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070808170921.GA21487@localhost.localdomain>
On Wed, Aug 08, 2007 at 09:09:21PM +0400, Anton Vorontsov wrote:
> mmc_spi already tested to work. When it will hit mainline
> the only change that will be needed is replacing "spidev"
> by "mmc_spi".
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 4 ++-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 52 +++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> index e9c332f..664dd16 100644
> --- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
> @@ -207,15 +207,17 @@
>
> spi@4c0 {
> device_type = "spi";
> + fsl,device-id = <1>;
Hrm... Freescale is using these 'fsl,device-id' properties, I'm
guessing they're basically the same thing as the 'cell-index' used in
the EMAC binding.
We should co-ordinate better on this, if it's to become a
convention...
--
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: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: David Gibson @ 2007-08-09 3:05 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070809005044.GD10114@localdomain>
On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
> The maple pci configuration space write methods read the written
> location immediately after the write is performed, presumably in order
> to flush the write. However, configuration space writes are not
> allowed to be posted, making these reads gratuitous.
It might be worth checking that there isn't a particular reason for
these. Just because posting writes are forbidden doesn't mean a
particular bridge won't screw it up...
> Furthermore,
> this behavior potentially causes us to violate the PCI PM spec when
> changing between e.g. D0 and D3 states, because a delay of up to 10ms
> may be required before the OS accesses configuration space after the
> write which initiates the transition. It definitely causes a system
> hang for me with a Broadcom 5721 PCIE network adapter, which is fixed
> by this change.
>
> Remove the gratuitous reads from u3_agp_write_config,
> u3_ht_write_config, and u4_pcie_write_config.
--
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: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: Benjamin Herrenschmidt @ 2007-08-09 1:14 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070809010431.GF10114@localdomain>
On Wed, 2007-08-08 at 20:04 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
> > >
> > > Remove the gratuitous reads from u3_agp_write_config,
> > > u3_ht_write_config, and u4_pcie_write_config.
> > >
> > > Signed-off-by: Nathan Lynch <ntl@pobox.com>
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > Thanks ! Care to fix powermac too ? :-)
>
> Sure, I'll get it tomorrow... looks like pasemi cribbed the powermac
> code too :)
Allright, thanks !
Cheersm
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: Nathan Lynch @ 2007-08-09 1:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1186620933.938.211.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
> >
> > Remove the gratuitous reads from u3_agp_write_config,
> > u3_ht_write_config, and u4_pcie_write_config.
> >
> > Signed-off-by: Nathan Lynch <ntl@pobox.com>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Thanks ! Care to fix powermac too ? :-)
Sure, I'll get it tomorrow... looks like pasemi cribbed the powermac
code too :)
^ permalink raw reply
* Re: [PATCH 6/6] pseries: eliminate global var
From: Nathan Lynch @ 2007-08-09 1:02 UTC (permalink / raw)
To: Linas Vepstas; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070808222223.GH25995@austin.ibm.com>
Linas Vepstas wrote:
> On Wed, Aug 08, 2007 at 04:57:14PM -0500, Nathan Lynch wrote:
> > Linas Vepstas wrote:
> > > +
> > > +#ifdef CONFIG_PPC_PSERIES
> > > +extern int pSeries_nvram_init(void);
> > > +extern int nvram_write_error_log(char * buff, int length,
> > > + unsigned int err_type, unsigned int err_seq);
> > > +extern int nvram_read_error_log(char * buff, int length,
> > > + unsigned int * err_type, unsigned int *err_seq);
> > > +extern int nvram_clear_error_log(void);
> > > +#endif /* CONFIG_PPC_PSERIES */
> >
> > Declarations need not be #ifdef'd.
>
> Ah, I thought that would be cleaner ... should I resubmit,
> the patch, or does it matter that much?
FWIW I'd prefer you drop that hunk and resubmit; it's needless churn
that can only cause build problems.
^ permalink raw reply
* Re: [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: Benjamin Herrenschmidt @ 2007-08-09 0:55 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070809005044.GD10114@localdomain>
On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
> The maple pci configuration space write methods read the written
> location immediately after the write is performed, presumably in order
> to flush the write. However, configuration space writes are not
> allowed to be posted, making these reads gratuitous. Furthermore,
> this behavior potentially causes us to violate the PCI PM spec when
> changing between e.g. D0 and D3 states, because a delay of up to 10ms
> may be required before the OS accesses configuration space after the
> write which initiates the transition. It definitely causes a system
> hang for me with a Broadcom 5721 PCIE network adapter, which is fixed
> by this change.
>
> Remove the gratuitous reads from u3_agp_write_config,
> u3_ht_write_config, and u4_pcie_write_config.
>
> Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Thanks ! Care to fix powermac too ? :-)
Cheers,
Ben.
> ---
> arch/powerpc/platforms/maple/pci.c | 9 ---------
> 1 files changed, 0 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
> index 2542403..b095eaa 100644
> --- a/arch/powerpc/platforms/maple/pci.c
> +++ b/arch/powerpc/platforms/maple/pci.c
> @@ -169,15 +169,12 @@ static int u3_agp_write_config(struct pci_bus *bus, unsigned int devfn,
> switch (len) {
> case 1:
> out_8(addr, val);
> - (void) in_8(addr);
> break;
> case 2:
> out_le16(addr, val);
> - (void) in_le16(addr);
> break;
> default:
> out_le32(addr, val);
> - (void) in_le32(addr);
> break;
> }
> return PCIBIOS_SUCCESSFUL;
> @@ -268,15 +265,12 @@ static int u3_ht_write_config(struct pci_bus *bus, unsigned int devfn,
> switch (len) {
> case 1:
> out_8(addr, val);
> - (void) in_8(addr);
> break;
> case 2:
> out_le16(addr, val);
> - (void) in_le16(addr);
> break;
> default:
> out_le32(addr, val);
> - (void) in_le32(addr);
> break;
> }
> return PCIBIOS_SUCCESSFUL;
> @@ -376,15 +370,12 @@ static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
> switch (len) {
> case 1:
> out_8(addr, val);
> - (void) in_8(addr);
> break;
> case 2:
> out_le16(addr, val);
> - (void) in_le16(addr);
> break;
> default:
> out_le32(addr, val);
> - (void) in_le32(addr);
> break;
> }
> return PCIBIOS_SUCCESSFUL;
^ permalink raw reply
* [RFC/PATCH] remove gratuitous reads from maple pci config space methods
From: Nathan Lynch @ 2007-08-09 0:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
The maple pci configuration space write methods read the written
location immediately after the write is performed, presumably in order
to flush the write. However, configuration space writes are not
allowed to be posted, making these reads gratuitous. Furthermore,
this behavior potentially causes us to violate the PCI PM spec when
changing between e.g. D0 and D3 states, because a delay of up to 10ms
may be required before the OS accesses configuration space after the
write which initiates the transition. It definitely causes a system
hang for me with a Broadcom 5721 PCIE network adapter, which is fixed
by this change.
Remove the gratuitous reads from u3_agp_write_config,
u3_ht_write_config, and u4_pcie_write_config.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/platforms/maple/pci.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
index 2542403..b095eaa 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -169,15 +169,12 @@ static int u3_agp_write_config(struct pci_bus *bus, unsigned int devfn,
switch (len) {
case 1:
out_8(addr, val);
- (void) in_8(addr);
break;
case 2:
out_le16(addr, val);
- (void) in_le16(addr);
break;
default:
out_le32(addr, val);
- (void) in_le32(addr);
break;
}
return PCIBIOS_SUCCESSFUL;
@@ -268,15 +265,12 @@ static int u3_ht_write_config(struct pci_bus *bus, unsigned int devfn,
switch (len) {
case 1:
out_8(addr, val);
- (void) in_8(addr);
break;
case 2:
out_le16(addr, val);
- (void) in_le16(addr);
break;
default:
out_le32(addr, val);
- (void) in_le32(addr);
break;
}
return PCIBIOS_SUCCESSFUL;
@@ -376,15 +370,12 @@ static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
switch (len) {
case 1:
out_8(addr, val);
- (void) in_8(addr);
break;
case 2:
out_le16(addr, val);
- (void) in_le16(addr);
break;
default:
out_le32(addr, val);
- (void) in_le32(addr);
break;
}
return PCIBIOS_SUCCESSFUL;
--
1.5.2.4
^ permalink raw reply related
* Re: Fix small race in 44x tlbie function
From: Josh Boyer @ 2007-08-09 0:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <1186614089.938.207.camel@localhost.localdomain>
On Thu, Aug 09, 2007 at 09:01:29AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> > On Wed, 8 Aug 2007 20:43:25 +0000 (UTC)
> > Hollis Blanchard <hollisb@us.ibm.com> wrote:
> >
> > > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > > >
> > > > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > > > inhibiting interrupts (even critical and debug interrupts) across the
> > > > relevant instructions.
> > >
> > > How could a critical or debug interrupt modify the contents of MMUCR?
> >
> > Interrupts from UICs can be configured as critical. If one of those
> > triggers, (or any other CE triggers) and causes a tlb miss, you have a
> > race. The watchdog timer interrupt also is a CE IIRC.
> >
> > CE and DE are admittedly a much smaller race, but still possible.
> > Masking EE off is the largest one.
>
> There is a much bigger problem if CEs can do tlb misses though... they
> can interrupt the tlb miss handler itself, either between the two halves
> of a tlb write, or between the write to MMUCR and the write to the tlb,
> and I suspect both cases will cause trouble.
Yes.
> We might want to check if we were in the TLB miss handler upon return
> from the CE and MCE handlers, and in this case, restart them (just
> return to the faulting instruction, that is use srr0 instead of
> csrr0/mcsrr0).
Something should be looked at, yeah.
josh
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Benjamin Herrenschmidt @ 2007-08-08 23:30 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1186611069.765.13.camel@basalt>
On Wed, 2007-08-08 at 17:11 -0500, Hollis Blanchard wrote:
> On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> > On Wed, 8 Aug 2007 20:43:25 +0000 (UTC)
> > Hollis Blanchard <hollisb@us.ibm.com> wrote:
> >
> > > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > > >
> > > > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > > > inhibiting interrupts (even critical and debug interrupts) across the
> > > > relevant instructions.
> > >
> > > How could a critical or debug interrupt modify the contents of MMUCR?
> >
> > Interrupts from UICs can be configured as critical. If one of those
> > triggers, (or any other CE triggers) and causes a tlb miss, you have a
> > race. The watchdog timer interrupt also is a CE IIRC.
>
> By "causes a tlb miss", you mean the interrupt handler associated with
> the critical-priority UIC interrupt performs MMIO which causes a TLB
> miss? Regular code couldn't cause a TLB miss AFAICS, since the kernel is
> always mapped, and an interrupt handler doesn't access userspace.
ioremap is an example, vmalloc space is another...
Ben.
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Josh Boyer @ 2007-08-08 23:41 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1186611069.765.13.camel@basalt>
On Wed, Aug 08, 2007 at 05:11:09PM -0500, Hollis Blanchard wrote:
> On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> > On Wed, 8 Aug 2007 20:43:25 +0000 (UTC)
> > Hollis Blanchard <hollisb@us.ibm.com> wrote:
> >
> > > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > > >
> > > > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > > > inhibiting interrupts (even critical and debug interrupts) across the
> > > > relevant instructions.
> > >
> > > How could a critical or debug interrupt modify the contents of MMUCR?
> >
> > Interrupts from UICs can be configured as critical. If one of those
> > triggers, (or any other CE triggers) and causes a tlb miss, you have a
> > race. The watchdog timer interrupt also is a CE IIRC.
>
> By "causes a tlb miss", you mean the interrupt handler associated with
> the critical-priority UIC interrupt performs MMIO which causes a TLB
> miss? Regular code couldn't cause a TLB miss AFAICS, since the kernel is
> always mapped, and an interrupt handler doesn't access userspace.
Yes.
josh
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Benjamin Herrenschmidt @ 2007-08-08 23:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20070808162951.46491bc7@weaponx.rchland.ibm.com>
On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> On Wed, 8 Aug 2007 20:43:25 +0000 (UTC)
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
>
> > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > >
> > > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > > inhibiting interrupts (even critical and debug interrupts) across the
> > > relevant instructions.
> >
> > How could a critical or debug interrupt modify the contents of MMUCR?
>
> Interrupts from UICs can be configured as critical. If one of those
> triggers, (or any other CE triggers) and causes a tlb miss, you have a
> race. The watchdog timer interrupt also is a CE IIRC.
>
> CE and DE are admittedly a much smaller race, but still possible.
> Masking EE off is the largest one.
There is a much bigger problem if CEs can do tlb misses though... they
can interrupt the tlb miss handler itself, either between the two halves
of a tlb write, or between the write to MMUCR and the write to the tlb,
and I suspect both cases will cause trouble.
We might want to check if we were in the TLB miss handler upon return
from the CE and MCE handlers, and in this case, restart them (just
return to the faulting instruction, that is use srr0 instead of
csrr0/mcsrr0).
Ben.
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Benjamin Herrenschmidt @ 2007-08-08 22:55 UTC (permalink / raw)
To: Alexandros Kostopoulos; +Cc: linuxppc-dev
In-Reply-To: <op.twqvg3i0nhx3hy@phoenix>
On Wed, 2007-08-08 at 17:21 +0300, Alexandros Kostopoulos wrote:
> I've noticed the following: In function pci_process_bridge_OF_ranges, when
> parsing the ranges for MEM and I/O space, the res->start for mem is
> correctly set to ranges[na+2], which is the cpu address in the ranges
> property. However, in I/O related code, res->start is set to ranges[2],
> which is in the PCI address field of the ranges property (and in my case
> is 0, as is also for the mpc8272ads case as well). Thus, the res->start of
> the I/O of the bridge is 0, which leads to the first device with I/O space
> (a davicom ethernet device) been also assigned a I/O region starting at 0.
> Finally, the dmfe (davicom ethernet driver over PCI) fails with "dmfe: I/O
> base is zero". So, is the implementation of pci_process_bridge_OF_ranges
> correct ? shouldn't res->start = ranges[na+2] for I/O as well?
The current code indeed assumes that IO space of a PCI host bridges starts
at 0 local always. We "fixed" that in the 64 bits variant but not the 32 bits
one (yet...).
Note that if we're going to fix it, we probably also need to change various
bits of resource fixup code as well that makes that assumption.
Might be worth trying making more of that stuff common between 32 and 64
bits (I hear the noise of people trying to get me merge the pci code .. :-)
Ben.
^ permalink raw reply
* [PATCH] 85xxCDS: Fix building without PCI.
From: Randy Vinson @ 2007-08-08 22:48 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev@ozlabs.org
>From 32ad910d7d88e754102f3101b8869c4ca68efb53 Mon Sep 17 00:00:00 2001
From: Randy Vinson <rvinson@mvista.com>
Date: Wed, 8 Aug 2007 15:45:58 -0700
Subject: [PATCH] 85xxCDS: Fix building without PCI.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index d7ee380..f5f5d39 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -335,10 +335,10 @@ define_machine(mpc85xx_cds) {
.get_irq = mpic_get_irq,
#ifdef CONFIG_PCI
.restart = mpc85xx_cds_restart,
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
#else
.restart = mpc85xx_restart,
#endif
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
- .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
};
--
1.5.3.rc2.22.g69a9b
^ permalink raw reply related
* Re: [PATCH 6/6] pseries: eliminate global var
From: Linas Vepstas @ 2007-08-08 22:22 UTC (permalink / raw)
To: Nathan Lynch; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070808215714.GB10114@localdomain>
On Wed, Aug 08, 2007 at 04:57:14PM -0500, Nathan Lynch wrote:
> Linas Vepstas wrote:
> > +
> > +#ifdef CONFIG_PPC_PSERIES
> > +extern int pSeries_nvram_init(void);
> > +extern int nvram_write_error_log(char * buff, int length,
> > + unsigned int err_type, unsigned int err_seq);
> > +extern int nvram_read_error_log(char * buff, int length,
> > + unsigned int * err_type, unsigned int *err_seq);
> > +extern int nvram_clear_error_log(void);
> > +#endif /* CONFIG_PPC_PSERIES */
>
> Declarations need not be #ifdef'd.
Ah, I thought that would be cleaner ... should I resubmit,
the patch, or does it matter that much?
--linas
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Alexandros Kostopoulos @ 2007-08-08 22:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <46BA1FD2.4000705@freescale.com>
> No, because as I said, res->start is relative to the start of IO-space.
> The in/out functions add isa_io_base to the address.
>
Hi Scott,
please allow me to insist a little bit more on this.
1. As far as the device tree is concerned, it is defined that the first 3
numbers in every line of the ranges property (for our case, with #address-
cells=3) is the PCI address of the device (in this case, host bridge), the
next one is the local bus base address and the last two the local region
size. In the case of memory space, res->start for the host bridge takes as a
value ranges[3], which is actually the local bus base address. Why does the
code for IO space uses ranges[2]. Shouldn't these two use the same field of
the corresponding ranges property line?
2. As far as isa_io_base is concerned: When primary (what does this actually
mean? primary PCI bus ?) is 1, then indeed
isa_io_base=ranges[na+2]=ranges[3] (in this case) as it should (while res-
>start=ranges[2] for some reason I don't understand, as I said earlier). And
this is indeed added in the i/o address of the device during in/out
operations. However, the driver I use, drivers/net/tulip/dmfe.c, actually
checks whether res->start for the PCI device is zero, and if it is so, it
fails. So, assuming that the pci_process_OF_bridges code is correct as is,
then there is some problem with the driver? Because the same driver worked in
arch/ppc, which makes me think that there, res->start was NOT 0, but was
already offset to the actual I/O space of the local bus.
I would really appreciate your comments (and forgive me for insisting on this
:) )
Alex
> > Because, currently, based on what I've
> > described in my previous mail, it gets set to 0. It seems to me like a
matter
> > of incorrect parsing of the device tree from
pci_process_bridge_OF_ranges()
> > for IO space.
>
> It is not, at least not in this case. It does appear to be ignoring the
> possibility that it needs to do further translation of the address
> through parent buses, though.
>
> -Scott
>
--
^ permalink raw reply
* Re: [PATCH 1/6] pseries: avoid excess rtas calls
From: Linas Vepstas @ 2007-08-08 22:20 UTC (permalink / raw)
To: Nathan Lynch; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070808215738.GC10114@localdomain>
On Wed, Aug 08, 2007 at 04:57:39PM -0500, Nathan Lynch wrote:
> Linas Vepstas wrote:
> >
> > We don't need to look up the rtas event token once per
> > cpu per second. This avoids some misc string ops and
> > rtas calls and provides some minor performance improvement.
>
> It does not avoid any calls to RTAS. (rtas_token merely looks up
> properties under the /rtas node.)
Right. I'd vaguely known but forgotten that of_get_property didn't
actually turn into an rtas call.
> Otherwise, looks okay.
Should I resubmit with modified commit message, or does anyone care?
--linas
^ permalink raw reply
* Re: Fedora 7 on a non FPU system
From: Michael Brian Willis @ 2007-08-08 22:18 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <46B8E76F.3020403@anagramm.de>
On Tue, 2007-08-07 at 23:43 +0200, Clemens Koller wrote:
> You can either use FPU emulation or do the floating point stuff on the e500
> core's SPE (Signal Processing Engine) which is AFAIK not supported by any
> major distribution.
I do have FPU emulation enabled in the kernel. I was able to get a
Yellow Dog 4.1 root filesystem to work. However when I move up to
YellowDog 5.0 or to Fedora 7, I have system lags. (For example, shortly
after boot-up, date and top do not behave properly. For example top
displays "nan" values. However a few minutes after boot up everything
seems fine.)
I suspect that the newest distribution versions rely more heavily on
full FPU functionality while the older distributions don't. Which might
be why older distributions seem to work a little better.
> CRUX - not a "major distro", because it's targeted at "experienced Linux users".
> I am running my selfmade version of "embedded CRUX" on my MPC8540 Boards
> based on http://cruxppc.sunsite.dk/wp/index.php which now fully supports
> the e500 core features.
Thanks, I will start looking into using CRUX.
> I bootstrapped the toolchain (binutils, (e)glibc, gcc and friends) from scratch
Did you find any documentation that was helpful when you did this?
I'm not really sure how to start this process. Do you basically just
download binutils, glibc etc... and compile them using the gcc that
comes with CRUX?
Thanks again for all your help!
Regards,
Michael Willis
Applied Research Labs-University of Texas
willis@arlut.utexas.edu
^ permalink raw reply
* Re: ML403 / ALSA driver for AC97 Controller
From: Timur Tabi @ 2007-08-08 22:16 UTC (permalink / raw)
To: Joachim Förster; +Cc: linuxppc-embedded
In-Reply-To: <1186300813.5534.33.camel@localhost>
On Aug 5, 2007, at 4:00 AM, Joachim F=F6rster wrote:
> Meanwhile, I had a _very_ short look into ASoC ... and I don't really
> know ... My driver already uses the AC97 Layer of ALSA, so in some way
> the codec is already separated from the controller. Xilinx' AC97
> Controller Reference does have some very bad impact on the codec which
> forced me to implement codec register shadowing ... hmmmm, I have to
> look at it (ASoC) again - as soon as there is more (free)time ...
I've written an ASoC driver (not yet published, though). ASoC is =20
good when the codec is mix-and-match with the transport mechanism (eg =20=
I2S or AC97), and the transport hardware is physically separate from =20
the DMA hardware. Now, I don't know much about AC97 or the AC97 =20
driver in ALSA, so I can't tell you whether AC97 drivers in general =20
should be ASoC.
I'm on vacation this week. Can you send me an email with a pointer =20
to your source code, because I think I lost the original post on this =20=
thread? I'll take a look at it next week and let you know whether =20
you should consider ASoC.
Also, ALSA patches should be posted against the head of the ALSA =20
Mercurial tree, not Linus' 2.6.22 branch, which is already outdated =20
by ALSA standards. And we should be having this conversation on alsa-=20=
devel.
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Hollis Blanchard @ 2007-08-08 22:11 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070808162951.46491bc7@weaponx.rchland.ibm.com>
On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> On Wed, 8 Aug 2007 20:43:25 +0000 (UTC)
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
>
> > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > >
> > > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > > inhibiting interrupts (even critical and debug interrupts) across the
> > > relevant instructions.
> >
> > How could a critical or debug interrupt modify the contents of MMUCR?
>
> Interrupts from UICs can be configured as critical. If one of those
> triggers, (or any other CE triggers) and causes a tlb miss, you have a
> race. The watchdog timer interrupt also is a CE IIRC.
By "causes a tlb miss", you mean the interrupt handler associated with
the critical-priority UIC interrupt performs MMIO which causes a TLB
miss? Regular code couldn't cause a TLB miss AFAICS, since the kernel is
always mapped, and an interrupt handler doesn't access userspace.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [Cbe-oss-dev] Export DCR symbols - resubmitting
From: Arnd Bergmann @ 2007-08-08 21:58 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Linuxppc-dev, paulus, Murali Iyer
In-Reply-To: <1186609609.4053.19.camel@macg5-2.rchland.ibm.com>
On Wednesday 08 August 2007, Murali Iyer wrote:
> This patch is needed in order to compile kernel modules that uses some
> of the DCR functions. For example, compiling powerpc emac driver as
> module it is needed.
Ok, thanks!
> Arnd, Dennis Spathis pinged me about this today and I thought it was a
> closed issue but still open. If you find it okay please upstream it or
> let me know if any modifications needed. Thanks.
Paul, please apply in either for-2.6.24 or as a fix for 2.6.23. The patch
is obviously correct, as the now exported functions were meant to be
used by modules in the first place. No code in the kernel currently
uses it, so it's not urgent.
> Signed-off-by: Murali Iyer <mniyer@us.ibm.com>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: [PATCH 1/6] pseries: avoid excess rtas calls
From: Nathan Lynch @ 2007-08-08 21:57 UTC (permalink / raw)
To: Linas Vepstas; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070808200115.GA20134@austin.ibm.com>
Linas Vepstas wrote:
>
> We don't need to look up the rtas event token once per
> cpu per second. This avoids some misc string ops and
> rtas calls and provides some minor performance improvement.
It does not avoid any calls to RTAS. (rtas_token merely looks up
properties under the /rtas node.)
Otherwise, looks okay.
^ permalink raw reply
* Re: [PATCH 6/6] pseries: eliminate global var
From: Nathan Lynch @ 2007-08-08 21:57 UTC (permalink / raw)
To: Linas Vepstas; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070808200713.GF20134@austin.ibm.com>
Linas Vepstas wrote:
> --- linux-2.6.22-git2.orig/include/asm-powerpc/nvram.h 2007-07-08 18:32:17.000000000 -0500
> +++ linux-2.6.22-git2/include/asm-powerpc/nvram.h 2007-08-08 13:34:27.000000000 -0500
> @@ -62,14 +62,19 @@ struct nvram_partition {
> unsigned int index;
> };
>
> -
> -extern int nvram_write_error_log(char * buff, int length, unsigned int err_type);
> -extern int nvram_read_error_log(char * buff, int length, unsigned int * err_type);
> -extern int nvram_clear_error_log(void);
> extern struct nvram_partition *nvram_find_partition(int sig, const char *name);
>
> -extern int pSeries_nvram_init(void);
> extern int mmio_nvram_init(void);
> +
> +#ifdef CONFIG_PPC_PSERIES
> +extern int pSeries_nvram_init(void);
> +extern int nvram_write_error_log(char * buff, int length,
> + unsigned int err_type, unsigned int err_seq);
> +extern int nvram_read_error_log(char * buff, int length,
> + unsigned int * err_type, unsigned int *err_seq);
> +extern int nvram_clear_error_log(void);
> +#endif /* CONFIG_PPC_PSERIES */
Declarations need not be #ifdef'd.
^ 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