From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753072AbdLDCrj (ORCPT ); Sun, 3 Dec 2017 21:47:39 -0500 Received: from regular1.263xmail.com ([211.150.99.135]:46493 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752832AbdLDCrf (ORCPT ); Sun, 3 Dec 2017 21:47:35 -0500 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-RL-SENDER: zyw@rock-chips.com X-FST-TO: enric.balletbo@collabora.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: zyw@rock-chips.com X-UNIQUE-TAG: <8f298a77607e15780e17867a4b2f88b1> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 0/4] Move DP phy switch to PHY driver To: Heiko Stuebner , Doug Anderson Cc: dri-devel@lists.freedesktop.org, Kishon Vijay Abraham I , Rob Herring , "open list:ARM/Rockchip SoC..." , LKML , Guenter Roeck , Sean Paul , William wu , Rob Herring , David Airlie , Shawn Lin , Catalin Marinas , Elaine Zhang , David Wu , Kever Yang , Brian Norris , Tomasz Figa , Will Deacon , devicetree@vger.kernel.org, Linux ARM , Jianqun Xu , Caesar Wang , Mark Rutland , Enric Balletbo i Serra References: <1486712654-15431-1-git-send-email-zyw@rock-chips.com> <1941891.vosvJnn3h1@phil> From: Chris Zhong Message-ID: <8042d73f-c1de-da41-9066-2377de1f521c@rock-chips.com> Date: Mon, 4 Dec 2017 10:47:08 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1941891.vosvJnn3h1@phil> Content-Type: text/plain; charset=gb18030; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Heiko On 2017Äê12ÔÂ02ÈÕ 05:58, Heiko Stuebner wrote: > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson: >> Hi, >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong wrote: >>> 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. >> I guess the first step would be finding the person to make a decision. >> Is that Heiko? Olof? Kishon? Rob?. As I see it there are a few >> options: >> >> 1. Land this series as-is. This makes the new bit work just like all >> the other ones next to it. If anyone happens to try to use an old >> device tree on a new kernel they'll break. Seems rather unlikely >> given that the whole type C PHY is not really fully functional >> upstream, but technically this is a no-no from a device tree >> perspective. >> >> 2. Change the series to make this property optional. If it's not >> there then the code behaves like it always did. This would address >> the "compatibility" problem but likely wouldn't actually help any real >> people, and it would be extra work. >> >> 3. Redo the driver to deprecate all the old offsets / bits and just >> put the table in the driver, keyed off the compatible string and base >> address if the IO memory. >> >> >> I can't make this decision. It's up to those folks who would be >> landing the patch and I'd be happy with any of them. What I'm less >> happy with, however, is the indecision preventing forward progress. >> We should pick one of the above things and land it. My own personal >> bias is #1: just land the series. No real people will be hurt and >> it's just adding another property that matches the ones next to it. > I'd second that #1 . That whole type-c phy thingy never fully worked in > the past (some for the never used dp output), so personally I don't have > issues with going that route. > > >> From a long term perspective (AKA how I'd write the next driver like >> this) I personally lean towards to "tables in the driver, not in the >> device tree" but quite honestly I'm happy to take whatever direction >> the maintainers give. > It looks like we're in agreement here :-) . GRF stuff should not leak into > the devicetree, as it causes endless headaches later. But I guess we'll > need to live with the ones that happened so far. > So, the first step is: move all the private property of tcphy to drivers/phy/rockchip/phy-rockchip-typec.c. Second step: new a member: uphy-dp-sel. In my mind, we should have discussed these properties before, and then I moved them all into DTS. > > > > -- Chris Zhong