From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034540AbdEYKgi (ORCPT ); Thu, 25 May 2017 06:36:38 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:33678 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032713AbdEYKgc (ORCPT ); Thu, 25 May 2017 06:36:32 -0400 Message-ID: <1495708587.12055.97.camel@collabora.co.uk> Subject: Re: [RFC] usb-phy-generic: Add support to SMSC USB3315 From: Fabien Lahoudere To: Stephen Boyd Cc: Peter Chen , Peter Senna Tschudin , Felipe Balbi , Greg Kroah-Hartman , "open list:USB PHY LAYER" , open list Date: Thu, 25 May 2017 12:36:27 +0200 In-Reply-To: <20170523210022.GN20170@codeaurora.org> References: <20170419061413.20961-1-peter.senna@collabora.com> <20170420085046.GA11378@b29397-desktop> <1495563396.12055.93.camel@collabora.co.uk> <20170523210022.GN20170@codeaurora.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 = <®_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