On Fri, Aug 05, 2011 at 10:59:12AM +0300, Heikki Krogerus wrote:
> Hi,
>
> On Fri, Aug 05, 2011 at 08:59:55AM +0200, Sascha Hauer wrote:
> > On Mon, Aug 01, 2011 at 05:29:14PM +0300, Heikki Krogerus wrote:
> > > This is only the idea. Work in progress.
> > >
> > > Adds struct usb_transceiver and functions to interact with
> > > the controller drivers. This also introduces very basic
> > > support for multiple transceivers.
> >
> > +1, we really need this to properly handle phys. The current single
> > transceiver support depends on the fact that there may be only one
> > otg port, which is true. Other host only ports often have a transceiver
> > aswell though.
>
> And there can be more the one transceiver even for one otg port. Take
> a look at RX-51 platform.
>
> > > +/*
> > > + * usb_get_transceiver - find a USB transceiver
> > > + * @name: the name of the transceiver driver
> > > + *
> > > + * Returns a transceiver driver matching the name, or NULL, and gets
> > > + * refcount to it. The caller is responsible for calling
> > > + * usb_put_transceiver() to release that count.
> > > + */
> > > +struct usb_transceiver *usb_get_transceiver(const char *name)
> > > +{
> >
> > What are drivers supposed to pass as name? I would say dev_name(dev),
> > right? In this case we might want to pass a struct device here.
>
> For this function? Well, this would be used by the controller drivers
> and what ever needs a handle to the transceiver. I don't believe we
> can use struct device here. It would mean the controller drivers would
> have the struct device of the transceivers beforehand.
>
> So the transceiver drivers would use usb_register_transceiver(struct
> usb_transceiver *) to add a themselves to the list. The controller
> drivers would use this function, usb_get_transceiver(), to get a
> handle to the transceiver.
Yes, that's clear to me. I just wondered what exact names we should use
to register a phy.
Consider a phy registering itself with
usb_register_transceiver(recv) with recv->name = "mxc-ehci.0"
(where recv->name could be passed from platform_data)
Then the mxc-ehci driver could get its receiver using
usb_get_transceiver(dev_name(&pdev->dev))
or with
usb_get_transceiver(&pdev->dev);
when we do what I suggested. This would be similar to the clocks which
get the clocks associated to a device with clk_get(&pdev->dev, id).
This would change the behaviour of usb_get_transceiver() from "give me
the phy with this name" to "give me the transceiver associated with this
device". It would prevent us from inventing arbitrary phy names.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
