Well, I think that I would rather see SNIP2 (from Suse 8.1 distro) than
SNIP1 from 2.4.20-rc2.
And I hear that there are MB's that won't boot without ACPI.
While I take the point that we are talking about a stable kernel
series, one shouldn't forget that ACPI is configurable :-)
--- SNIP 1 ---
<4> tbutils-0200 [03] Tb_validate_table_head: Table signature at e080f390
[c15ffe24] has invalid characters
<4> tbutils-0202: *** Warning: Invalid table signature ASF! found
<4> tbxface-0095: *** Error: Acpi_load_tables: Error getting required
tables (DSDT/FADT/FACS):AE_BAD_SIGNATURE
<4> tbxface-0116: *** Error: Acpi_load_tables: Could not load tables:
AE_BAD_SIGNATURE
<3>ACPI: System description table load failed
--- END SNIP 1 ---
--- SNIP 2 ---
<7>ACPI: have wakeup address 0x40001000
<6>Advanced speculative caching feature not present
<4>On node 0 totalpages: 130880
<4>zone(0): 4096 pages.
<4>zone(1): 126784 pages.
<4>zone(2): 0 pages.
<6>ACPI: RSDP (v000 ACPIAM ) @ 0x000f70d0
<6>ACPI: RSDT (v001 INTEL D845PESV 08194.04144) @ 0x1ff40000
<6>ACPI: FADT (v002 INTEL D845PESV 08194.04144) @ 0x1ff40200
<6>ACPI: MADT (v001 INTEL D845PESV 08194.04144) @ 0x1ff40300
<6>ACPI: ASF! (v016 AMIASF I845GASF 00000.00001) @ 0x1ff44390
<5>ACPI: BIOS passes blacklist
<4>Building zonelist for node : 0
<6>ACPI: Subsystem revision 20020829
<6>PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2
<6>PCI: Using configuration type 1
<6>ACPI: Interpreter enabled
<6>ACPI: Using PIC for interrupt routing
<6>ACPI: System [ACPI] (supports S0 S1 S4 S5)
<6>ACPI: PCI Root Bridge [PCI0] (00:00)
<4>PCI: Probing PCI hardware (bus 00)
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
<6>ACPI: Power Resource [URP1] (off)
<6>ACPI: Power Resource [FDDP] (off)
<6>ACPI: Power Resource [LPTP] (off)
<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 7 9 10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 11 12 14 *15)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 9 10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 *14 15)
<4>ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 9 10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
<6>PCI: Probing PCI hardware
--- END SNIP 2 ---
> From: Ducrot Bruno [mailto:[email protected]]
> What I mean is that the two seems to conflict.
> Compiling with sonypi but without acpi is OK, without sonypi but
> with acpi should also be OK, but the two should be not safe because
> they use the same io registers in order to ack/clean/enable the same
> interrupt.
It would be great if someone could take a look at the sonypi driver and see
what can be done to integrate it better with ACPI. ACPI includes an EC
driver, so at the minimum, sonypi should use that instead of poking the EC
itself, perhaps.
Regards -- Andy
On Wed, Nov 20, 2002 at 12:02:03PM +0100, Margit Schubert-While wrote:
> While I take the point that we are talking about a stable kernel
> series, one shouldn't forget that ACPI is configurable :-)
So you mean that anything configurable should get into a stable kernel just
because users are not forced to configure it ?
Unless you have the time to add an option "old ACPI / newer ACPI", you cannot
guarantee that there's no risk to break something. If someone has a PC which
needs ACPI to boot, and only the older one, you'll break it. One of the next
pre-releases would be far more appropriate than an -rc.
BTW, I agree that recent ACPI releases seem far more reliable than the one
in vanilla kernel, and I would also be glad to get them in a near future, but
after .20.
Cheers,
Willy
[email protected] said:
> It would be great if someone could take a look at the sonypi driver
> and see what can be done to integrate it better with ACPI. ACPI
> includes an EC driver, so at the minimum, sonypi should use that
> instead of poking the EC itself, perhaps.
Surely a proper driver should always be preferred over binary-only bytecode?
The sonypi driver looks like it properly requests the regions it uses; they
should be marked busy. Why is the ACPI code touching them?
--
dwmw2
On Wed, 2002-11-20 at 21:47, David Woodhouse wrote:
>
> [email protected] said:
> > It would be great if someone could take a look at the sonypi driver
> > and see what can be done to integrate it better with ACPI. ACPI
> > includes an EC driver, so at the minimum, sonypi should use that
> > instead of poking the EC itself, perhaps.
>
> Surely a proper driver should always be preferred over binary-only bytecode?
>
> The sonypi driver looks like it properly requests the regions it uses; they
> should be marked busy. Why is the ACPI code touching them?
The same microcontroller is handling both power management related
operations and also funky things like the camera. In most laptops the
microcontroller is either doing ACPI or APM so there is a convenient
split.
I guess sonypi could take the ACPI global lock ?
[email protected] said:
> I guess sonypi could take the ACPI global lock ?
I assume that's not a serious suggestion. Perhaps it could release the
region while it's not _actually_ using it, and the ACPI code could be fixed
to not touch regions which it doesn't own.
Or we write proper PM code for sonypi and make it not possible to use both
sonypi and ACPI at once.
--
dwmw2
On Wed, 2002-11-20 at 21:59, David Woodhouse wrote:
>
> [email protected] said:
> > I guess sonypi could take the ACPI global lock ?
>
> I assume that's not a serious suggestion. Perhaps it could release the
> region while it's not _actually_ using it, and the ACPI code could be fixed
> to not touch regions which it doesn't own.
It isnt about regions. The microcontroller talks a message protocol,
much the same actually as most power microcontroller seem to do. Its
just Sony also added other stuff to the protocol.
Taking the acpi lock looks like its a generic way to deal with this
situation. Its made more important because a few sony laptops actually
require ACPI to do pci/irq setup
> From: David Woodhouse [mailto:[email protected]]
> [email protected] said:
> > I guess sonypi could take the ACPI global lock ?
>
> I assume that's not a serious suggestion. Perhaps it could
> release the
> region while it's not _actually_ using it, and the ACPI code
> could be fixed
> to not touch regions which it doesn't own.
>
> Or we write proper PM code for sonypi and make it not
> possible to use both
> sonypi and ACPI at once.
When I looked a few years ago, 0x60 through 0x6F were marked owned by the
keyboard driver (even though it only really uses 0x60 and 0x64). I don't see
either ACPI *or* sonypi currently claiming those IO ports properly. (sonypi
claims some ioports but not 0x62 and 0x66, probably for this reason.)
> Surely a proper driver should always be preferred over
> binary-only bytecode?
The ACPI EC driver uses AML to properly configure itself (the cmd and data
ports actually can vary, and grabbing the GL is only sometimes required) but
beyond that the interpreter is not used.
However, since the only user of the EC driver until now has been ACPI, we
will need to do some work there to have nice, externally-callable
interfaces.
...and I suppose there will need to be some ifdef trickery to keep things
working when the ACPI EC driver is not there.
Stelian Pop is the current mantainer? Or davej? I should be able to do a
patch shortly to submit to whomever.
Regards -- Andy
On Wed, Nov 20, 2002 at 05:24:23PM -0800, Grover, Andrew wrote:
>
> Stelian Pop is the current mantainer? Or davej? I should be able to do a
> patch shortly to submit to whomever.
Stelian owns that one.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, Nov 20, 2002 at 09:59:30PM +0000, David Woodhouse wrote:
>
> [email protected] said:
> > I guess sonypi could take the ACPI global lock ?
>
> I assume that's not a serious suggestion. Perhaps it could release the
> region while it's not _actually_ using it, and the ACPI code could be fixed
> to not touch regions which it doesn't own.
>
> Or we write proper PM code for sonypi and make it not possible to use both
> sonypi and ACPI at once.
It could be a solution, especially if you have a proper APM, but
you have also to implement in sonypi at least a replacement for the
idle loop in order to get power state saving of the processor, and
also have more battery saving. Of course, this is the first feature
I think about the new acpi code.
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page