[PATCH] amd74xx: don't configure udma mode higher than BIOS did

[PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Tejun Heo]

On many nvidia boards, BIOSen often set CABLE bit in EIDE Controller
Configuration Register even when 40c cable is attached but configures
transfer mode correctly (<= udma33).  As amd74xx depends on the CABLE
bit to determine the cable type and thus the highest allowed udma
mode, this often results in incorrectly configured device resulting in
CRC errors and DMA disabling.

This patch makes amd74xx not configure udma mode higher than BIOS did.
If BIOS configured the device <= udma44, udma33 is the maximum speed.
Otherwise, the mode BIOs configured is the highest.  udma44
discrepancy is due to limitation in ide_find_best_mode() interface.
This shouldn't make much difference.

Signed-off-by: Tejun Heo <htejun@gmail.com>
---
Without this change, amd74xx can't figure out the right udma mode.
I've verified with 40c and 80c cables and a few new and old disks and
ODDs.  Works pretty good.

 drivers/ide/pci/amd74xx.c |   43 ++++++++++++++++++++++++++++++++++++-------
 1 file changed, 36 insertions(+), 7 deletions(-)

Index: work/drivers/ide/pci/amd74xx.c
===================================================================
--- work.orig/drivers/ide/pci/amd74xx.c
+++ work/drivers/ide/pci/amd74xx.c
@@ -84,6 +84,7 @@ static struct amd_ide_chip *amd_config;
 static ide_pci_device_t *amd_chipset;
 static unsigned int amd_80w;
 static unsigned int amd_clock;
+static u32 amd_udma_timing;
 
 static char *amd_dma[] = { "MWDMA16", "UDMA33", "UDMA66", "UDMA100", "UDMA133" };
 static unsigned char amd_cyc2udma[] = { 6, 6, 5, 4, 0, 1, 1, 2, 2, 3, 3, 3, 3, 3, 3, 7 };
@@ -292,14 +293,37 @@ static void amd74xx_tune_drive(ide_drive
 
 static int amd74xx_ide_dma_check(ide_drive_t *drive)
 {
-	int w80 = HWIF(drive)->udma_four;
+	/* UDMA timing to limit map, we don't limit below udma33 */
+	static const int udma_limit_map[] =
+		{ AMD_UDMA_33, AMD_UDMA_33, AMD_UDMA_33, AMD_UDMA_33,
+		  AMD_UDMA_33, AMD_UDMA_66, AMD_UDMA_100, AMD_UDMA_133 };
+	int w80, map;
+	u8 speed;
+
+	w80 = HWIF(drive)->udma_four && eighty_ninty_three(drive);
+	map = XFER_PIO | XFER_EPIO | XFER_MWDMA | XFER_UDMA |
+		((amd_config->flags & AMD_BAD_SWDMA) ? 0 : XFER_SWDMA);
+
+	if (w80) {
+		int udma_mode = amd_config->flags & AMD_UDMA;
+		u32 udma_timing = amd_udma_timing;
+
+		/* don't go over BIOS configured speed */
+		udma_timing >>= 8 * (3 - drive->dn);
+
+		if ((udma_timing & 0xc0) == 0xc0)
+			udma_mode = min(udma_mode,
+					udma_limit_map[udma_timing & 0x07]);
+
+		if (udma_mode >= AMD_UDMA_66)
+			map |= XFER_UDMA_66;
+		if (udma_mode >= AMD_UDMA_100)
+			map |= XFER_UDMA_100;
+		if (udma_mode >= AMD_UDMA_133)
+			map |= XFER_UDMA_133;
+	}
 
-	u8 speed = ide_find_best_mode(drive,
-		XFER_PIO | XFER_EPIO | XFER_MWDMA | XFER_UDMA |
-		((amd_config->flags & AMD_BAD_SWDMA) ? 0 : XFER_SWDMA) |
-		(w80 && (amd_config->flags & AMD_UDMA) >= AMD_UDMA_66 ? XFER_UDMA_66 : 0) |
-		(w80 && (amd_config->flags & AMD_UDMA) >= AMD_UDMA_100 ? XFER_UDMA_100 : 0) |
-		(w80 && (amd_config->flags & AMD_UDMA) >= AMD_UDMA_133 ? XFER_UDMA_133 : 0));
+	speed = ide_find_best_mode(drive, map);
 
 	amd_set_drive(drive, speed);
 
@@ -355,6 +379,11 @@ static unsigned int __devinit init_chips
 	}
 
 /*
+ * Cache UDMA timing BIOS configured.
+ */
+	pci_read_config_dword(dev, AMD_UDMA_TIMING, &amd_udma_timing);
+
+/*
  * Take care of prefetch & postwrite.
  */
 

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Alan]

