On Thu Apr 13, 2023 at 5:08 PM CEST, Bryan O'Donoghue wrote: > On 13/04/2023 15:19, Luca Weiss wrote: > > Hi Bryan, > > > > On Thu Apr 13, 2023 at 1:34 PM CEST, Bryan O'Donoghue wrote: > >> V5: > >> - Amagamates into once device, Heikki, Rob > >> > >> - Takes feedback on usage form Luka and Jianhua on VSafeV state transition detection > >> dev_err() -> dev_warn() > >> > >> - Orientation graph example and general expected bindings > >> I discussed offline with Bjorn the conclusions of the glink/sbu model. > >> The expected orientation-switch path is > >> connector/port@0 <-> phy/port@X <-> dp/port@0 > >> This can then be expanded to > >> connector/port@0 <-> redriver/port@0 <-> phy/port@X <-> dp/port@0 > >> > >> - Rob, Bjorn, Krzysztof > >> > >> - Data role > >> The data-role path is > >> connector/port@0 <-> dwc3/port@Y > > > > I believe I have adjusted my dts correctly for v5 compared to v4 but now > > the usb doesn't seem to work anymore in most cases. > > > > Only when having the phone already plugged in during boot in one > > orientation does USB come up, but also disappears once you replug the > > cable. I still see the same (or at least visually similar) messages when > > plugging in the USB cable or the USB stick but nothing more than that > > happens. > > > > Not that v4 worked perfectly on pm7250b+sm7225(/sm6350) but at least it > > worked in most cases as described in the emails there. Since the driver > > structure changed quite a bit, git diff isn't helpful here > > unfortunately. > > > > Don't think it matters but worth mentioning that sm6350 uses the new > > qmpphy bindings as described in qcom,sc8280xp-qmp-usb43dp-phy.yaml (this > > was also the case when testing v4 of this). > > > > Any idea? > > Can you confirm the output of /sys/class/typec/port0/orientation in host > mode with the USB key / peripheral in both orientations ? I see "reverse" and "normal" depending on the direction the USB stick is plugged in. When unplugged but also when plugged into my PC it stays at "unknown". > > If that's still OK, then perhaps we can figure out the gap in the PHY > code for v3 > > @caleb is working on this code for sdm845 which is a v3 PHY Regards Luca > > --- > bod
