>> 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.
-
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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:28 EST