pata_it8213: MWDMA0 is unsupported

PATCH In review Bartlomiej Zolnierkiewicz 3 participants 11 messages Nov 26, 2009 – Dec 3, 2009 libata

lore

Share & tools

lore

Bartlomiej Zolnierkiewicz

author

2009-11-26 16:30 UTC #0 lore raw

PATCH 1/1 pata_it8213: MWDMA0 is unsupported

MWDMA0 timings cannot be met with the PIIX based controller programming interface.

This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

---
Verified with the documentation (similar case as with pata_efar).

On top of patches from yesterday.

 drivers/ata/pata_it8213.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/ata/pata_it8213.c +1 -1

Index: b/drivers/ata/pata_it8213.c
===================================================================
@@ -227,7 +227,7 @@ static int it8213_init_one (struct pci_d
 	static const struct ata_port_info info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
-		.mwdma_mask	= ATA_MWDMA2,
+		.mwdma_mask	= ATA_MWDMA12_ONLY,
 		.udma_mask 	= ATA_UDMA6,
 		.port_ops	= &it8213_ops,
 	};

Bartlomiej Zolnierkiewicz

author

2009-11-26 17:01 UTC #1 lore raw

Quoted 10 lines · Bartlomiej Zolnierkiewicz

MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).

Uhhh, no...

Too many damn drivers.

Too much damn duplication.

Too much damn subtle differences here and there.

The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.

I'll drop those two patches from my tree and take some break..

Quoted 18 lines

On top of patches from yesterday.

 drivers/ata/pata_it8213.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ata/pata_it8213.c
===================================================================

drivers/ata/pata_it8213.c +1 -1

@@ -227,7 +227,7 @@ static int it8213_init_one (struct pci_d
 	static const struct ata_port_info info = {
 		.flags		= ATA_FLAG_SLAVE_POSS,
 		.pio_mask	= ATA_PIO4,
-		.mwdma_mask	= ATA_MWDMA2,
+		.mwdma_mask	= ATA_MWDMA12_ONLY,
 		.udma_mask 	= ATA_UDMA6,
 		.port_ops	= &it8213_ops,
 	};

Sergei Shtylyov

2009-11-26 17:22 UTC #2 lore raw

Quoted 12 lines · Bartlomiej Zolnierkiewicz

Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...

Quoted 8 lines

Too many damn drivers.
Too much damn duplication.
Too much damn subtle differences here and there.
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.

How so with pata_efar? The active/recovery bitfields are still 2-bit
wide, no?

Quoted 1 line

I'll drop those two patches from my tree and take some break..

Taking a break is good, not sure about dropping yet.

MBR, Sergei

Bartlomiej Zolnierkiewicz

author

2009-11-26 18:00 UTC #3 lore raw

Quoted 18 lines · Sergei Shtylyov

Quoted 15 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Too many damn drivers.
Too much damn duplication.

Quoted 7 lines

Quoted 4 lines
Too much damn subtle differences here and there.
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.
How so with pata_efar? The active/recovery bitfields are still 2-bit
wide, no?

Yes but when TIMEx bit is disabled we are using XFER_PIO_SLOW timings.

All data sheets including original Intel ones are a complete crap when it comes to explicitly documenting this behavior.

--
Bartlomiej Zolnierkiewicz

Bartlomiej Zolnierkiewicz

author

2009-11-26 18:11 UTC #4 lore raw

Quoted 24 lines · Bartlomiej Zolnierkiewicz

Quoted 23 lines · Sergei Shtylyov
Quoted 20 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Too many damn drivers.
Too much damn duplication.
Too much damn subtle differences here and there.
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.

Quoted 7 lines

Quoted 2 lines
How so with pata_efar? The active/recovery bitfields are still 2-bit
wide, no?
Yes but when TIMEx bit is disabled we are using XFER_PIO_SLOW timings.
All data sheets including original Intel ones are a complete crap when it comes to explicitly documenting this behavior.

OTOH all drivers set TIMEx for MWDMA0 currently.. ?

--
Bartlomiej Zolnierkiewicz

Sergei Shtylyov

2009-11-26 18:12 UTC #5 lore raw

Quoted 18 lines · Bartlomiej Zolnierkiewicz

Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Too many damn drivers.
Too much damn duplication.
Too much damn subtle differences here and there.

Quoted 7 lines

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.
How so with pata_efar? The active/recovery bitfields are still 2-bit
wide, no?
Yes but when TIMEx bit is disabled we are using XFER_PIO_SLOW timings.

600 ns cycle vs spec'ed 480 ns? Is it really worth it?

Quoted 4 lines

Quoted 2 lines
All data sheets including original Intel ones are a complete crap when it comes to explicitly documenting this behavior.
OTOH all drivers set TIMEx for MWDMA0 currently.. ?

... which would give a grossly overclocked timing.

Quoted 2 lines

--
Bartlomiej Zolnierkiewicz

MBR, Sergei

Bartlomiej Zolnierkiewicz

author

2009-11-26 18:28 UTC #6 lore raw

Quoted 23 lines · Sergei Shtylyov

Quoted 20 lines · Bartlomiej Zolnierkiewicz
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Too many damn drivers.
Too much damn duplication.
Too much damn subtle differences here and there.
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.

Quoted 6 lines

Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
How so with pata_efar? The active/recovery bitfields are still 2-bit
wide, no?
Yes but when TIMEx bit is disabled we are using XFER_PIO_SLOW timings.
600 ns cycle vs spec'ed 480 ns? Is it really worth it?

960 ns actually

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
All data sheets including original Intel ones are a complete crap when it comes to explicitly documenting this behavior.
OTOH all drivers set TIMEx for MWDMA0 currently.. ?
... which would give a grossly overclocked timing.

Except ata_piix which blacklists MWDMA0 for _all_ PATA controllers.. :)

