On 11 Dec 02 at 17:29, Alan Cox wrote:
> Ok this seems to be the problem
>
> 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if
> 8a [Master SecP PriP])
> Subsystem: Toshiba America Info Systems: Unknown device 0001
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at cff8 [size=8]
> Region 1: I/O ports at cff4 [size=4]
> Region 2: I/O ports at cfe8 [size=8]
> Region 3: I/O ports at cfe4 [size=4]
>
>
> The hardware isnt at the normal ide base addresse, yet the chip is
> reporting that it isnt in native mode. As far as I can see this
> configuration isnt allowed.
An old, pre-BMDMA, "PCI IDE Controller Specification, rev 1.0, 3/4/94"
I have here says on page 3, in chapter 2.4, second and third paragraphs say:
-- When a channel is in 'compatibility' mode, the controller can either disable the first four Base Address registers (i.e.; make them not writable and return 0's when read) or leave them fully programmable. In either case the values in these registers are ignored as long as the channel is in 'compatibility' mode.When a channel is in compatibility mode the IRQ used by the channel must be the 'compatibility' IRQ. PCI interrupt lines must not be effected by that channel's interrupt. Conversely, when the channel is in native-PCI mode the channel's interrupt should be connected to the appropriate INTx#. Compatibility IRQs should not be effected (i.e.; they should be tristated). --
> We see that the chip isnt in native mode so we defer to the legacy > scanner. Since the ports are not valid the legacy scanner doesn't find > them. > > Any thoughts on how we should handle this case Andre ?
We should ignore BARs (and reported INT#) when chip is not in native mode, but I'm sure that it breaks something else (note that I do not know any chip which honors BARs when using compatible mode; only problematic piece of hardware I know is PDC20265, but this one does not report itself as IDE hardware, so for this chip we have special cases in the code already; maybe VIA uses IRQ number specified in PCI config space instead of 14/15?). Petr Vandrovec vandrove@vc.cvut.cz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 15 2002 - 22:00:22 EST