[PATCH] fix powerbook media bay

[PATCH] fix powerbook media bay

[Paul Mackerras]

This patch fixes a couple of bugs and compile errors in the powerbook
media bay driver.  It was getting initialized after the IDE subsystem,
whereas it needs to be initialized before so that the IDE subsystem
can see the CD-ROM drive in the bay.

Please apply.

Paul.

diff -urN linux-2.5/drivers/macintosh/mediabay.c pmac-2.5/drivers/macintosh/mediabay.c
--- linux-2.5/drivers/macintosh/mediabay.c	2002-11-12 00:18:24.000000000 +1100
+++ pmac-2.5/drivers/macintosh/mediabay.c	2003-03-22 20:11:14.000000000 +1100
@@ -23,6 +23,7 @@
 #include <linux/stddef.h>
 #include <linux/unistd.h>
 #include <linux/init.h>
+#include <linux/ide.h>
 #include <asm/prom.h>
 #include <asm/pgtable.h>
 #include <asm/io.h>
@@ -493,7 +494,7 @@
 			} while(--timeout);
 			printk(KERN_DEBUG "Timeount waiting IDE in bay %d\n", i);
 			return -ENODEV;
-		} 
+		}
 #endif
 	
 	return -ENODEV;
@@ -567,9 +568,10 @@
 				hw_regs_t hw;
 
 				pmu_suspend();
-				ide_init_hwif_ports(&hw, (ide_ioreg_t) bay->cd_base, (ide_ioreg_t) 0, NULL);
+				ide_init_hwif_ports(&hw, (unsigned long) bay->cd_base, (unsigned long) 0, NULL);
 				hw.irq = bay->cd_irq;
-				bay->cd_index = ide_register_hw(&hw);
+				hw.chipset = ide_pmac;
+				bay->cd_index = ide_register_hw(&hw, NULL);
 				pmu_resume();
 			}
 			if (bay->cd_index == -1) {
@@ -834,4 +836,4 @@
 	return 0;
 }
 
-device_initcall(media_bay_init);
+subsys_initcall(media_bay_init);

Re: [PATCH] fix powerbook media bay

[Alan Cox]

On Sun, 2003-03-23 at 05:19, Paul Mackerras wrote:
> This patch fixes a couple of bugs and compile errors in the powerbook
> media bay driver.  It was getting initialized after the IDE subsystem,
> whereas it needs to be initialized before so that the IDE subsystem
> can see the CD-ROM drive in the bay.

IDE supports dynamic addition of interfaces so it should be possible
to make this work either way around.

Re: [PATCH] fix powerbook media bay

[Paul Mackerras]

Alan Cox writes:

> IDE supports dynamic addition of interfaces so it should be possible
> to make this work either way around.

Yes, it should be possible with some tweaks to the media bay driver.

It gets a bit complicated though because at the moment there is no way
to say "here's a new interface and by the way it's a pmac IDE
interface so please use the pmac driver on it".  (Come to that there
doesn't appear to be any way to dynamically add an interface that uses
MMIO.)

Consequently the pmac IDE driver needs to know about the mediabay IDE
interface at pmac_ide_probe time and reserve a slot for it (which it
does).  At that point the pmac IDE driver tells the mediabay driver
the ioremapped base address of the interface so that the mediabay
driver can pass that back in to ide_register_hw.  Which is all a bit
backwards.

Of course, if you happened to plug in a CF card while you didn't have
the CD drive in the media bay, the CF card would get the media bay's
hwif structure and it would blow up in your face.

Is the IDE stuff still in the middle of open-heart surgery?  I'm happy
to hack on it and send you patches if it isn't all going to change
dramatically in the next week anyway.

Paul.

Re: [PATCH] fix powerbook media bay

[Alan Cox]

On Sun, 2003-03-23 at 21:34, Paul Mackerras wrote:
> Is the IDE stuff still in the middle of open-heart surgery?  I'm happy
> to hack on it and send you patches if it isn't all going to change
> dramatically in the next week anyway.

Its on the crash trolley right now, but we think we may be able to save
the patient. The registration is saner now for PCI but not for the non
PCI cases. In addition the resource allocation is ass backwards and that
I will change at some point so the caller does the resource work.
PC9800 requires this really, PCMCIA badly needs it, and it lets me
remove a ton of hacks from the mmio aware drivers.

Alan

Re: [PATCH] fix powerbook media bay

[Benjamin Herrenschmidt]

On Mon, 2003-03-24 at 00:08, Alan Cox wrote:
> On Sun, 2003-03-23 at 21:34, Paul Mackerras wrote:
> > Is the IDE stuff still in the middle of open-heart surgery?  I'm happy
> > to hack on it and send you patches if it isn't all going to change
> > dramatically in the next week anyway.
> 
> Its on the crash trolley right now, but we think we may be able to save
> the patient. The registration is saner now for PCI but not for the non
> PCI cases. In addition the resource allocation is ass backwards and that
> I will change at some point so the caller does the resource work.
> PC9800 requires this really, PCMCIA badly needs it, and it lets me
> remove a ton of hacks from the mmio aware drivers.

Yes, please, do that :)

I did the hwif->mmio == 2 case especially for that purpose, that is
let the hwif driver deal with resource management since I need it
for ide-pmac.
(today, hwif->mmio == 0 means PIO, == 1 means MMIO with request_xxx
done by the generic code & other assumptions, and == 2 means the
generic code does nothing)

Paul: regarding media-bay, don't waste too much time on this for 2.5,
the whole probing stuff is going to change once I get the macio-asic
bus getting in and all those drivers moved to the new model.

The kernel still badly lacks some good way to deal with driver
dependencies (similar what I did with OCP stuff where a driver
can return -EAGAIN on probe when it relies on some other
not-yet-probed driver, but that's really a hack).

What I will do is that:

 - PCI layer will probe the macio-asic (based on matching the
OF node with whatever pmac_feature will have detected. I did consider
moving all of pmac_feature to macio-asic, but we still need too many
stuff beeing initialized early, so at least for 2.5, it will stay split)

 - macio-asic declares a bus type, and will probe devices based
on the OF tree. At this point, it will probe media-bays first

 - then it probes IDE drivers. Thus, the registration mecanism of
ide-pmac will be a carbon-copy of the one for IDE PCI devices.

In order to deal with ordering properly, media-bay will not call
ide_register_hw directly. Instead, it will call a pmac-ide specific
routine (either via macio-asic, that is it will force macio-asic
to add a new device to it's tree as by default, it will only be
one level deep, or I will go directly to ide-pmac, I haven't
decided yet).

At that point, ide-pmac can decide what to do, that is just reserve
the hwif slot for later probe, or really call ide_register_hw.

Ben.