Re: Fwd: hpet patches

Re: Fwd: hpet patches

[Jon Smirl]

On 6/14/05, Bob Picco <bob.picco@hp.com> wrote:
> Jon,
> Jon Smirl wrote:        [Tue Jun 14 2005, 12:26:41PM EDT]
> > Apparently there are many Dell systems that have an HPET but Dell is
> > not providing the ACPI entry. Can we add some probing for the HPET or
> > use something like the ICH5 PCI ID to enable it?
> This is also true of HP x86 and x86_64 (AMD 8000 chipset) hardware.  I enabled
> it on my HP x86_64 with the appropriate PCI commands but it has been a while
> and can't recall the details.  This solution is good for platform specific
> configuration but of course doesn't enable the driver discovery to work.
> 
> I also verified that the Documentation/hpet.txt sample program worked. I can't
> remember who (SuSE ?) posted the x86_64 HPET stuff just before I
> finished.  So I never posted. I didn't feel great about the solution because
> the address was hardcoded. I found myself more irritated at HP for not having
> configured it in the BIOS and ACPI table.
> >
> > I have verified that all Dimension 8300, PE400, Precision 360 have
> > this problem. From what I can tell many other Dell models are also
> > missing HPET ACPI. The problem is not universal, there are a few Dell
> > models that do have the ACPI entry.
> 
> bob
> 

Problem like this are usually fixed with quirks:

DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   
PCI_DEVICE_ID_INTEL_82801EB_0,  quirk_intel_ich5_hpet);

quirk_intel_ich5_hpet()
{
    if (!hpet_address)
          hpet_address = 0xfed00000ULL;
}

0xfed00000ULL is right for ICH5, do you want to start adding these as
part of HPET support? My hpet works fine once the address is set. For
complete coverage you need a list of these for all of the AMD/Intel
chipsets with hpet support. The list isn't very big.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Fwd: hpet patches

[Bob Picco]

Jon Smirl wrote:	[Tue Jun 14 2005, 01:50:49PM EDT]
> On 6/14/05, Bob Picco <bob.picco@hp.com> wrote:
> > Jon,
> > Jon Smirl wrote:        [Tue Jun 14 2005, 12:26:41PM EDT]
> > > Apparently there are many Dell systems that have an HPET but Dell is
> > > not providing the ACPI entry. Can we add some probing for the HPET or
> > > use something like the ICH5 PCI ID to enable it?
> > This is also true of HP x86 and x86_64 (AMD 8000 chipset) hardware.  I enabled
> > it on my HP x86_64 with the appropriate PCI commands but it has been a while
> > and can't recall the details.  This solution is good for platform specific
> > configuration but of course doesn't enable the driver discovery to work.
> > 
> > I also verified that the Documentation/hpet.txt sample program worked. I can't
> > remember who (SuSE ?) posted the x86_64 HPET stuff just before I
> > finished.  So I never posted. I didn't feel great about the solution because
> > the address was hardcoded. I found myself more irritated at HP for not having
> > configured it in the BIOS and ACPI table.
> > >
> > > I have verified that all Dimension 8300, PE400, Precision 360 have
> > > this problem. From what I can tell many other Dell models are also
> > > missing HPET ACPI. The problem is not universal, there are a few Dell
> > > models that do have the ACPI entry.
> > 
> > bob
> > 
> 
> Problem like this are usually fixed with quirks:
> 
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   
> PCI_DEVICE_ID_INTEL_82801EB_0,  quirk_intel_ich5_hpet);
> 
> quirk_intel_ich5_hpet()
> {
>     if (!hpet_address)
>           hpet_address = 0xfed00000ULL;
> }
> 
> 0xfed00000ULL is right for ICH5, do you want to start adding these as
> part of HPET support? My hpet works fine once the address is set. For
> complete coverage you need a list of these for all of the AMD/Intel
> chipsets with hpet support. The list isn't very big.
> 
Well my ignorance is going to show here.  The platform initialization code
has already run and PCI probing happens later.  How do you reconcile Venki's
concern for an HPET armed for legacy support when platform
is already using PIT?  Also the hpet driver isn't a PCI driver but 
ACPI driver.  It's working for you so I'm obviously missing a detail.

