The UDMA66 VIA hardware has no controller side cable detect bits we can
use. This patch minimally fixes the problem by reporting unknown in this
case and using drive side detection.
The old drivers/ide code does some additional tricks but those aren't
appropriate now we are in -rc.
Without this update UDMA66 via controllers run slowly. They don't fail so
it's a borderline call whether this is -rc material or not.
Signed-off-by: Alan Cox <[email protected]>
--- linux.vanilla-2.6.20-rc1/drivers/ata/pata_via.c 2006-12-14 17:23:30.000000000 +0000
+++ linux-2.6.20-rc1/drivers/ata/pata_via.c 2006-12-16 14:05:12.044300968 +0000
@@ -161,10 +161,15 @@
return -ENOENT;
}
- if ((config->flags & VIA_UDMA) >= VIA_UDMA_66)
+ if ((config->flags & VIA_UDMA) >= VIA_UDMA_100)
ap->cbl = via_cable_detect(ap);
- else
+ /* The UDMA66 series has no cable detect so do drive side detect */
+ else if ((config->flags & VIA_UDMA) < VIA_UDMA_66)
ap->cbl = ATA_CBL_PATA40;
+ else
+ ap->cbl = ATA_CBL_PATA_UNK;
+
+
return ata_std_prereset(ap);
}
Alan wrote:
> The UDMA66 VIA hardware has no controller side cable detect bits we can
> use. This patch minimally fixes the problem by reporting unknown in this
> case and using drive side detection.
>
> The old drivers/ide code does some additional tricks but those aren't
> appropriate now we are in -rc.
>
> Without this update UDMA66 via controllers run slowly. They don't fail so
> it's a borderline call whether this is -rc material or not.
>
> Signed-off-by: Alan Cox <[email protected]>
I think it's #upstream-fixes material (-rc material), and applied as such.
Especially considering that libata pata_* drivers are not the primary
drivers, I think it's best to forward this type of stuff, especially as
it is indeed IMO a fix worth having.
On Sat, Dec 16, 2006 at 10:47:49AM -0500, Jeff Garzik wrote:
> I think it's #upstream-fixes material (-rc material), and applied as such.
>
> Especially considering that libata pata_* drivers are not the primary
> drivers, I think it's best to forward this type of stuff, especially as
> it is indeed IMO a fix worth having.
They may not be primary today, but it's not going to be very long
at all before that situation changes. AFAIK, most of (if not all) the major
distros basing on 2.6.19+ are moving to using the libata PATA drivers in
their next releases.
Dave
--
http://www.codemonkey.org.uk
Dave Jones wrote:
> On Sat, Dec 16, 2006 at 10:47:49AM -0500, Jeff Garzik wrote:
>
> > I think it's #upstream-fixes material (-rc material), and applied as such.
> >
> > Especially considering that libata pata_* drivers are not the primary
> > drivers, I think it's best to forward this type of stuff, especially as
> > it is indeed IMO a fix worth having.
>
> They may not be primary today, but it's not going to be very long
> at all before that situation changes. AFAIK, most of (if not all) the major
> distros basing on 2.6.19+ are moving to using the libata PATA drivers in
> their next releases.
All the more reason to get fixes in as quickly as possible, to ensure
maximal amount of testing and exposure :)
Jeff