Attempting to patch DSDT to get HPET working

Attempting to patch DSDT to get HPET working

[Russ Dill]

I have an AMD SB460 southbridge (has HPET), but a BIOS with no HPET
support. I tried contacting ACER to see if they have plans for this:

> Thank you for contacting Acer America. I apologize in the delay in
> responding to your inquiry. At this time, Acer does not have any plans to
> offer a BIOS update to support HPET. Any BIOS updates for this computer
>will be posted at www.acerpanam.com, in the Drivers and Downloads section,
> as they become available.

So my two options are to hardcode it into the kernel (requires
recompilation) or modify my DSDT. Since the ubuntu kernel supports
loading an updated DSDT.aml in the initramfs, I'm trying this route.

I added this:

Device (HPET)
{
    Name (_HID, EisaId ("PNP0103"))
    Name (BUF0, ResourceTemplate ()
    {
        IRQNoFlags () {0}
        IRQNoFlags () {8}
        Memory32Fixed (ReadOnly, 0xFED00000, 0x00000400)
    })

    Method (_STA, 0, NotSerialized)
    {
         Return (0x0F)
    }

    Method (_CRS, 0, Serialized)
    {
        CreateDWordField (BUF0, 0x0A, HPT0)
        Store (0xFED01000, HPT0)
        Return (BUF0)
    }
}

between my Device (HMAC) stanza and my Device (MATH) stanza. On boot,
the kernel indicates that its loading an updated DSDT out of the
initramfs, and later on down the line, I get the following message:

hpet_acpi_add: no address or irqs in _CRS

So, good news, drivers/char/hpet.c is finding my PNP0103 entry. Bad
news, its having a problem with the resources. Any clue why?

(Machine is Acer Ferrari 5000, BIOS version 3225, ubuntu linux kernel 2.6.22-10)

Re: Attempting to patch DSDT to get HPET working

[Bjorn Helgaas]

On Wednesday 29 August 2007 11:20:47 pm Russ Dill wrote:
> I have an AMD SB460 southbridge (has HPET), but a BIOS with no HPET
> support.
> ...
> I added this:
> 
> Device (HPET)
> {
>     Name (_HID, EisaId ("PNP0103"))
>     Name (BUF0, ResourceTemplate ()
>     {
>         IRQNoFlags () {0}
>         IRQNoFlags () {8}
>         Memory32Fixed (ReadOnly, 0xFED00000, 0x00000400)
>     })
> 
>     Method (_STA, 0, NotSerialized)
>     {
>          Return (0x0F)
>     }
> 
>     Method (_CRS, 0, Serialized)
>     {
>         CreateDWordField (BUF0, 0x0A, HPT0)
>         Store (0xFED01000, HPT0)
>         Return (BUF0)
>     }
> }
> 
> ... I get the following message:
> 
> hpet_acpi_add: no address or irqs in _CRS
> 
> So, good news, drivers/char/hpet.c is finding my PNP0103 entry. Bad
> news, its having a problem with the resources. Any clue why?

If you look at drivers/char/hpet.c:hpet_resources(), you'll see that
it's fairly simple-minded.  In particular, hpet_acpi_add() requires
both an address and an IRQ, but hpet_resources() only looks at
ACPI_RESOURCE_TYPE_EXTENDED_IRQ items.

I'm not an AML expert, but my guess is that your AML generates a
plain ACPI_RESOURCE_TYPE_IRQ, not an EXTENDED_IRQ item.  If you can
write AML that generates an EXTENDED_IRQ item, I bet it will work.

This is a bug in the HPET driver.  I think the right way to fix it
is to convert it from an ACPI driver to a PNP driver and let PNPACPI
do the resource parsing.  That conversion is held up a bit right now
because PNP doesn't support enough IRQ descriptors for many HPETs,
but Thomas Renninger is working on the necessary PNP enhancements.

Bjorn

Re: Attempting to patch DSDT to get HPET working

[Thomas Renninger]

On Sat, 2007-09-08 at 13:47 -0600, Bjorn Helgaas wrote:
> On Wednesday 29 August 2007 11:20:47 pm Russ Dill wrote:
> > I have an AMD SB460 southbridge (has HPET), but a BIOS with no HPET
> > support.
> > ...
> > I added this:
> > 
> > Device (HPET)
> > {
> >     Name (_HID, EisaId ("PNP0103"))
> >     Name (BUF0, ResourceTemplate ()
> >     {
> >         IRQNoFlags () {0}
> >         IRQNoFlags () {8}
> >         Memory32Fixed (ReadOnly, 0xFED00000, 0x00000400)
> >     })
> > 
> >     Method (_STA, 0, NotSerialized)
> >     {
> >          Return (0x0F)
> >     }
> > 
> >     Method (_CRS, 0, Serialized)
> >     {
> >         CreateDWordField (BUF0, 0x0A, HPT0)
> >         Store (0xFED01000, HPT0)
> >         Return (BUF0)
> >     }
> > }
> > 
> > ... I get the following message:
> > 
> > hpet_acpi_add: no address or irqs in _CRS
> > 
> > So, good news, drivers/char/hpet.c is finding my PNP0103 entry. Bad
> > news, its having a problem with the resources. Any clue why?
> 
> If you look at drivers/char/hpet.c:hpet_resources(), you'll see that
> it's fairly simple-minded.  In particular, hpet_acpi_add() requires
> both an address and an IRQ, but hpet_resources() only looks at
> ACPI_RESOURCE_TYPE_EXTENDED_IRQ items.
> 
> I'm not an AML expert, but my guess is that your AML generates a
> plain ACPI_RESOURCE_TYPE_IRQ, not an EXTENDED_IRQ item.  If you can
> write AML that generates an EXTENDED_IRQ item, I bet it will work.
> 
> This is a bug in the HPET driver.  I think the right way to fix it
> is to convert it from an ACPI driver to a PNP driver and let PNPACPI
> do the resource parsing.  That conversion is held up a bit right now
> because PNP doesn't support enough IRQ descriptors for many HPETs,
> but Thomas Renninger is working on the necessary PNP enhancements.

AFAIK AMD provides a separate HPET table normally and Intel makes use of
an HPET AML device (the later should work, also without PNPACPI, I never
looked at the code, but I bet Bjorn is right and there can be done some
cleanups).
Can you document this matter in a bugzilla.kernel.org entry (also attach
full acpidump output), add me to CC (or assign it to me) and ping me
again in some days if I do not answer.
Whether a separate HPET table is also provided can be checked with:
acpidump >acpidump
acpixtract -a acpidump   (with latest acpica/pmtools)

Thanks,

   Thomas