I'm leaving my patches as they were for now, unless somebody wants to untangle this mess this is a safest and quickest way forward..

--
Bartlomiej Zolnierkiewicz

Sergei Shtylyov

2009-11-26 18:32 UTC #7 lore raw

Quoted 21 lines · Bartlomiej Zolnierkiewicz

Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Too many damn drivers.
Too much damn duplication.
Too much damn subtle differences here and there.
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
How so with pata_efar? The active/recovery bitfields are still 2-bit
wide, no?
Yes but when TIMEx bit is disabled we are using XFER_PIO_SLOW timings.
600 ns cycle vs spec'ed 480 ns? Is it really worth it?
960 ns actually

That table you're looking at (probably in the SLC90E66 datasheet?) must
be screwed up. 960 ns is used for command cycles, according to Intel's docs, data cycles run at 600 ns...

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
All data sheets including original Intel ones are a complete crap when it comes to explicitly documenting this behavior.
OTOH all drivers set TIMEx for MWDMA0 currently.. ?
... which would give a grossly overclocked timing.
Except ata_piix which blacklists MWDMA0 for _all_ PATA controllers.. :)

:-)

Quoted 2 lines

I'm leaving my patches as they were for now, unless somebody wants to untangle this mess this is a safest and quickest way forward..

MBR, Sergei

Sergei Shtylyov

2009-11-26 18:46 UTC #8 lore raw

Quoted 24 lines · Hello, I wrote:

Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 12 lines
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Quoted 8 lines
Too many damn drivers.
Too much damn duplication.
Too much damn subtle differences here and there.
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213}, it just not documented properly in the data sheet.
How so with pata_efar? The active/recovery bitfields are still
2-bit wide, no?

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Yes but when TIMEx bit is disabled we are using XFER_PIO_SLOW timings.
600 ns cycle vs spec'ed 480 ns? Is it really worth it?
960 ns actually
That table you're looking at (probably in the SLC90E66 datasheet?)
must be screwed up. 960 ns is used for command cycles, according to Intel's docs, data cycles run at 600 ns...

Well, after doublke checking 82371AB datasheet has 660 ns, and ICH PRM
has 900 ns. Not sure where I got what I've cited now, perhaps in some older version of PRM... what a mess indeed. :-/

MBR, Sergei

Jeff Garzik

2009-12-03 21:04 UTC #9 lore raw

In reply to Sergei Shtylyov

Quoted 18 lines · Sergei Shtylyov

Quoted 15 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Too many damn drivers.
Too much damn duplication.

Quoted 8 lines

Quoted 5 lines
Too much damn subtle differences here and there.
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213},
it just not documented properly in the data sheet.
How so with pata_efar? The active/recovery bitfields are still 2-bit wide, no?

So.... pata_it8213 is fine for MWDMA0, then?

Jeff

Sergei Shtylyov

2009-12-03 22:06 UTC #10 lore raw

Hello.

Quoted 18 lines · Jeff Garzik

Quoted 18 lines
Quoted 17 lines
Quoted 9 lines
MWDMA0 timings cannot be met with the PIIX based controller programming interface.
This change should be safe as this is how we have been doing things in IDE it8213 host driver for years.
Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>
---
Verified with the documentation (similar case as with pata_efar).
Uhhh, no...
Too many damn drivers.
Too much damn duplication.
Too much damn subtle differences here and there.

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
The hardware is probably fine for MWMDA0 when it comes to pata_{efar,it8213},
it just not documented properly in the data sheet.
How so with pata_efar? The active/recovery bitfields are still 2-bit wide, no?
So.... pata_it8213 is fine for MWDMA0, then?

No, TTBOMK. I just have no datasheet. However, it's programmed
overclocked and even in theory the cycle time cannot exceeed 600 ns vs 480 ns spec'ed.

Quoted 1 line

Jeff

MBR, Sergei