Re: Trying a Promise Ultra/66 on powerpc

Re: Trying a Promise Ultra/66 on powerpc

[Benjamin Herrenschmidt]

On Wed, Jul 28, 1999, Michel Lanners <mlan@cpu.lu> wrote:

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

OF will not enable memory space if there's no OF boot code on the board.
I beleive it doesn the same with IO space (but I didn't check). The lack
of PCI_COMMAND_INVALIDATE can be considered as an OF bug if the card
already has PCI_COMMAND_MASTER set as a default. I think the kernel
should add this to all devices at fixup time. (It should be harmless for
non-master devices anyway).

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

On  29 Jul, this message from Benjamin Herrenschmidt echoed through cyberspace:
> On Wed, Jul 28, 1999, Michel Lanners <mlan@cpu.lu> wrote:
> 
>>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?
> 
> OF will not enable memory space if there's no OF boot code on the board.
> I beleive it doesn the same with IO space (but I didn't check). The lack
> of PCI_COMMAND_INVALIDATE can be considered as an OF bug if the card
> already has PCI_COMMAND_MASTER set as a default. I think the kernel
> should add this to all devices at fixup time. (It should be harmless for
> non-master devices anyway).

Right, according to 'Designing PCI cards and Drivers..', OF never
enables neither memory space, nor IO space, neither ROM. It should,
however, set both PCI_COMMAND_MASTER and PCI_COMMAND_INVALIDATE. I
didn't chek, though...

I'm getting a patch ready that fixes this on the PMac plkatform. Geert,
how about OF in your CHRP box? Does it need the enable fix as well?

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

Re: Trying a Promise Ultra/66 on powerpc

[Geert Uytterhoeven]

On Sun, 8 Aug 1999, Michel Lanners wrote:
> On  29 Jul, this message from Benjamin Herrenschmidt echoed through cyberspace:
> > On Wed, Jul 28, 1999, Michel Lanners <mlan@cpu.lu> wrote:
> > 
> >>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?
> > 
> > OF will not enable memory space if there's no OF boot code on the board.
> > I beleive it doesn the same with IO space (but I didn't check). The lack
> > of PCI_COMMAND_INVALIDATE can be considered as an OF bug if the card
> > already has PCI_COMMAND_MASTER set as a default. I think the kernel
> > should add this to all devices at fixup time. (It should be harmless for
> > non-master devices anyway).
> 
> Right, according to 'Designing PCI cards and Drivers..', OF never
> enables neither memory space, nor IO space, neither ROM. It should,
> however, set both PCI_COMMAND_MASTER and PCI_COMMAND_INVALIDATE. I
> didn't chek, though...
> 
> I'm getting a patch ready that fixes this on the PMac plkatform. Geert,
> how about OF in your CHRP box? Does it need the enable fix as well?

Yep, my OF neither enables memory spaces on devices it doesn't have a driver
for. It even doesn't allocate space to them.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

On   8 Aug, this message from Geert Uytterhoeven echoed through cyberspace:
> On Sun, 8 Aug 1999, Michel Lanners wrote:
>> Right, according to 'Designing PCI cards and Drivers..', OF never
>> enables neither memory space, nor IO space, neither ROM. It should,
>> however, set both PCI_COMMAND_MASTER and PCI_COMMAND_INVALIDATE. I
>> didn't chek, though...
>> 
>> I'm getting a patch ready that fixes this on the PMac plkatform. Geert,
>> how about OF in your CHRP box? Does it need the enable fix as well?
> 
> Yep, my OF neither enables memory spaces on devices it doesn't have a driver
> for. It even doesn't allocate space to them.

That's even worse.... Might be one more reason for Martin to get the
dynamic resource allocation stuff for PCI devices into the kernel ;-)

Michel

PS Geert, don't stay up too long ;-)

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

Re: Trying a Promise Ultra/66 on powerpc

[Geert Uytterhoeven]

On Sun, 8 Aug 1999, Michel Lanners wrote:
> PS Geert, don't stay up too long ;-)

Why not? I've sent only two patches to Linus today. One more to follow soon
:-)

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


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

Re: Trying a Promise Ultra/66 on powerpc

[Martin Mares]

Hello,

> That's even worse.... Might be one more reason for Martin to get the
> dynamic resource allocation stuff for PCI devices into the kernel ;-)

   ;-))  I'm working on that, the most problematic bit is currently
to get Linus at least reply to my patches :|

   On the PPC, do you have enough information about host bridges, so
that you can re-address all the devices? Whereever this way is possible,
I'd prefer it over mixing addresses assigned by the firmware and the
kernel as it's hard to get right if there are any PCI to PCI bridges.

   I'll probably add a generic helper function for the whole address
assignment / card enabling business.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng."

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

Re: Trying a Promise Ultra/66 on powerpc

[Martin Mares]

Hi,

> How about fixing this in the kernel's PCI bus structures, by adding any
> required offsets in the pci_fixup() routines? This would make for clean
> inb()/outb() definitions (no offset), and also accomodates multiple I/O
> spaces behind more than one bridge. For instance, on the 7x00, both
> bandit and chaos have I/O space; the one for the PCI cards, the other
> for control (yes, control has an I/O port range! Not sure it serves,
> though...).
> 
> Any fixed-offset approach would break with multiple I/O ranges.... Not
> to mention the 9x00 machines (two separate host bridges, each three
> slots), where you can't work around the problem by using hardcoded
> addresses for the known motherboard chips.
> 
> I guess this approach could be made to work across the PPC
> architecture, not only on the PMac, as the PPC in general lacks anything
> special about I/O space... after all, those are just small memory
> spaces ;-)

   Looks okay to me.  I think it's what Sparc people are already doing
