public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson-VXdhtT5mjnY@public.gmane.org>
To: "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: eric.valette-GANU6spQydw@public.gmane.org,
	Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>,
	"Moore,
	Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: RE: lost thermal zones on 20040715 nc6000
Date: Tue, 24 Aug 2004 19:51:43 -0600	[thread overview]
Message-ID: <1093398703.2314.4.camel@localhost.localdomain> (raw)
In-Reply-To: <B44D37711ED29844BEA67908EAF36F03A38375-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>


  In case you didn't see, Linus posted a trivial patch that avoids the
problem for me:

http://marc.theaimsgroup.com/?l=linux-kernel&m=109339448319880&w=2

I still don't think we have any right to expose the hidden SMBus, it's
just asking for trouble, but...

	Alex

On Wed, 2004-08-25 at 09:27 +0800, Li, Shaohua wrote:
> I basically agree ACPI should access the region exclusively. The patch
> in Bug 3191 allows both SMBus driver and ACPI thermal zone driver access
> it. But there is a risk, we have no way to synchronize the access. Only
> one driver can access it one time. But somebody will argue SMBus driver
> has more benefit.
> 
> Thanks,
> Shaohua
> 
> >-----Original Message-----
> >From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
> >admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Alex Williamson
> >Sent: Wednesday, August 25, 2004 5:24 AM
> >To: Moore, Robert
> >Cc: acpi-devel
> >Subject: RE: [ACPI] lost thermal zones on 20040715 nc6000
> >
> >
> >    I've nearly gotten to the bottom of this problem.  It's not an
> >interpreter bug, nor is it a BIOS bug.  The address we were trying to
> >read in AML is a SMBus controller address.  This address sits on the
> >hidden SMBus function in the Intel chipset.  Unfortunately, the PCI
> >quirks routine un-hides the devices.  So far this is all the same as
> the
> >way it behaved prior to the 20040715 code drop.
> >
> >   The new piece is the motherboard driver.  Now this driver comes in
> an
> >claims the I/O port region that the SMBus controller is using.  We've
> >un-hidden the PCI function, so PCI wants that resource range.  It can't
> >get it so it moves the SMBus BAR to a different address.  The AML is
> now
> >hosed cause it's hard-coded to use the address it programmed in (why
> >shouldn't it, the device is hidden).  Why are we un-hiding the SMBus
> >function?  The AML sets up an OpRegion for the address space it uses,
> so
> >should have exclusive access to that range.  Suggestions?  Thanks,
> >
> >	Alex
> >




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

  parent reply	other threads:[~2004-08-25  1:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-25  1:27 lost thermal zones on 20040715 nc6000 Li, Shaohua
     [not found] ` <B44D37711ED29844BEA67908EAF36F03A38375-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-25  1:51   ` Alex Williamson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-08-25  1:59 Li, Shaohua
2004-08-24 21:40 Moore, Robert
2004-08-11 16:42 Moore, Robert
     [not found] ` <37F890616C995246BE76B3E6B2DBE05501A8B206-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2004-08-11 16:55   ` Alex Williamson
2004-08-24 21:24   ` Alex Williamson
2004-08-24 21:51     ` Karol Kozimor
2004-08-10 15:50 Alex Williamson

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=1093398703.2314.4.camel@localhost.localdomain \
    --to=alex.williamson-vxdhtt5mjny@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=eric.valette-GANU6spQydw@public.gmane.org \
    --cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox