Messages in this thread |  | | From | "Benjamin Herrenschmidt" <> | Subject | Re: [PATCH] highmem I/O for ide-pmac.c | Date | Thu, 12 Sep 2002 07:37:01 +0200 |
| |
>> 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/
|  |