on Ultra/AX.

   If you can, please wait a few days for me to merge my new PCI stuff
with Linus, it should make these fixups easy as I my current code leaves
control of the resource allocation fully to the arch-dependent code.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"...take my advice, I don't use it anyway."

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

Re: Trying a Promise Ultra/66 on powerpc

[Justin McKillican]

>> On   8 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
>> > On Sun, Aug 08, 1999 at 09:54:12PM +0200, Michel Lanners wrote:
>> >> >> > /dev/hdc:
>> >> >> >   Timing buffered disk reads:  32 MB in  5.83 seconds = 5.49 MB/sec
>> >> ;-)) How about this:
>> >>
>> >> /dev/hde:
>> >>  Timing buffered disk reads:  64 MB in  6.60 seconds = 9.70 MB/sec
>> >> Maxtor 91024D4; 10G 7200 RPM, UDMA-2 ie 33 MB/s.
>> >
>> > Eek.  I want that :)
>>
>> No, you'd rather want _this_:
>>
>> /dev/hda:
>>  Timing buffered disk reads:  64 MB in  4.67 seconds =13.70 MB/sec
>
> Stop whining and buy an UW-SCSI disk :-) My Viking II flies at 17 MB/s.
>
> Greetings,
>
>       Geert

Hehehe..   about $1200 USD for a 50gig Seagate baracuda (ultra2 scsi)


justin

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

Re: Trying a Promise Ultra/66 on powerpc

[Daniel Jacobowitz]

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.

(A) You can't compile IDE as a module and enable ide-pmac.  There will
be link errors in pmac_setup.c.

(B) Very closely tied to that, if ide-pmac is not enabled, a dummy
pmac_ide_init_hwif_ports() is compiled in pmac_setup.c.  But the real
version of this function (in ide-pmac.c) does more than just onboard
IDE specific tasks.  For PCI IDE cards it is still needed.  Enabling
ide-pmac eventually let me make use of the card.

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




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

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

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

Re: Trying a Promise Ultra/66 on powerpc

[Andre M. Hedrick]

On Wed, 28 Jul 1999, Michel Lanners wrote:

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

YES, there are no known or possible way to ever get the card in to a PIO
mode that is meaningful.  The BIOS defaults to a fixed value.

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

I am glad that it meets with your approval, if you can do better do it!
The drive is in a DMA mode 2, based on the xfer rate.

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

You will need more as I have just found a quirk in the chipset.
I know on no real way to test the adpater for the correct ribbon, yet.
It also does a fake and allows a drive to invoke the UDMA4 flag from the
drive with the wrong cable.

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

Andre Hedrick
The Linux IDE guy


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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

[-- Attachment #1: Type: TEXT/plain, Size: 3863 bytes --]

Hi all,

I've got it working as well ;-) Was a big headache, though...

Read on for the details.

First, the hardware: a PowerMac 7600, upgraded G3/300, 112 MB RAM,
kernel 2.2.10 with the genam patch from Andre, Promise Ultra/66 with
BIOS 1.11.

Problems start with the changed definition of a few ide functions, now
using hw_regs_t, in asm-ppc/ide.h. As a result,
arch/ppc/kernel/pmac_setup.c and chrp_pci.c need to include linux/ide.h
instead of asm/ide.h. In addition, pmac_setup.c
defines an empty ide_init_default_hwifs(), but it was previously
defined in asm-ppc/ide.h. Patch (linux-asm-ide.patch) below.

Then, I had the problem of enabling the PCI IO space of the card; I
have tried a more generic patch which I'll send in a different mail
with other PCI-related stuff (IRQ related).

What annoyed me the most, was getting access to the I/O-ports of the
Promise going. Turns out that the PCI config registers contain the IO
address as seen from the bus, which is not the same as seen from the
CPU. In fact, they start at 0x0 on the PCI bus, but the host bridge
maps that area to 0xf2000000 on the processor bus. 

This fact was already catered for with the definition of outb/inb and
friends, which get an offset added to the port. Unfortunately, the
PowerMac IDE code undoes this and replaces it with a different
mechanism, which in essence removes the offset. Grrr..

I've solved the problem by adding the right offset directly to the
io-port values as found in the kernel's PCI structures. I think this
needs more serious rework, though. Paul, are you the author of the
PowerMac IDE stuff? So we can work this out... 

On  28 Jul, this message from Andre M. Hedrick echoed through cyberspace:
>> > pdc202xx.c has no tuneproc.  Is this deliberate?
> 
> YES, there are no known or possible way to ever get the card in to a PIO
> mode that is meaningful.  The BIOS defaults to a fixed value.

Not sure what it means, but Promise' doc says it can do PIO modes. But
I prefer DMA ;-)....

>> > 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?
> 
> I am glad that it meets with your approval, if you can do better do it!

;-)) How about this:

/dev/hde:
 Timing buffered disk reads:  64 MB in  6.60 seconds = 9.70 MB/sec
Maxtor 91024D4; 10G 7200 RPM, UDMA-2 ie 33 MB/s.

However, I don't know what this means:
[root@piglet ~]# hdparm -i /dev/hde  

