On 11/16/2012 01:06 PM, Benoit Cousson wrote: > On 11/16/2012 11:55 AM, Roger Quadros wrote: >> Hi Benoit, >> >> On 11/16/2012 12:30 PM, Benoit Cousson wrote: >>> Hi Roger, >>> >>> On 11/15/2012 03:56 PM, Roger Quadros wrote: >>>> Provides a means for the OMAP USB host subsystem to be initialized >>>> from Device tree. This is a first step for device tree migration where >>>> we specify only the board specific stuff. Things like I/O address space >>>> and interrupts are not yet specified in the device tree but can be >>>> done as a next step. >>>> >>>> This patch will allow boards to be booted with our without device tree >>>> and have USB host functional. >>>> >>>> Signed-off-by: Roger Quadros <[email protected]> >>>> --- >>>> .../devicetree/bindings/arm/omap/usb-host.txt | 60 >>>> +++++++++++++++++ >>>> arch/arm/mach-omap2/board-generic.c | 1 + >>>> arch/arm/mach-omap2/common.h | 2 + >>>> arch/arm/mach-omap2/usb-host.c | 71 >>>> ++++++++++++++++++++ >>>> 4 files changed, 134 insertions(+), 0 deletions(-) >>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/usb-host.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/omap/usb-host.txt >>>> b/Documentation/devicetree/bindings/arm/omap/usb-host.txt >>>> new file mode 100644 >>>> index 0000000..f25cfa4 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/arm/omap/usb-host.txt >>>> @@ -0,0 +1,60 @@ >>>> +* usb-host - OMAP USB Host Subsystem >>>> + >>>> +The OMAP USB host subsystem consists of the following modules >>>> +1) USBTLL (Tranceiverless interface) >>>> +2) USBHOST (Host Controller module) which includes both EHCI and OHCI >>>> controllers >>>> + >>>> +THe USB Host subsystem can be connected to the external world using 3 >>>> PORTs that could >>>> +be configured in various modes like UTMI+ for external PHY, ULPI >>>> transceiverless link (TLL), >>>> +Serial TLL, High-speed interchip (HSIC), etc. >>>> + >>>> +Required proprties: >>>> +- compatible: Must be "ti,usb-host"; >>>> +- num_ports: Number of physical ports available >>>> + >>>> +Optional properties: >>>> +- 1 child node for each available port. These child nodes are usually >>>> supplied by the >>>> + board support device tree as they are specific to how the ports are >>>> wired on the board >>>> + >>>> + - mode: Integer specifying the mode in which the port is used >>>> + * OMAP_USBHS_PORT_MODE_UNUSED = 0, >>>> + * OMAP_EHCI_PORT_MODE_PHY = 1, >>>> + * OMAP_EHCI_PORT_MODE_TLL = 2, >>>> + * OMAP_EHCI_PORT_MODE_HSIC = 3, >>>> + * OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0 = 4, >>>> + * OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM = 5, >>>> + * OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0 = 6, >>>> + * OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM = 7, >>>> + * OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0 = 8, >>>> + * OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM = 9, >>>> + * OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0 = 10, >>>> + * OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM = 11, >>>> + * OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0 = 12, >>>> + * OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM = 13, >>>> + - clk: Name of the clock that needs to be active when using the port >>>> + - clkrate: Frequency at which the above clk needs to be run at >>>> + >>>> + >>>> +Example: >>>> + >>>> +/* In the OMAP Core tree */ >>>> +usbhost: usb-host { >>>> + compatible = "ti,usb-host"; >>>> + num_ports = <3>; >>>> +}; >>>> + >>>> +/* In the Board tree */ >>>> +&usbhost { >>>> + port@0 { >>>> + mode = <1>; >>>> + clk = "auxclk3_ck"; >>>> + clkrate = <19200000>; >>>> + }; >>>> + port@1 { >>>> + mode = <0>; >>>> + }; >>>> + port@2 { >>>> + mode = <0>; >>>> + }; >>>> +}; >>>> + >>>> diff --git a/arch/arm/mach-omap2/board-generic.c >>>> b/arch/arm/mach-omap2/board-generic.c >>>> index 601ecdf..4e53b62 100644 >>>> --- a/arch/arm/mach-omap2/board-generic.c >>>> +++ b/arch/arm/mach-omap2/board-generic.c >>>> @@ -40,6 +40,7 @@ static void __init omap_generic_init(void) >>>> omap_sdrc_init(NULL, NULL); >>>> >>>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); >>>> + usbhost_init_of(); >>> >>> You should never have to add that kind of hacks in generic board file. >>> Why do you need that during board init? >>> >>> In theory, the of_platform_populate will create all the devices, and >>> during the driver probe you will create the sub nodes. >>> >> >> OK. I was thinking of this as a temporary fix till the USB host drivers >> support OF nodes natively. Maybe I should work on fixing up the host >> drivers instead. > > Well, yeah, that's clearly better. > >> But I'm not sure how the PM runtime calls map to omap_device/hwmod >> framework when device tree boot is used. I can see that the device tree >> node can specify "ti,hwmods = " parameter. Just can't seem to figure out >> how all this adds up :P > > It is done auto-magically in the omap_device code. As soon as you add > the "ti,hwmods: attribute, an omap_device will be created instead of a > regular platform_device. A custom PM domain is added to handle the > pm_runtime callback for OMAP IPs. And every omap_device belongs to that > PM domain. >
Thanks. Just figured out it happens through BUS_NOTIFY_ADD_DEVICE -> _omap_device_notifier_call() - > omap_device_build_from_dt() cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
