Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

[Fabien Lahoudere]

Hello

I modify ci_hrdc_imx_probe to bypassÂ"data->phy = devm_usb_get_phy_by_phandle(&pdev->dev,
"fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init.

The problem is that in ci_ulpi_init, before calling "ci->ulpi = ulpi_register_interface(ci->dev,
&ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is called which is the
original function that make our system to hang.

Our phy is not initialised before calling ulpi_register_interface so I don't understand how the phy
can reply if it is not out of reset state.

The conclusion is that using ulpi_bus to manage our phy doesn't improve and we reach the same issue.

I will try to check if we don't do bad things in hw_phymode_configure.
If anyone have an idea it is welcome??

Fabien

On Thu, 2017-05-25 at 12:36 +0200, Fabien Lahoudere wrote:
> On Tue, 2017-05-23 at 14:00 -0700, Stephen Boyd wrote:
> > On 05/23, Fabien Lahoudere wrote:
> > > Hi,
> > > 
> > > We investigate on the topic and now our device tree look like:
> > > 
> > > in imx53.dtsi:
> > > 
> > > usbh2: usb@53f80400 {
> > > 	compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> > > ÂÂÂÂÂÂÂÂreg = <0x53f80400 0x0200>;
> > > ÂÂÂÂÂÂÂÂinterrupts = <16>;
> > > ÂÂÂÂÂÂÂÂclocks = <&clks IMX5_CLK_USBOH3_GATE>;
> > > ÂÂÂÂÂÂÂÂfsl,usbmisc = <&usbmisc 2>;
> > > ÂÂÂÂÂÂÂÂdr_mode = "host";
> > > ÂÂÂÂÂÂÂÂstatus = "disabled";
> > > };
> > > 
> > > usbmisc: usbmisc@53f80800 {
> > > 	#index-cells = <1>;
> > > 	compatible = "fsl,imx53-usbmisc";
> > > 	reg = <0x53f80800 0x200>;
> > > 	clocks = <&clks IMX5_CLK_USBOH3_GATE>;
> > > };
> > > 
> > > and in our dts:
> > > 
> > > &usbh2 {
> > > ÂÂÂÂÂÂÂÂpinctrl-names = "default";
> > > 	pinctrl-0 = <&pinctrl_usbh2>;
> > > 	disable-int60ck;
> > > ÂÂÂÂÂÂÂÂdr_mode = "host";
> > > ÂÂÂÂÂÂÂÂ//fsl,usbphy = <&usbphy2>;
> > > ÂÂÂÂÂÂÂÂvbus-supply = <&reg_usbh2_vbus>;
> > > ÂÂÂÂÂÂÂÂstatus = "okay";
> > > 	ulpi {
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂphy {
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂcompatible = "smsc,usb3315-ulpi";
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂreset-gpios = <&gpio4 4 GPIO_ACTIVE_LOW>;
> > > 			clock-names = "main_clk";
> > > 			/*
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ* Hardware uses CKO2 at 24MHz at several places. Set the parent
> > > 			Â*ÂÂclock of CKO2 to OSC.
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ*/
> > > 			clock-frequency = <24000000>;
> > > 			clocks = <&clks IMX5_CLK_CKO2>;
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂassigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
> > > 			assigned-clock-parents = <&clks IMX5_CLK_OSC>;
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂstatus = "okay";
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ};
> > > ÂÂÂÂÂÂÂÂ};
> > > };
> > > 
> > > And we create a basic driver to check what happened:
> > > 
> > > static int smsc_usb3315_phy_probe(struct ulpi *ulpi)
> > > {
> > > ÂÂÂÂÂÂÂÂprintk(KERN_ERR "Fabien: %s:%d-%s\n", __FILE__, __LINE__, __func__);
> > > 
> > > ÂÂÂÂÂÂÂÂreturn 0;
> > > }
> > > 
> > > static const struct of_device_id smsc_usb3315_phy_match[] = {
> > > ÂÂÂÂÂÂÂÂ{ .compatible = "smsc,usb3315-phy", },
> > > ÂÂÂÂÂÂÂÂ{ }
> > > };
> > > MODULE_DEVICE_TABLE(of, smsc_usb3315_phy_match);
> > > 
> > > static struct ulpi_driver smsc_usb3315_phy_driver = {
> > > ÂÂÂÂÂÂÂÂ.probe = smsc_usb3315_phy_probe,
> > > ÂÂÂÂÂÂÂÂ.driver = {
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ.name = "smsc_usb3315_phy",
> > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ.of_match_table = smsc_usb3315_phy_match,
> > > ÂÂÂÂÂÂÂÂ},
> > > };
> > > module_ulpi_driver(smsc_usb3315_phy_driver);
> > > 
> > > /*MODULE_ALIAS("platform:usb_phy_generic");*/
> > > MODULE_AUTHOR("GE Healthcare");
> > > MODULE_DESCRIPTION("SMSC USB 3315 ULPI Phy driver");
> > > MODULE_LICENSE("GPL v2");
> > > 
> > > I checked that the driver is registered by drivers/usb/common/ulpi.c:__ulpi_register_driver
> > > successfully.
> > 
> > Does the ulpi device have some vendor/product ids associated
> > with it? The design is made to only fallback to matching the
> > device to driver based on DT if the ulpi vendor id is 0.
> > Otherwise, if vendor is non-zero you'll need to have a
> > ulpi_device_id id table in your ulpi_driver structure.
> > 
> 
> Hi,
> 
> Thanks Stephen for your reply.
> Indeed we have a vendor/product so I modify my code but without effect.
> 
> After looking at the ulpi source code in the kernel, it seems that I need to call
> ulpi_register_interface. ci_hdrc_probe should be called to execute the ulpi init.
> 
> The problem is that we replace "fsl,usbphy = <&usbphy2>;" by an ulpi node but ci_hdrc_imx_probe
> fail
> because of "data->phy = devm_usb_get_phy_by_phandle(&pdev->dev, "fsl,usbphy", 0);"
> 
> So I will try to adapt ci_hdrc_imx_probe to continue phy initialisation if fsl,usbphy is missing.
> Is it the good way to proceed?
> 
> Thanks for any advice
> Fabien
>