/dev/hde:

 Model=Maxtor 91024D4, FwRev=NAN4251A, SerialNo=W407PXHA
 Config={ Fixed }
 RawCHS=19590/16/63, TrkSize=0, SectSize=0, ECCbytes=54
 BuffType=3(DualPortCache), BuffSize=512kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=2(fast)
 CurCHS=19590/16/63, CurSects=-66060037, LBA=yes, LBAsects=19746720
 WARNING 85806757 ORPHANED SECTORS :: KERNEL REPORTING ERROR
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2 
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4 
 UDMA modes: mode0 mode1 mode2 
 Drive Supports : ATA/ATAPI-4 T13 1153D revision 17 : ATA-1 ATA-2 ATA-3 ATA-4 

Any ideas? Drive bug, driver capacity calculation error, or endianess
error?

Andre, I have had my machine hang solid when doing either 

	hdparm -I /dev/hde   	or
	hdparm -d1 -X66 /dev/hde

Any idea what could be causing this?

Thanks, all!

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

[-- Attachment #2: linux-asm-ide.patch --]
[-- Type: TEXT/plain, Size: 1185 bytes --]

--- linux/arch/ppc/kernel/pmac_setup.c	Sun Aug  8 21:26:26 1999
+++ linux-ideok/arch/ppc/kernel/pmac_setup.c	Sun Aug  8 19:12:16 1999
@@ -41,6 +41,7 @@
 #include <linux/blk.h>
 #include <linux/vt_kern.h>
 #include <linux/console.h>
+#include <linux/ide.h>
 #include <asm/prom.h>
 #include <asm/system.h>
 #include <asm/pgtable.h>
@@ -53,7 +54,6 @@
 #include <asm/ohare.h>
 #include <asm/mediabay.h>
 #include <asm/feature.h>
-#include <asm/ide.h>
 #include <asm/machdep.h>
 
 #include "time.h"
@@ -550,10 +550,12 @@
  * This registers the standard ports for this architecture with the IDE
  * driver.
  */
+/* It is already defined in include/asm-ppc/ide.h
 void
 ide_init_default_hwifs(void)
 {
 }
+ */
 #endif
 
 __initfunc(void
--- linux/arch/ppc/kernel/chrp_pci.c	Sat Aug  7 17:09:39 1999
+++ linux-ideok/arch/ppc/kernel/chrp_pci.c	Sat Aug  7 17:33:51 1999
@@ -8,6 +8,7 @@
 #include <linux/string.h>
 #include <linux/init.h>
 #include <linux/openpic.h>
+#include <linux/ide.h>
 
 #include <asm/io.h>
 #include <asm/pgtable.h>
@@ -15,7 +16,6 @@
 #include <asm/hydra.h>
 #include <asm/prom.h>
 #include <asm/gg2.h>
-#include <asm/ide.h>
 #include <asm/machdep.h>
 
 #include "pci.h"

Re: Trying a Promise Ultra/66 on powerpc

[Tom Rini]

On Sun, 8 Aug 1999, Michel Lanners wrote:

> This fact was already catered for with the definition of outb/inb and
> friends, which get an offset added to the port. Unfortunately, the
> PowerMac IDE code undoes this and replaces it with a different
> mechanism, which in essence removes the offset. Grrr..
>
> I've solved the problem by adding the right offset directly to the
> io-port values as found in the kernel's PCI structures. I think this
> needs more serious rework, though. Paul, are you the author of the
> PowerMac IDE stuff? So we can work this out... 

Would this be one of the things solved/cleaned up by seperating ide-pmac.c
and the CONFIG option for it into generic enable IDE stuff and a driver
for the builtin IDE on some machines?  Last I tried, I needed to enable
both cmd646 and ide-pmac on myy blue&white (trying to do this is on my
todo list, someplace.. :))

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

On   8 Aug, this message from Tom Rini echoed through cyberspace:
> On Sun, 8 Aug 1999, Michel Lanners wrote:
[snip'ed about PMac IDE stuff]
> Would this be one of the things solved/cleaned up by seperating ide-pmac.c
> and the CONFIG option for it into generic enable IDE stuff and a driver
> for the builtin IDE on some machines?  Last I tried, I needed to enable
> both cmd646 and ide-pmac on myy blue&white (trying to do this is on my
> todo list, someplace.. :))

I hope so ;-). Not that I'm complaining, but <asm-ppc/ide.h> looks like
quite a mess to me....

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

Re: Trying a Promise Ultra/66 on powerpc

[Daniel Jacobowitz]

On Sun, Aug 08, 1999 at 04:55:01PM -0400, Tom Rini wrote:
> 
> On Sun, 8 Aug 1999, Michel Lanners wrote:
> 
> > This fact was already catered for with the definition of outb/inb and
> > friends, which get an offset added to the port. Unfortunately, the
> > PowerMac IDE code undoes this and replaces it with a different
> > mechanism, which in essence removes the offset. Grrr..
> >
> > I've solved the problem by adding the right offset directly to the
> > io-port values as found in the kernel's PCI structures. I think this
> > needs more serious rework, though. Paul, are you the author of the
> > PowerMac IDE stuff? So we can work this out... 
> 
> Would this be one of the things solved/cleaned up by seperating ide-pmac.c
> and the CONFIG option for it into generic enable IDE stuff and a driver
> for the builtin IDE on some machines?  Last I tried, I needed to enable
> both cmd646 and ide-pmac on myy blue&white (trying to do this is on my
> todo list, someplace.. :))

Yes, it would.  PMAC IDE is currently all mixed in the one option.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: Trying a Promise Ultra/66 on powerpc

