From: Marcelo Tosatti <marcelo.tosatti@cyclades•com>
To: Benjamin Herrenschmidt <benh@kernel•crashing.org>
Cc: Paul Mackerras <paulus@samba•org>,
linux-ppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: Re: [RFC] handle access to non-present IO ports on 8xx
Date: Wed, 8 Jun 2005 06:01:36 -0300 [thread overview]
Message-ID: <20050608090136.GA2593@logos.cnet> (raw)
In-Reply-To: <1117750262.31082.73.camel@gaston>
On Fri, Jun 03, 2005 at 08:11:01AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2005-06-02 at 14:02 -0300, Marcelo Tosatti wrote:
> > Hi Ben,
> >
> > On Thu, Jun 02, 2005 at 12:46:32PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2005-06-01 at 13:50 -0300, Marcelo Tosatti wrote:
> > >
> > > Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With
> > > "proper" PCMCIA controllers, those are swallowed properly when the card
> > > is removed. The eating of the machine check is a bit too hackish to my
> > > taste... Better is to "not do that" by making sure the legacy crap isn't
> > > trying to tap unexisting ports, but then, if PCMCIA is also a
> > > problem...
> >
> > Well, cardmgr calls the driver's shutdown/close routine as soon as
> > the card is removed. Some of those methods write to IO registers in
> > the process (eg net/pcmcia/pcnet_cs.c).
> >
> > I dont see any elegant change that could be done in PCMCIA.
>
> I know, the thing is, on platforms with a "classical" PCI<->PCMCIA
> bridge, the bridge will not issue machine checks when the card is
> removed. I don't know if that is possible with your HW setup, I suppose
> you are hooking PCMCIA directly to the CPU IO bus ...
I think the PCMCIA bus is hooked directly to the CPU, yes.
> > One possibility that comes to mind would be to enforce the rule
> > that drivers should not writeout in case of a removal event,
>
> They can't know, they get the removal even too late. The driver may be
> in the middle of writing when you remove the card. If there is no HW way
> to prevent the machine check, then you'll need software recovery.
>
> > but that does not sound feasible to me: It just looks too messy,
> > however I have no good argument against it.
> >
> > Well, its restricted to 8xx (maybe 32-bit PPC) with PCMCIA, so its
> > just not worth the trouble?
>
> Hehe... dunno.
>
> > Hmmm... I'll look that up. My limited testing on HW in question does not
> > exhibit longer MCE delays than "twi/isync/nop" sequence - actually, it is
> > always triggered during the IO access instruction itself.
>
> I suppose the 8xx may actually be quite synchronous on IOs then...
>
> > Where can I find information about write posting on 8xx? Is there a
> > term for it used in PPC documentation? I can't find anything...
>
> Well, do you have a store queue ? What does the 8xx manual says about
> ordering & queueing of non cacheable loads & stores ? Maybe the chip is
> fully synchronous on IOs ?
It seems so, yes.
Section 6.1 of MPC860UM.pdf:
"All exceptions associated with memory are implemented as precise, which
means that a load/store instruction is not complete until all possible
error indications are sampled from the load/store bus.
This also imples that a store or nonspeculative load instruction is
not issued to the load/store bus until all previous instructions have
completed."
I'll prepare a new patch reflecting this information, thanks again
Ben.
prev parent reply other threads:[~2005-06-08 15:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-01 16:50 [RFC] handle access to non-present IO ports on 8xx Marcelo Tosatti
2005-06-02 2:46 ` Benjamin Herrenschmidt
2005-06-02 7:04 ` Pantelis Antoniou
2005-06-02 17:02 ` Marcelo Tosatti
2005-06-02 22:11 ` Benjamin Herrenschmidt
2005-06-03 12:08 ` Mark Chambers
2005-06-08 9:01 ` Marcelo Tosatti [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=20050608090136.GA2593@logos.cnet \
--to=marcelo.tosatti@cyclades$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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