Re: [PATCH 2.5.13 IDE 54

[<benh@kernel.crashing.org>]

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

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.

Regards,
Ben.