> This patch makes amd74xx not configure udma mode higher than BIOS did.
> If BIOS configured the device <= udma44, udma33 is the maximum speed.

NAK

The boot firmware for AMD/Nvidia chips is only run on PC, and the data is
only valid on some of them, in some cases, and not after a suspend/resume
cycle. You cannot rely on the BIOS (if any) loaded register values. Since
you've posted patches to clean up the drive side detect (when tweaked
with a couple of fixes), this hack won't be neccessary.

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Tejun Heo]

Alan wrote:
>> This patch makes amd74xx not configure udma mode higher than BIOS did.
>> If BIOS configured the device <= udma44, udma33 is the maximum speed.
> 
> NAK
> 
> The boot firmware for AMD/Nvidia chips is only run on PC, and the data is
> only valid on some of them, in some cases, and not after a suspend/resume
> cycle. You cannot rely on the BIOS (if any) loaded register values. Since
> you've posted patches to clean up the drive side detect (when tweaked
> with a couple of fixes), this hack won't be neccessary.

If BIOS hasn't run, UDMA timing wouldn't have been programmed and as
such the speed won't be limited.  So, there should be no harm done in
that case.  Even if something goes really wrong, the worst happens is
capping speed to udma33.

The reason why I posted both drive side wire detection and this was that
both are often wrong on my test machine.  It's one of the popular NF4
boards from ASUS, probably one of the most sold.  I've tested with one
fairly recent samsung drive and two old drives from maxtor and wd.  All
of them support > udma33.  In many valid configurations using 40c, both
the host and drive reported 80c (I verified register values multiple
times) and configured accordingly by both pata_amd and amd74xx and then
of course cause a lot of transfer errors.

In all those cases, BIOS configured transfer mode correctly.  So,
without this patch, amd74xx will drop out of dma mode as soon as it gets
detected in many configurations.

So, I think the benefit (correct configuration on most machines) easily
outweighs the danger (incorrectly capping speed to working udma33 on
non-PC).

-- 
tejun

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Tejun Heo]

Forgot to reply about some stuff.  Adding.

Tejun Heo wrote:
> Alan wrote:
>>> This patch makes amd74xx not configure udma mode higher than BIOS did.
>>> If BIOS configured the device <= udma44, udma33 is the maximum speed.
>> NAK
>>
>> The boot firmware for AMD/Nvidia chips is only run on PC, and the data is
>> only valid on some of them, in some cases, and not after a suspend/resume
>> cycle.

To prevent that, the value is cached on driver probe and written back on
driver detach on pata_amd, which is necessary even when there is no
suspend/resume as mode programming alters the content of the register.
amd74xx cannot be unloaded, so caching is enough.  Also, doesn't
suspend/resume cycle store and restore PCI space anyway?

Thanks.

-- 
tejun

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Alan]

> To prevent that, the value is cached on driver probe and written back on
> driver detach on pata_amd, which is necessary even when there is no

Which is useless.

> suspend/resume as mode programming alters the content of the register.
> amd74xx cannot be unloaded, so caching is enough.  Also, doesn't
> suspend/resume cycle store and restore PCI space anyway?

If I load the driver after a kexec or after a suspend/resume cycle both
of which are quite valid your code breaks.

Alan

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Tejun Heo]

Alan wrote:
>> To prevent that, the value is cached on driver probe and written back on
>> driver detach on pata_amd, which is necessary even when there is no
> 
> Which is useless.

I can agree to 'not always effective' but its useful in common driver
load/unload cases.

>> suspend/resume as mode programming alters the content of the register.
>> amd74xx cannot be unloaded, so caching is enough.  Also, doesn't
>> suspend/resume cycle store and restore PCI space anyway?
> 
> If I load the driver after a kexec or after a suspend/resume cycle both
> of which are quite valid your code breaks.

