All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: Bob Picco <bob.picco@hp.com>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	Andrew Morton <akpm@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: Fwd: hpet patches
Date: Tue, 14 Jun 2005 17:51:12 -0400	[thread overview]
Message-ID: <9e4733910506141451f2f28cf@mail.gmail.com> (raw)
In-Reply-To: <20050614183812.GA5920@localhost.localdomain>

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

  reply	other threads:[~2005-06-14 21:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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     ` Fwd: hpet patches Jon Smirl
2005-06-14 18:38       ` Bob Picco
2005-06-14 21:51         ` Jon Smirl [this message]
2005-06-14 22:37 Pallipadi, Venkatesh
2005-06-14 23:11 ` Jon Smirl
  -- 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-15 17:15 Pallipadi, Venkatesh
2005-06-15 17:54 ` Jon Smirl
2005-06-15 18:11   ` Lee Revell
2005-06-16 14:00   ` Vitezslav Samel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e4733910506141451f2f28cf@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=akpm@osdl.org \
    --cc=bob.picco@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.