Re: [PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

Hi Doug

Thank you for mentioning this patch.

I think the focus of the discussion is: can we put the grf control bit 
to dts.

The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"

can help to switch these 2 phy. So I think this bit can be considered as 
a part of

Type-C phy, these 2 phy have different bits, just similar to other bits 
(such as "pipe-status").

Put them to DTS file might be a accepted practice.



On 2017å11æ29æ 07:32, Doug Anderson wrote:
> Hi,
>
> On Thu, Feb 9, 2017 at 11:44 PM, Chris Zhong <zyw@xxxxxxxxxxxxxx> wrote:
> > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> > only one PHY can connect to DP controller at one time, the other should
> > be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> > set this bit means enable PHY 1, clear this bit means enable PHY 0.
> >
> > If the board has 2 Type-C ports, the DP driver get the phy id from
> > devm_of_phy_get_by_index, and then control this switch according to
> > this id. But some others board only has one Type-C port, it may be PHY 0
> > or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
> > this switch to PHY driver, the PHY driver can distinguish between PHY 0
> > and PHY 1, and then write the correct register bit.
> >
> >
> >
> > Chris Zhong (4):
> >    Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
> >    arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
> >    phy: rockchip-typec: support DP phy switch
> >    drm/rockchip: cdn-dp: remove the DP phy switch
> >
> >   Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +++++
> >   arch/arm64/boot/dts/rockchip/rk3399.dtsi                     | 2 ++
> >   drivers/gpu/drm/rockchip/cdn-dp-core.c                       | 7 -------
> >   drivers/phy/phy-rockchip-typec.c                             | 9 +++++++++
> >   4 files changed, 16 insertions(+), 7 deletions(-)
> What ever happened to this series?  It seemed like it just dropped on
> the floor...
>
> There was a bit of contention on patch #3
> <https://patchwork.kernel.org/patch/9566095/> about the fact that we
> were specifying addresses in the device tree vs. hardcoding them in
> the driver.  Any way we can just make a decision and go with it?
>
>
> -Doug

--
Chris Zhong