I wrote about kexec in the other reply.  And about loading after
suspend/resume, yeap, it's outside of saved area, so it'll probably
contain reset or random value.  Again, the worst that happens is
limiting transfer mode to udma33, which, considering the likelihood of
the scenario weighted against the common case, is acceptable, IMHO.

I think the first thing we need to do is verifying this problem.  If
this is a rare problem, let's forget about it.  If it can be easily
reproduced, we need to do something about it one way or the other -
maybe sniffing BIOS mode as I did or maybe different smart trick.

Thanks.

-- 
tejun

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Alan]

> If BIOS hasn't run, UDMA timing wouldn't have been programmed and as
> such the speed won't be limited.  So, there should be no harm done in
> that case.  Even if something goes really wrong, the worst happens is
> capping speed to udma33.

Which is bad and leaves people with mysterious performance problems that
randomly appear in a new release. You have error handling code that will
do UDMA change down, you've fixed the disk side detect. We don't need to
destroy the pata_amd driver as well nor the IDE AMD driver.

You get whatever the chip has loaded. The BIOS may pick PIO modes only,
the BIOS may not have been run so the UDMA bits could be arbitary. You
may even get wrongly capped values.

Also another case you broke is kexec.

> So, I think the benefit (correct configuration on most machines) easily
> outweighs the danger (incorrectly capping speed to working udma33 on
> non-PC).

Yours is the first complaint I've seen about this hardware detection in
*THREE* years. Its a bigger problem with libata but thats because of the
drive side detect and also because currently we work on the basis in
libata that host side detect defines cable, while old ide (when behaving
and correctly working) works on the basis that if the host says 80wire and
the drive says 40 wire (or vice versa) then its 40.

Alan

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Tejun Heo]

Alan wrote:
> You get whatever the chip has loaded. The BIOS may pick PIO modes only,

In that case, the code does NOT apply.  All the code does is applying at
most UDMA33 limit if BIOS has configured && enabled UDMA mode.

> the BIOS may not have been run so the UDMA bits could be arbitary. You
> may even get wrongly capped values.

First of all, in 99% of cases, the BIOS has run and if the BIOS hasn't
run, the register is most likely to contain reset values which wouldn't
trigger the limit and even if the limit is wrongly triggered, the worst
that happens is limiting transfer speed to udma33.

> Also another case you broke is kexec.

1. If kexec is done while either of amd74xx or pata_amd is loaded, the
currently configured mode is what the kexeced kernel would use as
reference.  If the port has been slowed down during operation, yeah, it
would be sub-optimal but again the worst can happen is udma33.

2. If kexec is done after pata_amd is unloaded, pata_amd restored the
BIOS value on unload.  Should be identical to clean boot.

>> So, I think the benefit (correct configuration on most machines) easily
>> outweighs the danger (incorrectly capping speed to working udma33 on
>> non-PC).
> 
> Yours is the first complaint I've seen about this hardware detection in
> *THREE* years. Its a bigger problem with libata but thats because of the
> drive side detect and also because currently we work on the basis in
> libata that host side detect defines cable, while old ide (when behaving
> and correctly working) works on the basis that if the host says 80wire and
> the drive says 40 wire (or vice versa) then its 40.

CK804 IDE, at least mine, reports 80c in a lot of cases where it
shouldn't.  I dunno the reason but it also makes drives confused about
cable type.  Maybe it has the wrong capacitor attached or something.
This is A8N-E from ASUS, probably one of the popular ones using nf4.

When that happens, libata EH does its job and slows the interface to
udma33 after quite a few error messages.  On IDE, if this happens, the
drive is put into PIO mode making the machine painful to use.

I dunno why this is the first report in three years.  I might have a
defective board but I don't think that's the case as BIOS gets it right
everytime.

Googling...  I'm listing a few which seem similar.

  http://search.luky.org/linux-kernel.2005/msg30919.html
  http://www.centos.org/modules/newbb/viewtopic.php?topic_id=4662
  http://blog.gmane.org/gmane.linux.bios/month=20060601/page=6

When this type of errors occur, people try to swap cables, swap
positions and some of those combinations would probably work and the
problem would be considered solved.  I mean, really, very little of bugs
actually get reported to relevant people.

