From: Jiri Slaby <jirislaby@gmail.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jiri Slaby <jslaby@suse.cz>,
jbarnes@virtuousgeek.org, 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:29:00 +0100 [thread overview]
Message-ID: <4D27A1BC.4080802@gmail.com> (raw)
In-Reply-To: <201101071603.29999.bjorn.helgaas@hp.com>
On 01/08/2011 12:03 AM, Bjorn Helgaas wrote:
> On Friday, January 07, 2011 01:44:35 pm Jiri Slaby 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.
>
> My point is that BIOS should be telling the OS about GPIO/TCO/etc.
> regions via an ACPI mechanism, and, ideally, we would use that rather
> than reading the address out of chipset-dependent registers.
>
> Even though PMBASE says the ACPI registers occupy 128 bytes from
> 0x100-0x17f, it's likely there's no actual conflict between the
> last 16 bytes and the IDE device.
I wouldn't say so. According to the datasheet 0x60-0x7f of the space
(i.e. 0x160-0x17f here) is for TCO registers. There:
0x10 -- Software IRQ Generation Register (i.e. 0x170)
0x11-0x1f -- reserved (0x171-0x17f)
So at least 0x170 should be conflicting. Unless TCO is unused/disabled
and not mapped there at all. May be that the case?
> ACPI probably reports this region via the FADT (the GPE PM register
> blocks) and possibly a PNP0C02 device. These will probably report
> something that doesn't conflict with the legacy IDE ports, i.e., a
> subset of the 0x100-0x17f range.
>
> Ooooh, I notice in the bugzilla that something's wrong with SMBIOS
> (comment 29) and ACPI is disabled because we couldn't find the
> RSDP (dmesg in comment 27). What sort of machine is this, anyway?
> We didn't find PNPBIOS, either.
Hmm, it looks like some old crap. What exact information you would like
to know? I've just asked if ACPI is not disabled in BIOS. There should
be no machine without ACPI running still in the 21st century, I think.
thanks,
--
js
next prev parent reply other threads:[~2011-01-07 23:29 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
2011-01-07 23:03 ` Bjorn Helgaas
2011-01-07 23:29 ` Jiri Slaby [this message]
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=4D27A1BC.4080802@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).