[parisc-linux] lasi scsi driver

[parisc-linux] lasi scsi driver

[Gyula Matics]

It's only half working. It can list the devices on the bus, but that's all.

It is not working because it needs a horrible amount of cache flushing
and I still didn't get it right. (the committed code only contains enough
flushing to pass the two debugging tests)

The scsi card is running code that is in the main memory and the driver
is heavily patching that. The bigger problem is that the communication
with the card is done via a mailbox also residing in the main memory
and the driver is assuming that this mailbox is on a non-cacheable page.

I know that the architecture supports setting a page non-cacheable.
My question is if it is possible / good idea to set the mailbox page
to non-cacheable?

Gyula
ps: if you hack 53c7xx.c beware that many comments are misleading.
and generally it is a mess.

Re: [parisc-linux] lasi scsi driver

[Grant Grundler]

"Gyula Matics" wrote:
> It's only half working. It can list the devices on the bus, but that's all.
> 
> It is not working because it needs a horrible amount of cache flushing
> and I still didn't get it right. (the committed code only contains enough
> flushing to pass the two debugging tests)

Aside from the mailbox problems, have you added code to flush/purge
entries for payload data?

I was just talking about that with someone and thinking we could
put that in a "common" I/O path. I found "wakeup_bdflush()" but have
no clue what that does.

The goal here is to enable *all* SCSI disk drivers WRT to the payload data.
We are interested in getting PCI SCSI drivers working too and I know
this is going to be a problem. At least it's a problem until the
"Dynamic DMA mapping" interfaces are implemented for parisc-linux
and actually used by the drivers parisc-linux folks care about.


> The scsi card is running code that is in the main memory and the driver
> is heavily patching that. The bigger problem is that the communication
> with the card is done via a mailbox also residing in the main memory
> and the driver is assuming that this mailbox is on a non-cacheable page.
> 
> I know that the architecture supports setting a page non-cacheable.
> My question is if it is possible / good idea to set the mailbox page
> to non-cacheable?

Philipp Rumpf mentioned a possible implementation to me in a private
e-mail (make_page_uncached()). He's open to other ideas and/or
interfaces if another architecture has already solved this problem.
I started looking into this but I'm way outta my depth here.

Like the payload data, this is a kluge only needed until the
drivers use the new "Dynamic DMA mapping" interfaces described
in Documentation/DMA-mapping.txt. (I reccomend version 2.3.47
or newer). We should be able to hide the "(make_page_uncached()"
call in those interfaces from the drivers.

thanks,
grant

Grant Grundler
Unix Development Lab
+1.408.447.7253

Re: [parisc-linux] lasi scsi driver

[Gyula Matics]

> Aside from the mailbox problems, have you added code to flush/purge
> entries for payload data?

It is not a clean mailbox system. It is mixing data and commands in the
mailbox...

> > I know that the architecture supports setting a page non-cacheable.
> > My question is if it is possible / good idea to set the mailbox page
> > to non-cacheable?
> 
> Philipp Rumpf mentioned a possible implementation to me in a private
> e-mail (make_page_uncached()). He's open to other ideas and/or
> interfaces if another architecture has already solved this problem.

The driver was originally written for m68k and one can find this code
fragments in it:

    cache_push(virt_to_phys((void *)(instance->hostdata[0])), 8192);
    cache_clear(virt_to_phys((void *)(instance->hostdata[0])), 8192);
    kernel_set_cachemode(instance->hostdata[0], 8192, IOMAP_NOCACHE_SER);

> in Documentation/DMA-mapping.txt. (I reccomend version 2.3.47

OK, i'll read it.

Gyula

[parisc-linux] Lasi Ethernet - update

[Helge Deller]

Hi puffins & folks,

I just checked in an updated version of the LASI ethernet-driver, which helps me
to boot my 715/64 into root-nfs and sash...
The code needs more cleanup, but I thought it is better to commit it now, so
other people can at least use it.

In order to get the driver working I wrote own functions for dma_cache_wback()
and dma_cache_inv(), which needs generic clean-up and should of course go
into another source-file (cache.c ?). Phillipp, maybe you want to integrate
them properly ?

During the tests here, it seems, that the current kernel doesn´t handle
ARP-requests properly. When I ping one of the machines, the 715 segfaults at
once with:
  "Unexpected Interruption!: Code=31 regs=..... (Addr=0000000)"
Does this happen on other machines/netcards too ?


Regards,

Helge Deller.

Re: [parisc-linux] Lasi Ethernet - update

[Bdale Garbee]

In article <00030302170400.19213@P100> you wrote:

> During the tests here, it seems, that the current kernel doesn´t handle
> ARP-requests properly. When I ping one of the machines, the 715 segfaults at
> once with:
>   "Unexpected Interruption!: Code=31 regs=..... (Addr=0000000)"
> Does this happen on other machines/netcards too ?

For what it's worth, I have no problem pinging my A180 running a kernel I 
built with the bits that were current in CVS yesterday booted with NFS root.

Bdale

Re: [parisc-linux] Lasi Ethernet - update (fixed!)

[Helge Deller]

Am Fri, 03 Mar 2000 schrieb Bdale Garbee:
> In article <00030302170400.19213@P100> you wrote:
> 
> > During the tests here, it seems, that the current kernel doesn´t handle
> > ARP-requests properly. When I ping one of the machines, the 715 segfaults at
> > once with:
> >   "Unexpected Interruption!: Code=31 regs=..... (Addr=0000000)"
> > Does this happen on other machines/netcards too ?
> 
> For what it's worth, I have no problem pinging my A180 running a kernel I 
> built with the bits that were current in CVS yesterday booted with NFS root.
> 
> Bdale

Hi Bdale,

Thanks for your response. 
I found the bug in the lasi-ethernet driver, so it works now ! The problem
was, that the kernel crashed right after going to user-mode, and so I assumed
that it was a general kernel-related problem and not related to the
lasi-ethernet-driver.

This is fixed now in CVS. People, who have older machines are now able
to boot the kernel via nfsroot.

Helge.

Re: [parisc-linux] lasi scsi driver

[Helge Deller]

Hi,

Am Thu, 02 Mar 2000 schrieb Gyula Matics:
> > Aside from the mailbox problems, have you added code to flush/purge
> > entries for payload data?
> 
> It is not a clean mailbox system. It is mixing data and commands in the
> mailbox...
> 
> > > I know that the architecture supports setting a page non-cacheable.
> > > My question is if it is possible / good idea to set the mailbox page
> > > to non-cacheable?
> > 
> > Philipp Rumpf mentioned a possible implementation to me in a private
> > e-mail (make_page_uncached()). He's open to other ideas and/or
> > interfaces if another architecture has already solved this problem.
> 
> The driver was originally written for m68k and one can find this code
> fragments in it:
> 
>     cache_push(virt_to_phys((void *)(instance->hostdata[0])), 8192);
>     cache_clear(virt_to_phys((void *)(instance->hostdata[0])), 8192);
>     kernel_set_cachemode(instance->hostdata[0], 8192, IOMAP_NOCACHE_SER);

Theese function (in the same order) was used in the lasi-ethernet-driver too.
Maybe you want to take a look at the functions dma_cache_inv() and
dma_cache_wback(), which I defined  at the top of the lasi_82596.c driver.
Currently this is really only a bad hack, but I think this is the way you could
go until make_page_uncached() is available.... ?
This means:
cache_push() -> dma_cache_wback()   and
cache_clear() -> dma_cache_inv().
I just added this hack, since currently dma_cache_inv() is defined as
flush_all_caches(), and this function doesn´t INVALIDATES the cache.

> 
> > in Documentation/DMA-mapping.txt. (I reccomend version 2.3.47
> 
> OK, i'll read it.
> 
> Gyula

Helge.

Re: [parisc-linux] lasi scsi driver

[willy]

On Thu, Mar 02, 2000 at 01:19:40PM -0800, Grant Grundler wrote:
> I was just talking about that with someone and thinking we could
> put that in a "common" I/O path. I found "wakeup_bdflush()" but have
> no clue what that does.

that's the kernel demon which writes dirty pages to disk and has nothing
to do with flushing caches, unfortunately.

Re: [parisc-linux] lasi scsi driver

[Jerry Huck]

> From: "Gyula Matics" <gyula_matics@hp.com>
> To: <parisc-linux@puffin.external.hp.com>
> Date: Thu, 2 Mar 2000 21:42:50 +0100
> Subject: [parisc-linux] lasi scsi driver

> It's only half working. It can list the devices on the bus, but that's all.
> 
> It is not working because it needs a horrible amount of cache flushing
> and I still didn't get it right. (the committed code only contains enough
> flushing to pass the two debugging tests)
> 
> The scsi card is running code that is in the main memory and the driver
> is heavily patching that. The bigger problem is that the communication
> with the card is done via a mailbox also residing in the main memory
> and the driver is assuming that this mailbox is on a non-cacheable page.
> 
> I know that the architecture supports setting a page non-cacheable.
> My question is if it is possible / good idea to set the mailbox page
> to non-cacheable?
> 
> Gyula

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.  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).  Also, I can't find any architected interface that would let
you test if a memory page could be accessed uncacheable.

Even for IA-64, main memory systems do not have to support uncacheable
references.  A PDC-like mechanism - PAL/SAL/EFI - reports the
available memory ranges and gives the supported attributes.  In the
IA-64 case, the I/O system is coherent so you don't need any of the
cache flushing.  So don't ever get in the situation where you need
uncacheable main memory.

Jerry Huck

Re: [parisc-linux] lasi scsi driver

[willy]

On Fri, Mar 03, 2000 at 11:10:58AM -0800, Jerry Huck wrote:
> 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.  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).  Also, I can't find any architected interface that would let
> you test if a memory page could be accessed uncacheable.

That isn't necessarily a problem.  The interface requires the allocation
of pages which are coherent.  On recent architectures, it's possible to
allocate pages which are actually IO coherent.  On earlier architectures,
the same interface would return uncached pages.  The question is
whether there are any implementations which can do neither of the two
possibilities.

Re: [parisc-linux] lasi scsi driver

[Grant Grundler]

willy@thepuffingroup.com wrote:
> That isn't necessarily a problem.  The interface requires the allocation
> of pages which are coherent.  On recent architectures, it's possible to
> allocate pages which are actually IO coherent.  On earlier architectures,
> the same interface would return uncached pages.  The question is
> whether there are any implementations which can do neither of the two
> possibilities.

That's basically correct. Let's start talking about implementations.

HP systems have three I/O MMU's which are I/O coherent: U2/Uturn,
Astro/Ike, and Epic/SAGA.  AFAIK, all systems using one on them have
the processor(s) connected to a "Runway" bus.  This limits what
processor model those systems can have: PA-7200, -8000, -8200, or -8500.

(Caveats:
 - T-class has something similar to U2 which is NOT I/O coherent
 - V-class (EPIC/SAGA) is probably supportable with some limitations
)

In personal conversations, two knowledgable folks have suggested
the following:
o PA-7100LC systems support uncacheable memory and subcacheline access.
  So these boxes should be supportable.

o PA-7300LC systems *might* support uncacheable memory and subcacheline...
  (Could anyone definitively answer this for any PA-7300LC box?)

o PA-7000 systems are pretty much SOL.
  (But they could be perfectly useful if folks add cache flushing to
   the few device drivers needed for graphics and stuff off of LASI.)

In summary, the number of "unsupportable" systems isn't as big
as I first thought.

thanks,
grant

Grant Grundler
Unix Development Lab
+1.408.447.7253

[parisc-linux] uncacheable memory

[willy]

On Sat, Mar 04, 2000 at 09:49:49PM -0800, Grant Grundler wrote:
> HP systems have three I/O MMU's which are I/O coherent: U2/Uturn,
> Astro/Ike, and Epic/SAGA.  AFAIK, all systems using one on them have
> the processor(s) connected to a "Runway" bus.  This limits what
> processor model those systems can have: PA-7200, -8000, -8200, or -8500.
> 
> (Caveats:
>  - T-class has something similar to U2 which is NOT I/O coherent

According to the hwdb, the T600 has two `Java BC Summit Port (IOA)'.
And you're the only one in possession of a T-class :-).  All the devices
in the T600 seem to be special devices so the drivers would have to
be freshly written anyway.  I don't see a PCI adapter in the T-class,
can one be fitted?  I assume Summit is the name of a bus, like Runway
only different?

> In personal conversations, two knowledgable folks have suggested
> the following:
> o PA-7100LC systems support uncacheable memory and subcacheline access.
>   So these boxes should be supportable.

that's good, that's a fair chunk of those machines which people have (712,
725/100, 715/later, E-class, early D-class).

> o PA-7300LC systems *might* support uncacheable memory and subcacheline...
>   (Could anyone definitively answer this for any PA-7300LC box?)

According to the 7300LC ERS, section 1.1.2 (Integrated Caches and TLB)
`Uncached memory pages are supported via the TLB U-bit.'  Then section
1.2.2, (Differences from the PA7100LC) `Uncacheable pages are still
supported.  Note: PA7100LC did not require the U bit to be set on TLB
entries for I/O pages, but the PA7300LC does (this was always an
architural requirement).'

I think that's enough for us to go on.

> o PA-7000 systems are pretty much SOL.
>   (But they could be perfectly useful if folks add cache flushing to
>    the few device drivers needed for graphics and stuff off of LASI.)

how about PA7100/7150 systems?  (715/early, 735, 755, later Nova servers)
They will also need explicit cache flushing added, I guess.

Re: [parisc-linux] uncacheable memory (D370)

[rob hoppe]

> >  - T-class has something similar to U2 which is NOT I/O coherent
>

I have a chance at a T-500.  Is it of use?

>
> 725/100, 715/later, E-class, early D-class).
>
> > o PA-7300LC systems *might* support uncacheable memory and subcacheline...
> >   (Could anyone definitively answer this for any PA-7300LC box?)
>

Where does the D-370 dual processor fit here?


--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/                            _/
_/   Rob Hoppe                _/
_/   770-995-5099             _/
_/   770-560-1050 cell        _/
_/   770-338-5885 fax         _/
_/                            _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Re: [parisc-linux] uncacheable memory (D370)

[willy]

On Sun, Mar 05, 2000 at 10:57:16AM -0500, rob hoppe wrote:
> 
> 
> > >  - T-class has something similar to U2 which is NOT I/O coherent
> >
> 
> I have a chance at a T-500.  Is it of use?

Not in the short term, but if you can get access to it, I'd love to see
ioscan output turn up in the hwdb...

> >
> > 725/100, 715/later, E-class, early D-class).
> >
> > > o PA-7300LC systems *might* support uncacheable memory and subcacheline...
> > >   (Could anyone definitively answer this for any PA-7300LC box?)
> >
> 
> Where does the D-370 dual processor fit here?

The D370 has a U2 IOA in it and as such is IO Coherent.

Re: uncacheable memory

[Grant Grundler]

On Sat, Mar 04, 2000 at 09:49:49PM -0800, Grant Grundler wrote:
> HP systems have three I/O MMU's which are I/O coherent: U2/Uturn,
> Astro/Ike, and Epic/SAGA.  AFAIK, all systems using one on them have
> the processor(s) connected to a "Runway" bus.  This limits what
> processor model those systems can have: PA-7200, -8000, -8200, or -8500.
> 
> (Caveats:
>  - T-class has something similar to U2 which is NOT I/O coherent

Apologies. I should have been clearer about several things.

"T-class" should have been "T600".
I don't think T5xx series have any sort of I/O TLB in them.

willy@thepuffingroup.com wrote:
> According to the hwdb, the T600 has two `Java BC Summit Port (IOA)'.
> And you're the only one in possession of a T-class :-).

Actually, I'm neither in possession of one nor the only person who
might be. I couldn't believe it, but AFAIK HP sold thousands of them.
(The ioscan output is left over from my previous job.)
FTW, the URL is still valid but no longer linked from the
main "servers" web page:

	http://www.unixsolutions.hp.com/products/servers/tclass/

I suggest interested parties "snarf" what they can from those web pages
before the pages go away....375kg...sheesh.

> All the devices in the T600 seem to be special devices so the
> drivers would have to be freshly written anyway.  I don't see
> a PCI adapter in the T-class, can one be fitted?

First, T5xx only supports HP-PB devices. Basically same devices
as "Nova" (EFGHI-) class boxes and K-class. However, like K-class,
T600 also supports GSC cards in a "daughter board" form factor.
(but the "header" sheet metal is slightly different.... *SIGH*)

And HP does make/ship card-mode Dino 100BT cards for both T600
and K-class. Making card-mode Dino work on T600 is quite impossible
without looking at HP-UX source (or reverse engineering the binary).
I helped do it once. Java really doesn't like to play with Dino.

> I assume Summit is the name of a bus, like Runway only different?

Yes. AFIAK, Summit is the "memory" bus for T-5xx series.
On T600, same bus protocol but it's twice as "wide".


Someone else asked what's wrong with the memory controllers:

AFAIK, subcacheline accesses are a different type of transaction 
which many HP memory controllers don't *need* to support. I'm guessing
systems where I/O devices sit on the same bus as the memory controller
(eg 712, PA-7100LC), the memory controller supports all types of
transactions in order for DMA to work. So if the U-bit is also
supported by the processor, it'll all work.


hope this is better,
grant

Grant Grundler
Unix Development Lab
+1.408.447.7253

Re: [parisc-linux] lasi scsi driver

[Philipp Rumpf]

> In personal conversations, two knowledgable folks have suggested
> the following:
> o PA-7100LC systems support uncacheable memory and subcacheline access.
>   So these boxes should be supportable.
> 
> o PA-7300LC systems *might* support uncacheable memory and subcacheline...
>   (Could anyone definitively answer this for any PA-7300LC box?)

It does, according to our documentation.

> o PA-7000 systems are pretty much SOL.
>   (But they could be perfectly useful if folks add cache flushing to
>    the few device drivers needed for graphics and stuff off of LASI.)

More importantly, they don't use PCI (and not even GSC).  It's perfectly
fine for us to require HP-PB drivers aso to do cache flushing.

> In summary, the number of "unsupportable" systems isn't as big
> as I first thought.

I'm still not convinced there's going to be any problem at all, even on
runway systems.

	Philipp Rumpf

Re: [parisc-linux] lasi scsi driver

[Philipp Rumpf]

> 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 ?

> 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 ?

> 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.

	Philipp Rumpf

Re: [parisc-linux] lasi scsi driver

[Thomas Bogendoerfer]

On Sun, Mar 05, 2000 at 07:46:52PM +0100, Philipp Rumpf wrote:
> 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.

I can't say how things are for PARISC, but in the MIPS world it's usually
better to use cached memory/flush caches than doing uncached accesses.
And adding cache flushes to a driver isn't that big task, if you know
the hardware (been there, done that).

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: [parisc-linux] lasi scsi driver

[Jerry Huck]

> 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

Re: [parisc-linux] lasi scsi driver

[Philipp Rumpf]

> > 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.

Okay, so there are several things I'd like to resolve:

On Runway-based systems, we don't need uncached memory.
On PA7[13]00LC, uncached memory works.
On old 715s, we don't have PCI.


So, it looks to me like there's no case left we cannot handle except for
undocumented Runway interfaces we just hope don't get in our way (U2 / Uturn,
for now) (and even for those it's probably just one bit we'll have to set).

