From: Jiri Slaby <jirislaby@gmail.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>, Jiri Slaby <jslaby@suse.cz>,
linux-pci@vger.kernel.org, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Thomas Renninger <trenn@suse.de>
Subject: Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes
Date: Sat, 08 Jan 2011 00:13:52 +0100 [thread overview]
Message-ID: <4D279E30.8070706@gmail.com> (raw)
In-Reply-To: <20110107143741.7b2b2a8d@jbarnes-desktop>
On 01/07/2011 11:37 PM, Jesse Barnes wrote:
> On Fri, 07 Jan 2011 21:44:35 +0100
> Jiri Slaby <jirislaby@gmail.com> wrote:
>
>> On 01/06/2011 08:24 PM, Bjorn Helgaas wrote:
>>> Theoretically, ACPI tells us about the GPIO/TCO/etc. regions in a
>>> generic way via namespace devices or something in the static tables.
>>> Is that generic information missing, or is it there and Linux is
>>> ignoring it? If we're ignoring it, I'd rather fix that.
>>
>> It works for most boxes I would say. Try to google for "claimed by ICH4
>> ACPI/GPIO/TCO", it reports sane ranges like 0400-047f or 4000-407f.
>>
>>> The main reason for claiming I/O regions is to keep us from placing
>>> another device on top of them. But we've had PCIBIOS_MIN_IO = 0x1000
>>> forever, which should keep us from putting anything below that anyway
>>> (at least for PCI devices). So there must be some other reason for
>>> claiming space in this quirk.
>>
>> Anyway, this ACPI space may be below 0x1000 as can be seen above. From
>> the ICH standard, it can be anywhere...
>
> Is there some other resource we should be considering to avoid this
> space?
There are two kinds of address ranges (spaces) in ICH specs. Fixed
(address base is fixed) and Variable (base can be changed). And Fixed
space should not collide (the behaviour is explicitly unpredictable)
with Variable.
This ACPI space is defined as Variable. So it cannot collide with any
Fixed. Most of the Fixed are below 0x180, there is also 0x376, 0x3f6 for
IDE, 0x4D0-0x4D1 for PIC and 0xCF9 for reset generator.
> And we know it won't work if we try to use the IDE controller in the
> LPC allocated space? Have you checked the ICH4 specs to see what the
> decode rules are on this space? I guess LPC has priority and doesn't
> forward requests through to IDE?
If we read/write to ports 0x170-0x17f, IDE ctrl responds on that
machine. I.e. if I remove the quirk, disks are found. (Otherwise they
are not due to the conflict.)
thanks,
--
js
next prev parent reply other threads:[~2011-01-07 23:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 15:17 [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes Jiri Slaby
2011-01-06 19:24 ` Bjorn Helgaas
2011-01-07 20:44 ` Jiri Slaby
2011-01-07 22:37 ` Jesse Barnes
2011-01-07 23:13 ` Jiri Slaby [this message]
2011-01-07 23:03 ` Bjorn Helgaas
2011-01-07 23:29 ` Jiri Slaby
2011-01-08 0:16 ` Bjorn Helgaas
2011-01-08 9:58 ` Jiri Slaby
2011-01-10 18:40 ` Bjorn Helgaas
2011-01-13 10:07 ` Jiri Slaby
2011-01-13 23:19 ` Bjorn Helgaas
2011-01-14 0:15 ` Linus Torvalds
2011-01-14 10:31 ` Jiri Slaby
2011-01-14 10:32 ` [PATCH 1/2] PCI: add more checking to ICH region quirks Jiri Slaby
2011-01-14 10:32 ` [PATCH option B 2/2] PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICH Jiri Slaby
2011-02-11 12:09 ` Sergei Shtylyov
2011-02-11 14:16 ` Jiri Slaby
2011-01-14 10:32 ` [PATCH option A 2/2] PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO Jiri Slaby
2011-01-14 16:10 ` [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes Bjorn Helgaas
2011-01-15 15:39 ` Robert Hancock
2011-02-08 9:55 ` Jiri Slaby
2011-02-08 21:20 ` Jesse Barnes
2011-02-11 10:32 ` Jiri Slaby
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=4D279E30.8070706@gmail.com \
--to=jirislaby@gmail.com \
--cc=bjorn.helgaas@hp.com \
--cc=davem@davemloft.net \
--cc=jbarnes@virtuousgeek.org \
--cc=jslaby@suse.cz \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=trenn@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).