On Thu, Apr 26, 2007 at 09:19:34AM -0700, H. Peter Anvin wrote:
> Why wouldn't that be permitted? It, in fact, happens all the time (the
> host bridge withdraws the GNT# line and raises STOP#, which does a
> Termination With Data of the bus transfer.) This is a normal event and
> if you can't
On Thu, Apr 26, 2007 at 09:19:34AM -0700, H. Peter Anvin wrote:
Why wouldn't that be permitted? It, in fact, happens all the time (the
host bridge withdraws the GNT# line and raises STOP#, which does a
Termination With Data of the bus transfer.) This is a normal event and
if you can't handle
Lennart Sorensen wrote:
>
> My suspicision (although it is only that) is that the PXA255 trying to
> access memory may cause interruptions in PCI bus master transfers, which
> is of course not permitted by the PCI spec (at least the way I read it).
Why wouldn't that be permitted? It, in fact,
Jeff Garzik wrote:
Kok, Auke wrote:
Jeff, I think I should just push the IO patch and the sbit code to
Andrew and have it sit there. That is a vastly larger test resource than
we currently can generate for this. If needed we just let is sit there
for a whole release cycle before moving it to
Kok, Auke wrote:
Jeff Garzik wrote:
Lennert Buytenhek wrote:
This is all a while ago now, but wasn't the e100 S-bit patch originally
written by Intel people in response to the very same quote by Russell
King that you've quoted above?
Correct.
I just wanted to make sure it didn't kill any
Jeff Garzik wrote:
Lennert Buytenhek wrote:
This is all a while ago now, but wasn't the e100 S-bit patch originally
written by Intel people in response to the very same quote by Russell
King that you've quoted above?
Correct.
I just wanted to make sure it didn't kill any boxes.
Neither did
Lennert Buytenhek wrote:
This is all a while ago now, but wasn't the e100 S-bit patch originally
written by Intel people in response to the very same quote by Russell
King that you've quoted above?
Correct.
I just wanted to make sure it didn't kill any boxes.
Jeff
-
To unsubscribe
On Thu, Apr 26, 2007 at 09:41:22AM -0400, David Acker wrote:
> Here is a quote from Russell that describes what I believe is the main
> problem:
> http://www-gatago.com/linux/kernel/15457063.html
> "
> Has e100 actually been fixed to use the PCI DMA API correctly yet?
> Looking at it, it doesn't
Lennart Sorensen wrote:
Well the IT8152G+PXA255 combination used on the SBC we tried a couple of
years ago did not work. The PCI bus had errors and the SBC maker gave
up trying to fix it. We switched to a Geode SC1200 based board instead
which works fine PCI wise.
I don't think this is it.
Lennart Sorensen wrote:
Well the IT8152G+PXA255 combination used on the SBC we tried a couple of
years ago did not work. The PCI bus had errors and the SBC maker gave
up trying to fix it. We switched to a Geode SC1200 based board instead
which works fine PCI wise.
I don't think this is it.
On Thu, Apr 26, 2007 at 09:41:22AM -0400, David Acker wrote:
Here is a quote from Russell that describes what I believe is the main
problem:
http://www-gatago.com/linux/kernel/15457063.html
Has e100 actually been fixed to use the PCI DMA API correctly yet?
Looking at it, it doesn't look
Lennert Buytenhek wrote:
This is all a while ago now, but wasn't the e100 S-bit patch originally
written by Intel people in response to the very same quote by Russell
King that you've quoted above?
Correct.
I just wanted to make sure it didn't kill any boxes.
Jeff
-
To unsubscribe
Jeff Garzik wrote:
Lennert Buytenhek wrote:
This is all a while ago now, but wasn't the e100 S-bit patch originally
written by Intel people in response to the very same quote by Russell
King that you've quoted above?
Correct.
I just wanted to make sure it didn't kill any boxes.
Neither did
Kok, Auke wrote:
Jeff Garzik wrote:
Lennert Buytenhek wrote:
This is all a while ago now, but wasn't the e100 S-bit patch originally
written by Intel people in response to the very same quote by Russell
King that you've quoted above?
Correct.
I just wanted to make sure it didn't kill any
Jeff Garzik wrote:
Kok, Auke wrote:
Jeff, I think I should just push the IO patch and the sbit code to
Andrew and have it sit there. That is a vastly larger test resource than
we currently can generate for this. If needed we just let is sit there
for a whole release cycle before moving it to
Lennart Sorensen wrote:
My suspicision (although it is only that) is that the PXA255 trying to
access memory may cause interruptions in PCI bus master transfers, which
is of course not permitted by the PCI spec (at least the way I read it).
Why wouldn't that be permitted? It, in fact,
On Mon, Apr 16, 2007 at 11:07:36AM -0400, David Acker wrote:
> Lennart Sorensen wrote:
> >Which PCI host controller are you using with the PXA255? We tried using
> >a PXA255 based system with a PCI controller a couple of years ago and
> >have to change to a different cpu in the end due to the PCI
On Mon, Apr 16, 2007 at 11:07:36AM -0400, David Acker wrote:
Lennart Sorensen wrote:
Which PCI host controller are you using with the PXA255? We tried using
a PXA255 based system with a PCI controller a couple of years ago and
have to change to a different cpu in the end due to the PCI
Lennart Sorensen wrote:
Which PCI host controller are you using with the PXA255? We tried using
a PXA255 based system with a PCI controller a couple of years ago and
have to change to a different cpu in the end due to the PCI controller
simply not being valid PCI. The PXA255 wasn't designed
Lennart Sorensen wrote:
Which PCI host controller are you using with the PXA255? We tried using
a PXA255 based system with a PCI controller a couple of years ago and
have to change to a different cpu in the end due to the PCI controller
simply not being valid PCI. The PXA255 wasn't designed
On Thu, Mar 29, 2007 at 01:17:38AM -0400, David Acker wrote:
> I have a pxa255 based system with PCI added to it. The e100 would have
> memory corruption in its receive buffers detected by slab debugging
> unless I put in the patch to use the S-bit.
>
> Here is a link to the patch posting:
>
On Thu, Mar 29, 2007 at 01:17:38AM -0400, David Acker wrote:
I have a pxa255 based system with PCI added to it. The e100 would have
memory corruption in its receive buffers detected by slab debugging
unless I put in the patch to use the S-bit.
Here is a link to the patch posting:
Kok, Auke wrote:
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board.
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp2350 works both with
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp2350 works both with
Kok, Auke wrote:
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board.
26 matches
Mail list logo
