* 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
* Export DCR symbols - resubmitting
From: Murali Iyer @ 2007-08-08 21:46 UTC (permalink / raw)
To: Linuxppc-dev, cbe-oss-dev
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
Hi,
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.
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.
--
Bye,
Murali
[-- Attachment #2: export-dcr-symbols.diff --]
[-- Type: text/x-patch, Size: 1384 bytes --]
Subject: Export few DCR symbols for kernel modules
In order to compile drivers as modules that uses some of the
DCR functions, we need to export the symbols. Example, EMAC
driver and other drivers that are under development uses these
some of the functions.
This patch applies cleanly against 2.6.23-rc1 kernel and ready
for inclusion.
From: Murali Iyer
Signed-off-by: Murali Iyer <mniyer@us.ibm.com>
Index: linux-2.6.22/arch/powerpc/sysdev/dcr.c
===================================================================
--- linux-2.6.22.orig/arch/powerpc/sysdev/dcr.c
+++ linux-2.6.22/arch/powerpc/sysdev/dcr.c
@@ -33,6 +33,7 @@ unsigned int dcr_resource_start(struct d
return dr[index * 2];
}
+EXPORT_SYMBOL_GPL(dcr_resource_start);
unsigned int dcr_resource_len(struct device_node *np, unsigned int index)
{
@@ -44,6 +45,7 @@ unsigned int dcr_resource_len(struct dev
return dr[index * 2 + 1];
}
+EXPORT_SYMBOL_GPL(dcr_resource_len);
#ifndef CONFIG_PPC_DCR_NATIVE
@@ -122,6 +124,7 @@ dcr_host_t dcr_map(struct device_node *d
ret.token -= dcr_n * ret.stride;
return ret;
}
+EXPORT_SYMBOL_GPL(dcr_map);
void dcr_unmap(dcr_host_t host, unsigned int dcr_n, unsigned int dcr_c)
{
@@ -133,5 +136,6 @@ void dcr_unmap(dcr_host_t host, unsigned
iounmap(h.token);
h.token = NULL;
}
+EXPORT_SYMBOL_GPL(dcr_unmap);
#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Josh Boyer @ 2007-08-08 21:29 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <f9d9td$nov$1@sea.gmane.org>
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.
josh
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Hollis Blanchard @ 2007-08-08 20:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070807042050.GJ13522@localhost.localdomain>
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?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Cypress C67X00 driver question
From: Robertson, Joseph M. @ 2007-08-08 20:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]
Hi all,
First off big thanks to the guys working on the Cypress USB C67X00 driver!
Without them I would not even be this far.
But my question for them is: How are you guys initializing the Cypress chip?
It looks like the driver is expecting the cypress to be programmed and ready.
I have a FPGA design with a Cypress C67300 which has no eeprom or cpld, so it just comes up blank in coprocessor mode.
I believe I need to 'program' the chip and kick it before the driver loads is that right?
Has anyone ever done this before?
The Cypress docs do not even begin to provide a simple example of the minimum registers to set
before the usb will 'work'. I just need 2 hosts.
Thanks,
Joe Robertson
x8259
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 2417 bytes --]
^ permalink raw reply
* [PATCH 6/6] pseries: eliminate global var
From: Linas Vepstas @ 2007-08-08 20:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20070808200615.GE20134@austin.ibm.com>
Eliminate the use of error_log_cnt as a global var shared across
differnt directories. Pass it as a subroutine arg instead.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/kernel/nvram_64.c | 10 +++++-----
arch/powerpc/platforms/pseries/rtasd.c | 7 ++++---
include/asm-powerpc/nvram.h | 15 ++++++++++-----
3 files changed, 19 insertions(+), 13 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/nvram_64.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/nvram_64.c 2007-08-08 12:21:16.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/nvram_64.c 2007-08-08 12:24:01.000000000 -0500
@@ -38,8 +38,6 @@ static struct nvram_partition * nvram_pa
static long nvram_error_log_index = -1;
static long nvram_error_log_size = 0;
-extern volatile int error_log_cnt;
-
struct err_log_info {
int error_type;
unsigned int seq_num;
@@ -627,7 +625,8 @@ void __exit nvram_cleanup(void)
* sequence #: The unique sequence # for each event. (until it wraps)
* error log: The error log from event_scan
*/
-int nvram_write_error_log(char * buff, int length, unsigned int err_type)
+int nvram_write_error_log(char * buff, int length,
+ unsigned int err_type, unsigned int error_log_cnt)
{
int rc;
loff_t tmp_index;
@@ -665,7 +664,8 @@ int nvram_write_error_log(char * buff, i
*
* Reads nvram for error log for at most 'length'
*/
-int nvram_read_error_log(char * buff, int length, unsigned int * err_type)
+int nvram_read_error_log(char * buff, int length,
+ unsigned int * err_type, unsigned int * error_log_cnt)
{
int rc;
loff_t tmp_index;
@@ -691,7 +691,7 @@ int nvram_read_error_log(char * buff, in
return rc;
}
- error_log_cnt = info.seq_num;
+ *error_log_cnt = info.seq_num;
*err_type = info.error_type;
return 0;
Index: linux-2.6.22-git2/include/asm-powerpc/nvram.h
===================================================================
--- 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 */
+
#endif /* __KERNEL__ */
/* PowerMac specific nvram stuffs */
Index: linux-2.6.22-git2/arch/powerpc/platforms/pseries/rtasd.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/platforms/pseries/rtasd.c 2007-08-08 12:21:16.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/platforms/pseries/rtasd.c 2007-08-08 12:50:40.000000000 -0500
@@ -56,7 +56,7 @@ static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
static int no_more_logging;
-volatile int error_log_cnt = 0;
+static int error_log_cnt;
/*
* Since we use 32 bit RTAS, the physical address of this must be below
@@ -218,7 +218,7 @@ void pSeries_log_error(char *buf, unsign
/* Write error to NVRAM */
if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
- nvram_write_error_log(buf, len, err_type);
+ nvram_write_error_log(buf, len, err_type, error_log_cnt);
/*
* rtas errors can occur during boot, and we do want to capture
@@ -412,7 +412,8 @@ static int rtasd(void *unused)
/* See if we have any error stored in NVRAM */
memset(logdata, 0, rtas_error_log_max);
- rc = nvram_read_error_log(logdata, rtas_error_log_max, &err_type);
+ rc = nvram_read_error_log(logdata, rtas_error_log_max,
+ &err_type, &error_log_cnt);
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
^ 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