Please keep in mind that no one has reported driver side detection is
wrong in all these years even when in some cases we just assume 80c on
host side and depended on driver side detection (amd74xx UDMA66
controllers), but I'm pretty sure it has caused some griefs out in the wild.

I agree with you that this is a hack and ugly as hell.  I don't like it
either, but it solves an existing problem which could have and possibly
will hit many users.  So, I think this problem should at least be
verified.  If it's just my BIOS/motherboard that's crazy, I have no
problem forgetting about this.

So, anyone with CK804 (a.k.a NF4) up for some testing?

-- 
tejun

Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Alan]

> > Also another case you broke is kexec.
> 
> 1. If kexec is done while either of amd74xx or pata_amd is loaded, the
> currently configured mode is what the kexeced kernel would use as
> reference.  If the port has been slowed down during operation, yeah, it
> would be sub-optimal but again the worst can happen is udma33.

So we now have an exciting "well kexec might work but here is a new
random weirdness to screw people who it hit".

> CK804 IDE, at least mine, reports 80c in a lot of cases where it
> shouldn't.  I dunno the reason but it also makes drives confused about
> cable type.  Maybe it has the wrong capacitor attached or something.
> This is A8N-E from ASUS, probably one of the popular ones using nf4.

I take it this was how you came to find every cable related bug while
trying to work out what was going on ?

> When that happens, libata EH does its job and slows the interface to
> udma33 after quite a few error messages.  On IDE, if this happens, the
> drive is put into PIO mode making the machine painful to use.

No the IDE layer does DMA changedown fine, well apart from all the
error/timer races in the old IDE code.

> Googling...  I'm listing a few which seem similar.

All of which are before you fixed the drive side stuff

>   http://search.luky.org/linux-kernel.2005/msg30919.html
>   http://www.centos.org/modules/newbb/viewtopic.php?topic_id=4662
>   http://blog.gmane.org/gmane.linux.bios/month=20060601/page=6

And the third is LinuxBIOS so you've actually not fixed anything for that
one.

> Please keep in mind that no one has reported driver side detection is
> wrong in all these years even when in some cases we just assume 80c on
> host side and depended on driver side detection (amd74xx UDMA66
> controllers), but I'm pretty sure it has caused some griefs out in the wild.

Yep.

> I agree with you that this is a hack and ugly as hell.  I don't like it
> either, but it solves an existing problem which could have and possibly
> will hit many users.  So, I think this problem should at least be
> verified.  If it's just my BIOS/motherboard that's crazy, I have no
> problem forgetting about this.

It certainly seems to be Nvidia specific, so perhaps Nvidia can provide
more details on the Nforce4 cable detection ? As with a lot of Nvidia
stuff there was much reverse engineering involved in the original code
base.

And if its a specific board or couple of boards then we should perhaps
use DMI to match them specifically.

> So, anyone with CK804 (a.k.a NF4) up for some testing?

If it still goes I've got a rather iffy NF3 but not an NF4 handy.

Alan

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Tejun Heo]

Alan wrote:
[--snip--]
>> CK804 IDE, at least mine, reports 80c in a lot of cases where it
>> shouldn't.  I dunno the reason but it also makes drives confused about
>> cable type.  Maybe it has the wrong capacitor attached or something.
>> This is A8N-E from ASUS, probably one of the popular ones using nf4.
> 
> I take it this was how you came to find every cable related bug while
> trying to work out what was going on ?

Yeap, pretty much.  I thought fixing drive side cable detection would
fix it, but hell no.

>> When that happens, libata EH does its job and slows the interface to
>> udma33 after quite a few error messages.  On IDE, if this happens, the
>> drive is put into PIO mode making the machine painful to use.
> 
> No the IDE layer does DMA changedown fine, well apart from all the
> error/timer races in the old IDE code.

I dunno.  It always ended up in PIO mode in my case.  I can post the log
if necessary.

[--snip--]
>> I agree with you that this is a hack and ugly as hell.  I don't like it
>> either, but it solves an existing problem which could have and possibly
>> will hit many users.  So, I think this problem should at least be
>> verified.  If it's just my BIOS/motherboard that's crazy, I have no
>> problem forgetting about this.
> 
> It certainly seems to be Nvidia specific, so perhaps Nvidia can provide
> more details on the Nforce4 cable detection ? As with a lot of Nvidia
> stuff there was much reverse engineering involved in the original code
> base.

