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

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

[Matt Sealey]

Just bringing this up again as it's about that time of year.

There's an issue with some Via southbridges (the only notable and confirmed
example I have being the VT8231 on the PegasosPPC) which can be configured
such that they report that they are in "PCI Native Mode", but in fact handle
(and report) legacy ATA interrupts through the ISA Bridge configuration.

There are several different ways you can set it up from having a single
IRQ (true PCI native), to using PCI register access but with IRQ routing
through a certain pair of interrupts (14/15 or 10/11) or by having real
legacy ISA access (ports in the low memory ranges and the old 14/15 pair
we all remember from the first ATA controllers).

My problem with the driver is twofold; first, the old IDE block driver had a
hack applied which singles out the Pegasos as a quirk and maps two
interrupts into the "hwif" depending on the channel being set up. I
wrote a simple heuristic test which checks the IDE controller and
ISA bridge configuration and works out the correct IDE interrupts to
use. I can submit this patch but since the IDE block layer is going the
way of the dodo I see no point in it.

The second and REAL problem is that I see no real way in libata to
place detection of this quirk for the updated (and better) driver. I
noticed a strange patch on the linuxppc-dev mailing list by a Freescale
employee which changed the PCI class code of a ULI controller which
somehow made the libata driver for that controller consider it a
not-quite-native driver; I am not sure how that was meant to work but
it was obviously a platform-specific solution.

Does anyone have an idea how we can integrate this 'quirk' of the
non-native native PCI mode and support two IRQs properly so we can
have pata_via work on Pegasos (distros are dropping the old drivers
as we speak..)

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

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

[Jeff Garzik]

Matt Sealey wrote:
> Just bringing this up again as it's about that time of year.
> 
> There's an issue with some Via southbridges (the only notable and confirmed
> example I have being the VT8231 on the PegasosPPC) which can be configured
> such that they report that they are in "PCI Native Mode", but in fact handle
> (and report) legacy ATA interrupts through the ISA Bridge configuration.

pata_via calls ata_pci_init_one(), which supports the two-interrupt 
legacy configuration just fine.  The two-interrupt configuration is 
normal for a majority of pata_* drivers (and a few others), and has been 
working for years.

It sounds like you need to upgrade your BIOS to fix the requisite PCI 
config register, or need to add a PCI quirk for your platform, so that 
libata two-irq code will automagically start working for you.

	Jeff

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

[Alan Cox]

On Sat, 23 Jun 2007 01:26:06 +0100
Matt Sealey <matt@genesi-usa.com> wrote:

> There are several different ways you can set it up from having a single
> IRQ (true PCI native), to using PCI register access but with IRQ routing
> through a certain pair of interrupts (14/15 or 10/11) or by having real
> legacy ISA access (ports in the low memory ranges and the old 14/15 pair
> we all remember from the first ATA controllers).

SFF8038i is the standard you want for PCI ATA controllers.

> noticed a strange patch on the linuxppc-dev mailing list by a Freescale
> employee which changed the PCI class code of a ULI controller which
> somehow made the libata driver for that controller consider it a
> not-quite-native driver; I am not sure how that was meant to work but
> it was obviously a platform-specific solution.

Its part of the spec. The native/legacy/non-ide status of a device is
determined according to the SFF spec from the PCI class information bits.

> 
> Does anyone have an idea how we can integrate this 'quirk' of the
> non-native native PCI mode and support two IRQs properly so we can
> have pata_via work on Pegasos (distros are dropping the old drivers
> as we speak..)

The simplest way is probably to load the pci class and programming
interface bits correctly for the device to match how your IRQ setup has
been arranged. See page 78 of the VIA 8231 spec if you have it, and load
the programming class in the boot firmware or in a PCI header quirk)

Alan

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

[Matt Sealey]

Alan Cox wrote:
> On Sat, 23 Jun 2007 01:26:06 +0100
>
> The simplest way is probably to load the pci class and programming
> interface bits correctly for the device to match how your IRQ setup has
> been arranged. See page 78 of the VIA 8231 spec if you have it, and load
> the programming class in the boot firmware or in a PCI header quirk)

