Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-04 Thread Tejun Heo
Matt Sealey wrote: Well, let's put the class code as native since the chip is made native, in a platform file somewhere. Then, we can have a configuration option in the platform code which allows users to choose whether the IDE configuration is reworked to steer to a single IRQ or two IRQs.

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-04 Thread Matt Sealey
Tejun Heo wrote: I forgot about the PCI resource fix up done for legacy hosts. I think making the host legacy is the best way to take here considering that - no change for both ide and libata, just some fix up in platform code. ATA native/legacy thing doesn't mean much. It's just how the

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-04 Thread Tejun Heo
Hello, Matt. Matt Sealey wrote: Tejun Heo wrote: I forgot about the PCI resource fix up done for legacy hosts. I think making the host legacy is the best way to take here considering that - no change for both ide and libata, just some fix up in platform code. ATA native/legacy thing doesn't

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-03 Thread Tejun Heo
Matt Sealey wrote: I'm a litle confused here. Page 10 (4.2.1) so I just mask off bit 0 and bit 2 of the class prog-if byte and set it to compatible mode which will basically mean PCI mapped registers and two IRQs? This corresponds with the table on Page 7 (4.2.1.1).. Checked the Pegasos

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-03 Thread Matt Sealey
Tejun Heo wrote: Matt Sealey wrote: I'm a litle confused here. Page 10 (4.2.1) so I just mask off bit 0 and bit 2 of the class prog-if byte and set it to compatible mode which will basically mean PCI mapped registers and two IRQs? This corresponds with the table on Page 7 (4.2.1.1)..

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-03 Thread Alan Cox
We can't make the controller TRULY legacy since there is not any good way of mapping the IDE/BMDMA registers into the lower kilobyte or so of memory - obviously PPC has no io address space, it's all memory mapped, so the lower kilobyte of IO ports is really the CPU zero page. It's not a good

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-03 Thread Matt Sealey
Well, let's put the class code as native since the chip is made native, in a platform file somewhere. Then, we can have a configuration option in the platform code which allows users to choose whether the IDE configuration is reworked to steer to a single IRQ or two IRQs. That way they can choose

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-03 Thread Matt Sealey
Yes but the libata driver doesn't check the config register, it checks the class code, no? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Jeff Garzik wrote: Matt Sealey wrote: The old Via driver checked the host controller configuration space, rather than trust the

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-07-03 Thread Jeff Garzik
Matt Sealey wrote: Yes but the libata driver doesn't check the config register, it checks the class code, no? Talking about the end result... - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-06-23 Thread Alan Cox
On Sat, 23 Jun 2007 01:26:06 +0100 Matt Sealey [EMAIL PROTECTED] wrote: There are several different ways you can set it up from having a single IRQ (true PCI native), to using PCI register access but with IRQ routing through a certain pair of interrupts (14/15 or 10/11) or by having real

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-06-23 Thread Matt Sealey
Alan Cox wrote: On Sat, 23 Jun 2007 01:26:06 +0100 The simplest way is probably to load the pci class and programming interface bits correctly for the device to match how your IRQ setup has been arranged. See page 78 of the VIA 8231 spec if you have it, and load the programming class in the

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-06-23 Thread Alan Cox
On Sat, 23 Jun 2007 10:33:46 +0100 Matt Sealey [EMAIL PROTECTED] wrote: Alan Cox wrote: On Sat, 23 Jun 2007 01:26:06 +0100 The simplest way is probably to load the pci class and programming interface bits correctly for the device to match how your IRQ setup has been arranged. See

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-06-23 Thread Matt Sealey
I'm a litle confused here. Page 10 (4.2.1) so I just mask off bit 0 and bit 2 of the class prog-if byte and set it to compatible mode which will basically mean PCI mapped registers and two IRQs? This corresponds with the table on Page 7 (4.2.1.1).. Checked the Pegasos IDE class code and in the

how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-06-22 Thread Matt Sealey
Just bringing this up again as it's about that time of year. There's an issue with some Via southbridges (the only notable and confirmed example I have being the VT8231 on the PegasosPPC) which can be configured such that they report that they are in PCI Native Mode, but in fact handle (and

Re: how to handle pata_via when controller not in fully-pci-native mode (two irqs?)

2007-06-22 Thread Jeff Garzik
Matt Sealey wrote: Just bringing this up again as it's about that time of year. There's an issue with some Via southbridges (the only notable and confirmed example I have being the VT8231 on the PegasosPPC) which can be configured such that they report that they are in PCI Native Mode, but in