Hmmm... Anyone happen to have working nvidia contact?

> And if its a specific board or couple of boards then we should perhaps
> use DMI to match them specifically.
> 
>> So, anyone with CK804 (a.k.a NF4) up for some testing?
> 
> If it still goes I've got a rather iffy NF3 but not an NF4 handy.

Yeah, please.  If I connect a hdd at the end of 40c cable and leaving
the middle connector empty, the 80c bit is always one and the drive says
it's 80c cable while the BIOS configured mode is correctly udma33.  This
is the same for SAMSUNG SP0802N, Maxtor 91301U3 and HITACHI_DK23BA-20.

-- 
tejun

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Alan]

> > No the IDE layer does DMA changedown fine, well apart from all the
> > error/timer races in the old IDE code.
> 
> I dunno.  It always ended up in PIO mode in my case.  I can post the log
> if necessary.

Ok testing my hardware

- AMD get it right for those with host cable detect
- AMD get it right for disk side detect

- My NV03 gets it wrong on all counts but it pauses only briefly to
change neatly down to UDMA33 with old IDE.

(We could speed that with libata by going straight to UDMA33 on cable
error with PATA_CBL_UNK or some other way to flag "cable detection
untrusted")

The BIOS seems to get the detection it does right, so we need an Nvidia
person to answer this properly. Nvidia + 40pin cable is still clearly such
an obscure setting we don't want to damage general behaviour for it.

Good news is that the AMD just works, that AFAIK means all the non x86 PC
cases just work.

Alan

RE: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Allen Martin]

Unfortunately there's no standard way to do host side cable detect on
nForce systems without going through ACPI.  It's done through a GPIO
pin.  Board vendors are free to reallocate which GPIO pin is used for
this feature.  

One possible solution is to leave the default DMA mode at whatever the
BIOS left it at.  So if it's a UDMA5 drive but the BIOS left it at UDMA2
it was because of cable detect.

The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
Then you can remove all chipset specific knowledge from the IDE driver.
This is what the MS driver does on Windows, so you know it's received a
lot of testing from NVIDIA and board vendors.

-Allen

> -----Original Message-----
> From: Bartlomiej Zolnierkiewicz [mailto:bzolnier@gmail.com] 
> Sent: Monday, February 05, 2007 7:09 AM
> To: Allen Martin
> Subject: Fwd: Nvidia cable detection problems (was [PATCH] 
> amd74xx: don't configure udma mode higher than BIOS did)
> 
> Hi Allen,
> 
> Would it be possible to get some help on this issue?
> 
> Thanks,
> Bart
> 
> ---------- Forwarded message ----------
> From: Tejun Heo <htejun@gmail.com>
> Date: Feb 5, 2007 3:50 PM
> Subject: Re: Nvidia cable detection problems (was [PATCH] amd74xx:
> don't configure udma mode higher than BIOS did)
> To: Alan <alan@lxorguk.ukuu.org.uk>
> Cc: bzolnier@gmail.com, linux-ide@vger.kernel.org, 
> linux-kernel@vger.kernel.org
> 
> 
> Alan wrote:
> [--snip--]
> >> CK804 IDE, at least mine, reports 80c in a lot of cases where it 
> >> shouldn't.  I dunno the reason but it also makes drives confused 
> >> about cable type.  Maybe it has the wrong capacitor 
> attached or something.
> >> This is A8N-E from ASUS, probably one of the popular ones 
> using nf4.
> >
> > I take it this was how you came to find every cable related 
> bug while 
> > trying to work out what was going on ?
> 
> Yeap, pretty much.  I thought fixing drive side cable 
> detection would fix it, but hell no.
> 
> >> When that happens, libata EH does its job and slows the 
> interface to
> >> udma33 after quite a few error messages.  On IDE, if this happens, 
> >> the drive is put into PIO mode making the machine painful to use.
> >
> > No the IDE layer does DMA changedown fine, well apart from all the 
> > error/timer races in the old IDE code.
> 
> I dunno.  It always ended up in PIO mode in my case.  I can 
> post the log if necessary.
> 
> [--snip--]
> >> I agree with you that this is a hack and ugly as hell.  I 
> don't like 
> >> it either, but it solves an existing problem which could have and 
> >> possibly will hit many users.  So, I think this problem should at 
> >> least be verified.  If it's just my BIOS/motherboard 
> that's crazy, I 
> >> have no problem forgetting about this.
> >
> > It certainly seems to be Nvidia specific, so perhaps Nvidia can 
> > provide more details on the Nforce4 cable detection ? As 
> with a lot of 
> > Nvidia stuff there was much reverse engineering involved in the 
> > original code base.
> 
> Hmmm... Anyone happen to have working nvidia contact?
> 
> > And if its a specific board or couple of boards then we 
> should perhaps 
> > use DMI to match them specifically.
> >
> >> So, anyone with CK804 (a.k.a NF4) up for some testing?
> >
> > If it still goes I've got a rather iffy NF3 but not an NF4 handy.
> 
> Yeah, please.  If I connect a hdd at the end of 40c cable and 
> leaving the middle connector empty, the 80c bit is always one 
> and the drive says it's 80c cable while the BIOS configured 
> mode is correctly udma33.  This is the same for SAMSUNG 
> SP0802N, Maxtor 91301U3 and HITACHI_DK23BA-20.
> 
> --
> tejun
> 
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Alan]

> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
> Then you can remove all chipset specific knowledge from the IDE driver.
> This is what the MS driver does on Windows, so you know it's received a
> lot of testing from NVIDIA and board vendors.

Well we can certainly do some of that if ACPI is present and active. In
particular since _GTM will give us current modes allowing for hotplug and
post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
We could even probe UDMA3+ capable devices by doing _STM to a high mode
and _GTM to determine the cable type 8)

