All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Huck <jerry_huck@hp.com>
To: prumpf@inwestnet.de
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] lasi scsi driver
Date: Tue, 7 Mar 2000 11:33:09 -0800 (PST)	[thread overview]
Message-ID: <200003071933.LAA02811@lucy.cup.hp.com> (raw)
In-Reply-To: <20000305194652.A9157@abacus.local> from Philipp Rumpf at Mar "5," 2000 "07:46:52" pm

> Date: Sun, 5 Mar 2000 19:46:52 +0100
> From: Philipp Rumpf <prumpf@inwestnet.de>
> To: huck@cup.hp.com
> Subject: Re: [parisc-linux] lasi scsi driver

> > While the PA-RISC processor architecture supports the notion of a
> > non-cacheable page, most HP memory systems do not - certainly not the
> > most recent memory systems.
> 
> Can you give us a concrete list of broken memory systems ?

Unfortunately not, since these memory systems weren't broken wrt
the architecture, I didn't keep track of this feature.  We really need
some interesting combination of memory system and I/O adapter coherence
capability.  Grant has posted much more on this than I know.

> > If you set the U-bit on a main memory page and then reference the page,
> > the processor will emit a sub-cacheline transaction and the memory system
> > will do something bad (probably HPMC).
> 
> So there is a sub-cacheline transaction on Runway but current memory
> controllers don't implement it ?

Yes.  The bus interface doesn't know the distinction between I/O accesses
and main memory.  The processor relies on "F" extension and/or the U-bit
to sort out how to treat an address dereference.  Sub-cacheline transactions
are the normal memory-mapped I/O transactions.

> > So don't ever get in the situation where you need uncacheable main memory.
> 
> uncacheable main memory is the only sane way to deal with cache-incoherent
> DMA - macros to flush the cache are both slower and harder to add to drivers
> written with the assumption that dma is cache-coherent.

The architecture was not designed to import drivers written to a
cache-coherent model.  This is not unique to PA-RISC.  Even IA-32 had
a little trouble on the first write-back caches in the 486.  While it
is not simple to convert all drivers, many drivers have a fairly clean
design that make it manageable to add the appropriate flush calls.  Some
drivers have byte granular interactions that make them impossible to
re-work.

Sorry I couldn't be more helpful with specific characteristics.

Jerry

  parent reply	other threads:[~2000-03-07 20:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-02 20:42 [parisc-linux] lasi scsi driver Gyula Matics
2000-03-02 21:19 ` Grant Grundler
2000-03-02 21:44   ` Gyula Matics
2000-03-03  0:50     ` [parisc-linux] Lasi Ethernet - update Helge Deller
2000-03-03  2:55       ` Bdale Garbee
2000-03-03 13:14         ` [parisc-linux] Lasi Ethernet - update (fixed!) Helge Deller
2000-03-03  1:34     ` [parisc-linux] lasi scsi driver Helge Deller
2000-03-03 15:52   ` willy
2000-03-03 19:10 ` Jerry Huck
2000-03-04 19:49   ` willy
2000-03-05  5:49     ` Grant Grundler
2000-03-05 14:29       ` [parisc-linux] uncacheable memory willy
2000-03-05 15:57         ` [parisc-linux] uncacheable memory (D370) rob hoppe
2000-03-05 16:05           ` willy
2000-03-06  6:26         ` uncacheable memory Grant Grundler
2000-03-05 18:34       ` [parisc-linux] lasi scsi driver Philipp Rumpf
2000-03-05 18:46   ` Philipp Rumpf
2000-03-05 21:05     ` Thomas Bogendoerfer
2000-03-07 19:33     ` Jerry Huck [this message]
2000-03-07 23:45       ` Philipp Rumpf
2000-03-08  0:33         ` 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=200003071933.LAA02811@lucy.cup.hp.com \
    --to=jerry_huck@hp.com \
    --cc=huck@cup.hp.com \
    --cc=parisc-linux@thepuffingroup.com \
    --cc=prumpf@inwestnet.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 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.