From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Andersson Subject: Re: [PATCH v4 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings Date: Fri, 6 Sep 2019 11:25:30 -0700 Message-ID: <20190906182530.GD11938@tuxbook-pro> References: <5d694878.1c69fb81.5f13b.ec4f@mx.google.com> <20190830164520.GK26807@tuxbook-pro> <5d696ad2.1c69fb81.977ea.39e5@mx.google.com> <20190903173924.GB9754@jackp-linux.qualcomm.com> <5d6edee5.1c69fb81.a3896.1d05@mx.google.com> <20190903233410.GQ26807@tuxbook-pro> <20190905175802.GA19599@jackp-linux.qualcomm.com> <5d71edf5.1c69fb81.1f307.fdd6@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <5d71edf5.1c69fb81.1f307.fdd6@mx.google.com> Sender: linux-kernel-owner@vger.kernel.org To: Stephen Boyd Cc: Jack Pham , Jorge Ramirez , robh@kernel.org, andy.gross@linaro.org, shawn.guo@linaro.org, gregkh@linuxfoundation.org, mark.rutland@arm.com, kishon@ti.com, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, khasim.mohammed@linaro.org List-Id: devicetree@vger.kernel.org On Thu 05 Sep 22:26 PDT 2019, Stephen Boyd wrote: > Quoting Jack Pham (2019-09-05 10:58:02) > > Hi Jorge, Bjorn, > > > > On Thu, Sep 05, 2019 at 09:18:57AM +0200, Jorge Ramirez wrote: > > > On 9/4/19 01:34, Bjorn Andersson wrote: > > > > On Tue 03 Sep 14:45 PDT 2019, Stephen Boyd wrote: > > > >> that would need an of_regulator_get() sort of API that can get the > > > >> regulator out of there? Or to make the connector into a struct device > > > >> that can get the regulator out per some generic connector driver and > > > >> then pass it through to the USB controller when it asks for it. Maybe > > > >> try to prototype that out? > > > >> > > > > > > > > The examples given in the DT bindings describes the connector as a child > > > > of a PMIC, with of_graph somehow tying it to the various inputs. But in > > > > these examples vbus is handled by implicitly inside the MFD, where > > > > extcon is informed about the plug event they toggle vbus as well. > > > > > > > > In our case we have a extcon-usb-gpio to detect mode, which per Jorge's > > > > proposal will trickle down to the PHY and become a regulator calls on > > > > either some external regulator or more typically one of the chargers in > > > > the system. > > > > Interesting you mention extcon-usb-gpio. I thought extcon at least from > > bindings perspective is passé now. Maybe this is what you need (just > > landed in usb-next): > > > > usb: common: add USB GPIO based connection detection driver > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=4602f3bff2669012c1147eecfe74c121765f5c56 > > > > dt-bindings: usb: add binding for USB GPIO based connection detection driver > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=f651c73e71f53f65e9846677d79d8e120452b59f > > > > Fortunately this new driver might check the right boxes for you: > > - usb connector binding > > - ID detect GPIO > > - vbus-supply regulator > > > > With that, I think you can also keep the connector subnode out of the > > SSPHY node well, and similarly get rid of the vbus toggle handling from > > the PHY driver. > > > > The big thing missing now is that this driver replaces extcon > > completely, so we'll need handling in dwc3/dwc3-qcom to retrieve the > > role switch state to know when host mode is entered. I saw this a while > > back but don't think it got picked up: > > > > https://patchwork.kernel.org/patch/10909981/ > > > > Yes this looks like the approach that should be taken. One question > though, is this a micro-b connector or a type-c connector on the board? > I thought it was a type-c, so then this USB gpio based connection driver > isn't an exact fit? > For this particular case it's a type c connector, but the port controller is operated completely passively (and there's no PD or DP involved), so the GPIO based approach seems like a good fit. Regards, Bjorn