Remove superfluous timings table entry while at it.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
Sergei, XFER_UDMA_5 timing also looks suspicious,
please take a look when you have a minute, thanks.
drivers/ata/pata_hpt3x2n.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: b/drivers/ata/pata_hpt3x2n.c
===================================================================
--- a/drivers/ata/pata_hpt3x2n.c
+++ b/drivers/ata/pata_hpt3x2n.c
@@ -80,14 +80,13 @@ static struct hpt_clock hpt3x2n_clocks[]
{ XFER_MW_DMA_2, 0x2c829c62 },
{ XFER_MW_DMA_1, 0x2c829c66 },
- { XFER_MW_DMA_0, 0x2c829d2c },
+ { XFER_MW_DMA_0, 0x2c829d2e },
{ XFER_PIO_4, 0x0c829c62 },
{ XFER_PIO_3, 0x0c829c84 },
{ XFER_PIO_2, 0x0c829ca6 },
{ XFER_PIO_1, 0x0d029d26 },
{ XFER_PIO_0, 0x0d029d5e },
- { 0, 0x0d029d5e }
};
/**
Bartlomiej Zolnierkiewicz wrote:
> Remove superfluous timings table entry while at it.
> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
> ---
> Sergei, XFER_UDMA_5 timing also looks suspicious,
> please take a look when you have a minute, thanks.
Yeah, but it's the same as XFER_UDMA_4, so actually underclocked...
However, it matches what the HPT371N datasheet and the vendor drivers have.
The 'hpt366' driver uses more speedy mode, with 22.5 ns cycle. ;-)
MBR, Sergei
Hello, I wrote:
>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
>> ---
>> Sergei, XFER_UDMA_5 timing also looks suspicious,
>> please take a look when you have a minute, thanks.
> Yeah, but it's the same as XFER_UDMA_4, so actually underclocked...
> However, it matches what the HPT371N datasheet and the vendor drivers
> have. The 'hpt366' driver uses more speedy mode, with 22.5 ns cycle. ;-)
I have just verified: this driver has always used this timing
historically, at least for HPT372+ chips.
MBR, Sergei
On 11/27/2009 02:47 PM, Sergei Shtylyov wrote:
> Hello, I wrote:
>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
>>> ---
>>> Sergei, XFER_UDMA_5 timing also looks suspicious,
>>> please take a look when you have a minute, thanks.
>
>> Yeah, but it's the same as XFER_UDMA_4, so actually underclocked...
>> However, it matches what the HPT371N datasheet and the vendor drivers
>> have. The 'hpt366' driver uses more speedy mode, with 22.5 ns cycle. ;-)
>
> I have just verified: this driver has always used this timing
> historically, at least for HPT372+ chips.
Could you clarify which "this timing" you are referring to? :) I never
saw an Acked-by on this one.
Jeff
Hello.
Jeff Garzik wrote:
>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
>>>> ---
>>>> Sergei, XFER_UDMA_5 timing also looks suspicious,
>>>> please take a look when you have a minute, thanks.
>>
>>> Yeah, but it's the same as XFER_UDMA_4, so actually underclocked...
>>> However, it matches what the HPT371N datasheet and the vendor drivers
>>> have. The 'hpt366' driver uses more speedy mode, with 22.5 ns cycle.
>>> ;-)
>>
>> I have just verified: this driver has always used this timing
>> historically, at least for HPT372+ chips.
>
> Could you clarify which "this timing" you are referring to? :)
UDMA5 timing which looked suspicious to Bart: 'hpt366' driver uses
faster timing at 66 MHz clock than the vendor drivers and HPT371N
datasheet have (they have it the same as UDMA4).
> I never saw an Acked-by on this one.
I usually don't ACK libata patches, but this one can be an exception:
Acked-by: Sergei Shtylyov <[email protected]>
Though I guess you're waiting for Alan's ACK... :-)
> Jeff
MBR, Sergei