[Paul Mackerras]

Tom Rini <trini@disparity.net> wrote:

> Would this be one of the things solved/cleaned up by seperating ide-pmac.c
> and the CONFIG option for it into generic enable IDE stuff and a driver
> for the builtin IDE on some machines?  Last I tried, I needed to enable
> both cmd646 and ide-pmac on myy blue&white (trying to do this is on my
> todo list, someplace.. :))

There's no problem about enabling both cmd646 and ide-pmac with the
current vger sources, is there?  You do need to select experimental
drivers as well as "Generic PCI IDE chipset support"
(CONFIG_BLK_DEV_IDEPCI) and "Generic PCI bus-master DMA support"
(CONFIG_BLK_DEV_IDEDMA) before you get asked about the CMD646, though.

Paul.

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

Re: Trying a Promise Ultra/66 on powerpc

[Tom Rini]

On Mon, 9 Aug 1999, Paul Mackerras wrote:

> Tom Rini <trini@disparity.net> wrote:
> 
> > Would this be one of the things solved/cleaned up by seperating ide-pmac.c
> > and the CONFIG option for it into generic enable IDE stuff and a driver
> > for the builtin IDE on some machines?  Last I tried, I needed to enable
> > both cmd646 and ide-pmac on myy blue&white (trying to do this is on my
> > todo list, someplace.. :))
> 
> There's no problem about enabling both cmd646 and ide-pmac with the
> current vger sources, is there?  You do need to select experimental
> drivers as well as "Generic PCI IDE chipset support"
> (CONFIG_BLK_DEV_IDEPCI) and "Generic PCI bus-master DMA support"
> (CONFIG_BLK_DEV_IDEDMA) before you get asked about the CMD646, though.

Right, the problem comes from enabling CMD646 but not ide-pmac.  Right now
to use any IDE chipset on a pmac, you need to say yes to "Builtin PowerMac
IDE support" and whichever chipset you have (to boot at least, I'll check
being able to use it once I can boot off something else, but it sounds
like there might be a problem there as well).

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/




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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

Hi all,

On   9 Aug, this message from Tom Rini echoed through cyberspace:
> On Mon, 9 Aug 1999, Paul Mackerras wrote:
>> There's no problem about enabling both cmd646 and ide-pmac with the
>> current vger sources, is there?  You do need to select experimental
>> drivers as well as "Generic PCI IDE chipset support"
>> (CONFIG_BLK_DEV_IDEPCI) and "Generic PCI bus-master DMA support"
>> (CONFIG_BLK_DEV_IDEDMA) before you get asked about the CMD646, though.
> 
> Right, the problem comes from enabling CMD646 but not ide-pmac.  Right now
> to use any IDE chipset on a pmac, you need to say yes to "Builtin PowerMac
> IDE support" and whichever chipset you have (to boot at least, I'll check
> being able to use it once I can boot off something else, but it sounds
> like there might be a problem there as well).

On my box, the kernel panics on IDE initialization if I don't enable
builtin PowerMac IDE. There's no problem compiling the kernel, though...
and I haven't had time to trace the problems. Might be a missing
function definition (although linker should catch that?) or an
undefined constant? Or the uninitialized ppc_ide_md array?

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

Re: Trying a Promise Ultra/66 on powerpc

[Daniel Jacobowitz]

On Sun, Aug 08, 1999 at 09:54:12PM +0200, Michel Lanners wrote:
> Problems start with the changed definition of a few ide functions, now
> using hw_regs_t, in asm-ppc/ide.h. As a result,
> arch/ppc/kernel/pmac_setup.c and chrp_pci.c need to include linux/ide.h
> instead of asm/ide.h. In addition, pmac_setup.c
> defines an empty ide_init_default_hwifs(), but it was previously
> defined in asm-ppc/ide.h. Patch (linux-asm-ide.patch) below.

Check.

> Then, I had the problem of enabling the PCI IO space of the card; I
> have tried a more generic patch which I'll send in a different mail
> with other PCI-related stuff (IRQ related).

Great.  I hacked around this in Promise.

> What annoyed me the most, was getting access to the I/O-ports of the
> Promise going. Turns out that the PCI config registers contain the IO
> address as seen from the bus, which is not the same as seen from the
> CPU. In fact, they start at 0x0 on the PCI bus, but the host bridge
> maps that area to 0xf2000000 on the processor bus. 
> 
> This fact was already catered for with the definition of outb/inb and
> friends, which get an offset added to the port. Unfortunately, the
> PowerMac IDE code undoes this and replaces it with a different
> mechanism, which in essence removes the offset. Grrr..
> 
> I've solved the problem by adding the right offset directly to the
> io-port values as found in the kernel's PCI structures. I think this
> needs more serious rework, though. Paul, are you the author of the
> PowerMac IDE stuff? So we can work this out... 

This didn't, oddly, stop my card from working.  It does, however, make
me lock up hard if I hdparm -i /dev/hda.

Oh, if you didn't pick this up, you can make it ide0/1 instead of
ide2/3 by enable CONFIG_BLK_DEV_OFFBOARD.

> >> > /dev/hdc:
> >> >   Timing buffered disk reads:  32 MB in  5.83 seconds = 5.49 MB/sec
> ;-)) How about this:
> 
> /dev/hde:
>  Timing buffered disk reads:  64 MB in  6.60 seconds = 9.70 MB/sec
> Maxtor 91024D4; 10G 7200 RPM, UDMA-2 ie 33 MB/s.

