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

[Matt Sealey <matt@genesi-usa.com>]

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 resources
> are allocated.  Is there any specific reason to use native mode?

Yes, legacy mode means there are several "io ports" mapped into the
0 thru 0x1000 addresses. This might work in Linux, granted, but I am
not sure it is a good idea in the first place.

Mapping io ports to anywhere but the PCI io space is just an ugly
solution. The ATA native/legacy thing means a lot, as there is no
"legacy" on PowerPC. It's a PCI device, so we should try and fix up
it's actions as a PCI device, however, making it truly conform will
break any "not entirely compatible" drivers break (via8cxxx being
the biggest culprit). Therefore no firmware fixes for thee.

I do think we can knock it into full PCI native mode from the platform
fixups though, as a kernel option. Old drivers will work fine, old
kernels will work fine, and optionally old behaviour can be left, but
anyone building a new kernel with pata_via and no via8cxxx (i.e. all
new distributions) can enable the new behaviour.

Does that sound okay? No libata-level resource fixups need to be done
for a real PCI device, do they? I think we should just coerce the
controller to use a single interrupt and disable ISA interrupt
steering, fix the class code, and see if libata handles it.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations