linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michel Lanners <mlan@cpu.lu>
To: drow@false.org
Cc: mj@ucw.cz, hedrick@Astro.Dyer.Vanderbilt.Edu,
	linuxppc-user@lists.linuxppc.org,
	linuxppc-dev@lists.linuxppc.org
Subject: Re: Trying a Promise Ultra/66 on powerpc
Date: Wed, 28 Jul 1999 07:48:18 +0200 (CEST)	[thread overview]
Message-ID: <199907280548.HAA00294@piglet.cpu.lu> (raw)
In-Reply-To: <19990727230416.A457@them.org>


Hi all,

Some PCI and some IDE thoughts and questions in here...

On  27 Jul, this message from Daniel Jacobowitz echoed through cyberspace:
> On Tue, Jul 27, 1999 at 04:07:28PM -0500, Andre M. Hedrick wrote:
>> What are we missing in ppc-pci stuff that does not register an interrupt?
>> I can work around this in general by asking the card if the dev->irq is
>> NULL.  However, if this is the case, logic dictates that polling the card
>> will yield the same result.
> 
> OK.  I have this working now.  In getting it to work, I've come across
> a couple of issues.
[snip]
> (C) I needed to add a patch to automatically try setting PCI_COMMAND_IO
> if powerpc.  Without this the card would be marked as not supporting
> native mode, and not be initialized.  On x86 bios32.c takes care of
> bioses which do not set this.  Should something in the PPC PCI
> initialization be doing the same?

It seems that OpenFirmware is not doing its job well in initializing all
PCI devices.For the planb driver, which uses an onboard PCI device
(video input) known to OF (i.e Apple device), I need to set
PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE. Or is
it just a problem with IO space enabling, and memory is already
switched on by OF?

On a related note, how do I find a memory region, not yet used, for
remapping a PCI device's memory space? There is a bug with an onboard
device on some Macs, in that it really decodes less address bits than
it says it does, making it overlap other devices (which then need to be
remapped). Right now, the driver uses the same region as in MacOS,
without checking...

> On a much less related note:
> drow:~# hdparm -p /dev/hdc
> 
> /dev/hdc:
>  attempting to auto-tune PIO mode
>  HDIO_SET_PIO_MODE failed: Function not implemented
> 
> pdc202xx.c has no tuneproc.  Is this deliberate?
> 
> As it is I get this (off a 5400 RPM Maxtor 25.4G DiamondMax)
> /dev/hdc:
>   Timing buffered disk reads:  32 MB in  5.83 seconds = 5.49 MB/sec

This is not brilliant, but acceptable. What mode of operation was that
in? UDMA? Or regular DMA or even PIO?

On a related note, can you provide the patches you needed to apply
(minus the uniform IDE stuff from Andre, which I have)? I'm planning to
get my Ultra66 on Friday ;-)...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

  reply	other threads:[~1999-07-28  5:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <19990727112137.A897@drow.res.cmu.edu>
     [not found] ` <Pine.LNX.3.96.990727160229.10158B-100000@Astro.Dyer.Vanderbilt.Edu>
     [not found]   ` <19990727102627.A370@drow.res.cmu.edu>
     [not found]     ` <Pine.LNX.3.96.990727093644.6993B-100000@Astro.Dyer.Vanderbilt.Edu>
     [not found]       ` <19990727235430.D1046@albireo.ucw.cz>
1999-07-28  3:04         ` Trying a Promise Ultra/66 on powerpc Daniel Jacobowitz
1999-07-28  5:48           ` Michel Lanners [this message]
1999-07-28  7:17             ` Andre M. Hedrick
1999-08-08 19:54               ` Michel Lanners
1999-08-08 20:55                 ` Tom Rini
1999-08-08 21:01                   ` Michel Lanners
1999-08-09  3:22                   ` Daniel Jacobowitz
1999-08-09  6:02                   ` Paul Mackerras
1999-08-09 19:28                     ` Tom Rini
1999-08-09 20:06                       ` Michel Lanners
1999-08-09  3:26                 ` Daniel Jacobowitz
1999-08-09 21:13                   ` Michel Lanners
1999-08-12 20:05                   ` Michel Lanners
1999-08-13  8:43                     ` Geert Uytterhoeven
1999-08-09  5:13                 ` Paul Mackerras
1999-08-09  5:18                   ` David A. Gatwood
1999-08-09  5:33                     ` Paul Mackerras
1999-08-09  5:38                       ` David A. Gatwood
1999-08-09  6:50                   ` Benjamin Herrenschmidt
1999-08-09 20:15                     ` Michel Lanners
1999-08-09 20:23                   ` Michel Lanners
1999-08-10  0:10                     ` Paul Mackerras
1999-08-10  5:38                       ` Michel Lanners
1999-08-10  8:45                         ` Benjamin Herrenschmidt
1999-08-15  9:20                         ` Martin Mares
1999-08-10 12:56                       ` Geert Uytterhoeven
1999-08-12 17:30                         ` Michel Lanners
1999-07-28  6:18           ` Tom Rini
1999-07-28  8:07           ` Martin Mares
1999-07-29  0:31             ` Andre M. Hedrick
1999-08-01  7:23           ` Michel Lanners
1999-07-29  9:16 Benjamin Herrenschmidt
1999-08-08 20:00 ` Michel Lanners
1999-08-08 20:52   ` Geert Uytterhoeven
1999-08-08 21:21     ` Michel Lanners
1999-08-08 21:27       ` Geert Uytterhoeven
1999-08-15  9:23       ` Martin Mares
  -- strict thread matches above, loose matches on Subject: below --
1999-08-13 14:28 Justin McKillican
     [not found] <199908092022.WAA00327@piglet.cpu.lu>
1999-08-15  9:39 ` Martin Mares

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=199907280548.HAA00294@piglet.cpu.lu \
    --to=mlan@cpu.lu \
    --cc=drow@false.org \
    --cc=hedrick@Astro.Dyer.Vanderbilt.Edu \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=linuxppc-user@lists.linuxppc.org \
    --cc=mj@ucw.cz \
    /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;
as well as URLs for NNTP newsgroup(s).