| Message ID | 1359993540-20780-12-git-send-email-rogerq@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday 05 February 2013 03:04 PM, Roger Quadros wrote: > Hi Rajendra, > > On 02/04/2013 05:58 PM, Roger Quadros wrote: >> Provide the RESET and Power regulators for the USB PHY, >> the USB Host port mode and the PHY device. >> >> Also provide pin multiplexer information for the USB host >> pins. >> >> Signed-off-by: Roger Quadros <rogerq@ti.com> >> --- >> arch/arm/boot/dts/omap4-panda.dts | 55 +++++++++++++++++++++++++++++++++++++ >> 1 files changed, 55 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts >> index 4122efe..fe2d3d4 100644 >> --- a/arch/arm/boot/dts/omap4-panda.dts >> +++ b/arch/arm/boot/dts/omap4-panda.dts >> @@ -57,6 +57,35 @@ >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> + >> + /* HS USB Port 1 RESET */ >> + hsusb1_reset: hsusb1_reset_reg { >> + compatible = "regulator-fixed"; >> + regulator-name = "hsusb1_reset"; >> + regulator-min-microvolt = <3300000>; >> + regulator-max-microvolt = <3300000>; >> + gpio = <&gpio2 30 0>; /* gpio_62 */ >> + startup-delay-us = <70000>; >> + enable-active-high; >> + }; >> + >> + /* HS USB Port 1 Power */ >> + hsusb1_power: hsusb1_power_reg { >> + compatible = "regulator-fixed"; >> + regulator-name = "hsusb1_vbus"; >> + regulator-min-microvolt = <3300000>; >> + regulator-max-microvolt = <3300000>; >> + gpio = <&gpio1 1 0>; /* gpio_1 */ >> + startup-delay-us = <70000>; >> + enable-active-high; >> + }; >> + >> + /* HS USB Host PHY on PORT 1 */ >> + hsusb1_phy: hsusb1_phy { >> + compatible = "usb-nop-xceiv"; >> + reset-supply = <&hsusb1_reset>; >> + vcc-supply = <&hsusb1_power>; >> + }; > > This is the patch I was discussing with you about before. > > Let me explain the problem again. > > The Pandaboard has a USB PHY whose reference clock is provided by > FREF_CLK3 pin which is a clock generated by the OMAP. > The PHY driver expects a reference to this clock in the PHY device node. Well, the driver just does a clk_get(dev, "main_clk"); and clk_get() is then able to either pick the reference from the PHY dt node or from a clkdev entry. The problem here seems to be that you are not able to add a clkdev entry because the device name wouldn't be fixed, since you have a node in the form of 'node: node {'. All other onchip OMAP devices don't have this issue because they have an entry in the form of 'node: node@addr' and hence have a fixed device name and hence can add a clkdev entry for the clocks they want to control. I don't know if there is any good way to define the DT node for the on board PHY in such a way that the device name is always fixed, in which case you can then add a clkdev entry for 'dev, main_clk' mapping to the onchip clock that provides the clock, but if there is one, then that should fix your problem. > See the above node hsusb1_phy. we would need something like > hsusb1_phy { > ... > clocks = <&fref_clk3>; > clock-names = "main_clk"; > ... > }; > > Currently on OMAP, there is no way to provide a phandle to this clock. > > Is it practical to provide device tree based implementation of at least > the externally accessible OMAP clocks? > > cheers, > -roger > >> }; >> >> &omap4_pmx_core { >> @@ -67,6 +96,7 @@ >> &mcbsp1_pins >> &dss_hdmi_pins >> &tpd12s015_pins >> + &hsusbb1_pins >> >; >> >> twl6040_pins: pinmux_twl6040_pins { >> @@ -110,6 +140,23 @@ >> 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */ >> >; >> }; > >
On 02/05/2013 01:15 PM, Rajendra Nayak wrote: > On Tuesday 05 February 2013 03:04 PM, Roger Quadros wrote: >> Hi Rajendra, >> >> On 02/04/2013 05:58 PM, Roger Quadros wrote: >>> Provide the RESET and Power regulators for the USB PHY, >>> the USB Host port mode and the PHY device. >>> >>> Also provide pin multiplexer information for the USB host >>> pins. >>> >>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>> --- >>> arch/arm/boot/dts/omap4-panda.dts | 55 +++++++++++++++++++++++++++++++++++++ >>> 1 files changed, 55 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts >>> index 4122efe..fe2d3d4 100644 >>> --- a/arch/arm/boot/dts/omap4-panda.dts >>> +++ b/arch/arm/boot/dts/omap4-panda.dts >>> @@ -57,6 +57,35 @@ >>> "AFML", "Line In", >>> "AFMR", "Line In"; >>> }; >>> + >>> + /* HS USB Port 1 RESET */ >>> + hsusb1_reset: hsusb1_reset_reg { >>> + compatible = "regulator-fixed"; >>> + regulator-name = "hsusb1_reset"; >>> + regulator-min-microvolt = <3300000>; >>> + regulator-max-microvolt = <3300000>; >>> + gpio = <&gpio2 30 0>; /* gpio_62 */ >>> + startup-delay-us = <70000>; >>> + enable-active-high; >>> + }; >>> + >>> + /* HS USB Port 1 Power */ >>> + hsusb1_power: hsusb1_power_reg { >>> + compatible = "regulator-fixed"; >>> + regulator-name = "hsusb1_vbus"; >>> + regulator-min-microvolt = <3300000>; >>> + regulator-max-microvolt = <3300000>; >>> + gpio = <&gpio1 1 0>; /* gpio_1 */ >>> + startup-delay-us = <70000>; >>> + enable-active-high; >>> + }; >>> + >>> + /* HS USB Host PHY on PORT 1 */ >>> + hsusb1_phy: hsusb1_phy { >>> + compatible = "usb-nop-xceiv"; >>> + reset-supply = <&hsusb1_reset>; >>> + vcc-supply = <&hsusb1_power>; >>> + }; >> >> This is the patch I was discussing with you about before. >> >> Let me explain the problem again. >> >> The Pandaboard has a USB PHY whose reference clock is provided by >> FREF_CLK3 pin which is a clock generated by the OMAP. >> The PHY driver expects a reference to this clock in the PHY device node. > > Well, the driver just does a clk_get(dev, "main_clk"); and clk_get() is > then able to either pick the reference from the PHY dt node or from a > clkdev entry. > > The problem here seems to be that you are not able to add a clkdev entry > because the device name wouldn't be fixed, since you have a node in > the form of 'node: node {'. All other onchip OMAP devices don't have > this issue because they have an entry in the form of 'node: node@addr' > and hence have a fixed device name and hence can add a clkdev entry for > the clocks they want to control. > > I don't know if there is any good way to define the DT node for the > on board PHY in such a way that the device name is always fixed, in > which case you can then add a clkdev entry for 'dev, main_clk' mapping > to the onchip clock that provides the clock, but if there is one, then > that should fix your problem. Fixing the device name doesn't really solve the problem. Not all OMAP boards will use the same clock for the external device. So you can't provide this information in some common clock data file. The data has to come from a board specific location, which in the DT boot case is the board's dts file. I think all we need to do is register a clock provider using of_clk_add_provider() and provide a clk_src_get() hook that can get the right clock. usage e.g. /* provider */ clks: omapclocks { compatible = "ti,omapclocks"; #clock-cells = <1>; }; /* consumer */ hsusb1_phy: hsusb1_phy { compatible = "usb-nop-xceiv"; clocks = <&clks "auxclk3_ck">; /* FREF_CLK3 */ clock-names = "main-clk"; }; The only problem I see is that the argument to the clks phandle cannot be a string. It needs to be u32. In that case we need to map all clocks into a u32 index. If we can do that only for auxclks, my problem is solved for panda. The usage e.g then changes to /* provider */ aux_clks: omap_aux_clocks { compatible = "ti,omap_aux_clocks"; #clock-cells = <1>; }; /* consumer */ hsusb1_phy: hsusb1_phy { compatible = "usb-nop-xceiv"; clocks = <&aux_clks 3>; /* FREF_CLK3 */ clock-names = "main-clk"; }; Does this idea sound reasonable? regards, -roger
On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: > Fixing the device name doesn't really solve the problem. > Not all OMAP boards will use the same clock for the external device. Are you saying different OMAP boards will use different Internal clocks? Or different OMAP boards will use a single Internal clock or an external one.
On 02/05/2013 04:13 PM, Rajendra Nayak wrote: > On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: >> Fixing the device name doesn't really solve the problem. >> Not all OMAP boards will use the same clock for the external device. > > Are you saying different OMAP boards will use different Internal clocks? > Or different OMAP boards will use a single Internal clock or an > external one. > All I was saying is that one board can use for example auxclk1 whereas another one can use auxclk3, both generated by OMAP for the same PHY configuration. cheers, -roger
On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote: > On 02/05/2013 04:13 PM, Rajendra Nayak wrote: >> On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: >>> Fixing the device name doesn't really solve the problem. >>> Not all OMAP boards will use the same clock for the external device. >> >> Are you saying different OMAP boards will use different Internal clocks? >> Or different OMAP boards will use a single Internal clock or an >> external one. >> > All I was saying is that one board can use for example auxclk1 whereas another > one can use auxclk3, both generated by OMAP for the same PHY configuration. Ok, so lets keep DT aside for a while. How would something like this work in a non-DT world? Would the driver then be able to do a clk_get(dev, "main_clk"); and get say auxclk1 on one board and auxclk3 on another? > > cheers, > -roger >
On 02/05/2013 04:21 PM, Rajendra Nayak wrote: > On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote: >> On 02/05/2013 04:13 PM, Rajendra Nayak wrote: >>> On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: >>>> Fixing the device name doesn't really solve the problem. >>>> Not all OMAP boards will use the same clock for the external device. >>> >>> Are you saying different OMAP boards will use different Internal clocks? >>> Or different OMAP boards will use a single Internal clock or an >>> external one. >>> >> All I was saying is that one board can use for example auxclk1 whereas another >> one can use auxclk3, both generated by OMAP for the same PHY configuration. > > Ok, so lets keep DT aside for a while. How would something like this > work in a non-DT world? Would the driver then be able to do a > clk_get(dev, "main_clk"); and get say auxclk1 on one board and > auxclk3 on another? > Yes, all you need to do is specify an alias to the clock in the board file. e.g. in board 1 file clk_add_alias("main_clk", "phy.1", "auxclk1_ck", NULL); in board 2 file clk_add_alias("main_clk", "phy.1", "auxclk3_ck", NULL); cheers, -roger
On Tuesday 05 February 2013 07:59 PM, Roger Quadros wrote: > On 02/05/2013 04:21 PM, Rajendra Nayak wrote: >> On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote: >>> On 02/05/2013 04:13 PM, Rajendra Nayak wrote: >>>> On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: >>>>> Fixing the device name doesn't really solve the problem. >>>>> Not all OMAP boards will use the same clock for the external device. >>>> >>>> Are you saying different OMAP boards will use different Internal clocks? >>>> Or different OMAP boards will use a single Internal clock or an >>>> external one. >>>> >>> All I was saying is that one board can use for example auxclk1 whereas another >>> one can use auxclk3, both generated by OMAP for the same PHY configuration. >> >> Ok, so lets keep DT aside for a while. How would something like this >> work in a non-DT world? Would the driver then be able to do a >> clk_get(dev, "main_clk"); and get say auxclk1 on one board and >> auxclk3 on another? >> > > Yes, all you need to do is specify an alias to the clock in the board file. Can we then create a special board specific node for panda and do similar things from DT? See a similar discussion below on how to handle the gpio_request() we had as part of board files http://www.spinics.net/lists/linux-omap/msg85248.html > > e.g. in board 1 file > clk_add_alias("main_clk", "phy.1", "auxclk1_ck", NULL); > > in board 2 file > clk_add_alias("main_clk", "phy.1", "auxclk3_ck", NULL); > > cheers, > -roger >
On 02/05/2013 04:36 PM, Rajendra Nayak wrote: > On Tuesday 05 February 2013 07:59 PM, Roger Quadros wrote: >> On 02/05/2013 04:21 PM, Rajendra Nayak wrote: >>> On Tuesday 05 February 2013 07:48 PM, Roger Quadros wrote: >>>> On 02/05/2013 04:13 PM, Rajendra Nayak wrote: >>>>> On Tuesday 05 February 2013 07:16 PM, Roger Quadros wrote: >>>>>> Fixing the device name doesn't really solve the problem. >>>>>> Not all OMAP boards will use the same clock for the external device. >>>>> >>>>> Are you saying different OMAP boards will use different Internal clocks? >>>>> Or different OMAP boards will use a single Internal clock or an >>>>> external one. >>>>> >>>> All I was saying is that one board can use for example auxclk1 whereas another >>>> one can use auxclk3, both generated by OMAP for the same PHY configuration. >>> >>> Ok, so lets keep DT aside for a while. How would something like this >>> work in a non-DT world? Would the driver then be able to do a >>> clk_get(dev, "main_clk"); and get say auxclk1 on one board and >>> auxclk3 on another? >>> >> >> Yes, all you need to do is specify an alias to the clock in the board file. > > Can we then create a special board specific node for panda and do > similar things from DT? > See a similar discussion below on how to handle the gpio_request() > we had as part of board files > http://www.spinics.net/lists/linux-omap/msg85248.html Doesn't look very elegant to me, but I wouldn't mind if there is no better option. Even then, we can't rely on the device name as its index can change based on where it is located in the dts file. e.g. in the beginning it may be named phy.8, and if a device node is added before it, it will get changed to phy.9 > >> >> e.g. in board 1 file >> clk_add_alias("main_clk", "phy.1", "auxclk1_ck", NULL); >> >> in board 2 file >> clk_add_alias("main_clk", "phy.1", "auxclk3_ck", NULL); >> cheers, -roger
On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote: > Doesn't look very elegant to me, but I wouldn't mind if there is no better option. > Even then, we can't rely on the device name as its index can change based on where it is Well, thats what I said in the first mail, that *if* you are able to fix the device name, *then* we could use clkdev the way its used in non-DT case. But then you came back saying 'Fixing the device name doesn't really solve the problem.' :) > located in the dts file. e.g. in the beginning it may be named phy.8, and if a device > node is added before it, it will get changed to phy.9 If you provide a phandle to the PHY node in the board node, for which you need to add the clk alias, you can always extract the device (using of_find_device_by_node() ) and hence its name, so it doesn't matter if its phy.8 or phy.9.
On 02/06/2013 12:21 PM, Rajendra Nayak wrote: > On Tuesday 05 February 2013 08:22 PM, Roger Quadros wrote: >> Doesn't look very elegant to me, but I wouldn't mind if there is no better option. >> Even then, we can't rely on the device name as its index can change based on where it is > > Well, thats what I said in the first mail, that *if* you are able to > fix the device name, *then* we could use clkdev the way its used in > non-DT case. But then you came back saying 'Fixing the device name > doesn't really solve the problem.' :) It does, yes, but depending on fixed device names is not so great for DT, is it? Doesn't solve the problem in the right sense :) > >> located in the dts file. e.g. in the beginning it may be named phy.8, and if a device >> node is added before it, it will get changed to phy.9 > > If you provide a phandle to the PHY node in the board node, for which > you need to add the clk alias, you can always extract the device (using > of_find_device_by_node() ) and hence its name, so it doesn't matter if > its phy.8 or phy.9. Right, I'll come up with something on these lines. Thanks for the suggestions :). cheers, -roger
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts index 4122efe..fe2d3d4 100644 --- a/arch/arm/boot/dts/omap4-panda.dts +++ b/arch/arm/boot/dts/omap4-panda.dts @@ -57,6 +57,35 @@ "AFML", "Line In", "AFMR", "Line In"; }; + + /* HS USB Port 1 RESET */ + hsusb1_reset: hsusb1_reset_reg { + compatible = "regulator-fixed"; + regulator-name = "hsusb1_reset"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + gpio = <&gpio2 30 0>; /* gpio_62 */ + startup-delay-us = <70000>; + enable-active-high; + }; + + /* HS USB Port 1 Power */ + hsusb1_power: hsusb1_power_reg { + compatible = "regulator-fixed"; + regulator-name = "hsusb1_vbus"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + gpio = <&gpio1 1 0>; /* gpio_1 */ + startup-delay-us = <70000>; + enable-active-high; + }; + + /* HS USB Host PHY on PORT 1 */ + hsusb1_phy: hsusb1_phy { + compatible = "usb-nop-xceiv"; + reset-supply = <&hsusb1_reset>; + vcc-supply = <&hsusb1_power>; + }; }; &omap4_pmx_core { @@ -67,6 +96,7 @@ &mcbsp1_pins &dss_hdmi_pins &tpd12s015_pins + &hsusbb1_pins >; twl6040_pins: pinmux_twl6040_pins { @@ -110,6 +140,23 @@ 0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */ >; }; + + hsusbb1_pins: pinmux_hsusbb1_pins { + pinctrl-single,pins = < + 0x82 0x10C /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */ + 0x84 0x4 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */ + 0x86 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */ + 0x88 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */ + 0x8a 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */ + 0x8c 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */ + 0x8e 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */ + 0x90 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */ + 0x92 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */ + 0x94 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */ + 0x96 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */ + 0x98 0x104 /* USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */ + >; + }; }; &i2c1 { @@ -206,3 +253,11 @@ &twl_usb_comparator { usb-supply = <&vusb>; }; + +&usbhshost { + port1_mode = <1>; /* OMAP_EHCI_PORT_MODE_PHY */ +}; + +&usbhsehci { + phy = <&hsusb1_phy>; +};
Provide the RESET and Power regulators for the USB PHY, the USB Host port mode and the PHY device. Also provide pin multiplexer information for the USB host pins. Signed-off-by: Roger Quadros <rogerq@ti.com> --- arch/arm/boot/dts/omap4-panda.dts | 55 +++++++++++++++++++++++++++++++++++++ 1 files changed, 55 insertions(+), 0 deletions(-)