My confusion then. We used to have these in the PPC tree, and I
suspected those were APUS related ;)
>> On PPC, we still have some historical horrible macros redefinitions
>> in asm/ide.h to let APUS (PPC Amiga) deal with these.
>
>In asm-ppc/ide.h? Didn't see them there.
Right, looks like they are gone lately. Well, the TiVO may have been one
reason for these though I don't think the support for this box has ever
made it into our main tree. It's possible that we had some broken PReP
or whatever early boxes.
>The main problem is that IDE use[sd] `inb' et al. for accesses, which is not
>valid for I/O on something other than ISA/PCI I/O space. So for m68k and APUS
>we have to do weird things. The new IN_BYTE() etc. should help a bit there,
>though.
We tweak on pmac by feeding the IDE layer with our controller virtual address
minus _IO_BASE (for non-PPC people, _IO_BASE is the virtual address of the
main PCI IO space, all inx/outx are relative to this). The pointer arithmetic
does the magic. It sucks, but works without redefining everything around.
I haven't looked at the new IN_BYTE stuff, though if it is IDE specific,
I'd rather see it called IDE_IN_BYTE. The current scheme sucks also because
inx/outx, at least on PPC, are a lot slower than normal MMIO access (one
reason beeing their ability to recovert from machine checks). It would be
nice for IDE to use it's own accessors on MMIO platforms. This has to be
a per-controller things though. A global macro is no good. You can (and on
some configs, you do have on the motherboard) both MMIO mapped controllers
and old-style IO mapped ones. One example is the B&W mac G3 which has both
the Apple MMIO mapped mac-io IDE controller and the CMD646 on the PCI bus.
Also, when applying the taskfile, I suspect we don't need strong barriers as
we do currently have, only on IO write barrier before actually writing the
command byte. But I would gladly leave the whole issue of redefining barriers
especially regarding IOs to Anton Blanchard ;)
Maybe the entire function for writing a taskfile register state to the
controller should be made a hwif indirect call. (On Darwin, they more or
less do that, along with a bitmask indicating which register has to be
applied, though I suspect the tests against this bitmask would eats pretty
much all of the benefit of removing the useless barriers).
>> Now, the problem of dealing with DMA along with the swapping is
>> something scary. I beleive the sanest solution that won't please
>> affected people is to _not_ support DMA on these broken HW ;)
>
>Agreed. And you have to disable DMA when accessing a disk that
originates from
>such a system on a sane box.
Agreed.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/