Eek.  I want that :)


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

Hi Dan,

I'm getting returned mail (user unknown) on Andre's email address. Do
you happen to know his new address?

On   8 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
[Io port mapping funnies]
>
> This didn't, oddly, stop my card from working.  It does, however, make
> me lock up hard if I hdparm -i /dev/hda.

What is your machine? Any IDE devices onboard?

I'm getting lockups myself on hdparm -I and -d1 -X66 (for the Maxtor
drive) and at drive identification on bootup with a Quantum Fireball.
Weired....

> Oh, if you didn't pick this up, you can make it ide0/1 instead of
> ide2/3 by enable CONFIG_BLK_DEV_OFFBOARD.

Yeah, I was just too lazy to enable it, thanks ;-)

>> /dev/hde:
>>  Timing buffered disk reads:  64 MB in  6.60 seconds = 9.70 MB/sec
>> Maxtor 91024D4; 10G 7200 RPM, UDMA-2 ie 33 MB/s.
> 
> Eek.  I want that :)

Yeah, interesting drive, as it is _very_ silent; nothing to do with the
usual 7200 RPM stuff, plus it is relatively fast. And affordable ;-) 

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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

On   8 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
> On Sun, Aug 08, 1999 at 09:54:12PM +0200, Michel Lanners wrote:
>> >> > /dev/hdc:
>> >> >   Timing buffered disk reads:  32 MB in  5.83 seconds = 5.49 MB/sec
>> ;-)) How about this:
>> 
>> /dev/hde:
>>  Timing buffered disk reads:  64 MB in  6.60 seconds = 9.70 MB/sec
>> Maxtor 91024D4; 10G 7200 RPM, UDMA-2 ie 33 MB/s.
> 
> Eek.  I want that :)

No, you'd rather want _this_:

/dev/hda:
 Timing buffered disk reads:  64 MB in  4.67 seconds =13.70 MB/sec

bonnie looks even more impressive:

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
max       200 12816 86.2 12382 38.7  5104 32.4 12365 84.6 20219 50.6 156.4  2.7

This is still with the Maxtor drive, but with forcing the burst bit
enabled:

PDC202XX_FORCE_BURST_BIT=y

I suppose this changes the way data is transfered across the PCI bus,
making the Promise send bursts of data rather than single longs.

So try it for yourself....

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

Re: Trying a Promise Ultra/66 on powerpc

[Geert Uytterhoeven]

On Thu, 12 Aug 1999, Michel Lanners wrote:
> On   8 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
> > On Sun, Aug 08, 1999 at 09:54:12PM +0200, Michel Lanners wrote:
> >> >> > /dev/hdc:
> >> >> >   Timing buffered disk reads:  32 MB in  5.83 seconds = 5.49 MB/sec
> >> ;-)) How about this:
> >> 
> >> /dev/hde:
> >>  Timing buffered disk reads:  64 MB in  6.60 seconds = 9.70 MB/sec
> >> Maxtor 91024D4; 10G 7200 RPM, UDMA-2 ie 33 MB/s.
> > 
> > Eek.  I want that :)
> 
> No, you'd rather want _this_:
> 
> /dev/hda:
>  Timing buffered disk reads:  64 MB in  4.67 seconds =13.70 MB/sec

Stop whining and buy an UW-SCSI disk :-) My Viking II flies at 17 MB/s.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


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

Re: Trying a Promise Ultra/66 on powerpc

[Paul Mackerras]

> This fact was already catered for with the definition of outb/inb and
> friends, which get an offset added to the port. Unfortunately, the
> PowerMac IDE code undoes this and replaces it with a different
> mechanism, which in essence removes the offset. Grrr..

Not any more.  I took that stuff out a few weeks ago so that the
CMD646 on the blue&white G3s could work.

Basically the problem is that the IDE driver assumes that you access
all IDE controllers via I/O ports.  When you have a controller that
has memory-mapped registers, there is a problem.  When you have a
system where one IDE controller has I/O ports and another has memory-
mapped registers, you have a bigger problem.  The current approach to
solving this problem is to map the addresses of the memory-mapped
registers into pseudo I/O port numbers (by subtracting _IO_BASE).  If
there is a better way, somebody let me know. :-)

> I've solved the problem by adding the right offset directly to the
> io-port values as found in the kernel's PCI structures. I think this
> needs more serious rework, though. Paul, are you the author of the
> PowerMac IDE stuff? So we can work this out... 

Yep, for my sins. :-) :-)

Also, does anyone know how a quick way to get the best DMA cycle
timing values in a tuneproc?

Paul.

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

Re: Trying a Promise Ultra/66 on powerpc

[David A. Gatwood]

On Mon, 9 Aug 1999, Paul Mackerras wrote:

> > I've solved the problem by adding the right offset directly to the
> > io-port values as found in the kernel's PCI structures. I think this
> > needs more serious rework, though. Paul, are you the author of the
> > PowerMac IDE stuff? So we can work this out... 
> 
> Yep, for my sins. :-) :-)
> 
> Also, does anyone know how a quick way to get the best DMA cycle
> timing values in a tuneproc?

You mean for IDE?  Check the MkLinux driver.  One of Apple's folks ported
some OS X (server?) code in for IDE DMA timings a couple months back.


David


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

Re: Trying a Promise Ultra/66 on powerpc

[Paul Mackerras]

David A. Gatwood <dgatwood@mvista.com> wrote:

