Needed this to build Fedora rawhide kernel (2.6.12-rc1 + some patches)
on alpha. This is the upstream portion of the build fixes.
Signed-off-by: Jeff Garzik <[email protected]>
On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> +/* TODO: integrate with include/asm-generic/pci.h ? */
> +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> +{
> + return channel ? 15 : 14;
> +}
Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
Why in the world would we have this much infrastructure for one driver? And
why not just not compile that one for Alpha, since it'll never be used.
r~
On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > +{
> > + return channel ? 15 : 14;
> > +}
>
> Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> Why in the world would we have this much infrastructure for one driver? And
> why not just not compile that one for Alpha, since it'll never be used.
My presumption is that it will be used in other IDE drivers in the
future. Bart?
If it will only be used in that one driver, then I agree.
Jeff
On Sat, 19 Mar 2005 18:16:41 -0500, Jeff Garzik <[email protected]> wrote:
> On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> > On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > > +{
> > > + return channel ? 15 : 14;
> > > +}
> >
> > Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> > Why in the world would we have this much infrastructure for one driver? And
> > why not just not compile that one for Alpha, since it'll never be used.
>
> My presumption is that it will be used in other IDE drivers in the
> future. Bart?
This code is meant to be used by other IDE/libata drivers.
[ Original thread can be found in linux-ide ML archive. ]
On Mon, Mar 21, 2005 at 09:05:39AM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Sat, 19 Mar 2005 18:16:41 -0500, Jeff Garzik <[email protected]> wrote:
> > On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> > > On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > > > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > > > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > > > +{
> > > > + return channel ? 15 : 14;
> > > > +}
> > >
> > > Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> > > Why in the world would we have this much infrastructure for one driver? And
> > > why not just not compile that one for Alpha, since it'll never be used.
> >
> > My presumption is that it will be used in other IDE drivers in the
> > future. Bart?
>
> This code is meant to be used by other IDE/libata drivers.
Then isn't linux/ide.h the proper place for default pci_get_legacy_ide_irq()
implementation instead of asm-generic/pci.h? The latter is only used by
7 out of 23 architectures, so not only alpha gets broken.
Ivan.
On Mon, 21 Mar 2005 12:16:16 +0300, Ivan Kokshaysky
<[email protected]> wrote:
> On Mon, Mar 21, 2005 at 09:05:39AM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Sat, 19 Mar 2005 18:16:41 -0500, Jeff Garzik <[email protected]> wrote:
> > > On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> > > > On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > > > > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > > > > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > > > > +{
> > > > > + return channel ? 15 : 14;
> > > > > +}
> > > >
> > > > Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> > > > Why in the world would we have this much infrastructure for one driver? And
> > > > why not just not compile that one for Alpha, since it'll never be used.
> > >
> > > My presumption is that it will be used in other IDE drivers in the
> > > future. Bart?
> >
> > This code is meant to be used by other IDE/libata drivers.
>
> Then isn't linux/ide.h the proper place for default pci_get_legacy_ide_irq()
ide.h is not shared between IDE and libata drivers (but ata.h is)
> implementation instead of asm-generic/pci.h? The latter is only used by
> 7 out of 23 architectures, so not only alpha gets broken.
I'm cc:ing Ben as it was his idea
> > Then isn't linux/ide.h the proper place for default pci_get_legacy_ide_irq()
>
> ide.h is not shared between IDE and libata drivers (but ata.h is)
>
> > implementation instead of asm-generic/pci.h? The latter is only used by
> > 7 out of 23 architectures, so not only alpha gets broken.
I'm not sure what the original problem is with alpha, but I added this
call to remove the hard coding of irq numbers in various drivers that
"find" the chip in legacy mode. Instead, I give the arch the opportunity
to provide the actual irq numbers in that case.
IRQs on IDE in legacy mode is sort of an out-of-spec piece of junk that
was invented to make PCI based peecees "look like" good old rotten
hardware, unfortunately, some modern and non-x86 HW vendors still don't
haev a clue and configure (wire in some case) their on board IDE in
legacy mode, but with IRQs that, on those archs, aren't 14 and 15. That
hook fixes the problem on some ppc64 machines but should be extended to
cover various other cases where similar shit happens.
It's in PCI because I figured it was as bad there than anywhere else. In
this case, it's the IDE layer asking the PCI layer "hey, that guy
doesn't respect the normal PCI IRQ mapping, can you tell me how it's
routed ?" :) Back then, I didn't know of a header shared between ide and
libata so I put it there.
Ben.
On Mon, Mar 21, 2005 at 11:27:39PM +1100, Benjamin Herrenschmidt wrote:
> IRQs on IDE in legacy mode is sort of an out-of-spec piece of junk that
> was invented to make PCI based peecees "look like" good old rotten
> hardware, unfortunately, some modern and non-x86 HW vendors still don't
> haev a clue and configure (wire in some case) their on board IDE in
> legacy mode, but with IRQs that, on those archs, aren't 14 and 15. That
> hook fixes the problem on some ppc64 machines but should be extended to
> cover various other cases where similar shit happens.
Indeed, such setup is quite typical for southbridge chips with
integrated IDE controller - they still simulate sort of ISA IRQ
routing...
> It's in PCI because I figured it was as bad there than anywhere else. In
> this case, it's the IDE layer asking the PCI layer "hey, that guy
> doesn't respect the normal PCI IRQ mapping, can you tell me how it's
> routed ?" :) Back then, I didn't know of a header shared between ide and
> libata so I put it there.
Ok, but asm-generic/pci.h is not a good place for default IRQ 14/15 case -
this header cannot be included on non-x86 without additional #ifdef's.
Perhaps we can move it to linux/pci.h or linux/ata.h (as Bart noted)?
Ivan.
On Sad, 2005-03-19 at 23:11, Richard Henderson wrote:
> On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > +{
> > + return channel ? 15 : 14;
> > +}
>
> Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> Why in the world would we have this much infrastructure for one driver? And
> why not just not compile that one for Alpha, since it'll never be used.
The issue is bigger - it's needed for the CMD controllers on PA-RISC for
example it appears - and anything else where IDE legacy IRQ is wired
oddly.
On Mon, Mar 21, 2005 at 02:52:10PM +0000, Alan Cox wrote:
> The issue is bigger - it's needed for the CMD controllers on PA-RISC for
> example it appears - and anything else where IDE legacy IRQ is wired
> oddly.
Sure, but who queries this information? That's my question.
r~
On Mon, Mar 21, 2005 at 10:16:18AM -0800, Richard Henderson wrote:
> On Mon, Mar 21, 2005 at 02:52:10PM +0000, Alan Cox wrote:
> > The issue is bigger - it's needed for the CMD controllers on PA-RISC for
> > example it appears - and anything else where IDE legacy IRQ is wired
> > oddly.
>
> Sure, but who queries this information? That's my question.
IDE drivers.
Since its a detail that varies widely depending on platform, the arch
should either provide it or at least have a way to override it.
linux/pci.h would be fine place for the "generic version arch overrides
with HAVE_ARCH_PCI_IDE_IRQ", or we could fix the asm-generic header to
not need #ifdefs in -your- source just to be usable.
Jeff
>
> Ok, but asm-generic/pci.h is not a good place for default IRQ 14/15 case -
> this header cannot be included on non-x86 without additional #ifdef's.
> Perhaps we can move it to linux/pci.h or linux/ata.h (as Bart noted)?
Well, I would have expected other archs to just make their own, but I
have no special preference here ... linux/pci.h is as good as anything.
Ben.
[I'm not subscribed, please excuse the thread-breaking]
Alan Cox wrote:
> > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > +{
> > + return channel ? 15 : 14;
> > +}
>
> The issue is bigger - it's needed for the CMD controllers on PA-RISC for
> example it appears - and anything else where IDE legacy IRQ is wired
> oddly.
The built-in IDE controller on the Astro/Elroy based PA-RISC workstations
(B1000, C3000, J5000 and similar) is part of a NS87560 chip. By default
(and we don't currently touch this), we route the internal interrupts
to Linux interrupts 14 and 15. We could change that, but I don't currently
see a need to, since we're "the same as x86". It uses the ns87415 driver.
I don't know what the situation is with the zx1-based boxes, currently only
the C8000. If it's the same as the ia64 zx1 boxes, it'll have a CMD 649.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain