* RE: Fwd: hpet patches
@ 2005-06-15 17:15 Pallipadi, Venkatesh
2005-06-15 17:54 ` Jon Smirl
0 siblings, 1 reply; 12+ messages in thread
From: Pallipadi, Venkatesh @ 2005-06-15 17:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: Bob Picco, Andrew Morton, lkml
>-----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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: hpet patches
2005-06-15 17:15 Fwd: hpet patches Pallipadi, Venkatesh
@ 2005-06-15 17:54 ` Jon Smirl
2005-06-15 18:11 ` Lee Revell
2005-06-16 14:00 ` Vitezslav Samel
0 siblings, 2 replies; 12+ messages in thread
From: Jon Smirl @ 2005-06-15 17:54 UTC (permalink / raw)
To: Pallipadi, Venkatesh; +Cc: Bob Picco, Andrew Morton, lkml
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: hpet patches
2005-06-15 17:54 ` Jon Smirl
@ 2005-06-15 18:11 ` Lee Revell
2005-06-16 14:00 ` Vitezslav Samel
1 sibling, 0 replies; 12+ messages in thread
From: Lee Revell @ 2005-06-15 18:11 UTC (permalink / raw)
To: Jon Smirl
Cc: George Anzinger, Pallipadi, Venkatesh, Bob Picco, Andrew Morton, lkml
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: hpet patches
2005-06-15 17:54 ` Jon Smirl
2005-06-15 18:11 ` Lee Revell
@ 2005-06-16 14:00 ` Vitezslav Samel
1 sibling, 0 replies; 12+ messages in thread
From: Vitezslav Samel @ 2005-06-16 14:00 UTC (permalink / raw)
To: Jon Smirl; +Cc: Pallipadi, Venkatesh, Bob Picco, Andrew Morton, lkml
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Fwd: hpet patches
@ 2005-06-14 23:16 Pallipadi, Venkatesh
2005-06-14 23:36 ` Jon Smirl
0 siblings, 1 reply; 12+ messages in thread
From: Pallipadi, Venkatesh @ 2005-06-14 23:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: Bob Picco, Andrew Morton, lkml
>-----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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: hpet patches
2005-06-14 23:16 Pallipadi, Venkatesh
@ 2005-06-14 23:36 ` Jon Smirl
2005-06-15 0:51 ` Andi Kleen
0 siblings, 1 reply; 12+ messages in thread
From: Jon Smirl @ 2005-06-14 23:36 UTC (permalink / raw)
To: Pallipadi, Venkatesh; +Cc: Bob Picco, Andrew Morton, lkml
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: hpet patches
2005-06-14 23:36 ` Jon Smirl
@ 2005-06-15 0:51 ` Andi Kleen
0 siblings, 0 replies; 12+ messages in thread
From: Andi Kleen @ 2005-06-15 0:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: Bob Picco, Andrew Morton, lkml
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Fwd: hpet patches
@ 2005-06-14 22:37 Pallipadi, Venkatesh
2005-06-14 23:11 ` Jon Smirl
0 siblings, 1 reply; 12+ messages in thread
From: Pallipadi, Venkatesh @ 2005-06-14 22:37 UTC (permalink / raw)
To: Jon Smirl, Bob Picco; +Cc: Andrew Morton, lkml
>-----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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: hpet patches
2005-06-14 22:37 Pallipadi, Venkatesh
@ 2005-06-14 23:11 ` Jon Smirl
0 siblings, 0 replies; 12+ messages in thread
From: Jon Smirl @ 2005-06-14 23:11 UTC (permalink / raw)
To: Pallipadi, Venkatesh; +Cc: Bob Picco, Andrew Morton, lkml
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
^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <88056F38E9E48644A0F562A38C64FB6004F77C29@scsmsx403.amr.corp.intel.com>]
end of thread, other threads:[~2005-06-16 14:01 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-15 17:15 Fwd: hpet patches Pallipadi, Venkatesh
2005-06-15 17:54 ` Jon Smirl
2005-06-15 18:11 ` Lee Revell
2005-06-16 14:00 ` Vitezslav Samel
-- strict thread matches above, loose matches on Subject: below --
2005-06-14 23:16 Pallipadi, Venkatesh
2005-06-14 23:36 ` Jon Smirl
2005-06-15 0:51 ` Andi Kleen
2005-06-14 22:37 Pallipadi, Venkatesh
2005-06-14 23:11 ` Jon Smirl
[not found] <88056F38E9E48644A0F562A38C64FB6004F77C29@scsmsx403.amr.corp.intel.com>
[not found] ` <9e473391050614092661d665ee@mail.gmail.com>
[not found] ` <20050614164605.GQ3728@localhost.localdomain>
2005-06-14 17:50 ` Jon Smirl
2005-06-14 18:38 ` Bob Picco
2005-06-14 21:51 ` Jon Smirl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).