Re: [PATCH 3/3] pata_amd: fix and improve cable detection

[Tejun Heo <htejun@gmail.com>]

Alan Cox wrote:
>> all we can use is how the BIOS configured it.  I suppose BIOS does it by
>> issuing trial commands which I don't think adding to libata is a good idea.
> 
> The BIOS does it by asking the hardware somehow. I traced one or two
> BIOSes that far. The info is there but its not documented in the
> slightest so only ACPI makes it visible via the BIOS.

OIC, gawdddddddd... What was so long with just following what those
AMD chips did?

>> Can you please lemme know what you don't like about the current
>> implementation or what other approach you have in mind?  I don't like
>> Nvidia PATA either but there are a lot of people using it out there.
> 
> We seem to be able to trust the drives and BIOS ACPI data for Nvidia (at
> least what I have seen), so I guess we should simply declare the cable
> type unknown, 80 wire if ACPI says it is and then do the drive detect
> side ?

There are machines with broken BIOSen so actually the most reliable
source is the UDMA timing register.  On ASUS A8N-E, ACPI and UDMA
timing register always concur.  I think it's best to look at both not
so much for accuracy but for debugging, so the following printk in the
patch.

+	if (ap->pflags & ATA_PFLAG_INIT_GTM_VALID)
+		snprintf(acpi_str, sizeof(acpi_str), " (%u:%u:0x%x)",
+			 ap->acpi_init_gtm.drive[0].dma,
+			 ap->acpi_init_gtm.drive[1].dma,
+			 ap->acpi_init_gtm.flags);
+
+	ata_port_printk(ap, KERN_DEBUG, "nv_cable_detect: native=%d (0x%x) "
+			"BIOS=%d (0x%x) ACPI=%d%s verdict=%d\n",
+			native_cbl, ata66, bios_cbl, saved_udma, acpi_cbl,
+			acpi_str, verdict);

When cable detection goes wrong, we'll at least know what all those
different sources are telling.

Thanks.

-- 
tejun