bob

Re: Fwd: hpet patches

[Jon Smirl]

On 6/14/05, Bob Picco <bob.picco@hp.com> wrote:
> Jon Smirl wrote:        [Tue Jun 14 2005, 01:50:49PM EDT]
> > Problem like this are usually fixed with quirks:
> >
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
> > PCI_DEVICE_ID_INTEL_82801EB_0,  quirk_intel_ich5_hpet);
> >
> > quirk_intel_ich5_hpet()
> > {
> >     if (!hpet_address)
> >           hpet_address = 0xfed00000ULL;
> > }
> >
> > 0xfed00000ULL is right for ICH5, do you want to start adding these as
> > part of HPET support? My hpet works fine once the address is set. For
> > complete coverage you need a list of these for all of the AMD/Intel
> > chipsets with hpet support. The list isn't very big.
> >
> Well my ignorance is going to show here.  The platform initialization code
> has already run and PCI probing happens later.  How do you reconcile Venki's
> concern for an HPET armed for legacy support when platform
> is already using PIT?  Also the hpet driver isn't a PCI driver but
> ACPI driver.  It's working for you so I'm obviously missing a detail.

You don't actually use the PCI_FIXUP macros. You make a new one called
ACPI_FIXUP and run them right after ACPI is read and before you do
anything else. I was just illustrating how the quirk fixup system
worked.

To make it work on my system I just added an assignment statement for
the fix right after the ACPI code looked for the HPET entry. But
that's not a general solution, building the ACPI_FIXUP macros is one.

-- 
Jon Smirl
jonsmirl@gmail.com

RE: Fwd: hpet patches

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Jon Smirl [mailto:jonsmirl@gmail.com] 
>Sent: Tuesday, June 14, 2005 2:51 PM
>To: Bob Picco
>Cc: Pallipadi, Venkatesh; Andrew Morton; lkml
>Subject: Re: Fwd: hpet patches
>
>On 6/14/05, Bob Picco <bob.picco@hp.com> wrote:
>> Jon Smirl wrote:        [Tue Jun 14 2005, 01:50:49PM EDT]
>> > Problem like this are usually fixed with quirks:
>> >
>> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
>> > PCI_DEVICE_ID_INTEL_82801EB_0,  quirk_intel_ich5_hpet);
>> >
>> > quirk_intel_ich5_hpet()
>> > {
>> >     if (!hpet_address)
>> >           hpet_address = 0xfed00000ULL;
>> > }
>> >
>> > 0xfed00000ULL is right for ICH5, do you want to start 
>adding these as
>> > part of HPET support? My hpet works fine once the address 
>is set. For
>> > complete coverage you need a list of these for all of the AMD/Intel
>> > chipsets with hpet support. The list isn't very big.
>> >
>> Well my ignorance is going to show here.  The platform 
>initialization code
>> has already run and PCI probing happens later.  How do you 
>reconcile Venki's
>> concern for an HPET armed for legacy support when platform
>> is already using PIT?  Also the hpet driver isn't a PCI driver but
>> ACPI driver.  It's working for you so I'm obviously missing a detail.
>
>You don't actually use the PCI_FIXUP macros. You make a new one called
>ACPI_FIXUP and run them right after ACPI is read and before you do
>anything else. I was just illustrating how the quirk fixup system
>worked.
>
>To make it work on my system I just added an assignment statement for
>the fix right after the ACPI code looked for the HPET entry. But
>that's not a general solution, building the ACPI_FIXUP macros is one.
>

OK. I was thinking PCI fixup is to late in the initialization for 
HPET fixup. But, we should be OK with a new ACPI_FIXUP macro. My only
other concern is, we should safely fallback to PIT, when our fixed_up 
HPET address isn't right.

Thanks,
Venki

Re: Fwd: hpet patches

