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 <redacted>
---
arch/powerpc/platforms/maple/pci.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-08-09 00:55:40
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 <redacted>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Thanks ! Care to fix powermac too ? :-)
Cheers,
Ben.
From: David Gibson <hidden> Date: 2007-08-09 03:05:55
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
On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
quoted
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.
From: David Gibson <hidden> Date: 2007-08-09 04:18:03
On Wed, Aug 08, 2007 at 11:16:32PM -0500, Nathan Lynch wrote:
David Gibson wrote:
quoted
On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
quoted
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
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,
None of the PCI interfaces on the U3 or U4 bridges have that
problem as far as I know. I think the workaround was copied
from code for older Apple bridges?
but that a sync after the write (implied by
releasing pci_lock in the generic pci code) should suffice for those.
I don't see how a sync could help here at all, not more than
an eieio anyway?
Segher
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,
None of the PCI interfaces on the U3 or U4 bridges have that
problem as far as I know. I think the workaround was copied
from code for older Apple bridges?
Okay, then the change should be fine for maple.
quoted
but that a sync after the write (implied by
releasing pci_lock in the generic pci code) should suffice for those.
I don't see how a sync could help here at all, not more than
an eieio anyway?
Alright, well, maybe take it up with Ben when I post the patch for
powermac, since that's where it could actually matter.
The pasemi pci configuration space write method reads 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.
Remove the unnecessary reads from pa_pxp_write_config.
Signed-off-by: Nathan Lynch <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
The powermac 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.
Remove the unnecessary reads from macrisc_write_config,
u3_ht_write_config, and u4_pcie_write_config.
Signed-off-by: Nathan Lynch <redacted>
---
arch/powerpc/platforms/powermac/pci.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
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,
None of the PCI interfaces on the U3 or U4 bridges have that
problem as far as I know. I think the workaround was copied
from code for older Apple bridges?
Okay, then the change should be fine for maple.
Yes. Of course, as usual, testing is needed, yada yada.
quoted
quoted
but that a sync after the write (implied by
releasing pci_lock in the generic pci code) should suffice for those.
I don't see how a sync could help here at all, not more than
an eieio anyway?
Alright, well, maybe take it up with Ben when I post the patch for
powermac, since that's where it could actually matter.
It should be fine on PowerMac as well -- all G5s use U3/U4,
the workaround is for certain older Apple bridge chips.
Segher
From: Olof Johansson <hidden> Date: 2007-08-11 23:41:22
On Thu, Aug 09, 2007 at 04:37:27PM -0500, Nathan Lynch wrote:
The pasemi pci configuration space write method reads 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.
Remove the unnecessary reads from pa_pxp_write_config.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-08-11 23:41:29
It should be fine on PowerMac as well -- all G5s use U3/U4,
the workaround is for certain older Apple bridge chips.
Yeah, remove them. The workaround that is needed afaik is really only
the one that reads back the -address- before accessing the data register
(and I think it's sill needed on U3), but it's unrelated to what that
patch changes.
As I said on IRC, I suspect those reads come from misguided attempts on
my part to avoid the processor itself posting those writes, since we
want config space access to be synchronous all the way. In that case,
however, a sync will do the job just fine to ensure the previous write
did hit the bridge.
Cheers,
Ben.