> You mean for IDE?  Check the MkLinux driver.  One of Apple's folks ported
> some OS X (server?) code in for IDE DMA timings a couple months back.

I saw some code in the macosx driver that looks in the driveid and
figures it all out - is that what you mean?

I guess I was asking whether there was already some nifty function in
the Linux kernel that did for DMA modes what ide_get_best_pio_mode
does for PIO modes.

Also, do you have a cvsweb server for your cvs repository?  I don't
want to have to checkout 10s of MB of source just to look at a couple
of files. :-)  (See http://samba.org/cvs.html if you haven't come
across cvsweb before.)

Regards,
Paul.

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

Re: Trying a Promise Ultra/66 on powerpc

[David A. Gatwood]

On Mon, 9 Aug 1999, Paul Mackerras wrote:

> David A. Gatwood <dgatwood@mvista.com> wrote:
> 
> > You mean for IDE?  Check the MkLinux driver.  One of Apple's folks ported
> > some OS X (server?) code in for IDE DMA timings a couple months back.
> 
> I saw some code in the macosx driver that looks in the driveid and
> figures it all out - is that what you mean?

I have _no_ idea where in the code the guy found this stuff.  :-)


> I guess I was asking whether there was already some nifty function in
> the Linux kernel that did for DMA modes what ide_get_best_pio_mode
> does for PIO modes.
> 
> Also, do you have a cvsweb server for your cvs repository?  I don't
> want to have to checkout 10s of MB of source just to look at a couple
> of files. :-)  (See http://samba.org/cvs.html if you haven't come
> across cvsweb before.)

I haven't set up CVSweb, but you can just check out a couple of files.
The relevant ones are

osfmk/src/mach_kernel/ppc/POWERMAC/wd.c
osfmk/src/mach_kernel/ppc/POWERMAC/wdreg.h
osfmk/src/mach_kernel/ppc/POWERMAC/wd_entries.h

And you're right, I should set that up....  :-)


Later,
David


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

Re: Trying a Promise Ultra/66 on powerpc

[Benjamin Herrenschmidt]

On Mon, Aug 9, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:

>Basically the problem is that the IDE driver assumes that you access
>all IDE controllers via I/O ports.  When you have a controller that
>has memory-mapped registers, there is a problem.  When you have a
>system where one IDE controller has I/O ports and another has memory-
>mapped registers, you have a bigger problem.  The current approach to
>solving this problem is to map the addresses of the memory-mapped
>registers into pseudo I/O port numbers (by subtracting _IO_BASE).  If
>there is a better way, somebody let me know. :-)

Looks like the best way would be to store the port base or pointers to
the in/out functions in the HWIF structure.

>> I've solved the problem by adding the right offset directly to the
>> io-port values as found in the kernel's PCI structures. I think this
>> needs more serious rework, though. Paul, are you the author of the
>> PowerMac IDE stuff? So we can work this out... 
>
>Yep, for my sins. :-) :-)
>
>Also, does anyone know how a quick way to get the best DMA cycle
>timing values in a tuneproc?

I looked for this not so long ago, when fixing the sl82c105.c for a board
we are designing. unfortunately, it looks like the Linux kernel expect
the BIOS to have done all the work of setting the DMA mode. This is
especially nasty for removable drives and for controllers like the
winbond using the same register for DMA and PIO timings.
Also, I heard (I didn't check) that the tuneproc is not appropriate for
this since it may be called with using_dma not set to it's definitive value.
I was thinking about doing this in the dma_proc itself, when DMA is
enabled/disabled.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

Hi gentlemen (any ladies around?),

On   9 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
> On Mon, Aug 9, 1999, Paul Mackerras <paulus@cs.anu.edu.au> wrote:
>>Basically the problem is that the IDE driver assumes that you access
>>all IDE controllers via I/O ports.  When you have a controller that
>>has memory-mapped registers, there is a problem.  When you have a
>>system where one IDE controller has I/O ports and another has memory-
>>mapped registers, you have a bigger problem.  The current approach to
>>solving this problem is to map the addresses of the memory-mapped
>>registers into pseudo I/O port numbers (by subtracting _IO_BASE).  If
>>there is a better way, somebody let me know. :-)
> 
> Looks like the best way would be to store the port base or pointers to
> the in/out functions in the HWIF structure.

How about fixing this in the kernel's PCI bus structures, by adding any
required offsets in the pci_fixup() routines? This would make for clean
inb()/outb() definitions (no offset), and also accomodates multiple I/O
spaces behind more than one bridge. For instance, on the 7x00, both
bandit and chaos have I/O space; the one for the PCI cards, the other
for control (yes, control has an I/O port range! Not sure it serves,
though...).

Any fixed-offset approach would break with multiple I/O ranges.... Not
to mention the 9x00 machines (two separate host bridges, each three
slots), where you can't work around the problem by using hardcoded
addresses for the known motherboard chips.

I guess this approach could be made to work across the PPC
architecture, not only on the PMac, as the PPC in general lacks anything
special about I/O space... after all, those are just small memory
spaces ;-)

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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

On   9 Aug, this message from Paul Mackerras echoed through cyberspace:
>> This fact was already catered for with the definition of outb/inb and
>> friends, which get an offset added to the port. Unfortunately, the
>> PowerMac IDE code undoes this and replaces it with a different
>> mechanism, which in essence removes the offset. Grrr..
> 
> Not any more.  I took that stuff out a few weeks ago so that the
> CMD646 on the blue&white G3s could work.