> > 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.

There won't be any flush calls left to add in 2.4.  Unless you want to
maintain a patch against Linus for every single PCI driver in the tree
there's really no way we can use those with systems that neither have
uncached memory nor coherent DMA (and still, we don't know of even one
such system).

	Philipp Rumpf

Re: [parisc-linux] lasi scsi driver

[Grant Grundler]

Philipp Rumpf wrote:

> Okay, so there are several things I'd like to resolve:
> 
> On Runway-based systems, we don't need uncached memory.
> On PA7[13]00LC, uncached memory works.
> On old 715s, we don't have PCI.

I was mostly worried about systems with PCI.
I'm not worried anymore.


> So, it looks to me like there's no case left we cannot handle except for
> undocumented Runway interfaces we just hope don't get in our way (U2 / Uturn,
> for now) (and even for those it's probably just one bit we'll have to set).

I'm pretty sure systems with Runway will not be a problem.
(Except T600) There are other Runway-to-xxx bus converters but
I believe those will be transparent WRT I/O coherency problems.

> There won't be any flush calls left to add in 2.4.  Unless you want to
> maintain a patch against Linus for every single PCI driver in the tree
> there's really no way we can use those with systems that neither have
> uncached memory nor coherent DMA (and still, we don't know of even one
> such system).

I'm pretty sure Jerry wasn't referring to PCI drivers.
Systems with PCI are either I/O Coherent or have PA-7[13]00LC.

It seems only drivers running on systems with PA-7000 processors (which
AFAIK doesn't support U-bit) would need cache flushing. While those
drivers aren't for PCI devices, they might share some of the "core"
driver logic (NCR 53c700 SCSI?). So people who care about those boxes
(eg model 710) *will* have to maintain patches against a few drivers
or fork off their own version of the driver. The good thing is the
number of different models, the age of those models, and thus number
of drivers should all be pretty small.

grant

> 
> 	Philipp Rumpf
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 

Grant Grundler
Unix Development Lab
+1.408.447.7253