Alan Cox wrote:
>> detection. We're basically just trying to follow what BIOS did. Maybe
>> we should return ATA_CBL_PATA_MAYBE_80 unconditionally and implement
>
> MAYBE_80 = UNK.
Yeah, right. I somehow thought it was close to "don't really know but
treat as 40c" but it's more like "don't rea
> detection. We're basically just trying to follow what BIOS did. Maybe
> we should return ATA_CBL_PATA_MAYBE_80 unconditionally and implement
MAYBE_80 = UNK.
> ata_acpi_more_filter()?
We can also use UNK intelligently in the eh code to go straight from
UDMA133/100/66 to 33 (if you don't alrea
Alan Cox wrote:
>> 2. UDMA mode is configured but equal to or under UDMA33. Dunno whether
>> it's cable or device limit but anyways you better limit it to UDMA33 too.
>
> If it is under UDMA33 you know it isn't a cable limit
>
> If it is UDMA 33 and the device top is > UDMA 33 it might be
>
> T
> 2. UDMA mode is configured but equal to or under UDMA33. Dunno whether
> it's cable or device limit but anyways you better limit it to UDMA33 too.
If it is under UDMA33 you know it isn't a cable limit
If it is UDMA 33 and the device top is > UDMA 33 it might be
This matters as you've got to a
On Saturday 03 November 2007, Bartlomiej Zolnierkiewicz wrote:
> On Friday 02 November 2007, Alan Cox wrote:
> > > Using the initial GTM value is the right thing to do because both are
> > > trying to check firmware setting and by the time ->cable_detect runs
> > > the controller is already forced
On Friday 02 November 2007, Alan Cox wrote:
> > Using the initial GTM value is the right thing to do because both are
> > trying to check firmware setting and by the time ->cable_detect runs
> > the controller is already forced into PIO0 by reset.
>
> As we only look at the DMA bits that doesn't m
Alan Cox wrote:
>> What the function answers is not actually cable type but "according to
>> the current configuration, using this cable type won't violate BIOS
>> configuration" kind of answer. How the caller is to use that is the
>> caller's responsibility.
>
> How does the caller make use of i
> GTM results do change whether you call STM or not. GTM in many cases is
> implemented as reading the current configuration value from the
> controller so if you configure PIO0, it will return PIO0 timings. And,
> yeah, on ASUS A8N-E, if you configure PIO0, GTM answer says DMA is off.
Oh fun -
Alan Cox wrote:
>> Using the initial GTM value is the right thing to do because both are
>> trying to check firmware setting and by the time ->cable_detect runs
>> the controller is already forced into PIO0 by reset.
>
> As we only look at the DMA bits that doesn't matter but I agree it would
> be
> Using the initial GTM value is the right thing to do because both are
> trying to check firmware setting and by the time ->cable_detect runs
> the controller is already forced into PIO0 by reset.
As we only look at the DMA bits that doesn't matter but I agree it would
be cleaner if we were more
The current ata_acpi_cbl_80wire() is too retricted in its
functionality. It always reads GTM itself and only returns whether
the cable is 80 wire or not. Extend it such that...
* It accepts @gtm argument instead of reading iteslf.
* Returns one of ATA_CBL_PATA40, ATA_CBL_PATA80 or ATA_CBL_PATA_
11 matches
Mail list logo