Is that change in vger only? Submitted for 2.2.11?

> Basically the problem is that the IDE driver assumes that you access
> all IDE controllers via I/O ports.

Not a problem in itself, I guess: it's just that on the PPC, I/O ports
are not necessarily below 64k in processor-view..

> When you have a controller that
> has memory-mapped registers, there is a problem.  When you have a
> system where one IDE controller has I/O ports and another has memory-
> mapped registers, you have a bigger problem.  The current approach to
> solving this problem is to map the addresses of the memory-mapped
> registers into pseudo I/O port numbers (by subtracting _IO_BASE).  If
> there is a better way, somebody let me know. :-)

I'd vote for making I/O ports a memory addresss like any other, and
making sure drivers get this address right. See my other post for
details..

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

Re: Trying a Promise Ultra/66 on powerpc

[Paul Mackerras]

Michel Lanners <mlan@cpu.lu> wrote:

> I'd vote for making I/O ports a memory addresss like any other, and
> making sure drivers get this address right. See my other post for
> details..

The problem is, there are PCI device drivers which assume you can get
an address in I/O space from a PCI device (either directly from the
config-space base address registers or from the pci_dev struct) and
then just do inb and outb on that port address.  That's why inb/outb
add _IO_BASE to the port number.

One way might be to adjust the base addresses in all the pci_dev
structs and then make sure all drivers use the address from the
pci_dev struct rather than reading config space themselves.

Paul.

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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

On  10 Aug, this message from Paul Mackerras echoed through cyberspace:
> Michel Lanners <mlan@cpu.lu> wrote:
> 
>> I'd vote for making I/O ports a memory addresss like any other, and
>> making sure drivers get this address right. See my other post for
>> details..
> 
> The problem is, there are PCI device drivers which assume you can get
> an address in I/O space from a PCI device (either directly from the
> config-space base address registers or from the pci_dev struct) and
> then just do inb and outb on that port address.  That's why inb/outb
> add _IO_BASE to the port number.
> 
> One way might be to adjust the base addresses in all the pci_dev
> structs and then make sure all drivers use the address from the
> pci_dev struct rather than reading config space themselves.

Exactly what I meant. I feel drivers shouldn't read addresses directly
from config space, but rather from the pci_dev struct, so that any
necessary pcibios_fixup() can be made. By the way, the same is true for
interrupts....

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

Re: Trying a Promise Ultra/66 on powerpc

[Benjamin Herrenschmidt]

On Tue, Aug 10, 1999, Michel Lanners <mlan@cpu.lu> wrote:

>Exactly what I meant. I feel drivers shouldn't read addresses directly
>from config space, but rather from the pci_dev struct, so that any
>necessary pcibios_fixup() can be made. By the way, the same is true for
>interrupts....

I fully agree with that, except that we should keep a way for a driver to
know which offset to apply, in case it really needs to go thru config
space hacks. (There are some exceptional cases where devices are
incorrectly mapped).

I beleive we should fixup this way both io addresses and interrupt
numbers. OF dev tree is great, but we should keep things coherent with
other archs, especially for generic PCI drivers.

Finally, the pci subsystem could export a couple of function to
re-allocate an i/o or memory range on a given bus (and return the
appropriate offset) for the few drivers that need to hack with their
original mappings.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




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

Re: Trying a Promise Ultra/66 on powerpc

[Martin Mares]

Hello,

> Exactly what I meant. I feel drivers shouldn't read addresses directly
> from config space, but rather from the pci_dev struct, so that any
> necessary pcibios_fixup() can be made. By the way, the same is true for
> interrupts....

   They really shouldn't and I hope I've already fixed all drivers
in the kernel not to do that.

   Actually, it's already documented in Documentation/pci.txt :-)

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Computers are useless.  They can only give you answers."  -- Pablo Picasso

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

Re: Trying a Promise Ultra/66 on powerpc

[Geert Uytterhoeven]

On Tue, 10 Aug 1999, Paul Mackerras wrote:
> Michel Lanners <mlan@cpu.lu> wrote:
> > I'd vote for making I/O ports a memory addresss like any other, and
> > making sure drivers get this address right. See my other post for
> > details..
> 
> The problem is, there are PCI device drivers which assume you can get
> an address in I/O space from a PCI device (either directly from the
> config-space base address registers or from the pci_dev struct) and
> then just do inb and outb on that port address.  That's why inb/outb
> add _IO_BASE to the port number.
> 
> One way might be to adjust the base addresses in all the pci_dev
> structs and then make sure all drivers use the address from the
> pci_dev struct rather than reading config space themselves.

Which will make our /proc/ioports look funny.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

On  10 Aug, this message from Geert Uytterhoeven echoed through cyberspace:
>> One way might be to adjust the base addresses in all the pci_dev
>> structs and then make sure all drivers use the address from the
>> pci_dev struct rather than reading config space themselves.
> 
> Which will make our /proc/ioports look funny.

[mlan@piglet ~]$ cat /proc/ioports
f2000480-f2000487 : ide2
f2000488-f200048f : ide3
f2000490-f20004bf : PDC20262

I don't see why this would be funny.... except if you're used to the
PeeCee definition of IO ports being below 64 k ;-))

In any case, I still find it much better to adjust pci_dev, than to
play with offsets in inb()/outb().

But most important, adjusting struct pci_dev is the only way I see to
support IO space on more than one host bridge.

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

Re: Trying a Promise Ultra/66 on powerpc

