Re: Linux 2.4.21-pre1

["Petr Vandrovec" <VANDROVE@vc.cvut.cz>]

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