Re: [PATCH 2.5.13 IDE 54

Martin Dalecki
2002-05-07T14:43:40Z

Uz.ytkownik benh@kernel.crashing.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
> 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.

Alomst all of them done ;-). Please take a look at the end of
ide-dma.c

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