Ah so the correct way *is* to change the PCI class? I don't think we're
going to be publishing such a thing in the firmware (sadly) but this could
be done in a platform fixup for sure, then? Or a Forth script in the
firmware... hmm.. that sounds pretty easy actually.

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

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

[Alan Cox]

On Sat, 23 Jun 2007 10:33:46 +0100
Matt Sealey <matt@genesi-usa.com> wrote:

> 
> Alan Cox wrote:
> > On Sat, 23 Jun 2007 01:26:06 +0100
> >
> > The simplest way is probably to load the pci class and programming
> > interface bits correctly for the device to match how your IRQ setup has
> > been arranged. See page 78 of the VIA 8231 spec if you have it, and load
> > the programming class in the boot firmware or in a PCI header quirk)
> 
> Ah so the correct way *is* to change the PCI class? I don't think we're
> going to be publishing such a thing in the firmware (sadly) but this could
> be done in a platform fixup for sure, then? Or a Forth script in the
> firmware... hmm.. that sounds pretty easy actually.

The programming interface.

http://t13.org/Documents/UploadedDocuments/project/d1510r1-Host-Adapter.pdf

explains it all.

The only other gotcha is that if you want to change the class bits to
indicate the device is in legacy mode you must do that in an "early"
fixup so that it occurs before pci_setup_device makes decisions based
upon the programming interface.

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

[Matt Sealey]

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

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

Alan Cox wrote:
> On Sat, 23 Jun 2007 10:33:46 +0100
> Matt Sealey <matt@genesi-usa.com> wrote:
> 
>> Alan Cox wrote:
>>> On Sat, 23 Jun 2007 01:26:06 +0100
>>>
>>> The simplest way is probably to load the pci class and programming
>>> interface bits correctly for the device to match how your IRQ setup has
>>> been arranged. See page 78 of the VIA 8231 spec if you have it, and load
>>> the programming class in the boot firmware or in a PCI header quirk)
>> Ah so the correct way *is* to change the PCI class? I don't think we're
>> going to be publishing such a thing in the firmware (sadly) but this could
>> be done in a platform fixup for sure, then? Or a Forth script in the
>> firmware... hmm.. that sounds pretty easy actually.
> 
> The programming interface.
> 
> http://t13.org/Documents/UploadedDocuments/project/d1510r1-Host-Adapter.pdf
> 
> explains it all.
> 
> The only other gotcha is that if you want to change the class bits to
> indicate the device is in legacy mode you must do that in an "early"
> fixup so that it occurs before pci_setup_device makes decisions based
> upon the programming interface.
> 
> 

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

[Tejun Heo]

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.

-- 
tejun

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

[Matt Sealey]

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@genesi-usa.com>
Genesi, Manager, Developer Relations

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

[Tejun Heo]

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

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

[Matt Sealey]

I can't personally test anything (no Pegasos here) but I'm sure I can find some
people who can.

MMIO is required. There is no other way on PowerPC. You can do some funny tricks
in some northbridges to map certain memory ranges as PCI IO addresses through
the northbridge but we don't implement them (I think not anyway).

The "bugs" so far, are:

* IDE class code is set to "legacy" mode even though the controller is in
  "native" mode (MMIO to PCI BAR)
* ISA bridge IDE IRQ Steering register is set to push 14/15 as IDE IRQs