Alan

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Tejun Heo]

Alan wrote:
>> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
>> Then you can remove all chipset specific knowledge from the IDE driver.
>> This is what the MS driver does on Windows, so you know it's received a
>> lot of testing from NVIDIA and board vendors.
> 
> Well we can certainly do some of that if ACPI is present and active. In
> particular since _GTM will give us current modes allowing for hotplug and
> post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> We could even probe UDMA3+ capable devices by doing _STM to a high mode
> and _GTM to determine the cable type 8)

Glad to see the problem getting solved.  Now that we know the solution,
any volunteers?  :-)

-- 
tejun

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Bartlomiej Zolnierkiewicz]

Hi,

On 2/5/07, Tejun Heo <htejun@gmail.com> wrote:
> Alan wrote:
> >> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
> >> Then you can remove all chipset specific knowledge from the IDE driver.
> >> This is what the MS driver does on Windows, so you know it's received a
> >> lot of testing from NVIDIA and board vendors.

Allen, thanks for quick reply.

Your mail explained the issue pretty well and saved us a lot of time.

> > Well we can certainly do some of that if ACPI is present and active. In
> > particular since _GTM will give us current modes allowing for hotplug and
> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> > We could even probe UDMA3+ capable devices by doing _STM to a high mode
> > and _GTM to determine the cable type 8)

agreed

> Glad to see the problem getting solved.  Now that we know the solution,
> any volunteers?  :-)

Well, since you posted the initial patches and have the affected hardware... 8)

Thanks,
Bart

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Tejun Heo]

Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> On 2/5/07, Tejun Heo <htejun@gmail.com> wrote:
>> Alan wrote:
>> >> The *real* solution is to use the BIOS ACPI _GTM _STM methods for
>> this.
>> >> Then you can remove all chipset specific knowledge from the IDE
>> driver.
>> >> This is what the MS driver does on Windows, so you know it's
>> received a
>> >> lot of testing from NVIDIA and board vendors.
> 
> Allen, thanks for quick reply.
> 
> Your mail explained the issue pretty well and saved us a lot of time.

My thanks too.

>> > Well we can certainly do some of that if ACPI is present and active. In
>> > particular since _GTM will give us current modes allowing for
>> hotplug and
>> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that
>> way.
>> > We could even probe UDMA3+ capable devices by doing _STM to a high mode
>> > and _GTM to determine the cable type 8)
> 
> agreed
> 
>> Glad to see the problem getting solved.  Now that we know the solution,
>> any volunteers?  :-)
> 
> Well, since you posted the initial patches and have the affected
> hardware... 8)

