All of lore.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 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.