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

[Tejun Heo <htejun@gmail.com>]

Matt Sealey wrote:
> So we actually have to fix up some platform support for it? That's not very
> nice.

Well, the hardware isn't very nice, is it?  :-)

> 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.

So, the legacy ioport addresses aren't fixed.  It can be determined by
the previously-said arch macros.  Or are you saying that mmio is required?

> 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?

Yeah, sure.  I was gonna do it once the native PCI BARs + legacy IRQ
hack I posted to the bugzilla bug is verified to work.  There's a
pending cleanup to ata_pci_init_once() and friends which will make the
job easier.  Can you test the patch and try to determine why it doesn't
work?

Thanks.

-- 
tejun