Date: Mon, 5 Jun 2017 17:43:30 +0800
From: Peter Chen <hzpeterchen@gmail.com>
To: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
CC: Stephen Boyd <sboyd@codeaurora.org>, Peter Chen <peter.chen@nxp.com>,
        Peter Senna Tschudin <peter.senna@collabora.com>,
        Felipe Balbi <balbi@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "open list:USB PHY LAYER" <linux-usb@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] usb-phy-generic: Add support to SMSC USB3315
Message-ID: <20170605094330.GA21071@b29397-desktop>
References: <20170419061413.20961-1-peter.senna@collabora.com>
 <20170420085046.GA11378@b29397-desktop>
 <1495563396.12055.93.camel@collabora.co.uk>
 <20170523210022.GN20170@codeaurora.org>
 <1495708587.12055.97.camel@collabora.co.uk>
 <1495789230.12055.104.camel@collabora.co.uk>
 <20170602220010.GQ20170@codeaurora.org>
 <1496653020.31741.2.camel@collabora.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1496653020.31741.2.camel@collabora.co.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2017 09:43:27.7025
 (UTC)
X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e;Ip=[192.88.168.50];Helo=[tx30smr01.am.freescale.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2568
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3078
Lines: 70

On Mon, Jun 05, 2017 at 10:57:00AM +0200, Fabien Lahoudere wrote:
> On Fri, 2017-06-02 at 15:00 -0700, Stephen Boyd wrote:
> > On 05/26, Fabien Lahoudere wrote:
> > > 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.
> > 
> > I haven't see any problem in hw_phymode_configure(). What's the
> > value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If
> > you phy needs to be taken out of reset to reply to the ulpi reads
> > of the vendor/product ids, then it sounds like you have a similar
> > situation to what I had. I needed to turn on some regulators to
> > get those reads to work, otherwise they would fail, but knowing
> > what needed to be turned on basically meant I needed to probe the
> > ulpi driver so probing the ids wasn't going to be useful. So on
> > my device the reads for the ids go through, but they get all
> > zeroes back, which is actually ok because there aren't any bits
> > set on my devices anyway. After the reads see 0, we fallback to
> > DT matching, which avoids the "bring it out of reset/power it on"
> > sorts of problems entirely.
> > 
> 
> Yes the phy mode is configured to USBPHY_INTERFACE_MODE_ULPI.
> Indeed, this phy need to be out of reset to work. For example everything works fine if I call?
> "_ci_usb_phy_init(ci);" before calling "hw_phymode_configure(ci);"
> This function only init reset GPIO and clock.
> 
> For information, the original patch I have to fix the issue:
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 79ad8e9..21aaff1 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -391,6 +391,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
> ?	case USBPHY_INTERFACE_MODE_UTMI:
> ?	case USBPHY_INTERFACE_MODE_UTMIW:
> ?	case USBPHY_INTERFACE_MODE_HSIC:
> +	case USBPHY_INTERFACE_MODE_ULPI:
> ?		ret = _ci_usb_phy_init(ci);
> ?		if (!ret)
> ?			hw_wait_phy_stable();
> @@ -398,7 +399,6 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
> ?			return ret;
> ?		hw_phymode_configure(ci);
> ?		break;
> -	case USBPHY_INTERFACE_MODE_ULPI:
> ?	case USBPHY_INTERFACE_MODE_SERIAL:
> ?		hw_phymode_configure(ci);
> ?		ret = _ci_usb_phy_init(ci);
> --?

Currently, the hw_phymode_configure is called twice for ULPI PHY, the
two execution are between _ci_usb_phy_init, would you test which one
causes hang? If the second causes hang, you can make a patch for
hw_phymode_configure that if the required PORTSC_PTS is the same
the value in register, do noop.

-- 

Best Regards,
Peter Chen