[PATCH v2 2/4] dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra
Konrad Dybcio
konrad.dybcio at oss.qualcomm.com
Fri Jun 19 08:12:40 PDT 2026
On 6/12/26 10:00 AM, Dmitry Baryshkov wrote:
> On Wed, Jun 10, 2026 at 03:36:20PM +0200, Konrad Dybcio wrote:
>> On 5/17/26 9:16 PM, Dmitry Baryshkov wrote:
>>> On Fri, May 15, 2026 at 09:06:21PM +0530, Krishna Kurapati wrote:
>>>>
>>>>
>>>> On 5/14/2026 8:07 PM, Krzysztof Kozlowski wrote:
>>>>> On 14/05/2026 08:22, Krishna Kurapati wrote:
>>>>>>
>>>>>>
>>>>>> On 5/14/2026 12:26 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 07/05/2026 13:37, Krishna Kurapati wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/5/2026 7:30 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> On 05/05/2026 15:57, Krishna Kurapati wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/5/2026 6:59 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 05/05/2026 15:27, Krishna Kurapati wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/5/2026 4:22 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>> On 05/05/2026 12:49, Krzysztof Kozlowski wrote:
>>>>>>>>>>>>>> On Mon, May 04, 2026 at 10:36:57PM +0530, Krishna Kurapati wrote:
>>>>>>>>>>>>>>> Declare the USB-C QMP PHY present on the Qualcomm Shikra platform.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Krishna Kurapati <krishna.kurapati at oss.qualcomm.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> .../devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++
>>>>>>>>>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ... and then I looked at the driver. So un-reviewed. Devices are clearly
>>>>>>>>>>>>> compatible. If not, explain what is not compatible.
>>>>>>>>>>>>>
>>>>>>>>>>>> Talos uses GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>>>>>>>>
>>>>>>>>>>>> In Shikra, we are using GCC_USB3_PRIM_PHY_COM_AUX_CLK. We don't have
>>>>>>>>>>>> GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>>>>>>>>
>>>>>>>>>>>> Hence, I didn't use a fallback compatible.
>>>>>>>>>>>
>>>>>>>>>>> This still explains nothing. How different clock makes interface for SW
>>>>>>>>>>> incompatible exactly?
>>>>>>>>>>>
>>>>>>>>>> So I went by the naming. AUX vs COM_AUX.
>>>>>>>>>
>>>>>>>>> The naming does not matter. If the clock is called
>>>>>>>>> "no_one_expects_spanish_inquisition", does that make software
>>>>>>>>> incompatible? Why would the name itself matter?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Can I use a fallback compatible and in DT vote for "COM_AUX" clock with
>>>>>>>>>> clock-names mentioning "aux" ?
>>>>>>>>>
>>>>>>>>> I don't know, I asked what is different in software interface.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Krzysztof,
>>>>>>>>
>>>>>>>> I checked with the hw team here and found out two things.
>>>>>>>>
>>>>>>>> 1. Shikra is a spinoff of Agatti and its sw interface (clocks used and
>>>>>>>> regulators used) is the same as agatti.
>>>>>>>>
>>>>>>>> 2. I thought we could use qcm2290 as a fallback since the phy register
>>>>>>>> init sequence is the same for Talos/Shikra/Agatti. The difference
>>>>>>>> between Talos and agatti when checked in the driver was the init load
>>>>>>>> settings. I checked with the hw team and they suggested using the init
>>>>>>>> load settings which talos was using.
>>>>>>>>
>>>>>>>> Hence both these compatibles (qcm2290 and qcs615) cannot be used as
>>>>>>>> fallback for Shikra.
>>>>>>>
>>>>>>> Then I do not understand why you are using qcs615_usb3phy_cfg for
>>>>>>> Shikra. You say that the initialization is different, but you use
>>>>>>> exactly the same initialization. So in a meaning of compatibility
>>>>>>> between hardware for Devicetree they are compatible.
>>>>>>>
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> There are 3 things:
>>>>>>
>>>>>> 1. Clocks used:
>>>>>> -> Talos supports AUX Clock since it supports DP over USB.
>>>>>> -> Agatti and Shikra use COM_AUX clock since they dont support DP over USB.
>>>>>>
>>>>>> 2. Phy register Init sequence - same for all 3 targets
>>>>>>
>>>>>> 3. Regulator init load:
>>>>>> -> Different for both Talos and Agatti
>>>>>> -> Recommendation is to use Talos regulator load values.
>>>>>>
>>>>>> SW interface wise, shikra is comaptible with agatti. If we use agatti as
>>>>>> fallback, we would end up using the platform data of Agatti where the
>>>>>> regulator init load is not suitable for Shikra. Hence not using Agatti
>>>>>> as fallback.
>>>>>>
>>>>>> Coming to driver changes, I used qcs615_cfg because it has required phy
>>>>>> register sequence and regulator init load as needed by shikra.
>>>>>
>>>>> So is it compatible with QCS615? If not, then something is incomplete or
>>>>> confusing. The driver uses the same software interface.
>>>>>
>>>> Sorry for the confusion. The Talos compatible represents the USB/DP PHY with
>>>> aux clock input, while Shikra is a USB-only PHY with com_aux input clock, so
>>>> the two PHYs are not compatible with each other.
>>>
>>> According to the memory map, there is an (unused) DP registers part
>>> right after the QMP USB3 PHY. So, sofware-wise it is compatible to
>>> Talos. Having the different clock input means different integration of
>>> the block rather than the differences in the hardware block.
>>>
>>> So, the block should be compatible to qcom,qcs615-qmp-usb3-dp-phy
>>
>> It should still carry its own compatible though, to let the driver
>> disallow powering up the DP part
>
> Why? The DP part is there, in the PHY, pretty much like it's present on
> most of USBC platforms. I assume it can be powered on. There is no
> point in it though as there is no DP controller (nor DP pins).
I wouldn't bet too much on that sub-block being fully silicon-validated
given its of no use as there isn't a DPTX onboard..
Konrad
More information about the linux-phy
mailing list