On Wed, Jun 04, 2014 at 01:24:08PM +0200, BALATON Zoltan wrote:
On Wed, 4 Jun 2014, Segher Boessenkool wrote:
There surely is support for a host bridge?
Yes, for uninorth but PowerMac3,1 on real hardware has an additional bridge between the host bridge and the pci devices according to the device tree dumps I've seen and comments in QEMU that say it is not enabled because it is not supported by the firmware. I meant that bridge.
Let's see...
/pci@f0000000 \ that's the uni-n AGP host bridge /pci@f2000000 \ and that's the uni-n 66MHz PCI host bridge /pci@f2000000/pci-bridge@d \ PCI-PCI bridge to a 33MHz bus, \ all the goodies (usb, 1394, enet, macio) \ are on here. also some slots. this is \ keylargo. /pci@f4000000 \ another 66MHz bus, with the uni-n 1394 and enet \ on it
So the only PCI-PCI bridge is the one to keylargo. If that is not enabled nothing will work (it has the disks behind it, but what's more, also the interrupt controller and the interface to the PMU). So you are saying this does not work at all on hardware?
I agree that the code that decides when to enable bus mastering should be in the device driver.
Now I'm confused. One of you say it should be in pci.c the other says it should be in the device driver which is usbohci.c in this case. Currently it is in a function in pci.c which is only called for the only ohci controller supported so I think it satisfies both so no change needed. Did I misunderstood something?
I am saying the code that *decides* to enable bus mastering should be in the device driver, as you had it; only the device driver knows when in its initialisation is the appropriate place to enable bus mastering (many devices put junk on the bus if you enable it without first initialising other things). But the code that actually does the enabling probably belongs in the PCI subsystem (for example, it should refuse to enable it for a device if the parent bus (or grandparent, etc.) does not allow it).
It would be nice to test this on real hardware. If no one has that, just try to make sure your new code will not fail on hardware where the old code worked (like, don't run any "dangerous" code unless your device is detected).
I can't test on real hardware. The ohci driver is only used if an Apple Keylargo OHCI controller is detected that is fairly specific to mac99 machines where the current code probably does not work now due to the bridge issue above. So did I miss something?
Hrm? The USB OHCI is just a standard USB OHCI, used on way more machines than just Apple kit.
Now I'm confused :-)
Anyway, if the code is truly in such an abominable state that it does not work at all on hardware, just try to make sure it does keep working wherever it does now work. And write clean code, no awful hacks, certainly no awful hacks that cross boundaries and/or are not well documented, that kind of thing. Leave it in a better state than it was in originally and one day we will have something great ;-)
Segher