[Jon Smirl]

On 6/14/05, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
> OK. I was thinking PCI fixup is to late in the initialization for
> HPET fixup. But, we should be OK with a new ACPI_FIXUP macro. My only
> other concern is, we should safely fallback to PIT, when our fixed_up
> HPET address isn't right.

If we're keying off from the PCI ID for the chip, how can it not have
the device? On the other hand, it would probably be good to always do
a little test on the HPET and fall back to the PIT if the HPET is
dead.

-- 
Jon Smirl
jonsmirl@gmail.com

RE: Fwd: hpet patches

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Jon Smirl [mailto:jonsmirl@gmail.com] 
>Sent: Tuesday, June 14, 2005 4:11 PM
>To: Pallipadi, Venkatesh
>Cc: Bob Picco; Andrew Morton; lkml
>Subject: Re: Fwd: hpet patches
>
>On 6/14/05, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
>> OK. I was thinking PCI fixup is to late in the initialization for
>> HPET fixup. But, we should be OK with a new ACPI_FIXUP macro. My only
>> other concern is, we should safely fallback to PIT, when our fixed_up
>> HPET address isn't right.
>
>If we're keying off from the PCI ID for the chip, how can it not have
>the device? On the other hand, it would probably be good to always do
>a little test on the HPET and fall back to the PIT if the HPET is
>dead.

HPET device itself can be there. But, it can appear in different 
addresses. Most commonly used address is 0xfed00000. But, it can be 
different as well. 

Thanks,
Venki

Re: Fwd: hpet patches

[Jon Smirl]

On 6/14/05, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
> HPET device itself can be there. But, it can appear in different
> addresses. Most commonly used address is 0xfed00000. But, it can be
> different as well.

Does Intel build different versions of something like an 82801EB with
the HPET at different addresses and still have the same part number?
For a specific part number/PCI ID isn't HPET always in the same place?
If the HPET is going to be in a different place I would expected the
chip would have a different PCI ID.

I would think that the ACPI fixup table would look something like:
ACPI_FIXUP(INTEL, ICH4, hpet_ich4_fixup)
ACPI_FIXUP(INTEL, ICH4M, hpet_ich4m_fixup)
ACPI_FIXUP(INTEL, ICH5, hpet_ich5_fixup)
ACPI_FIXUP(INTEL, ICH6, hpet_ich6_fixup)

hpet_ich4_fixup()
{
     hpet_address = 0xfed00000; or whatever
}
hpet_ich4m_fixup()
{
     hpet_address = 0xfed00000; or whatever
}
hpet_ich5_fixup()
{
     hpet_address = 0xfed00000; or whatever
}
hpet_ich6_fixup()
{
     hpet_address = 0xfed00000; or whatever
}

or something like:
ACPI_FIXUP(INTEL, ICH4, hpet_ich4_fixup)
ACPI_FIXUP(INTEL, ICH4M, hpet_ich4m_fixup)
ACPI_FIXUP(INTEL, ICH5, hpet_standard_fixup)
ACPI_FIXUP(INTEL, ICH6, hpet_standard_fixup)
ACPI_FIXUP(INTEL, ICH6M, hpet_standard_fixup)
with one line for each chip (less than 10?) that Intel has released
containing an HPET.

hpet_standard_fixup()
{
     hpet_address = 0xfed00000;
}
hpet_ich4_fixup()
{
     hpet_address = special case;
}
hpet_ich4m_fixup()
{
     hpet_address = special case;
}

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Fwd: hpet patches

[Andi Kleen]

Jon Smirl <jonsmirl@gmail.com> writes:

> On 6/14/05, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
>> HPET device itself can be there. But, it can appear in different
>> addresses. Most commonly used address is 0xfed00000. But, it can be
>> different as well.
>
> Does Intel build different versions of something like an 82801EB with
> the HPET at different addresses and still have the same part number?

