On Wed, Dec 11, 2024 at 08:50:02PM +0800, Xiangxu Yin wrote: > > > On 12/11/2024 5:46 PM, Dmitry Baryshkov wrote: > > On Wed, Dec 11, 2024 at 08:46:16AM +0800, Xiangxu Yin wrote: > >> > >> > >> On 12/10/2024 11:09 PM, Dmitry Baryshkov wrote: > >>> On Thu, Dec 05, 2024 at 08:31:24PM +0200, Dmitry Baryshkov wrote: > >>>> On Thu, Dec 05, 2024 at 09:26:47PM +0800, Xiangxu Yin wrote: > >>>>> > >>>>> > >>>>> On 11/29/2024 10:33 PM, Dmitry Baryshkov wrote: > >>>>>> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@xxxxxxxxxxx> wrote: > >>>>>>> > >>>>>>> Extended DP support for QCS615 USB or DP phy. Differentiated between > >>>>>>> USBC and DP PHY using the match table’s type, dynamically generating > >>>>>>> different types of cfg and layout attributes during initialization based > >>>>>>> on this type. Static variables are stored in cfg, while parsed values > >>>>>>> are organized into the layout structure. > >>>>>> > >>>>>> We didn't have an understanding / conclusion whether > >>>>>> qcom,usb-ssphy-qmp-usb3-or-dp PHYs are actually a single device / PHY > >>>>>> or two PHYs being placed next to each other. Could you please start > >>>>>> your commit message by explaining it? Or even better, make that a part > >>>>>> of the cover letter for a new series touching just the USBC PHY > >>>>>> driver. DP changes don't have anything in common with the PHY changes, > >>>>>> so you can split the series into two. > >>>>>> > >>>>> Before implement DP extension, we have discussed with abhinav and krishna about whether use combo, usbc or separate phy. > >>>> > >>>> What is "DP extension"? > >>>> > >> I'm sorry confusion casued by my description. It's means extend DP implemnt for USBC phy driver. > >>>>> > >>>>> We identified that DP and USB share some common controls for phy_mode and orientation. > >>>>> Specifically, 'TCSR_USB3_0_DP_PHYMODE' controls who must use the lanes - USB or DP, > >>>>> while PERIPH_SS_USB0_USB3PHY_PCS_MISC_TYPEC_CTRL controls the orientation. > >>>>> It would be more efficient for a single driver to manage these controls. > >>>> > >>>> The question is about the hardware, not about the driver. > >>>> > >>>>> Additionally, this PHY does not support Alt Mode, and the two control registers are located in separate address spaces. > >>>>> Therefore, even though the orientation for DP on this platform is always normal and connected to the video output board, > >>>>> we still decided to base it on the USBC extension. > >>>> > >>>> Could you please clarify, do usb3-or-dp PHYs support DP-over-USB-C? I > >>>> thought that usbc-or-dp platforms support that, but they don't > >>>> support DP+USB pin configuration. Note, the question is broader than > >>>> just QCS615, it covers the PHY type itself. > >>>> > >>>> Also, is TCSR configuration read/write or read-only? Are we supposed to > >>>> set the register from OS or are we supposed to read it and thus detemine > >>>> the PHY mode? > >>> > >>> Any updates on these two topics? > >>> > >> Still confirming detail info with HW & design team. > >> I’ll update the information that has been confirmed so far. > >> This phy support DP-over-USB-C,but it's not support alt-mode which 2 lane work for DP, other 2 lane work for USB. > >> TCSR phy mode is read/write reg and we can read for determine phy mode. > > > > Ok, thanks for the explanation. From my point of view: > > > > - Implement the DP PHY to be a part of the same driver. Each device > > supported by the usbc driver should get both PHYs. > > > > - Make sure not to break the ABI: #phy-cells = <0> should still work and > > return USB PHY, keeping backwards compatibility. Newer devices or > > upgraded DT for old devices should return USB PHY for <... 0> and DP > > PHY for <... 1>. > > > Yes, currently we have implemented like your description, > Each deivce shoud get both PHYs, DP PHY for <... 1> and USB PHY for <... 0>. Please note the backwards compatibility clause. > > - I'm not shure how to handle the USB and DP coexistence, especially in > > your case of the USB-or-DP PHY. > > > For coexistence process: > > When we start implement DP part, usb driver team said only need config TCSR phy mode and orientation during switch in USB-C port. > Based on your previous comments avout SW_PWRDN, I'm confirming with the USB team whether SW_REST/SWPWRDN/START_CTRL registers might affect DP. Thanks! > Anyway, even though the original SoC design supports DP or USB over Type-C， > but on QCS615 ADP AIR platform, there are only four USB-A port which works with 'qcs615-qmp-usb3-phy' driver, and no USB-C port. > DP port is mappped from usb pin to the video out sub-board. > so we are unable to verify the switching case between DP and USB devices under USB-C. That's also fine. We will get to that point once MSM8998 / SDM660 get USB-C support (the only current blocker is the support for the TYPEC block of the PMI8998). > However, I'm also confirming whether anything other will affect USB and DP each other. -- With best wishes Dmitry
