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

[Tejun Heo <htejun@gmail.com>]

Matt Sealey wrote:
> Well, let's put the class code as "native" since the chip is made "native",
> in a platform file somewhere. Then, we can have a configuration option in
> the platform code which allows users to choose whether the IDE configuration
> is reworked to steer to a single IRQ or two IRQs. That way they can choose
> which driver they are using (they cannot use both, and compiling in both is
> stupid, so..)
> 
> Then pata_via can just work. It does seem easier now to do this in the
> platform support thing. As long as it only affects brand new kernels and
> is only enabled when libata pata_via is enabled (we can make it depend on
> it) then it should work fine, although having it in some other config
> page seems pretty quirky. I don't know how you would suggest to do it..
> have CONFIG_FIX_PEGASOS_IDE in drivers/ata/Kconfig and code in
> arch/powerpc/platforms/chrp which recognises it? This patch idea has to
> get past two teams now, though.. and modifying chip registers that early
> in CHRP initialisation seems to be quirky in itself (I don't think PCI
> is up yet) :D

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?

-- 
tejun