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).. >> >> Checked the Pegasos IDE class code and in the firmware it's set to 0x1018F so, I >> would assume the correct value is 0x1018A (knocking out the "native mode"). >> >> Okay! Great. This looks easy. Just gotta decode PCI addresses in Forth now.. > > I think I wrote this in the bugzilla entry but my memory is fuzzy as > always, so I'll repeat it here. If you turn off the native bits, > libata-sff will use ATA_PRIMARY_CMD and its friends to determine IO > ports and ATA_PRIMARY_IRQ and friends to determine IRQs. PCI BAR is > only used to determine IO ports for BMDMA register. > > ie. The legacy mode means "there's no standard way to configure the damn > thing. Just believe what the arch code says. However, BMDMA is > introduced after PCI so let's use PCI BAR for it." So, if you're gonna > make the controller legacy (which I think is the correct way), don't > forget to update those arch macros. So we actually have to fix up some platform support for it? That's not very nice. 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 idea to be poking around just there and we never intended that to work. However the VT8231 (and probably all the Via chips) do happily operate in "native PCI mode" with the line register reporting 14 or 10, and IRQ steering still set to two IRQs (10/11 or 14/15 or some combination). You might consider this an ATA specification violation or a chipset bug, but it does in fact work.. my original patch handled it as a quirk (it is a quirk, a very strange way of operating..) - isn't there a way we can get the same kind of quirky fix in libata or are we being super-clean about it? The patch I made for the old IDE driver looks to be a clumsy version of what some of libata-sff does in ata_pci_init_one and ata_pci_probe_ent and maybe a little bit of ata_pci_init_native_mode. Is it possible to perhaps replace ata_pci_init_one with a custom function which handles this (in pata_via.c) quirky behaviour and #ifdef it out with a Kconfig variable? CONFIG_ATA_VIA_HALFNATIVE_QUIRK or something? I think that would be best. Everyone can ignore it and distributions building for Pegasos can enable it.. but I think "fixing" IDE chipset quirks by reconfiguring the chipset in some platform support code is the wrong place. It either needs to be set up properly in firmware (breaking ide/via82cxxx.c in the process and therefore any old kernels anyone is running. We don't want to impose a kernel upgrade with our firmware upgrades..) or fixed in the IDE driver (libata and it's drivers are eminently updatable by unloading modules, whereas platform support is a reboot job..) -- Matt Sealey <matt@xxxxxxxxxxxxxx> Genesi, Manager, Developer Relations - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
