> 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
>
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
> 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
>
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
this
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
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
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
userspace
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
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
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
> > 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
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 to
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
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 statement
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
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
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 ->
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 -
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
- 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
- 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
22 matches
Mail list logo
