On 6/14/05, Bob Picco <[email protected]> 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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
