Uz.ytkownik firstname.lastname@example.org napisa?:
>>OK I see I have "forced" you to take care of this.
>>My problem previously was the simple fact that in esp.
>>the pmac code was sidestepping the generic code and providing his
>>own mechanisms for handling chipset specific dma transfer methods.
>>As you can see now it's possible to have overloaded most
>>of the "virtuaized" udma_xxx channel methods.
>>Now you request me to virtualize the udma_enable stuff.
>>Nothing easier then this.
> I haven't looked closely at your new stuff yet, but here's what
> we need for ide-pmac (and similarily, on a whole bunch of embedded
> IDE controllers that do not behave like a legacy controller).
> - hook on enabling/disabling DMA & setting up timing stuffs. Due to
> some weird HW, we must be in control of the actual sending of the
> feature setting command to the drive
> - hook on creating/disposing the DMA related data structures (lists
> - hook on setting up the DMA SG list as PRDs are really only
> specific to the legacy PCI controllers, we deal with all sort
> of different DMA controllers here in the outside world ;)
> - hook on starting the DMA transfer
> - hook on stopping the DMA transfer
> - hook on knowing if the DMA is done and/or letting it drain
> completely upon reception of the last interrupt.
Alomst all of them done ;-). Please take a look at the end of
> Ideally, in order to properly deal with some HW details, the hook on
> starting the DMA transfer should also be the one ultimately issuing
> the command to the taskfile register, as depending on the HW, it may
> have to be done either prior or after starting the DMA channel.
> So instead of having a ton of hook, I'd rather see all of this be
> properly abstracted by default, the legacy IDE beeing only one
> of the possible set of callbacks, instead of having the default code
> in ide.c with hooks for different chipsets.
This is presisely where the "default" code from the
"virtualizations" found in ide-dma.c is going to go, after
some restabilizing of the interface.
So I think we are at least "mentally" in sync.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
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 : Tue May 07 2002 - 22:00:29 EST