This patch adds a PCI device ID for the IT8152F/G
Advanced RISC-to-PCI Companion Chip.
Signed-off-by: Raphael Assenat <[email protected]>
--- linux-2.6.20/include/linux/pci_ids.h 2007-02-04 13:44:54.000000000 -0500
+++ linux-2.6.20-8d/include/linux/pci_ids.h 2007-02-09 15:00:38.000000000 -0500
@@ -1626,6 +1626,7 @@
#define PCI_VENDOR_ID_ROCKWELL 0x127A
#define PCI_VENDOR_ID_ITE 0x1283
+#define PCI_DEVICE_ID_ITE_8152 0x8152
#define PCI_DEVICE_ID_ITE_8211 0x8211
#define PCI_DEVICE_ID_ITE_8212 0x8212
#define PCI_DEVICE_ID_ITE_8872 0x8872
On Fri, Feb 09, 2007 at 03:14:05PM -0500, Raphael Assenat wrote:
> This patch adds a PCI device ID (0x8152) for the IT8152F/G
> Advanced RISC-to-PCI Companion Chip.
>
> --
> Raphael Assenat
> 8D Technologies Inc.
> This patch adds a PCI device ID for the IT8152F/G
> Advanced RISC-to-PCI Companion Chip.
>
> Signed-off-by: Raphael Assenat <[email protected]>
>
> --- linux-2.6.20/include/linux/pci_ids.h 2007-02-04 13:44:54.000000000 -0500
> +++ linux-2.6.20-8d/include/linux/pci_ids.h 2007-02-09 15:00:38.000000000 -0500
> @@ -1626,6 +1626,7 @@
> #define PCI_VENDOR_ID_ROCKWELL 0x127A
>
> #define PCI_VENDOR_ID_ITE 0x1283
> +#define PCI_DEVICE_ID_ITE_8152 0x8152
> #define PCI_DEVICE_ID_ITE_8211 0x8211
> #define PCI_DEVICE_ID_ITE_8212 0x8212
> #define PCI_DEVICE_ID_ITE_8872 0x8872
Oh that one. Anyone ever have a reliable PCI bus with one of these?
The one system on a board I have worked with in the past had so many
problems with the PCI bus that we have to switch to another board
instead. Too bad since the ARM cpu was much faster and better and
handling network traffic (we switched to a Geode SC1200 based board).
At the time my theory was that the cpu would interrupt DMA transfers
when it wanted access to system memory, which would break the PCI
transfers. But that was just my theory.
--
Len Sorensen
Lennart Sorensen wrote:
> On Fri, Feb 09, 2007 at 03:14:05PM -0500, Raphael Assenat wrote:
>
>>This patch adds a PCI device ID (0x8152) for the IT8152F/G
>>Advanced RISC-to-PCI Companion Chip.
>>
>>--
>>Raphael Assenat
>>8D Technologies Inc.
>
>
>>This patch adds a PCI device ID for the IT8152F/G
>>Advanced RISC-to-PCI Companion Chip.
>>
>>Signed-off-by: Raphael Assenat <[email protected]>
>>
>>--- linux-2.6.20/include/linux/pci_ids.h 2007-02-04 13:44:54.000000000 -0500
>>+++ linux-2.6.20-8d/include/linux/pci_ids.h 2007-02-09 15:00:38.000000000 -0500
>>@@ -1626,6 +1626,7 @@
>> #define PCI_VENDOR_ID_ROCKWELL 0x127A
>>
>> #define PCI_VENDOR_ID_ITE 0x1283
>>+#define PCI_DEVICE_ID_ITE_8152 0x8152
>> #define PCI_DEVICE_ID_ITE_8211 0x8211
>> #define PCI_DEVICE_ID_ITE_8212 0x8212
>> #define PCI_DEVICE_ID_ITE_8872 0x8872
>
>
> Oh that one. Anyone ever have a reliable PCI bus with one of these?
> The one system on a board I have worked with in the past had so many
> problems with the PCI bus that we have to switch to another board
> instead. Too bad since the ARM cpu was much faster and better and
> handling network traffic (we switched to a Geode SC1200 based board).
>
> At the time my theory was that the cpu would interrupt DMA transfers
> when it wanted access to system memory, which would break the PCI
> transfers. But that was just my theory.
Really? I have no idea if it's possible to get a reliable PCI bus or
not with this chip. Right now, we only use it for it's built-in OHCI
USB host controller and UART. You're making me hope I never have to
use it for interfacing a PCI card!
Best regards,
--
Raphael Assenat
8D Technologies Inc.
On Tue, Feb 13, 2007 at 09:45:54AM -0500, Raphael Assenat wrote:
> Really? I have no idea if it's possible to get a reliable PCI bus or
> not with this chip. Right now, we only use it for it's built-in OHCI
> USB host controller and UART. You're making me hope I never have to
> use it for interfacing a PCI card!
Well on the system on a board we were trying, using the development
baseboard from the same supplier, by simply doing a ping flood through
the onboard rtl8139 I managed to get corrupted ethernet packets fairly
frequently. The WAN cards (T1/E1) we were trying to make work with it
were much more upset by it. It could be bad enough corruption to cause
the chip on the card and the driver to get out of sync and just have no
idea what to do anymore. Given our mainboard works perfectly fine using
a Geode SC1200 instead of the PXA255 board, I can only figure the PCI
bus wasn't implemented correctly on that chip, unless PCI on arm is done
wrong in linux (I sure hope not). There doesn't seem to be very many
arm systems with PCI, so it's hard to tell. Now other than PCI the
system was wonderful. Fast, reliable, ran great even at high
temperatures, etc. Just couldn't get the stupid PCI bus to work.
--
Len Sorensen
On Tue, Feb 13, 2007 at 10:16:33AM -0500, Lennart Sorensen wrote:
> There doesn't seem to be very many
> arm systems with PCI, so it's hard to tell.
NetWinder, EBSA285 (which the NetWinder is a derivative of), the N2100,
etc are PCI based and are all well proven in the field.
However, I have come across issues with what I suspect are buggy
bridges - some southbridges require out of band cache control
signalling and don't behave properly if you don't provide this (despite
having modes to disable such signalling) and some PCMCIA bridges which
don't like delayed read responses from host bridges.
That said, I've an EBSA285 with Promise UDMA, 3com NIC, S3 VGA and a
plug-in southbridge card which has been running since about 1999 or so
and the only real data corruption problem I've heard of was when a track
on my Promise UDMA card was eaten by the sticky label resulting in silent
corruption of writes to the disks.
(I did consider replacing the Promise UDMA card, but the IT821x card
I bought to replace it didn't have all the pins on the chip soldered
down - to the extent that even a PC couldn't recognise the PCI card.
So I'm running on the assumption that the self-repaired Promise UDMA
card is all round going to be more reliable than the as yet unproven
IT821x card.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Feb 13, 2007 at 03:30:29PM +0000, Russell King wrote:
> On Tue, Feb 13, 2007 at 10:16:33AM -0500, Lennart Sorensen wrote:
> > There doesn't seem to be very many
> > arm systems with PCI, so it's hard to tell.
>
> NetWinder, EBSA285 (which the NetWinder is a derivative of), the N2100,
> etc are PCI based and are all well proven in the field.
Which PCI controller do they use?
> However, I have come across issues with what I suspect are buggy
> bridges - some southbridges require out of band cache control
> signalling and don't behave properly if you don't provide this (despite
> having modes to disable such signalling) and some PCMCIA bridges which
> don't like delayed read responses from host bridges.
Well certainly on the cpu board we were trying out, it didn't work,
whether it was a buggy PCI bridge, or a bad design I am not sure. I
suspect the chip.
> That said, I've an EBSA285 with Promise UDMA, 3com NIC, S3 VGA and a
> plug-in southbridge card which has been running since about 1999 or so
> and the only real data corruption problem I've heard of was when a track
> on my Promise UDMA card was eaten by the sticky label resulting in silent
> corruption of writes to the disks.
Ouch.
> (I did consider replacing the Promise UDMA card, but the IT821x card
> I bought to replace it didn't have all the pins on the chip soldered
> down - to the extent that even a PC couldn't recognise the PCI card.
> So I'm running on the assumption that the self-repaired Promise UDMA
> card is all round going to be more reliable than the as yet unproven
> IT821x card.)
And they shipped a card in that state?
--
Len Sorensen
On Tue, Feb 13, 2007 at 10:47:28AM -0500, Lennart Sorensen wrote:
> On Tue, Feb 13, 2007 at 03:30:29PM +0000, Russell King wrote:
> > On Tue, Feb 13, 2007 at 10:16:33AM -0500, Lennart Sorensen wrote:
> > > There doesn't seem to be very many
> > > arm systems with PCI, so it's hard to tell.
> >
> > NetWinder, EBSA285 (which the NetWinder is a derivative of), the N2100,
> > etc are PCI based and are all well proven in the field.
>
> Which PCI controller do they use?
NetWinder and EBSA285 are DC21285 (footbridge). The N2100 is IOP32x
based. As for gluing a PCI bridge to something not designed for PCI
(eg, a PXA255) I can't comment.
> > (I did consider replacing the Promise UDMA card, but the IT821x card
> > I bought to replace it didn't have all the pins on the chip soldered
> > down - to the extent that even a PC couldn't recognise the PCI card.
> > So I'm running on the assumption that the self-repaired Promise UDMA
> > card is all round going to be more reliable than the as yet unproven
> > IT821x card.)
>
> And they shipped a card in that state?
Indeed. :(
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: