DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1F4EA60764
Date: Fri, 2 Jun 2017 15:00:10 -0700
From: Stephen Boyd <sboyd@codeaurora.org>
To: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Cc: 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: <20170602220010.GQ20170@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>
 <1495708587.12055.97.camel@collabora.co.uk>
 <1495789230.12055.104.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: <1495789230.12055.104.camel@collabora.co.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1523
Lines: 30

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.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project