lkml.org 
[lkml]   [2002]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.160 / U:1.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site