There are two fixes to consider; one, is that we fix the class code with a
firmware fix (or forth script or boot loader hack or platform support code
in arch/powerpc/platforms/chrp/*) and then the ISA IDE IRQ Steering is
still using two IRQs. This will not break the old via82cxxx.c driver as
it has no care in the world what the class code is.

Two, is that we fix the IDE IRQ Steering but we would break via82cxxx.c
since it freaks out when the controller is in true native mode on some
if not most (if not all) kernel versions. We would therefore by having
any firmware fix break everyone's systems and force them to use libata.
Old Linux distributions using non-libata drivers (pre-pata_via) would
stop working. If we had it as a Forth script or boot loader hack it
would be optional. If we put it in the kernel (I hope not..) then it
would just fix new users.

All in all I think the easiest way that entails the least line of
resistance and support for users for Genesi and the Linux IDE team
is to make pata_via handle this quirky but perfectly working chip
configuration (it is the best of both worlds for using PCI MBAR
register locations and legacy IRQs). I think that is what your patch
does some of the way but does it handle both problems? I'll check,
I'm pretty busy today :/

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

Tejun Heo wrote:
> 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.
> 

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

[Alan Cox]

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

The right way to do this IMHO is still to use the PCI quirk side logic.
Unfortunately to put your legacy ports at different I/O addresses you
need changes which are still pending to the libata-sff code so that it
stops using the hardcoded ATA_PRIMARY_FOO bits.

Alan

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

[Matt Sealey]

Alan Cox wrote:
>> 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.
> 
> The right way to do this IMHO is still to use the PCI quirk side logic.
> Unfortunately to put your legacy ports at different I/O addresses you
> need changes which are still pending to the libata-sff code so that it
> stops using the hardcoded ATA_PRIMARY_FOO bits.

We can't move the IO ports. They're stuck in the PCI BAR.

All we can do is fix the IRQ steering in the "ISA bridge" to report a single
IRQ instead of two.

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

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

[Alan Cox]

> > The right way to do this IMHO is still to use the PCI quirk side logic.
> > Unfortunately to put your legacy ports at different I/O addresses you
> > need changes which are still pending to the libata-sff code so that it
> > stops using the hardcoded ATA_PRIMARY_FOO bits.
> 
> We can't move the IO ports. They're stuck in the PCI BAR.

If you flag the chip up to report itself as legacy mode it'll assume
0x1F0 etc as the IO mapping address [however the PPC then maps that onto
its I/O maps depends on what the readb/writeb etc macros do].

The value in the PCI BAR is ignored in legacy mode, its not relevant or
valid. Currently libata then uses a hardcoded 0x1F0/7 etc which is wrong
as it should be asking for the pci_resource() values which are correctly
set in the PCI code [and can be tweaked for arch specials if need be]

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

[Matt Sealey]

The chip isn't in legacy mode. We never set it to legacy mode. Legacy mode would not work.

It's set to native mode. However the PCI class code does not reflect this :)

The old Via driver checked the host controller configuration space, rather
than trust the PCI class code and the ATA specs, it seems? Well, you would
know since you wrote it? :D

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

Alan Cox wrote:
>>> The right way to do this IMHO is still to use the PCI quirk side logic.
>>> Unfortunately to put your legacy ports at different I/O addresses you
>>> need changes which are still pending to the libata-sff code so that it
>>> stops using the hardcoded ATA_PRIMARY_FOO bits.
>> We can't move the IO ports. They're stuck in the PCI BAR.
> 
> If you flag the chip up to report itself as legacy mode it'll assume
> 0x1F0 etc as the IO mapping address [however the PPC then maps that onto
> its I/O maps depends on what the readb/writeb etc macros do].
> 
> The value in the PCI BAR is ignored in legacy mode, its not relevant or
> valid. Currently libata then uses a hardcoded 0x1F0/7 etc which is wrong
> as it should be asking for the pci_resource() values which are correctly
> set in the PCI code [and can be tweaked for arch specials if need be]
> 

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

[Jeff Garzik]

Matt Sealey wrote:
> The old Via driver checked the host controller configuration space, rather
> than trust the PCI class code and the ATA specs, it seems?

This is just as dependent on firmware settings as trusting the PCI class 
code...  "six of one, half-dozen of the other"

	Jeff

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

[Matt Sealey]

Yes but the libata driver doesn't check the config register, it checks
the class code, no?

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

Jeff Garzik wrote:
> Matt Sealey wrote:
>> The old Via driver checked the host controller configuration space,
>> rather
>> than trust the PCI class code and the ATA specs, it seems?
> 
> This is just as dependent on firmware settings as trusting the PCI class
> code...  "six of one, half-dozen of the other"
> 
>     Jeff
> 
> 

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

[Jeff Garzik]

Matt Sealey wrote:
> Yes but the libata driver doesn't check the config register, it checks
> the class code, no?

Talking about the end result...

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

[Alan Cox]

On Tue, 03 Jul 2007 14:41:55 +0100
Matt Sealey <matt@genesi-usa.com> wrote:

> The chip isn't in legacy mode. We never set it to legacy mode. Legacy mode would not work.
> It's set to native mode. However the PCI class code does not reflect this :)

By the time the OS has booted to the point the IDE layer runs the PCI
class code has been read and pci->resource[] arrays have been set up for
the legacy addresses not the PCI BAR ones.

So with a current kernel at the point the pci header quirks run you can
load the PCI bar values back into the pci->resource[] array. The code is
designed to allow for this. Unfortunately libata then ignores the values
provided because some changes haven't been made that have been pending
for ages. I'll push the relevant trivial bits to Andrew today after
testing them

> The old Via driver checked the host controller configuration space, rather
> than trust the PCI class code and the ATA specs, it seems? Well, you would
> know since you wrote it? 

Not those bits.

The intended code flow is this

	pci probe
		early quirk
		class IDE legacy
			Load the resources 0 to 3 specially
		header quirk

	resource tree reserved	

	libata
		Use resource 0-3 for legacy or native

Right now the last bit is using hardcoded numbers that need fixing up.

Alan

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

[Matt Sealey]

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

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

Alan Cox wrote:
> On Tue, 03 Jul 2007 14:41:55 +0100
> Matt Sealey <matt@genesi-usa.com> wrote:
> 
>> The chip isn't in legacy mode. We never set it to legacy mode. Legacy mode would not work.
>> It's set to native mode. However the PCI class code does not reflect this :)
> 
> By the time the OS has booted to the point the IDE layer runs the PCI
> class code has been read and pci->resource[] arrays have been set up for
> the legacy addresses not the PCI BAR ones.
> 
> So with a current kernel at the point the pci header quirks run you can
> load the PCI bar values back into the pci->resource[] array. The code is
> designed to allow for this. Unfortunately libata then ignores the values
> provided because some changes haven't been made that have been pending
> for ages. I'll push the relevant trivial bits to Andrew today after
> testing them
> 
>> The old Via driver checked the host controller configuration space, rather
>> than trust the PCI class code and the ATA specs, it seems? Well, you would
>> know since you wrote it? 
> 
> Not those bits.
> 
> The intended code flow is this
> 
> 	pci probe
> 		early quirk
> 		class IDE legacy
> 			Load the resources 0 to 3 specially
> 		header quirk
> 
> 	resource tree reserved	
> 
> 	libata
> 		Use resource 0-3 for legacy or native
> 
> Right now the last bit is using hardcoded numbers that need fixing up.
> 
> Alan

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

[Tejun Heo]

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

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

[Matt Sealey]

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

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

[Tejun Heo]

Hello, Matt.

Matt Sealey wrote:
> 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.

For libata, being native or legacy doesn't really mean that much.  With
the patch posted yesterday[1], the only difference is how IRQs are
requested.  Other than that, libata initializes aa legacy controller the
same way as a native controller, so you can use mmio exactly the same way.

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

That would work too but if you do PCI header fix up for legacy host,
nothing needs to be changed and nothing needs to be selected during
boot.  Both via82cxxx and pata_via would just work.  The controller's
PCI BARs contain valid values on entering kernel, right?  The only thing
you have to do is flipping the legacy bit in platform PCI fix up code.

-- 
tejun

[1] http://article.gmane.org/gmane.linux.ide/20357