From: Grant Grundler <grundler@parisc-linux.org>
To: Russell King <rmk+pcmcia@arm.linux.org.uk>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc
Date: Sun, 11 Dec 2005 00:41:38 -0700 [thread overview]
Message-ID: <20051211074138.GB7987@colo.lackof.org> (raw)
In-Reply-To: <20051206094908.GB1706@flint.arm.linux.org.uk>
On Tue, Dec 06, 2005 at 09:49:08AM +0000, Russell King wrote:
> > Is there some obvious document that explains my basic questions?
>
> Unfortunately the only thing which exists is the code, sorry.
Russell,
As promised, here's a first cut on something to add to
Documentation/pcmcia/memory_probe. This is in the hope of
being helpful to others porting PCMCIA to their platform.
There is a "FIXME" bit that you'll need to rephrase or perhaps delete.
I'm not clear if you generalized when mentioning P2P bridges as
the parent of the resources.
I also think the distinction between, CIS memory and PCMCIA
card MMIO ranges isn't as sharp as it could be. The last bit
at the bottom hints at it but doesn't say anything about
why the additional MMIO address space is needed.
I also assumed "CIS data" is the content in "CIS memmory".
/dream on
And someday it might be interesting to use the PCI error recovery
code in PCMCIA memory probing to recovery from failures on PPC and
ia64 platforms. It might be possible on some PARISC chipsets as well
but no one is working on PCI error recovery for any PARISC chipset AFAIK.
/dream off
thanks,
grant
PCMCIA Memory Probing
---------------------
Summarized from parisc-linux mailing thread by Grant Grundler:
http://lists.parisc-linux.org/pipermail/parisc-linux/2005-December/027743.html
Abstract
--------
The memory probing code sets up a mapping to place the CIS in one of
the available regions, and then tries to validate/read the CIS.
The probe code then unmaps the CIS data, maps it into the next place,
and repeats. We're reading data from the PCMCIA card after setting
up various valid mappings.
> Why are we doing this? Is this a form of bus walk?
We are ensuring the MMIO resource really is available. On PCs this
resource may clash with weirdo ACPI/SMM/BIOS crap which we don't know
about. On non-PCs probing should be completely harmless. If it isn't,
we found another hardware problem which precludes use of the offending
address range. So the memory probe itself is not the problem, but it may
find something we weren't expecting which will cause a problem later.
[ unfortunately, it's not always harmless on PA-RISC and some
IA64 platforms. These platforms will HPMC (or MCA respectively) if a
CPU times out on an MMIO read. Error recovery on ia64 could eventually
deal sanely with this. -ggg ]
CIS data describes how much IO and memory space PCMCIA card needs,
the supply voltages, access timings, device IDs and so forth.
It is only accessed once a card has been inserted, and we have asked
the PCMCIA controller to map the CIS memory from the card into the
hosts memory space - which must be available.
CIS data is memory mapped the same way the memory probing is done.
Hence, if the memory probing causes issues, reading CIS data from the
card under the non-probing scenarios is not realiable either.
> How is the region selected? (ie please point me at the right code)
By the addresses passed in as available resources, or the parent bridge
resources if the cardbus bridge is attached to a P2P bridge.
# FIXME - what if the PCMCIA controller is connected to a Host PCI
# Bus controller?
# Maybe I'm being a bit anal in the intrepretation here because
# Host PCI bus controllers *act* like PCI-PCI Bridges from
# a PCI Point of view. But the number and type of resources
# available from a Host PCI bus controller is NOT architected
# as is the case for a PCI-PCI Bridge.
PCMCIA Probe interates over the entire MMIO resource with a step size
of 16k to 8MB depending on the size of the resource. We ioremap
the physical address, and then ask the PCMCIA controller to forward
accesses targetted at the physical address to the PCMCIA card.
We then access the physical address, verify the card's CIS data matches
previously read data, and then we destroy the mapping and iounmap.
Repeat for each step until we reach the end of the MMIO resource.
If that fails, we perform the same thing (mapping the CIS data) but
we use a checksum method on the mapped card data instead.
PCMCIA bridges use memory and IO outside their own BARs when setting
up mappings for legacy PCMCIA cards. Hence, the parent bridge needs
to forward _more_ IO and memory than the bus would appear to require.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
prev parent reply other threads:[~2005-12-11 7:41 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-04 6:04 [parisc-linux] [PATCH] PCMCIA: Disable probing on parisc Kyle McMartin
2005-12-04 10:33 ` [parisc-linux] " Russell King
2005-12-04 17:52 ` Kyle McMartin
2005-12-05 21:32 ` James Bottomley
2005-12-05 22:03 ` Russell King
2005-12-06 0:45 ` James Bottomley
2005-12-06 9:36 ` Russell King
2005-12-06 13:36 ` James Bottomley
2005-12-07 12:21 ` Dominik Brodowski
2005-12-07 14:01 ` James Bottomley
2005-12-11 6:50 ` Grant Grundler
2005-12-11 15:14 ` James Bottomley
2005-12-11 17:50 ` Grant Grundler
2005-12-11 18:01 ` James Bottomley
2005-12-11 18:55 ` Helge Deller
2005-12-11 19:09 ` Matthew Wilcox
2005-12-11 19:49 ` Dominik Brodowski
2005-12-11 20:37 ` James Bottomley
2005-12-11 22:35 ` Helge Deller
2005-12-12 7:30 ` Grant Grundler
2005-12-12 14:45 ` James Bottomley
2005-12-12 21:17 ` Helge Deller
2005-12-13 22:28 ` Grant Grundler
2005-12-11 19:48 ` Dominik Brodowski
2005-12-11 20:23 ` James Bottomley
2005-12-06 8:14 ` Grant Grundler
2005-12-06 9:49 ` Russell King
2005-12-06 16:46 ` Grant Grundler
2005-12-11 7:41 ` Grant Grundler [this message]
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=20051211074138.GB7987@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=rmk+pcmcia@arm.linux.org.uk \
/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