Hi Ray,
Good questions, thanks for asking them. The interfaces in that
bus glue haven't yet had that sort of "how much of this code
can we eliminate" treatment. Now that OHCI is getting lots of
support for non-PCI versions, that treatment is needed!
On Friday 06 August 2004 16:18, Ray Lehtiniemi wrote:
> - is there any reason for functions like these to exist?
>
> ohci-omap.c:usb_hcd_omap_hcim_irq()
> ohci-lh7a404.c:usb_hcd_lh7a404_hcim_irq()
>
> why couldn't the underlying usb_hcd_irq() function be registered
> directly with request_irq()?
That was the original idea. I think the deal is that folk
just copied/pasted the SA-1111 code, which did it that
way for no reason that's clear to me.
> - why is drivers/usb/core/hcd-pci.c in the core directory instead
> of the host directory? it's only used by the ohci/uhci/ehci drivers,
> and equivalent routines for non-pci functions are in the host
> directory
In core, it gets shared more easily. (On x86, it's almost a page
of text that drivers don't need to copy...) Most Linux systems use
that code. And the idea was to get away from the mode where
those three drivers had their own subtly different/broken copies
of such logic ... it caused a lot of HC-specific init bugs. (Now
we're getting to the point where init bugs are more likely to
be due to ACPI problems than USB problems. Real progress!)
> - the hc_driver->start() routines for most glue files are identical
> and non-specific. should that routine go into the top portion of the
> drivers/usb/host/ohci-hcd.c file, with a hook to a platform specific
> hc_driver->quirks() function to handle the PCI quirks detections?
That sounds like it might be a good solution to that problem.
Feel like submitting a patch? A related fix would be making
the HCD allocation routine take a handle to the underlying
device, so that by the time start() is called the hcca can have
already been allocated and zeroed.
> - on the same topic, why does ohci_pci_start() fail to call this
> chunk of code:
>
> if (hc_reset (ohci) < 0) {
> ohci_stop (hcd);
> return -ENODEV;
> }
>
> when all the others seem to do this before calling hc_start()?
PCI supports a newish HCD reset() method, which usbcore will
call. That doesn't actually look very PCI-specific. All the OHCIs
should provide reset() in the bus glue, not just PCI.
> - there appears to be a bunch of probe/remove/suspend/resume functions
> that specialize on bus type (PCI, amba, platform, omap, ...) which are
> invoked from the corresponding functions for each bus type. many
> of these have the same basic structure, and differ only in the
> way they allocate interrupts, memory resources, etc. is it reasonable
> to try and factor these out somehow?
Only if it works ... :)
The OMAP stuff now uses platform_bus though that's not merged.
In the near term I think using that is the most likely path to success
I'd certainly prefer if there was more shared code there, but for
historical reasons PCI has its own scheme that doesn't involve
publishing resources. It'd be nicest if the driver model addressed
at least some of those issues ... but so far it doesn't.
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