I'll be on the road for the next two weeks and Alan seems to have taken
it already.  :-)

-- 
tejun

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Bartlomiej Zolnierkiewicz]

On 2/5/07, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > Well we can certainly do some of that if ACPI is present and active. In
> > > particular since _GTM will give us current modes allowing for hotplug and
> > > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> > > We could even probe UDMA3+ capable devices by doing _STM to a high mode
> > > and _GTM to determine the cable type 8)
>
> agreed

New look at the issue:

Since we are already using UDMA mode set by BIOS to determine if 80c cable
is present so why not also use it to determine if the 40c cable is present?

I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.

2-lines change and we wouldn't have to deal with ACPI at ell.

What do you think?

Bart

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Alan]

> Since we are already using UDMA mode set by BIOS to determine if 80c cable
> is present so why not also use it to determine if the 40c cable is present?
> 
> I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.
> 
> 2-lines change and we wouldn't have to deal with ACPI at ell.

And as I explained earlier you get false values. The existing hack is
dodgy as well and breaks on suspend/resume then loading the driver for
one. It's probably the best that can be done without ACPI but the ACPI
_GTM/_STM methods are pretty clean so its not hard to use them. You need
them for full suspend/resume support anyway.

Alan

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Bartlomiej Zolnierkiewicz]

On 2/5/07, Alan <alan@lxorguk.ukuu.org.uk> wrote:
> > Since we are already using UDMA mode set by BIOS to determine if 80c cable
> > is present so why not also use it to determine if the 40c cable is present?
> >
> > I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.
> >
> > 2-lines change and we wouldn't have to deal with ACPI at ell.
>
> And as I explained earlier you get false values. The existing hack is
> dodgy as well and breaks on suspend/resume then loading the driver for
> one. It's probably the best that can be done without ACPI but the ACPI
> _GTM/_STM methods are pretty clean so its not hard to use them. You need
> them for full suspend/resume support anyway.

OK

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Alan]

> > Well we can certainly do some of that if ACPI is present and active. In
> > particular since _GTM will give us current modes allowing for hotplug and
> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> > We could even probe UDMA3+ capable devices by doing _STM to a high mode
> > and _GTM to determine the cable type 8)
> 
> Glad to see the problem getting solved.  Now that we know the solution,
> any volunteers?  :-)

I am currently putting together an experimental pata_acpi driver to play
with this stuff. May take a bit of time while I work out the current acpi
interface gunge and how to expand it.

The fact we have to try each mode to see what we can set doesn't make it
pretty either!

Alan

Re: Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did)

[Jeff Garzik]

Alan wrote:
>>> Well we can certainly do some of that if ACPI is present and active. In
>>> particular since _GTM will give us current modes allowing for hotplug and
>>> post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
>>> We could even probe UDMA3+ capable devices by doing _STM to a high mode
>>> and _GTM to determine the cable type 8)
>> Glad to see the problem getting solved.  Now that we know the solution,
>> any volunteers?  :-)
> 
> I am currently putting together an experimental pata_acpi driver to play
> with this stuff. May take a bit of time while I work out the current acpi
> interface gunge and how to expand it.
> 
> The fact we have to try each mode to see what we can set doesn't make it
> pretty either!

Make sure you take a look at libata-dev.git#acpi which is the origin of 
the libata ACPI support found in -mm

That's pending for an upstream merge.

	Jeff

Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did

[Sergei Shtylyov]

Tejun Heo wrote:

> CK804 IDE, at least mine, reports 80c in a lot of cases where it
> shouldn't.  I dunno the reason but it also makes drives confused about
> cable type.  Maybe it has the wrong capacitor attached or something.
> This is A8N-E from ASUS, probably one of the popular ones using nf4.

> When that happens, libata EH does its job and slows the interface to
> udma33 after quite a few error messages.  On IDE, if this happens, the
> drive is put into PIO mode making the machine painful to use.

    Why? The old IDE core should just be downgrading UDMA to a speed where it 
starts working (i.e. 44 or 33 MB/s usually).

MBR, Sergei