> Unfortunately, link order appears to have no effect when the drivers in
> question are built modular, as appears to be the typical case, unlike
> old IDE where they were generally built in because of all the other
> busted behavior if you built the drivers as modules. This means that
> usersp
Alan wrote:
The link order is set up so that we try things in a very specific
deliberate order
- Hardware specific driver (unless it deliberately punts to ACPI)
- ACPI driver using _GTM/_STM etc
- Generic PCI driver ("stay in the mode the BIOS set and pray")
- ISA register compatibility mode (PI
> Couldn't be do this generically inside libata core somehow, i.e. try to
> use ACPI to set the proper mode and fall back to the driver-specific
> mode setting code if that didn't work? I think if we could do that it
We want to use the native hebaviour first
> would solve a number of problems
> Couldn't be do this generically inside libata core somehow,
> i.e. try to
> use ACPI to set the proper mode and fall back to the driver-specific
> mode setting code if that didn't work? I think if we could do that it
> would solve a number of problems (i.e. we could prevent it from doing
> t
Alan wrote:
On Thu, 22 Feb 2007 12:11:32 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Alan wrote:
ACPI is the only way to do cable handling on the Nvidia PATA chipset. The
You failed to quote the salient part of the message. Disliking a
separate pata_acpi driver in no way invalidates your st
On Thu, 22 Feb 2007 12:11:32 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan wrote:
> > ACPI is the only way to do cable handling on the Nvidia PATA chipset. The
>
> You failed to quote the salient part of the message. Disliking a
> separate pata_acpi driver in no way invalidates your state
Alan wrote:
ACPI is the only way to do cable handling on the Nvidia PATA chipset. The
You failed to quote the salient part of the message. Disliking a
separate pata_acpi driver in no way invalidates your statement (quoted
above).
Jeff
-
To unsubscribe from this list: send the lin
> > It does seem to drive the PATA controllers, but the cable detection
> > doesn't seem to be working:
The cable detection is broken in the base code not in the ACPI driver.
It's totally hosed for most chipsets in PIIX.
> > scsi5 : pata_acpi
> > ata5.00: ATAPI, max UDMA/66
> > ata5.00: limited
Robert Hancock wrote:
Alan wrote:
- Add a driver for motherboard ACPI method devices
- Link it after normal drivers so ACPI is not preferred
- Hook the AMD driver to prefer ACPI for the Nvidia devices if ACPI is
active
- While we are at it fix up the simplex clear the AMD driver.
Depends upon t
Alan wrote:
- Add a driver for motherboard ACPI method devices
- Link it after normal drivers so ACPI is not preferred
- Hook the AMD driver to prefer ACPI for the Nvidia devices if ACPI is
active
- While we are at it fix up the simplex clear the AMD driver.
Depends upon the set_mode -> do_set_m
- Add a driver for motherboard ACPI method devices
- Link it after normal drivers so ACPI is not preferred
- Hook the AMD driver to prefer ACPI for the Nvidia devices if ACPI is
active
- While we are at it fix up the simplex clear the AMD driver.
Depends upon the set_mode -> do_set_mode wrapper pa
11 matches
Mail list logo
