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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c6fb4d29-6c6d-7f39-3cdd-3bc42c4519a2@rock-chips.com>
Date:   Thu, 30 Nov 2017 10:27:49 +0800
From:   Chris Zhong <zyw@...k-chips.com>
To:     Doug Anderson <dianders@...omium.org>
Cc:     dri-devel@...ts.freedesktop.org,
        Kishon Vijay Abraham I <kishon@...com>,
        Rob Herring <robh@...nel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Guenter Roeck <groeck@...omium.org>,
        Sean Paul <seanpaul@...omium.org>,
        William wu <wulf@...k-chips.com>,
        Rob Herring <robh+dt@...nel.org>,
        David Airlie <airlied@...ux.ie>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Elaine Zhang <zhangqing@...k-chips.com>,
        David Wu <david.wu@...k-chips.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Kever Yang <kever.yang@...k-chips.com>,
        Brian Norris <briannorris@...omium.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Will Deacon <will.deacon@....com>, devicetree@...r.kernel.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Jianqun Xu <jay.xu@...k-chips.com>,
        Caesar Wang <wxt@...k-chips.com>,
        Mark Rutland <mark.rutland@....com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>
Subject: Re: [PATCH 0/4] Move DP phy switch to PHY driver

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@...k-chips.com> 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