Re: [PATCH] highmem I/O for ide-pmac.c

["Benjamin Herrenschmidt" <benh@kernel.crashing.org>]

>> Looking at it again, both ide_build_sglist and ide_raw_build_sglist do
>> *almost* what we want.  If ide-pmac used hwif->sg_table instead of
>> pmif->sg_table, and if ide_[raw_]build_sglist were exported and took
>> the maximum number of entries as a parameter instead of using the
>> PRD_ENTRIES constant, then ide-pmac wouldn't need to have its own
>> versions of those routines.  Would those changes be OK?
>
>Sounds like a perfectly fine change to me.
>
>> Ben, any reason why we have to use pmif->sg_table rather than
>> hwif->sg_table?
>
>Looks identical to me. hwif->sg_table is kmalloc'ed sg list of
>PRD_ENTRIES (256), pmif->sg_table is kmalloc'ed ditto of MAX_DCMDS (256)
>entries.

Well, I decided to move all of those to pmif when I had the media
bay broken because ide_unregister calling ide_release_dma which
disposed of the tables behind my back.

Looking at ide.c in it's current incarnation (2.4.20pre), it seems
the common code will only play such tricks if hwif->dma_base is
non-NULL, in which case it assumes a PRD-style DMA.

So if we keep hwif->dma_base to 0, then we can probably go back
to using the hwif fields for sg_* and thus share the routines
with ide-dma.

I'd suggest you don't bother too much with that now. I'm working
with andre on his new IDE stuff in which I already did some
cleanup work on ide-pmac, I'll add that to it next week. That
code should ultimately move to both 2.4 and 2.5 (by 2.4.21 time
frame I beleive).

Ben.