USB support for device tree

[Grant Likely]

On Nov 4, 2011 11:08 PM, "Pavan Kondeti" <pkondeti at codeaurora.org> wrote:
>
> Hi
>
> On 11/4/2011 11:42 PM, Grant Likely wrote:
> > It is not legal for two device nodes to have overlapping 'reg' regions
> > (unless one is a child of the other), so by extension it is not okay
> > for two nodes to have the same 'name at addr'.  However, it is perfectly
> > acceptable and encouraged for two nodes at different addresses to
> > start with the same value for 'name@'.  This is called the generic
> > names recommended practice, and it can also be found in the ePAPR
> > documentation on node names.
> >
> > If you want to have both host and device drivers bound to a single
> > device for OTG mode, then you should use a wrapper driver in Linux
> > that binds to the single node and instantiates each of the interfaces
> > as a child device.  For an example take a look at
> > drivers/usb/host/fsl-mph-dr-of.c.
>
> Currently we have two platform devices one for OTG and one for host,
> corresponding drivers for them. If I would like to keep it this way, the
> device tree becomes something like below
>
> hsusb0-otg: usb-otg at 0xa6000000 {
>        compatible = "qcom,hsusb-otg";
>        ---
> };
>
> hsusb0-device: usb-gadget at 0xa6000000 {
>        compatible = "qcom,hsusb-device";
>        ---
> };
>
> hsusb0-host: usb at 0xa6000000 {
>        compatible = "qcom,hsusb-host", "usb-ehci";
>        ---
> };

No, you don't need three nodes. Only one node for the whole thing since
from the hardware perspective it is still a single device. The driver for
that node should create the child otg and gadget platform_devices so that
you can preserve the existing driver structure.

There does not need to be a device tree node for every struct device in the
kernel.

g.

>
> Are you okay with above naming convention?
>
> --
> Sent by a consultant of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20111104/e714093b/attachment.html>