[Tom Rini]

On Tue, 27 Jul 1999, Daniel Jacobowitz wrote:

> (A) You can't compile IDE as a module and enable ide-pmac.  There will
> be link errors in pmac_setup.c.
> 
> (B) Very closely tied to that, if ide-pmac is not enabled, a dummy
> pmac_ide_init_hwif_ports() is compiled in pmac_setup.c.  But the real
> version of this function (in ide-pmac.c) does more than just onboard
> IDE specific tasks.  For PCI IDE cards it is still needed.  Enabling
> ide-pmac eventually let me make use of the card.

This is because the ide-pmac option is general IDE support and onboard IDE
on the older macs.  It should be setup ALA x86, so that config_ide or
whatever does yes/no to IDE support and ide-pmac is pmac ide driver only.
The module thing was (i think) fixed or atleast worked around a while
back, check the linuxpp.cs.nmt.edu dirs..

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


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

Re: Trying a Promise Ultra/66 on powerpc

[Martin Mares]

Hello,

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

   Yes. Take a look at arch/i386/kernel/bios32.c, the pcibios_fixup_devices
function.
 
> 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...

   The current resource management code doesn't support searching
for free regions, but I already have some patches for it, they only
need some more work.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"How an engineer writes a program: Start by debugging an empty file..."

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

Re: Trying a Promise Ultra/66 on powerpc

[Andre M. Hedrick]

On Wed, 28 Jul 1999, Martin Mares wrote:

>    Yes. Take a look at arch/i386/kernel/bios32.c, the pcibios_fixup_devices
> function.

When you make it let me know and I will add it my kernel directory, being
IDE related.  The "fortuna" patches have the ide-pmac.c fixed finally.
This was the current holdup for the 2.2.X ide updates.

http://linux.kernel.org/pub/linux/kernel/people/hedrick



Andre Hedrick
The Linux IDE guy


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

Re: Trying a Promise Ultra/66 on powerpc

[Michel Lanners]

Hi all,

Below you'll find my experiences so far with the Ultra/66...

On  27 Jul, this message from Daniel Jacobowitz echoed through cyberspace:
> OK.  I have this working now.  In getting it to work, I've come across
> a couple of issues.
> 
> (A) You can't compile IDE as a module and enable ide-pmac.  There will
> be link errors in pmac_setup.c.

Compiling workes for me. I've not been able to boot that kernel,
though... for other reasons (crashes in MacOS; I need BootX).

> (B) Very closely tied to that, if ide-pmac is not enabled, a dummy
> pmac_ide_init_hwif_ports() is compiled in pmac_setup.c.  But the real
> version of this function (in ide-pmac.c) does more than just onboard
> IDE specific tasks.  For PCI IDE cards it is still needed.  Enabling
> ide-pmac eventually let me make use of the card.

I agree; I had the same problem. I first tried to comment out
pmac_ide_init_hwif_ports(), without enabling ide-pmac; but that
resulted in a kernel panic upon initializing of the IDE driver. (Now
that I think about it: the panic might have been due to PCI stuff...)

In addition, I had to change include files: problem is that both
pmac_setup.c and chrp_pci.c need the definition of hw_regs_t, which is
defined in <linux/ide.h>. My solution was to replace
#include <asm/ide.h> with #include <linux/ide.h>; the latter including
<asm/ide.h> anyway. Is this the right solution?

There might be other platform-specific files that need this patch as
well; Andre: I think it is the changes you made to
pmac_ide_init_hwif_ports() that made this necessary; you might need to
patch all files where you changed this function.

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

Noticed that too. My solution is a more generic one: I copied the fixup
code from bios32.c over to arch/ppc/kernel/pmac_pci.c, minus the
I/O-port fixup. So far, it didn't break anything else, and according to
boot messages, it does correct the Ultra's PCI settings:

PCI: Probing PCI hardware
PCI: Enabling I/O for device 00:68
PCI: Enabling memory for device 00:68

Obviously, this is not the best solution neither, as it is only called
on the PowerMac platform.

> 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

Hmmm, according to boot messages, I'm getting PIO mode for all ports:

Uniform Multi-Platform E-IDE driver Revision: 6.20
PDC20262: IDE controller on PCI bus 00 dev 68
PDC20262: not 100% native mode: will probe irqs later
PDC20262: ROM enabled at 0x80820000
PDC20262: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode.
    ide2: BM-DMA at 0x0400-0x0407, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0x0408-0x040f, BIOS settings: hdg:pio, hdh:pio

> 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

You beat me on this one... I'm not getting anything off my disks:

hde: no response (status = 0xa1), resetting drive
hde: no response (status = 0xa1)
hdf: no response (status = 0xa1), resetting drive
hdf: no response (status = 0xa1)
hdg: no response (status = 0xa1), resetting drive
hdg: no response (status = 0xa1)
hdh: no response (status = 0xa1), resetting drive
hdh: no response (status = 0xa1)
hde: no response (status = 0xa1), resetting drive
hde: no response (status = 0xa1)
hdf: no response (status = 0xa1), resetting drive
hdf: no response (status = 0xa1)
hdg: no response (status = 0xa1), resetting drive
hdg: no response (status = 0xa1)
hdh: no response (status = 0xa1), resetting drive
hdh: no response (status = 0xa1)

Andre, any idea why it is not seing my disks? Anything you want me to
try? I've had both a Matrox and an IBM on the two ports, one via the
UDMA66 cable, the other via standard cable.

Thanks

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