Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: James Bottomley <James.Bottomley@SteelEye.com>,
	Kyle McMartin <kyle@parisc-linux.org>,
	linux-pcmcia@lists.infradead.org,
	parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc
Date: Tue, 6 Dec 2005 01:14:58 -0700	[thread overview]
Message-ID: <20051206081458.GA16793@colo.lackof.org> (raw)
In-Reply-To: <20051205220344.GJ15201@flint.arm.linux.org.uk>

On Mon, Dec 05, 2005 at 10:03:44PM +0000, Russell King wrote:
..
> I don't have issue with the I/O side.  It's the memory side I'm
> wondering about.
> 
> The probing code sets up a mapping to place the CIS at one of the
> regions,

How is the region selected? (ie please point me at the right code)

Is there some obvious document that explains my basic questions?
I'm happy to read to learn a bit more.  My ob600ct is still
here waiting for me to fix PCMCIA on it...*sigh*


If using IO port space, parisc can be very flexible as each PCI bus
essentially has it's own IO port space range.

But with MMIO space, routing is typically setup by firmware.
Each PCI bus controller will get one(*) region of MMIO space
routed to it by the chipset. Children of that PCI bus must use
MMIO addresses allocated from that region.

(*) I'm simplifying a bit here. The full explanation is more complex.
   But treating it like one region is sufficient in practice
   and for the purpose of this discussion.

>  and then tries to validate/read the CIS.  It then unmaps
> it and maps it into the next place and repeats.  Hence, we're
> reading data from the PCMCIA card after setting up various valid
> mappings.

Ok. More basic questions:
Why are we doing this? Is this a form of bus walk?

> These mappings are not much different from the mappings which are
> used to interpret the CIS data from the card after the memory
> probing has completed.

I'm not familiar with how CIS data is read from a PCMCIA device.
Normal PCI uses "Config Space". Is PCMCIA using MMIO space
for both CIS/device discovery and assigning MMIO space to
PCMCIA device registers?

> Hence, if the memory probing is causing you issues, I'd be concerned
> about the reliability of reading the CIS data from the card under
> the non-probing scenarios.

If PCMCIA is susceptible to write posting issues, then a
PCI-PCMCIA bridge on PARISC is likely to expose those issues.
ie timing of register writes are likely different.


> Alternatively, maybe you've found a real bug somewhere in PCMCIA
> which needs fixing...

That's possible. If PCMCIA is assigning MMIO addresses outside the
range routed down the PCI bus, the box will HPMC. The "PIM dump"
(CPU state when it HPMC'd) can tell which address the CPU failed
to access. So we should be able to determine if this is the case
or not pretty easily.

I don't have any PCI-PCMCIA adapters...so may have to wait until
james is home again and has an hour to poke at this again.

hth,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

  parent reply	other threads:[~2005-12-06  8:14 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 [this message]
2005-12-06  9:49         ` Russell King
2005-12-06 16:46           ` Grant Grundler
2005-12-11  7:41           ` Grant Grundler

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=20051206081458.GA16793@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=James.Bottomley@SteelEye.com \
    --cc=kyle@parisc-linux.org \
    --cc=linux-pcmcia@lists.infradead.org \
    --cc=parisc-linux@lists.parisc-linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox