[1/2] dt-bindings: phy: mediatek: tphy: add a property for force-mode switch

Due to some old SoCs with shared t-phy only support force-mode switch, and
can't use compatible to distinguish between shared and non-shared t-phy,
add a property to supported it.
But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.

Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

On Mon, 2023-11-27 at 14:37 +0100, AngeloGioacchino Del Regno wrote:
> Il 27/11/23 08:21, Krzysztof Kozlowski ha scritto:
> > On 27/11/2023 08:09, Macpaul Lin wrote:
> > > On 11/25/23 18:37, Krzysztof Kozlowski and Chunfeng Yun wrote:
> > > > 	
> > > > 
> > > > External email : Please do not click links or open attachments
> > > > until you
> > > > have verified the sender or the content.
> > > > 
> > > > On 25/11/2023 02:23, Chunfeng Yun wrote:
> > > > > Due to some old SoCs with shared t-phy only support force-
> > > > > mode switch, and
> > > > > can't use compatible to distinguish between shared and non-
> > > > > shared t-phy,
> > > > > add a property to supported it.
> > > > > But now prefer to use "mediatek,syscon-type" on new SoC as
> > > > > far as possible.
> 
> Two questions:
> 1. Why is it *not* possible to use the compatible string to
> distinguish between
>     shared and non-shared T-PHYs?
There may be shared t-phy and non-shared t-phy at the same time on the
SoC.

> 2. If we really can't use compatibles, what's the reason why we can't
> use the
>     "mediatek,syscon-type" property?
It need hardware support it, it uses a top pericfg register to tell the
phy that the mode we want before power on the phy controller.


> 
> Regards,
> Angelo
> 
> > > > > 
> > > > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > > > > ---
> > > > >   Documentation/devicetree/bindings/phy/mediatek,tphy.yaml |
> > > > > 6 ++++++
> > > > >   1 file changed, 6 insertions(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > index 2bb91542e984..eedba5b7025e 100644
> > > > > ---
> > > > > a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > @@ -235,6 +235,12 @@ patternProperties:
> > > > >             Specify the flag to enable BC1.2 if support it
> > > > >           type: boolean
> > > > >   
> > > > > +      mediatek,force-mode:
> > > > > +        description:
> > > > > +          Use force mode to switch shared phy mode, perfer
> > > > > to use the bellow
> 
>

On 30/11/2023 02:51, Chunfeng Yun (云春峰) wrote:
>>> 3. How about we revise the description as follows for more
>> precisely?
>>>
>>> mediatek,force-mode:
>>>    description:
>>>      The force mode is used to manually switch the shared PHY mode
>>>      between USB and PCIe. When force-mode is set, the USB 3.0 mode
>>>      will be selected. This is typically required for older SoCs
>>>      that do not automatically manage PHY mode switching.
>>>      For newer SoCs that support it, it is preferable to use the
>>>      "mediatek,syscon-type" property instead.
>>>    type: boolean
>>
>> Again, what is force-mode? 
> Our DE describe this behavior as force-mode, as you see, the driver

What is "DE"?

> power down controller and reset pipe to set the mode directly we want,

So force-mode is driver behavior?

> but usually the phy controller switch to the mode automatically
> according to the external signal, e.g. trapping pin, efuse etc.
> 
>> It looks like you wrote bindings for the
>> driver behavior. Bindings describe hardware, not how the driver
>> should
>> behave. The property might be reasonable, but you must describe here
>> hardware characteristics/issue/etc.

You must address this, in such case.



Best regards,
Krzysztof