| Message ID | 20210318045706.200458-3-hch@lst.de |
|---|---|
| State | New |
| Headers | show |
| Series | [01/10] alpha: use libata instead of the legacy ide driver | expand |
On Thu, Mar 18, 2021 at 05:56:58AM +0100, Christoph Hellwig wrote: > footbridge_defconfig enables CONFIG_IDE but no actual host controller > driver, so just drop it. I have been using the Cypress 82C693 IDE driver on Footbridge for a CD ROM drive, and I know it doesn't work with the PATA driver - as I need to disable BM DMA, otherwise the 82C693/DC21285 combination deadlocks the PCI bus. The PATA driver doesn't support disabling BM DMA without disabling it for all PATA ports, which is really annoying for my IT821x card in the same machine. So, I'm rather stuck using the PATA driver for the HDDs and the IDE driver for the CD ROM. That said, a commit a while back "cleaning up" the PCI layer appears to have totally shafted the 82C693, as the kernel tries to request IO resources at the legacy IDE addresses against the PCI bus resource which only covers 0x1000-0xffff. Hence, the 82C693 IDE ports are non- functional at the moment. I'm debating about trying to find a fix to the PCI breakage that was introduced by "ARM: move PCI i/o resource setup into common code". I hadn't noticed it because I don't use the CD ROM drive very often, and I don't upgrade the kernel that often either on the machine - but it has been running 24x7 for almost two decades.
On Fri, Mar 19, 2021 at 05:07:53PM +0000, Russell King - ARM Linux admin wrote: > On Thu, Mar 18, 2021 at 05:56:58AM +0100, Christoph Hellwig wrote: > > footbridge_defconfig enables CONFIG_IDE but no actual host controller > > driver, so just drop it. > > I have been using the Cypress 82C693 IDE driver on Footbridge for a > CD ROM drive, and I know it doesn't work with the PATA driver - as > I need to disable BM DMA, otherwise the 82C693/DC21285 combination > deadlocks the PCI bus. The PATA driver doesn't support disabling > BM DMA without disabling it for all PATA ports, which is really > annoying for my IT821x card in the same machine. > > So, I'm rather stuck using the PATA driver for the HDDs and the > IDE driver for the CD ROM. > > That said, a commit a while back "cleaning up" the PCI layer appears > to have totally shafted the 82C693, as the kernel tries to request > IO resources at the legacy IDE addresses against the PCI bus resource > which only covers 0x1000-0xffff. Hence, the 82C693 IDE ports are non- > functional at the moment. > > I'm debating about trying to find a fix to the PCI breakage that was > introduced by "ARM: move PCI i/o resource setup into common code". > > I hadn't noticed it because I don't use the CD ROM drive very often, > and I don't upgrade the kernel that often either on the machine - > but it has been running 24x7 for almost two decades. Okay, a bit more on this... If I extend the arch/arm/kernel/bios32.c code to kill BARs 2/3 (which actually are not present on the CY82C693) then the IDE driver works for me, but the PATA driver does not: cy82c693 0000:00:06.1: IDE controller (0x1080:0xc693 rev 0x00) cy82c693 0000:00:06.1: not 100% native mode: will probe irqs later legacy IDE will be removed in 2021, please switch to libata Report any missing HW support to linux-ide@vger.kernel.org ide0: BM-DMA at 0x1080-0x1087 ide1: BM-DMA at 0x1088-0x108f Probing IDE interface ide0... hda: PIONEER DVD-RW DVR-105, ATAPI CD/DVD-ROM drive hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 ... (unbind Cypress_IDE and try binding pata_cypress) pata_cypress 0000:00:06.1: no available native port
On Fri, Mar 19, 2021 at 05:53:12PM +0000, Russell King - ARM Linux admin wrote: > If I extend the arch/arm/kernel/bios32.c code to kill BARs 2/3 (which > actually are not present on the CY82C693) then the IDE driver works > for me, but the PATA driver does not: > > cy82c693 0000:00:06.1: IDE controller (0x1080:0xc693 rev 0x00) > cy82c693 0000:00:06.1: not 100% native mode: will probe irqs later > legacy IDE will be removed in 2021, please switch to libata > Report any missing HW support to linux-ide@vger.kernel.org > ide0: BM-DMA at 0x1080-0x1087 > ide1: BM-DMA at 0x1088-0x108f > Probing IDE interface ide0... > hda: PIONEER DVD-RW DVR-105, ATAPI CD/DVD-ROM drive > hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 > ... > > (unbind Cypress_IDE and try binding pata_cypress) > > pata_cypress 0000:00:06.1: no available native port This comes from ata_pci_sff_init_host when it tails to initialize a port. There are three cases why it can't initialize the port: 1) because it is marked as dummy, which is the case for the second port of the cypress controller, but you're not using that even with the old ide driver, and we'd still not get that message just because of that second port. 2) when ata_resources_present returns false because the BAR has a zero start or length 3) because pcim_iomap_regions() fails. This prints a warning to the log ("failed to request/iomap BARs for port %d (errno=%d)") that you should have seen So the problem here has to be number two. The legacy ide driver OTOH seems to lack a lot of these checks, although I'm not sure how it manages to actually work without those. Can you show how the BAR assignment for the device looks using lscpi or a tool of your choice?
On Mon, Mar 22, 2021 at 03:54:03PM +0100, Christoph Hellwig wrote: > On Fri, Mar 19, 2021 at 05:53:12PM +0000, Russell King - ARM Linux admin wrote: > > If I extend the arch/arm/kernel/bios32.c code to kill BARs 2/3 (which > > actually are not present on the CY82C693) then the IDE driver works > > for me, but the PATA driver does not: > > > > cy82c693 0000:00:06.1: IDE controller (0x1080:0xc693 rev 0x00) > > cy82c693 0000:00:06.1: not 100% native mode: will probe irqs later > > legacy IDE will be removed in 2021, please switch to libata > > Report any missing HW support to linux-ide@vger.kernel.org > > ide0: BM-DMA at 0x1080-0x1087 > > ide1: BM-DMA at 0x1088-0x108f > > Probing IDE interface ide0... > > hda: PIONEER DVD-RW DVR-105, ATAPI CD/DVD-ROM drive > > hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 > > ... > > > > (unbind Cypress_IDE and try binding pata_cypress) > > > > pata_cypress 0000:00:06.1: no available native port > > This comes from ata_pci_sff_init_host when it tails to initialize > a port. There are three cases why it can't initialize the port: > > 1) because it is marked as dummy, which is the case for the second > port of the cypress controller, but you're not using that even > with the old ide driver, and we'd still not get that message just > because of that second port. > 2) when ata_resources_present returns false because the BAR has > a zero start or length > 3) because pcim_iomap_regions() fails. This prints a warning to the > log ("failed to request/iomap BARs for port %d (errno=%d)") that you > should have seen > > So the problem here has to be number two. The legacy ide driver OTOH > seems to lack a lot of these checks, although I'm not sure how it > manages to actually work without those. > > Can you show how the BAR assignment for the device looks using lscpi > or a tool of your choice? There's a big problem here. I have to explicitly zero the resources (getting rid of the legacy ones assigned by the PCI probe code) because they are in fact _wrong_ for the CY82C693. The PCI code assumes that PCI function 1 (primary port) and PCI function 2 (secondary port) are two independent dual-channel IDE ports, and as the PROG-IF of the class code indicates that all ports are in legacy mode, the PCI code assigns the legacy ioport resources to _both_ PCI functions. Essentially, the CY82C693 is a bit of an odd-ball because it splits the two IDE ports across two functions rather than a single function. It gets worse than that though - due to a change to remove pcibios_min_io from the generic code, moving it into the ARM architecture code, this has caused a regression that prevents the legacy resources being registered against the bus resource. So even if they are there, they cause probe failures. I haven't found a reasonable way to solve this yet, but until there is, there is no way that the PATA driver can be used as the "legacy mode" support is effectively done via the PCI code assigning virtual IO port resources. I'm quite surprised that the CY82C693 even works on Alpha - I've asked for a lspci for that last week but nothing has yet been forthcoming from whoever responded to your patch for Alpha - so I can't compare what I'm seeing with what's happening with Alpha.
On Mon, Mar 22, 2021 at 03:15:03PM +0000, Russell King - ARM Linux admin wrote: > It gets worse than that though - due to a change to remove > pcibios_min_io from the generic code, moving it into the ARM > architecture code, this has caused a regression that prevents the > legacy resources being registered against the bus resource. So even > if they are there, they cause probe failures. I haven't found a > reasonable way to solve this yet, but until there is, there is no > way that the PATA driver can be used as the "legacy mode" support > is effectively done via the PCI code assigning virtual IO port > resources. > > I'm quite surprised that the CY82C693 even works on Alpha - I've > asked for a lspci for that last week but nothing has yet been > forthcoming from whoever responded to your patch for Alpha - so I > can't compare what I'm seeing with what's happening with Alpha. That sounds like something we could fix with a quirk for function 2 in the PCI resource assignment code. Can you show what vendor and device ID function 2 has so that I could try to come up with one?
On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote: > On Mon, Mar 22, 2021 at 03:15:03PM +0000, Russell King - ARM Linux admin wrote: > > It gets worse than that though - due to a change to remove > > pcibios_min_io from the generic code, moving it into the ARM > > architecture code, this has caused a regression that prevents the > > legacy resources being registered against the bus resource. So even > > if they are there, they cause probe failures. I haven't found a > > reasonable way to solve this yet, but until there is, there is no > > way that the PATA driver can be used as the "legacy mode" support > > is effectively done via the PCI code assigning virtual IO port > > resources. > > > > I'm quite surprised that the CY82C693 even works on Alpha - I've > > asked for a lspci for that last week but nothing has yet been > > forthcoming from whoever responded to your patch for Alpha - so I > > can't compare what I'm seeing with what's happening with Alpha. > > That sounds like something we could fix with a quirk for function 2 > in the PCI resource assignment code. Can you show what vendor and > device ID function 2 has so that I could try to come up with one? Something like this: diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 953f15abc850ac..851918206c4f2d 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1855,7 +1855,7 @@ int pci_setup_device(struct pci_dev *dev) * addresses. These are not always echoed in BAR0-3, and * BAR0-3 in a few cases contain junk! */ - if (class == PCI_CLASS_STORAGE_IDE) { + if (class == PCI_CLASS_STORAGE_IDE && !dev->no_legacy_ide_bars) { u8 progif; pci_read_config_byte(dev, PCI_CLASS_PROG, &progif); if ((progif & 1) == 0) { diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 653660e3ba9ef1..c661462d894a5b 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5612,3 +5612,16 @@ static void apex_pci_fixup_class(struct pci_dev *pdev) } DECLARE_PCI_FIXUP_CLASS_HEADER(0x1ac1, 0x089a, PCI_CLASS_NOT_DEFINED, 8, apex_pci_fixup_class); + +/* + * CY82C693 splits the primary and secondar IDE channels over 2 functions, which + * causes the PCI resource assignment algorithm to assign the legacy IDE I/O + * regions to both of them. Disable that assignment for function 2 here. + */ +static void quirk_cy82c693_legacy_resources(struct pci_dev *pdev) +{ + if (PCI_FUNC(pdev->devfn) == 2) + pdev->no_legacy_ide_bars = 1; +} +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CONTAQ, PCI_DEVICE_ID_CONTAQ_82C693, + quirk_cy82c693_legacy_resources); diff --git a/include/linux/pci.h b/include/linux/pci.h index 86c799c97b7796..7ca3f5ebbfade7 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -453,6 +453,7 @@ struct pci_dev { unsigned int link_active_reporting:1;/* Device capable of reporting link active */ unsigned int no_vf_scan:1; /* Don't scan for VFs after IOV enablement */ unsigned int no_command_memory:1; /* No PCI_COMMAND_MEMORY */ + unsigned int no_legacy_ide_bars:1; /* do not assign legacy IDE BARs */ pci_dev_flags_t dev_flags; atomic_t enable_cnt; /* pci_enable_device has been called */
On 3/22/21 4:15 PM, Russell King - ARM Linux admin wrote: > I'm quite surprised that the CY82C693 even works on Alpha - I've > asked for a lspci for that last week but nothing has yet been > forthcoming from whoever responded to your patch for Alpha - so I > can't compare what I'm seeing with what's happening with Alpha. Here is lspci on my DEC Alpha XP-1000: root@tsunami:~> lspci 0000:00:07.0 ISA bridge: Contaq Microsystems 82c693 0000:00:07.1 IDE interface: Contaq Microsystems 82c693 0000:00:07.2 IDE interface: Contaq Microsystems 82c693 0000:00:07.3 USB controller: Contaq Microsystems 82c693 0000:00:0d.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) 0001:01:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) 0001:01:06.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 06) 0001:01:08.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 0001:02:09.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) root@tsunami:~> It's using pata_cypress: root@tsunami:~> lsmod|grep cypress pata_cypress 3595 3 libata 235071 2 ata_generic,pata_cypress root@tsunami:~ Adrian
I use pata_cypress on Alpha, and for the above mentioned problems, it always restricted me to use only one IDE channel out of the two available. Also, not forcing it to use PIO mode, it always failed to operate. I would love to test on Alpha, and give you feedback about a fix/finished implementation of the driver. I have both Alpha Server DS20E and Alpha Personal Workstation 500 including that freak chipset. Let me know if/when I can help with my limited capabilities. btw, here is the lspci of the Compaq PWS 500au: snow / # lspci 00:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) 00:07.0 ISA bridge: Contaq Microsystems 82c693 00:07.1 IDE interface: Contaq Microsystems 82c693 00:07.2 IDE interface: Contaq Microsystems 82c693 00:07.3 USB controller: Contaq Microsystems 82c693 00:0b.0 Multimedia video controller: 3Dfx Interactive, Inc. Voodoo 2 (rev 02) 00:0c.0 PCI bridge: Digital Equipment Corporation DECchip 21052 (rev 01) 00:14.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 02) 01:04.0 VGA compatible controller: Cirrus Logic GD 5430/40 [Alpine] (rev 47) 01:05.0 Display controller: Intergraph Corporation Device 00eb (rev 40) 02:04.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 05) 02:0a.0 SCSI storage controller: Broadcom / LSI 53c810 (rev 01) Thanks, best regards, Barnabas Viragh On Mon, Mar 22, 2021 at 5:10 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > > On 3/22/21 4:15 PM, Russell King - ARM Linux admin wrote: > > I'm quite surprised that the CY82C693 even works on Alpha - I've > > asked for a lspci for that last week but nothing has yet been > > forthcoming from whoever responded to your patch for Alpha - so I > > can't compare what I'm seeing with what's happening with Alpha. > > Here is lspci on my DEC Alpha XP-1000: > > root@tsunami:~> lspci > 0000:00:07.0 ISA bridge: Contaq Microsystems 82c693 > 0000:00:07.1 IDE interface: Contaq Microsystems 82c693 > 0000:00:07.2 IDE interface: Contaq Microsystems 82c693 > 0000:00:07.3 USB controller: Contaq Microsystems 82c693 > 0000:00:0d.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) > 0001:01:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) > 0001:01:06.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 06) > 0001:01:08.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) > 0001:02:09.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) > root@tsunami:~> > > It's using pata_cypress: > > root@tsunami:~> lsmod|grep cypress > pata_cypress 3595 3 > libata 235071 2 ata_generic,pata_cypress > root@tsunami:~ > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz@debian.org > `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote: > On Mon, Mar 22, 2021 at 03:15:03PM +0000, Russell King - ARM Linux admin wrote: > > It gets worse than that though - due to a change to remove > > pcibios_min_io from the generic code, moving it into the ARM > > architecture code, this has caused a regression that prevents the > > legacy resources being registered against the bus resource. So even > > if they are there, they cause probe failures. I haven't found a > > reasonable way to solve this yet, but until there is, there is no > > way that the PATA driver can be used as the "legacy mode" support > > is effectively done via the PCI code assigning virtual IO port > > resources. > > > > I'm quite surprised that the CY82C693 even works on Alpha - I've > > asked for a lspci for that last week but nothing has yet been > > forthcoming from whoever responded to your patch for Alpha - so I > > can't compare what I'm seeing with what's happening with Alpha. > > That sounds like something we could fix with a quirk for function 2 > in the PCI resource assignment code. Can you show what vendor and > device ID function 2 has so that I could try to come up with one? I already have a quirk in arch/arm/kernel/bios32.c for this - but it is no longer sufficient due to changes in the PCI layer, where much of this is documented.
On Mon, Mar 22, 2021 at 05:09:13PM +0100, John Paul Adrian Glaubitz wrote: > On 3/22/21 4:15 PM, Russell King - ARM Linux admin wrote: > > I'm quite surprised that the CY82C693 even works on Alpha - I've > > asked for a lspci for that last week but nothing has yet been > > forthcoming from whoever responded to your patch for Alpha - so I > > can't compare what I'm seeing with what's happening with Alpha. > > Here is lspci on my DEC Alpha XP-1000: > > root@tsunami:~> lspci > 0000:00:07.0 ISA bridge: Contaq Microsystems 82c693 > 0000:00:07.1 IDE interface: Contaq Microsystems 82c693 > 0000:00:07.2 IDE interface: Contaq Microsystems 82c693 > 0000:00:07.3 USB controller: Contaq Microsystems 82c693 > 0000:00:0d.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01) > 0001:01:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) > 0001:01:06.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 06) > 0001:01:08.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) > 0001:02:09.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05) > root@tsunami:~> This is no good. What I asked last Thursday was: "Could you send me the output of lspci -vvx -s 7.1 and lspci -vvx -s 7.2 please?" so I can see the resources the kernel is using and a dump of the PCI config space to see what the hardware is using. Thanks.
PWS 500au:
snow / # lspci -vvx -s 7.1
00:07.1 IDE interface: Contaq Microsystems 82c693 (prog-if 80 [ISA
Compatibility mode-only controller, supports bus mastering])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4
Region 4: I/O ports at 9080 [size=16]
Kernel driver in use: pata_cypress
Kernel modules: pata_cypress
00: 80 10 93 c6 45 00 80 02 00 80 01 01 00 00 80 00
10: f1 01 00 00 f5 03 00 00 00 00 00 00 00 00 00 00
20: 81 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
snow / # lspci -vvx -s 7.2
00:07.2 IDE interface: Contaq Microsystems 82c693 (prog-if 00 [ISA
Compatibility mode-only controller])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 0
Region 0: I/O ports at 0170 [size=8]
Region 1: I/O ports at 0374
Region 4: Memory at 0c240000 (32-bit, non-prefetchable)
[disabled] [size=64K]
Kernel modules: pata_cypress
00: 80 10 93 c6 45 00 80 02 00 00 01 01 00 00 80 00
10: 71 01 00 00 75 03 00 00 00 00 00 00 00 00 00 00
20: 00 00 24 0c 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00
On Mon, Mar 22, 2021 at 6:04 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Mon, Mar 22, 2021 at 05:09:13PM +0100, John Paul Adrian Glaubitz wrote:
> > On 3/22/21 4:15 PM, Russell King - ARM Linux admin wrote:
> > > I'm quite surprised that the CY82C693 even works on Alpha - I've
> > > asked for a lspci for that last week but nothing has yet been
> > > forthcoming from whoever responded to your patch for Alpha - so I
> > > can't compare what I'm seeing with what's happening with Alpha.
> >
> > Here is lspci on my DEC Alpha XP-1000:
> >
> > root@tsunami:~> lspci
> > 0000:00:07.0 ISA bridge: Contaq Microsystems 82c693
> > 0000:00:07.1 IDE interface: Contaq Microsystems 82c693
> > 0000:00:07.2 IDE interface: Contaq Microsystems 82c693
> > 0000:00:07.3 USB controller: Contaq Microsystems 82c693
> > 0000:00:0d.0 VGA compatible controller: Texas Instruments TVP4020 [Permedia 2] (rev 01)
> > 0001:01:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
> > 0001:01:06.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 06)
> > 0001:01:08.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
> > 0001:02:09.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
> > root@tsunami:~>
>
> This is no good. What I asked last Thursday was:
>
> "Could you send me the output of lspci -vvx -s 7.1 and lspci -vvx -s 7.2
> please?"
>
> so I can see the resources the kernel is using and a dump of the PCI
> config space to see what the hardware is using.
>
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Mar 22, 2021 at 04:33:14PM +0100, Christoph Hellwig wrote: > On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote: > > On Mon, Mar 22, 2021 at 03:15:03PM +0000, Russell King - ARM Linux admin wrote: > > > It gets worse than that though - due to a change to remove > > > pcibios_min_io from the generic code, moving it into the ARM > > > architecture code, this has caused a regression that prevents the > > > legacy resources being registered against the bus resource. So even > > > if they are there, they cause probe failures. I haven't found a > > > reasonable way to solve this yet, but until there is, there is no > > > way that the PATA driver can be used as the "legacy mode" support > > > is effectively done via the PCI code assigning virtual IO port > > > resources. > > > > > > I'm quite surprised that the CY82C693 even works on Alpha - I've > > > asked for a lspci for that last week but nothing has yet been > > > forthcoming from whoever responded to your patch for Alpha - so I > > > can't compare what I'm seeing with what's happening with Alpha. > > > > That sounds like something we could fix with a quirk for function 2 > > in the PCI resource assignment code. Can you show what vendor and > > device ID function 2 has so that I could try to come up with one? > > Something like this: That solves the problem for the IDE driver, which knows how to deal with legacy mode, but not the PATA driver, which doesn't. The PATA driver needs these resources. As I say, having these resources presents a problem on ARM. A previous commit (3c5d1699887b) changed the way the bus resources are setup which results in /proc/ioports containing: 00000000-0000000f : dma1 00000020-0000003f : pic1 00000060-0000006f : i8042 00000070-00000073 : rtc_cmos 00000070-00000073 : rtc0 00000080-0000008f : dma low page 000000a0-000000bf : pic2 000000c0-000000df : dma2 00000213-00000213 : ISAPnP 000002f8-000002ff : serial8250.0 000002f8-000002ff : serial 000003c0-000003df : vga+ 000003f8-000003ff : serial8250.0 000003f8-000003ff : serial 00000480-0000048f : dma high page 00000a79-00000a79 : isapnp write 00001000-0000ffff : PCI0 I/O 00001000-0000107f : 0000:00:08.0 00001000-0000107f : 3c59x 00001080-0000108f : 0000:00:06.1 00001090-0000109f : 0000:00:07.0 00001090-0000109f : pata_it821x 000010a0-000010a7 : 0000:00:07.0 000010a0-000010a7 : pata_it821x 000010a8-000010af : 0000:00:07.0 000010a8-000010af : pata_it821x 000010b0-000010b3 : 0000:00:07.0 000010b0-000010b3 : pata_it821x 000010b4-000010b7 : 0000:00:07.0 000010b4-000010b7 : pata_it821x The "PCI0 I/O" resource is the bus level resource, and the legacy resources can not be claimed against that. Without these resources, the PATA cypress driver doesn't work. As I said previously, the reason this regression was not picked up earlier is because I don't upgrade the kernel on this machine very often; the machine has had uptimes into thousands of days. I need to try reverting Rob's commit to find out if anything breaks on this platform - it's completely wrong from a technical point of view for any case where we have a PCI southbridge, since the southbridge provides ISA based resources. I'm not entirely sure what the point of it was, since we still have the PCIBIOS_MIN_IO macro which still uses pcibios_min_io. I'm looking at some of the other changes Rob made back at that time which also look wrong, such as 8ef6e6201b26 which has the effect of locating the 21285 IO resources to PCI address 0, over the top of the ISA southbridge resources. I've no idea what Rob was thinking when he removed the csrio allocation code in that commit, but looking at it to day, it's soo obviously wrong even to a casual glance.
On Mon, Mar 22, 2021 at 06:10:01PM +0100, Cye Borg wrote: > PWS 500au: > > snow / # lspci -vvx -s 7.1 > 00:07.1 IDE interface: Contaq Microsystems 82c693 (prog-if 80 [ISA > Compatibility mode-only controller, supports bus mastering]) > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr+ Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Interrupt: pin A routed to IRQ 0 > Region 0: I/O ports at 01f0 [size=8] > Region 1: I/O ports at 03f4 > Region 4: I/O ports at 9080 [size=16] > Kernel driver in use: pata_cypress > Kernel modules: pata_cypress > 00: 80 10 93 c6 45 00 80 02 00 80 01 01 00 00 80 00 > 10: f1 01 00 00 f5 03 00 00 00 00 00 00 00 00 00 00 > 20: 81 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 > > snow / # lspci -vvx -s 7.2 > 00:07.2 IDE interface: Contaq Microsystems 82c693 (prog-if 00 [ISA > Compatibility mode-only controller]) > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr+ Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Interrupt: pin B routed to IRQ 0 > Region 0: I/O ports at 0170 [size=8] > Region 1: I/O ports at 0374 > Region 4: Memory at 0c240000 (32-bit, non-prefetchable) > [disabled] [size=64K] > Kernel modules: pata_cypress > 00: 80 10 93 c6 45 00 80 02 00 00 01 01 00 00 80 00 > 10: 71 01 00 00 75 03 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 24 0c 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 Thanks very much. Could I also ask for the output of: # lspci -vxxx -s 7.0 as well please - this will dump all 256 bytes for the ISA bridge, which contains a bunch of configuration registers. Thanks.
Sure, here it is:
snow / # lspci -vxxx -s 7.0
00:07.0 ISA bridge: Contaq Microsystems 82c693
Flags: bus master, medium devsel, latency 0
Kernel modules: pata_cypress
00: 80 10 93 c6 47 00 80 02 00 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 03 02 00 00 26 60 00 01 f0 60 00 80 80 71 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Best regards,
Barnabas
ps.: let me know, if anything else I can do.
On Tue, Mar 23, 2021 at 7:43 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Mon, Mar 22, 2021 at 06:10:01PM +0100, Cye Borg wrote:
> > PWS 500au:
> >
> > snow / # lspci -vvx -s 7.1
> > 00:07.1 IDE interface: Contaq Microsystems 82c693 (prog-if 80 [ISA
> > Compatibility mode-only controller, supports bus mastering])
> > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > ParErr+ Stepping- SERR- FastB2B- DisINTx-
> > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
> > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0
> > Interrupt: pin A routed to IRQ 0
> > Region 0: I/O ports at 01f0 [size=8]
> > Region 1: I/O ports at 03f4
> > Region 4: I/O ports at 9080 [size=16]
> > Kernel driver in use: pata_cypress
> > Kernel modules: pata_cypress
> > 00: 80 10 93 c6 45 00 80 02 00 80 01 01 00 00 80 00
> > 10: f1 01 00 00 f5 03 00 00 00 00 00 00 00 00 00 00
> > 20: 81 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> >
> > snow / # lspci -vvx -s 7.2
> > 00:07.2 IDE interface: Contaq Microsystems 82c693 (prog-if 00 [ISA
> > Compatibility mode-only controller])
> > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > ParErr+ Stepping- SERR- FastB2B- DisINTx-
> > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
> > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0
> > Interrupt: pin B routed to IRQ 0
> > Region 0: I/O ports at 0170 [size=8]
> > Region 1: I/O ports at 0374
> > Region 4: Memory at 0c240000 (32-bit, non-prefetchable)
> > [disabled] [size=64K]
> > Kernel modules: pata_cypress
> > 00: 80 10 93 c6 45 00 80 02 00 00 01 01 00 00 80 00
> > 10: 71 01 00 00 75 03 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 24 0c 00 00 00 00 00 00 00 00 00 00 00 00
> > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00
>
> Thanks very much.
>
> Could I also ask for the output of:
>
> # lspci -vxxx -s 7.0
>
> as well please - this will dump all 256 bytes for the ISA bridge, which
> contains a bunch of configuration registers. Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
diff --git a/arch/arm/configs/footbridge_defconfig b/arch/arm/configs/footbridge_defconfig index 3a7938f244e566..1fe60e0fcf2790 100644 --- a/arch/arm/configs/footbridge_defconfig +++ b/arch/arm/configs/footbridge_defconfig @@ -65,7 +65,6 @@ CONFIG_PARIDE_ON26=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y -CONFIG_IDE=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y
footbridge_defconfig enables CONFIG_IDE but no actual host controller driver, so just drop it. Signed-off-by: Christoph Hellwig <hch@lst.de> --- arch/arm/configs/footbridge_defconfig | 1 - 1 file changed, 1 deletion(-)