[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] highmem I/O for ide-pmac.c
>> 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)

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).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.035 / U:7.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site