Re: [PATCH] (2.6.20-rc7) cmd64x: fix PIO mode setup (take 2)

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

Hello.

Bartlomiej Zolnierkiewicz wrote:

>>>>>Index: linux-2.6/drivers/ide/pci/cmd64x.c
>>>>>===================================================================
>>>>>--- linux-2.6.orig/drivers/ide/pci/cmd64x.c
>>>>>+++ linux-2.6/drivers/ide/pci/cmd64x.c

>>>>While this was always incorrectly setting PIO4, the PIO4 is "the usual" case
>>>>and for this driver we need to program PIO explicitly even when using DMA.

>>>   Hm, why it's *so* special, i.e. why almost all the other drivers can
>>>get away without it (the majority seems to have autotune set *only* if
>>>hwif->dma_base is seen as 0 in the init_hwif() method? :-/

>>>>The core code doesn't program PIO mode unless told to (->autotune flag == 1)
>>>>so after the above change PIO mode won't be programmed et all.

>>>>I think that we now need to set ->autotune unconditionally in
>>>>init_hwif_cmd64x().

>>  Don't think we *need* to. Look at the code at the end of init_chipset()
>>method.  Those values it writes to ARTTIM/DRWTIM registers already matches
>>PIO4!  That's another question what this code is doing there, being both
>>duplicate and misplaced. :-)

> For me it looks like a bunch of hacks to get things working on
> BIOS/firmware-less and non-x86 systems. :)

> [ This code pre-dates PIO4 forcing in config_cmd64x_chipset_for_pio(). ]

    The "#ifdef __i386__" part looked the most mysterous:  why anyone would 
want to program less *IDE* address setup on x86 than on non-x86? :-O
    I was going to remove all that crap as well but decided to defer it, 
mostly because of that part...

> Bart

MBR, Sergei