Sometimes the address can be configured in the chipset and HPET also
be disabled. So the only reliable way would be to check the chipset 
registers for each chipset. Unfortunately some are undocumented
(e.g. i've been trying to figure that out for Nvidia for quite some time
to no avail :/) 

-Andi

RE: Fwd: hpet patches

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Jon Smirl [mailto:jonsmirl@gmail.com] 
>Sent: Tuesday, June 14, 2005 4:37 PM
>To: Pallipadi, Venkatesh
>Cc: Bob Picco; Andrew Morton; lkml
>Subject: Re: Fwd: hpet patches
>
>On 6/14/05, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
>> HPET device itself can be there. But, it can appear in different
>> addresses. Most commonly used address is 0xfed00000. But, it can be
>> different as well.
>
>Does Intel build different versions of something like an 82801EB with
>the HPET at different addresses and still have the same part number?
>For a specific part number/PCI ID isn't HPET always in the same place?
>If the HPET is going to be in a different place I would expected the
>chip would have a different PCI ID.
>

The specification for ICH5 has the details about this address
http://www.intel.com/design/chipsets/datashts/25251601.pdf (Chapter 17).
We need to look at specific device address to figure out the HPET base 
address in this case.


Thanks,
Venki

Re: Fwd: hpet patches

[Jon Smirl]

On 6/15/05, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
> The specification for ICH5 has the details about this address
> http://www.intel.com/design/chipsets/datashts/25251601.pdf (Chapter 17).
> We need to look at specific device address to figure out the HPET base
> address in this case.

The ICH5 fix up needs to look something like this:
PCI_DEVICE_ID_INTEL_82801EB_0 is the PCI ID for the LPC device.

ACPI_FIXUP(INTEL, PCI_DEVICE_ID_INTEL_82801EB_0, hpet_ich5_fixup)
hpet_ich5_fixup()
{
     pci_bios_find_device(PCI_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0, ...)
     pci_bios_read(device, GENERAL_CONTROL_REGISTER, ..)
     Check bit 17 and see if it is enabled
     use bit 15:16 to set hpet_address to one of the four addresses
}

It would be more complicated to try and turn it on if it is turned
off. Mine is turned on at boot even though it has no ACPI entry. A
routine like this should at least get things started.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Fwd: hpet patches

[Lee Revell]

On Wed, 2005-06-15 at 13:54 -0400, Jon Smirl wrote:
> It would be more complicated to try and turn it on if it is turned
> off. Mine is turned on at boot even though it has no ACPI entry. A
> routine like this should at least get things started.
> 

I think you are reinventing the wheel, the high res timers patch already
has the necessary voodoo to find and enable the HPET, AFAICT it already
handles your situation (HPET present but missing from ACPI table).

http://sourceforge.net/projects/high-res-timers/

Lee

Re: Fwd: hpet patches

[Vitezslav Samel]

On Wed, Jun 15, 2005 at 01:54:16PM -0400, Jon Smirl wrote:
> On 6/15/05, Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
> > The specification for ICH5 has the details about this address
> > http://www.intel.com/design/chipsets/datashts/25251601.pdf (Chapter 17).
> > We need to look at specific device address to figure out the HPET base
> > address in this case.
> 
> The ICH5 fix up needs to look something like this:
> PCI_DEVICE_ID_INTEL_82801EB_0 is the PCI ID for the LPC device.
> 
> ACPI_FIXUP(INTEL, PCI_DEVICE_ID_INTEL_82801EB_0, hpet_ich5_fixup)
> hpet_ich5_fixup()
> {
>      pci_bios_find_device(PCI_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0, ...)
>      pci_bios_read(device, GENERAL_CONTROL_REGISTER, ..)
>      Check bit 17 and see if it is enabled
>      use bit 15:16 to set hpet_address to one of the four addresses
> }
> 
> It would be more complicated to try and turn it on if it is turned
> off. Mine is turned on at boot even though it has no ACPI entry.

  On our HP DL380g4 (ICH5 chipset) it is turned off. Could you, please,
try to turn it on in your patches? I'll be glad to test your patches.

	Thanks,
		Vita