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.
So what do I do if my controller does not have a simple memory-mapping for
each IDE-register into the memory ? Do I have to clutter ide.h and ide.c
with #ifdef's or is there any cleaner abstraction on the way (something
like adding a hwif field to perform the OUT/IN-byte stuff, and
ide_xxput_bytes) ?
(I have a solution working by replacing OUT_BYTE and ide_xxput_bytes, but
wanted to make it without having to patch the "official" ide.c/ide.h)
Regards,
Bjorn
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.
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.
>
> So what do I do if my controller does not have a simple memory-mapping for
> each IDE-register into the memory ? Do I have to clutter ide.h and ide.c
> with #ifdef's or is there any cleaner abstraction on the way (something
> like adding a hwif field to perform the OUT/IN-byte stuff, and
> ide_xxput_bytes) ?
>
> (I have a solution working by replacing OUT_BYTE and ide_xxput_bytes, but
> wanted to make it without having to patch the "official" ide.c/ide.h)
>
> Regards,
> Bjorn
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
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.