Assorted bugs in the PIIX drivers

Assorted bugs in the PIIX drivers

[Alan Cox]

I finally got all the documents rounded up to try and redo Jgarzik's
PIIX driver a bit more completely (I'm short MPIIX if anyone has it ?)

I then started reading the docs and the code and noticing a couple of
problems

1.	We set IE1 on PIO0-2 which the docs say is for PIO3+

2.	The ata_piix one (but not the ide/pci one) have shifts wrong so that
the secondary slave timings are half loaded into the primary slave


I'm also not clear if the "no MWDMA0" list has been updated correctly
for the newer chipsets.

I've yet to review the DMA programming, just the PIO so far.

Re: Assorted bugs in the PIIX drivers

[Alan Cox]

On Gwe, 2005-11-25 at 14:43 +0000, Alan Cox wrote:
> I finally got all the documents rounded up to try and redo Jgarzik's
> PIIX driver a bit more completely (I'm short MPIIX if anyone has it ?)

Add another one - PPE is set unconditionally while the documentation
says it should be set for fixed disk only.

Re: Assorted bugs in the PIIX drivers

[Marc Koschewski]

* Alan Cox <alan@lxorguk.ukuu.org.uk> [2005-11-25 14:43:28 +0000]:

> I finally got all the documents rounded up to try and redo Jgarzik's
> PIIX driver a bit more completely (I'm short MPIIX if anyone has it ?)
> 
> I then started reading the docs and the code and noticing a couple of
> problems
> 
> 1.	We set IE1 on PIO0-2 which the docs say is for PIO3+
> 
> 2.	The ata_piix one (but not the ide/pci one) have shifts wrong so that
> the secondary slave timings are half loaded into the primary slave
> 
> 
> I'm also not clear if the "no MWDMA0" list has been updated correctly
> for the newer chipsets.
> 
> I've yet to review the DMA programming, just the PIO so far.

Alan,

	could it be possible to again drop the ide=nodma kernel parameter in my
configs that use reiserfs? reiserfs just bails out when I mount devices on ide
busses that miss that parameter. I somtimes had to --rebuild-tree after a boot
with DMA enabled.

Regards,
	Marc

Re: Assorted bugs in the PIIX drivers

[Alan Cox]

On Gwe, 2005-11-25 at 16:36 +0100, Marc Koschewski wrote:
> 	could it be possible to again drop the ide=nodma kernel parameter in my
> configs that use reiserfs? reiserfs just bails out when I mount devices on ide
> busses that miss that parameter. I somtimes had to --rebuild-tree after a boot
> with DMA enabled.

One to ask the IDE maintainer about for the drivers/ide/pci code.
However the bugs and questions from my check only affect non hardisk
devices and very early slow PIO devices so wouldn't explain problems
seen with modern drive configurations.

The setup for modern (UDMA) while horribly convoluted appears to be
totally correct.

Alan

Re: Assorted bugs in the PIIX drivers

[Sergei Shtylyov]

Hello.

Alan Cox wrote:
> I finally got all the documents rounded up to try and redo Jgarzik's
> PIIX driver a bit more completely (I'm short MPIIX if anyone has it ?)
>
> I then started reading the docs and the code and noticing a couple of
> problems

> 1.	We set IE1 on PIO0-2 which the docs say is for PIO3+

    For PIO2+ actually, according to Intel's PRM (29860004.pdf), and it's said
to have no effect in the lower modes. This is actually not very correct since
when one issues Set Transfer Mode ATA command with the value (8 + PIOn), this
means select PIO _flow control_ mode n, so -IORDY is assumed to be in use.

> I'm also not clear if the "no MWDMA0" list has been updated correctly
> for the newer chipsets.

    What is/was the point for keeping MW DMA 0 support anyway? On PIIX, it's
greatly slowed down (600 vs 480 ns cycle) and was never "offically" supported
by Intel.

MBR, Sergei

Re: Assorted bugs in the PIIX drivers

[Alan Cox]

On Llu, 2006-05-15 at 19:12 +0400, Sergei Shtylyov wrote:
>     For PIO2+ actually, according to Intel's PRM (29860004.pdf), and it's said
> to have no effect in the lower modes. This is actually not very correct since
> when one issues Set Transfer Mode ATA command with the value (8 + PIOn), this
> means select PIO _flow control_ mode n, so -IORDY is assumed to be in use.

PIO2 depends on the drive (there is a drive parameter telling you the
highest timing clock you can do with/without IORDY

> > I'm also not clear if the "no MWDMA0" list has been updated correctly
> > for the newer chipsets.
> 
>     What is/was the point for keeping MW DMA 0 support anyway? On PIIX, it's
> greatly slowed down (600 vs 480 ns cycle) and was never "offically" supported
> by Intel.

Some old old drives only do MWDMA0. The Intel docs I have here don't
describe it in any way as "unsupported", merely broken on some ICH
variants.

Alan

Re: Assorted bugs in the PIIX drivers

[Sergei Shtylyov]

Hello.

Alan Cox wrote:

> On Llu, 2006-05-15 at 19:12 +0400, Sergei Shtylyov wrote:

>>    For PIO2+ actually, according to Intel's PRM (29860004.pdf), and it's said
>> to have no effect in the lower modes. This is actually not very correct since
>> when one issues Set Transfer Mode ATA command with the value (8 + PIOn), this
>> means select PIO _flow control_ mode n, so -IORDY is assumed to be in use.

> PIO2 depends on the drive (there is a drive parameter telling you the
> highest timing clock you can do with/without IORDY

    Yes. But when you're setting any _explicit_ PIO mode with Set Features
command, you're tell the drive to use -IORDY at the same time.

>>> I'm also not clear if the "no MWDMA0" list has been updated correctly
>>> for the newer chipsets.

>>    What is/was the point for keeping MW DMA 0 support anyway? On PIIX, it's
>> greatly slowed down (600 vs 480 ns cycle) and was never "offically" supported
>> by Intel.

> Some old old drives only do MWDMA0. The Intel docs I have here don't
> describe it in any way as "unsupported",

    They just don't describe it, period. :-)

> merely broken on some ICH variants.

    ICH errata #55: "Note that DMA Mode-0 is an unsupported mode of the ICH."

> Alan

MBR, Sergei

RE: Assorted bugs in the PIIX drivers

[SMALL, Timothy]

This looks like the MPIIX datasheet:

http://www.mit.edu/afs/sipb/contrib/doc/specs/unfiled/i82371MX.pdf

Also, may or may not want to bother with looking at supporting another chip
- the never-actually-released-by-Intel i82600 integrated single chip
north/south bridge.  This chipset design (can you still call it a chipset if
it only has one chip?) is licensed from Intel, and sold by Radisys.  The
docs are here:

http://www.radisys.com/service_support/tech_solutions/techsupportlib_detail.
cfm?ProductID=1262

I have it working fine with the ide/pci driver in PIO, and UDMA, but not
MDMA modes, but haven't had a chance to revisit it, but it is on my TODO
list...

Tim.


> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
> Sent: Friday, November 25, 2005 2:43 PM
> To: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Assorted bugs in the PIIX drivers
> 
> 
> I finally got all the documents rounded up to try and redo 
> Jgarzik's PIIX driver a bit more completely (I'm short MPIIX 
> if anyone has it ?)
> 
> I then started reading the docs and the code and noticing a 
> couple of problems
> 
> 1.	We set IE1 on PIO0-2 which the docs say is for PIO3+
> 
> 2.	The ata_piix one (but not the ide/pci one) have shifts 
> wrong so that
> the secondary slave timings are half loaded into the primary slave
> 
> 
> I'm also not clear if the "no MWDMA0" list has been updated 
> correctly for the newer chipsets.
> 
> I've yet to review the DMA programming, just the PIO so far.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-ide" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

This email is for the intended addressee only.
If you have received it in error then you must not use, retain, disseminate or otherwise deal with it.
Please notify the sender by return email.
The views of the author may not necessarily constitute the views of EADS Astrium Limited.
Nothing in this email shall bind EADS Astrium Limited in any contract or obligation.

EADS Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England