Messages in this thread | | | Date | Wed, 17 Apr 2002 10:39:29 +0200 | From | Martin Dalecki <> | Subject | Re: [PATCH] 2.5.8 IDE 36 |
| |
Benjamin Herrenschmidt wrote:
> 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).
Thank you for the elaborated explanation. I think that some of your ideas presented here could be well pursued becouse they are indeed good. :-).
- 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/
| |