All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Valette <eric.valette@free.fr>
To: "Li, Shaohua" <shaohua.li@intel.com>, Karol Kozimor <sziwan@hell.org.pl>
Cc: eric.valette@free.fr, "Brown, Len" <len.brown@intel.com>,
	"Wang, Zhenyu Z" <zhenyu.z.wang@intel.com>,
	Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>,
	linux@brodo.de,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing
Date: Thu, 19 Aug 2004 13:09:27 +0200	[thread overview]
Message-ID: <41248A67.80806@free.fr> (raw)
In-Reply-To: <41245F59.4080608@free.fr>

Eric Valette wrote:
> Li, Shaohua wrote:
> 
>> Eric,
>> The patch for bug 3049 has been in 2.6.8.1 and should fix the IO port
>> problem. If the Asus quirk is just because of IO port problem, I'd like
>> to remove it. Note PNP driver also reserves the IO port for the SMBus
>> and lets SMBus driver to use it. ACPI motherboard driver behaves the
>> same as PNP driver.
> 
> 
> Unfortunately, as I understand it, the fix is done to "unhide" the SMBus 
> that otherwyse is not seen but it has unexpected side effect of messing 
> ioports allocation/reservation. I guess lspci with and without the fix 
> could help to understand the problem. Here is the comment on top of the 
> function :

OK I've put my debugger hat and tried to go a little further. Here is an 
(I hope) interesting PCI tweaking session. For helping the readder here 
are the meaning of some value :
	1) 8086:248c : Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
	2) 8086:2483 : the PCI ID for the i801 SMB bus
	3) 0xF2 the register offset used to enable the SBus in the ISA Bridge
	4) 0x20 = SMBBA = SMBbus base address in the i2c-i801.c file


root@pink-floyd:/home/valette# setpci -H1 -v -d 8086:248c 0xF2.W 
00:1f.0:f2 = 8409
root@pink-floyd:/home/valette# pcitweak -l  > 
pci_devices_list_without_enabling_SMBus 2>&1
root@pink-floyd:/home/valette# setpci -H1 -v -d 8086:248c 0xF2.W=8401 
00:1f.0:f2 8401
root@pink-floyd:/home/valette# pcitweak -l  > 
pci_devices_list_after_enabling_SMBus 2>&1
root@pink-floyd:/home/valette# diff 
pci_devices_list_without_enabling_SMBus 
pci_devices_list_after_enabling_SMBus
10a11
 > PCI: 00:1f:3: chip 8086,2483 card 1043,1628 rev 02 class 0c,05,00 hdr 00
root@pink-floyd:/home/valette# setpci -H1 -v -d 8086:2483 20.w
00:1f.3:20 = e801

So my deduction are :
	1) The trick for enabling the SMBbus is working,
	2) The configured base IO range register value is e801 leading to 
theoritically request the e800 -> e808 IO region and curiously not e810 
as requested described by the DTST...

Now I do not understand why it get something else as io port region no 
that the ACPI fix for bug 3049 remove the IORESOURCE_BUSY flags


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

  reply	other threads:[~2004-08-19 11:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-19  7:50 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing Li, Shaohua
2004-08-19  8:05 ` Eric Valette
2004-08-19 11:09   ` Eric Valette [this message]
2004-08-29 13:04   ` Dominik Brodowski
2004-08-29 13:50     ` Eric Valette
  -- strict thread matches above, loose matches on Subject: below --
2004-08-10  9:08 2.6.8-rc4-mm1 : radeon_monitor.c broken vs CONFIG_FB_MODE_HELPERS + Hard freeze Eric Valette
2004-08-10 10:35 ` 2.6.8-rc4-mm1 : Hard freeze due to ACPI Eric Valette
2004-08-10 16:07   ` Andrew Morton
     [not found]     ` <4123AC79.5000709@free.fr>
2004-08-19  0:00       ` 2.6.8.1-mm1 and Asus L3C : problematic change found, can be reverted. Real fix still missing Karol Kozimor
2004-08-19  7:16         ` Eric Valette

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=41248A67.80806@free.fr \
    --to=eric.valette@free.fr \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@brodo.de \
    --cc=shaohua.li@intel.com \
    --cc=sziwan@hell.org.pl \
    --cc=zhenyu.z.wang@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.