All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Reed <mdr@sgi.com>
To: Michael Reed <mdr@sgi.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	pazke@donpac.ru, Michael Joosten <michael.joosten@c-lab.de>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH]: Re: qla1280.c broken on SGI visws, PCI coherency	problem
Date: Tue, 13 Dec 2005 07:22:54 -0600	[thread overview]
Message-ID: <439ECB2E.7070103@sgi.com> (raw)
In-Reply-To: <439E0112.1030801@sgi.com>



Michael Reed wrote:
> 
> James Bottomley wrote:
>> On Mon, 2005-12-12 at 15:00 -0600, Michael Reed wrote:
>>> (The subject of this email isn't quite accurate.  It's not
>>> a pci coherency problem, it's a pio write ordering problem.)
>>>
>>> I've been asked to pass along the suggestion that "mmiowb"
>>> should be implemented for the platform.
>>> Given that I've been unable to unearth the chipset documentation
>>> for the Vis WS, I can only hope that you've got some good ideas
>>> on how this might be accomplished.
>> Well, the idea was that mmiowb and posting flushes were orthogonal.
>> mmiowb would be used in places where a posted write flush was done but
>> was strictly unnnecessary.  This bug report is implying that the posted
>> write flush was necessary, so it was incorrectly replaced with mmiowb
>> (which is a nop on most platforms).
> 
> The mmiowb() is sufficient to assure
> ordering of the write to the board register.
> (Have I incorrectly used the term pio?
> I'm not meaning to imply a particular address space used to
> access a board's registers.)
> 
> It's not a timing issue.  The WRT_REG write doesn't have to reach
> the board before the driver can perform another function.  It
> just has to reach the board in the order issued.

I believe the biggest issue with VISWS is that it appears to need
mmiowb() and we likely don't know how to implement it.  Hence, for
that platform, it would make sense to replace the mmiowb() with a
posting read.

We should let the maintainer chime in.  Perhaps he has the
info that would allow an implementation of mmiowb() for the
platform.  That would be best as there are other drivers
(tg3, for example) that also use mmiowb().  Retaining mmiowb()
also allows those platforms that can take advantage of it
a small (perhaps not so small?) performance gain.

Mike


> 
>>> I agree that replacing the pio read which flushed the preceeding
>>> pio write with mmiowb() is what has likely broken the driver.  If you
>>> restore them,  please make it either mmiowb or pio read, but not both.
>>>
>>> Perhaps something like this?  It's not the most elegant solution....
>> I'm tempted to say I think we need to put the write posting flush back
>> in and dump the mmiowb(), but since the driver is supposedly doing PIO
>> for VISWS, there's something else going on here (PIO writes aren't
>> supposed to post).  I've cc'd the VISWS maintainer in case he can think
>> of anything.
> 
> Again, apologies if I've misused the term PIO.
> 
> Mike
> 
>> James
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

  reply	other threads:[~2005-12-13 13:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-09 19:11 qla1280.c broken on SGI visws, PCI coherency problem Michael Joosten
2005-12-09 23:48 ` Michael Reed
2005-12-12 21:00   ` [PATCH]: " Michael Reed
2005-12-12 21:24     ` Christoph Hellwig
2005-12-12 21:31       ` Jesse Barnes
2005-12-12 21:47     ` James Bottomley
2005-12-12 23:00       ` Michael Reed
2005-12-13 13:22         ` Michael Reed [this message]
2005-12-13 14:50           ` James Bottomley
2005-12-13 18:15             ` Michael Reed
2005-12-14  5:00               ` Michael Joosten
2005-12-14 17:29                 ` James Bottomley
2005-12-15  1:17                   ` Michael Joosten
2005-12-15  2:20                     ` Jeremy Higdon
2005-12-15 16:21                       ` Michael Joosten
2005-12-14  1:39             ` Jeremy Higdon
2005-12-14  3:16               ` Michael Reed
2005-12-14  1:28       ` Jeremy Higdon
2005-12-14  4:59         ` James Bottomley
2005-12-14 23:56           ` Jeremy Higdon
2005-12-15  0:14             ` Michael Reed
2005-12-15  1:13               ` Jeremy Higdon

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=439ECB2E.7070103@sgi.com \
    --to=mdr@sgi.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michael.joosten@c-lab.de \
    --cc=pazke@donpac.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.