On Mon, 27 Nov 2000, Andre Hedrick wrote:
> Yes, I have been working on that for some time.
> This requires that the macros be exported the arch-xxx/ide.h
> Additionally it takes more work to modify the request_io and release_io,
> but it is all doable.
Right on! Do you think it would be too big a performance hit if OUT_BYTE
actually was an hwif function call instead of a macro ? OUT_BYTE has more
to do with the specific hw interface than the system architecture, really.
Actually the entire hwif_unregister function should be handled by the hwif
itself I guess (haven't noticed that yet since I never unregister my
drivers :)
My "hack" right now involves putting "magic" values in the io_ports array
so that OUT_BYTE separate them correctly (my controller has ONE address
where a 32-bit write does the commands, with a bitfield controlling the
IDE bus address instead of splitting into 7 + 1 separate addresses).
BTW can ide_register_hw be called from the automatic "module_init" chains
during bootup, or is that too early or too late ? It would be nice if that
was the case because otherwise we need to add to the long list in
probe_for_hwifs with initialization calls.
-BW
> On Tue, 28 Nov 2000, Bjorn Wesen wrote:
> > Hi! Quick question: is it possible to write an IDE driver for a controller
> > that is not mappable using outp and those memory-mapped thingys ?
> >
> > I see all the nice overrideables in struct hwif_s but the main code still
> > uses OUT_BYTE which is hardcoded to an outb_p.. non-overrideable. Same
> > thing with ide_input/output_bytes, they do direct in/out accesses also
> > without consulting any hwif specific routine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 21:00:19 EST