On Sat, Aug 07, 2004 at 08:33:17AM -0700, David Brownell wrote:
> >
> > 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.
yup, that's what i did too. i'll go ahead with that change then.
> > - 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!)
ah, i see. hmm.. the one page savings explanation is vaguely unsatisfying,
but the broken copies argument makes a lot of sense.
> > - 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?
yah, i'll take a run at it sometime in the next week or so. i'll put
together a multi-platform patch for the irq handler thing too.
> 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.
you mean that when, for example, usb_hcd_sa1111_probe() calls
driver->hcd_alloc(), it should pass a pointer to struct sa1111_dev *dev,
(or the underlying struct device...), and the ohci_hcd_alloc()
routine should then take care of the dma_alloc_coherent() to set up
ohci->hcca? why would it need a pointer to the dev then?
hmm... looking at it, shouldn't the lh7a404, sa1111, omap probe routines
take care to call driver->hcd_free(hcd) if the hcd_buffer_create (hcd)
fails? seems like they all leak the hcd in that event... the err1 label
should move up a few lines...
> 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.
i only see this reset routine being called from usb_hcd_pci_probe(). is it
used elsewhere?
> > - 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 ... :)
that would be a selling feature :-)
> 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
where's the omap repository?
> 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.
yah, i've been trying to wrap my head around the new driver model. seems
like there's still a few rough edges here and there (or maybe just lack
of established conventions, i guess)
--
----------------------------------------------------------------------
Ray L <[EMAIL PROTECTED]>
-------------------------------------------------------
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
