From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko =?ISO-8859-1?Q?St=FCbner?= Subject: Re: [PATCH 0/4] Move DP phy switch to PHY driver Date: Mon, 04 Dec 2017 22:53:03 +0100 Message-ID: <4518665.CiImf8ftzB@diego> References: <1486712654-15431-1-git-send-email-zyw@rock-chips.com> <4091462.xo23GTqF41@diego> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Doug Anderson Cc: Mark Rutland , David Airlie , Catalin Marinas , Shawn Lin , Will Deacon , Kever Yang , dri-devel@lists.freedesktop.org, Guenter Roeck , Chris Zhong , Brian Norris , Kishon Vijay Abraham I , "open list:ARM/Rockchip SoC..." , Jianqun Xu , Caesar Wang , devicetree@vger.kernel.org, Elaine Zhang , Rob Herring , William wu , Linux ARM , LKML , Tomasz Figa , David Wu , Enric Balletbo i Serra List-Id: linux-rockchip.vger.kernel.org SGksCgpBbSBNb250YWcsIDQuIERlemVtYmVyIDIwMTcsIDA4OjA4OjMxIENFVCBzY2hyaWViIERv dWcgQW5kZXJzb246Cj4gT24gU3VuLCBEZWMgMywgMjAxNyBhdCAxMTo0NiBQTSwgSGVpa28gU3TD vGJuZXIgPGhlaWtvQHNudGVjaC5kZT4gd3JvdGU6Cj4gPiBBbSBNb250YWcsIDQuIERlemVtYmVy IDIwMTcsIDEwOjQ3OjA4IENFVCBzY2hyaWViIENocmlzIFpob25nOgo+ID4+IE9uIDIwMTflubQx MuaciDAy5pelIDA1OjU4LCBIZWlrbyBTdHVlYm5lciB3cm90ZToKPiA+PiA+IEFtIEZyZWl0YWcs IDEuIERlemVtYmVyIDIwMTcsIDEzOjQyOjQ2IENFVCBzY2hyaWViIERvdWcgQW5kZXJzb246Cj4g Pj4gPj4gT24gV2VkLCBOb3YgMjksIDIwMTcgYXQgNjoyNyBQTSwgQ2hyaXMgWmhvbmcgPHp5d0By b2NrLWNoaXBzLmNvbT4gCndyb3RlOgo+ID4+ID4+PiBUaGFuayB5b3UgZm9yIG1lbnRpb25pbmcg dGhpcyBwYXRjaC4KPiA+PiA+Pj4gCj4gPj4gPj4+IEkgdGhpbmsgdGhlIGZvY3VzIG9mIHRoZSBk aXNjdXNzaW9uIGlzOiBjYW4gd2UgcHV0IHRoZSBncmYgY29udHJvbAo+ID4+ID4+PiBiaXQKPiA+ PiA+Pj4gdG8KPiA+PiA+Pj4gZHRzLgo+ID4+ID4+PiAKPiA+PiA+Pj4gVGhlIFJLMzM5OSBoYXMg MiBUeXBlLUMgcGh5LCBidXQgb25seSBvbmUgRFAgY29udHJvbGxlciwgdGhpcwo+ID4+ID4+PiAi dXBoeV9kcF9zZWwiCj4gPj4gPj4+IAo+ID4+ID4+PiBjYW4gaGVscCB0byBzd2l0Y2ggdGhlc2Ug MiBwaHkuIFNvIEkgdGhpbmsgdGhpcyBiaXQgY2FuIGJlIGNvbnNpZGVyZWQKPiA+PiA+Pj4gYXMK PiA+PiA+Pj4gYQo+ID4+ID4+PiBwYXJ0IG9mCj4gPj4gPj4+IAo+ID4+ID4+PiBUeXBlLUMgcGh5 LCB0aGVzZSAyIHBoeSBoYXZlIGRpZmZlcmVudCBiaXRzLCBqdXN0IHNpbWlsYXIgdG8gb3RoZXIK PiA+PiA+Pj4gYml0cwo+ID4+ID4+PiAoc3VjaCBhcyAicGlwZS1zdGF0dXMiKS4KPiA+PiA+Pj4g Cj4gPj4gPj4+IFB1dCB0aGVtIHRvIERUUyBmaWxlIG1pZ2h0IGJlIGEgYWNjZXB0ZWQgcHJhY3Rp Y2UuCj4gPj4gPj4gCj4gPj4gPj4gSSBndWVzcyB0aGUgZmlyc3Qgc3RlcCB3b3VsZCBiZSBmaW5k aW5nIHRoZSBwZXJzb24gdG8gbWFrZSBhIGRlY2lzaW9uLgo+ID4+ID4+IElzIHRoYXQgSGVpa28/ ICBPbG9mPyAgS2lzaG9uPyAgUm9iPy4gIEFzIEkgc2VlIGl0IHRoZXJlIGFyZSBhIGZldwo+ID4+ ID4+IG9wdGlvbnM6Cj4gPj4gPj4gCj4gPj4gPj4gMS4gTGFuZCB0aGlzIHNlcmllcyBhcy1pcy4g IFRoaXMgbWFrZXMgdGhlIG5ldyBiaXQgd29yayBqdXN0IGxpa2UgYWxsCj4gPj4gPj4gdGhlIG90 aGVyIG9uZXMgbmV4dCB0byBpdC4gIElmIGFueW9uZSBoYXBwZW5zIHRvIHRyeSB0byB1c2UgYW4g b2xkCj4gPj4gPj4gZGV2aWNlIHRyZWUgb24gYSBuZXcga2VybmVsIHRoZXknbGwgYnJlYWsuICBT ZWVtcyByYXRoZXIgdW5saWtlbHkKPiA+PiA+PiBnaXZlbiB0aGF0IHRoZSB3aG9sZSB0eXBlIEMg UEhZIGlzIG5vdCByZWFsbHkgZnVsbHkgZnVuY3Rpb25hbAo+ID4+ID4+IHVwc3RyZWFtLCBidXQg dGVjaG5pY2FsbHkgdGhpcyBpcyBhIG5vLW5vIGZyb20gYSBkZXZpY2UgdHJlZQo+ID4+ID4+IHBl cnNwZWN0aXZlLgo+ID4+ID4+IAo+ID4+ID4+IDIuIENoYW5nZSB0aGUgc2VyaWVzIHRvIG1ha2Ug dGhpcyBwcm9wZXJ0eSBvcHRpb25hbC4gIElmIGl0J3Mgbm90Cj4gPj4gPj4gdGhlcmUgdGhlbiB0 aGUgY29kZSBiZWhhdmVzIGxpa2UgaXQgYWx3YXlzIGRpZC4gIFRoaXMgd291bGQgYWRkcmVzcwo+ ID4+ID4+IHRoZSAiY29tcGF0aWJpbGl0eSIgcHJvYmxlbSBidXQgbGlrZWx5IHdvdWxkbid0IGFj dHVhbGx5IGhlbHAgYW55IHJlYWwKPiA+PiA+PiBwZW9wbGUsIGFuZCBpdCB3b3VsZCBiZSBleHRy YSB3b3JrLgo+ID4+ID4+IAo+ID4+ID4+IDMuIFJlZG8gdGhlIGRyaXZlciB0byBkZXByZWNhdGUg YWxsIHRoZSBvbGQgb2Zmc2V0cyAvIGJpdHMgYW5kIGp1c3QKPiA+PiA+PiBwdXQgdGhlIHRhYmxl IGluIHRoZSBkcml2ZXIsIGtleWVkIG9mZiB0aGUgY29tcGF0aWJsZSBzdHJpbmcgYW5kIGJhc2UK PiA+PiA+PiBhZGRyZXNzIGlmIHRoZSBJTyBtZW1vcnkuCj4gPj4gPj4gCj4gPj4gPj4gCj4gPj4g Pj4gSSBjYW4ndCBtYWtlIHRoaXMgZGVjaXNpb24uICBJdCdzIHVwIHRvIHRob3NlIGZvbGtzIHdo byB3b3VsZCBiZQo+ID4+ID4+IGxhbmRpbmcgdGhlIHBhdGNoIGFuZCBJJ2QgYmUgaGFwcHkgd2l0 aCBhbnkgb2YgdGhlbS4gIFdoYXQgSSdtIGxlc3MKPiA+PiA+PiBoYXBweSB3aXRoLCBob3dldmVy LCBpcyB0aGUgaW5kZWNpc2lvbiBwcmV2ZW50aW5nIGZvcndhcmQgcHJvZ3Jlc3MuCj4gPj4gPj4g V2Ugc2hvdWxkIHBpY2sgb25lIG9mIHRoZSBhYm92ZSB0aGluZ3MgYW5kIGxhbmQgaXQuICBNeSBv d24gcGVyc29uYWwKPiA+PiA+PiBiaWFzIGlzICMxOiBqdXN0IGxhbmQgdGhlIHNlcmllcy4gIE5v IHJlYWwgcGVvcGxlIHdpbGwgYmUgaHVydCBhbmQKPiA+PiA+PiBpdCdzIGp1c3QgYWRkaW5nIGFu b3RoZXIgcHJvcGVydHkgdGhhdCBtYXRjaGVzIHRoZSBvbmVzIG5leHQgdG8gaXQuCj4gPj4gPiAK PiA+PiA+IEknZCBzZWNvbmQgdGhhdCAjMSAuIFRoYXQgd2hvbGUgdHlwZS1jIHBoeSB0aGluZ3kg bmV2ZXIgZnVsbHkgd29ya2VkIGluCj4gPj4gPiB0aGUgcGFzdCAoc29tZSBmb3IgdGhlIG5ldmVy IHVzZWQgZHAgb3V0cHV0KSwgc28gcGVyc29uYWxseSBJIGRvbid0Cj4gPj4gPiBoYXZlCj4gPj4g PiBpc3N1ZXMgd2l0aCBnb2luZyB0aGF0IHJvdXRlLgo+ID4+ID4gCj4gPj4gPj4gIEZyb20gYSBs b25nIHRlcm0gcGVyc3BlY3RpdmUgKEFLQSBob3cgSSdkIHdyaXRlIHRoZSBuZXh0IGRyaXZlciBs aWtlCj4gPj4gPj4gCj4gPj4gPj4gdGhpcykgSSBwZXJzb25hbGx5IGxlYW4gdG93YXJkcyB0byAi dGFibGVzIGluIHRoZSBkcml2ZXIsIG5vdCBpbiB0aGUKPiA+PiA+PiBkZXZpY2UgdHJlZSIgYnV0 IHF1aXRlIGhvbmVzdGx5IEknbSBoYXBweSB0byB0YWtlIHdoYXRldmVyIGRpcmVjdGlvbgo+ID4+ ID4+IHRoZSBtYWludGFpbmVycyBnaXZlLgo+ID4+ID4gCj4gPj4gPiBJdCBsb29rcyBsaWtlIHdl J3JlIGluIGFncmVlbWVudCBoZXJlIDotKSAuIEdSRiBzdHVmZiBzaG91bGQgbm90IGxlYWsKPiA+ PiA+IGludG8KPiA+PiA+IHRoZSBkZXZpY2V0cmVlLCBhcyBpdCBjYXVzZXMgZW5kbGVzcyBoZWFk YWNoZXMgbGF0ZXIuIEJ1dCBJIGd1ZXNzIHdlJ2xsCj4gPj4gPiBuZWVkIHRvIGxpdmUgd2l0aCB0 aGUgb25lcyB0aGF0IGhhcHBlbmVkIHNvIGZhci4KPiA+PiAKPiA+PiBTbywgdGhlIGZpcnN0IHN0 ZXAgaXM6IG1vdmUgYWxsIHRoZSBwcml2YXRlIHByb3BlcnR5IG9mIHRjcGh5IHRvCj4gPj4gZHJp dmVycy9waHkvcm9ja2NoaXAvcGh5LXJvY2tjaGlwLXR5cGVjLmMuCj4gPj4gU2Vjb25kIHN0ZXA6 IG5ldyBhIG1lbWJlcjogdXBoeS1kcC1zZWwuCj4gPj4gSW4gbXkgbWluZCwgd2Ugc2hvdWxkIGhh dmUgZGlzY3Vzc2VkIHRoZXNlIHByb3BlcnRpZXMgYmVmb3JlLCBhbmQgdGhlbiBJCj4gPj4gbW92 ZWQgdGhlbSBhbGwgaW50byBEVFMuCj4gPiAKPiA+IEFjdHVhbGx5LCBJIHdhcyBhZ3JlZWluZyB3 aXRoIERvdWcsIHRoYXQgd2UgcHJvYmFibHkgZG9uJ3QgbmVlZCB0byByZXdvcmsKPiA+IHRoZSB0 eXBlLWMgcGh5IGRyaXZlci4gQXMgbW9zdCBwcm9wZXJ0aWVzIGZvciBpdCBhcmUgaW4gdGhlIGRl dmljZXRyZWUKPiA+IHJpZ2h0IG5vdyB3ZSdsbCBuZWVkIHRvIHN1cHBvcnQgdGhlbSBmb3IgYmFj a3dhcmRzLWNvbXBhdGlibGl0eSBhbnl3YXkuCj4gPiAKPiA+IEFuZCB5ZXMsIHRoZXJlIHByb2Jh Ymx5IHdhcyBkaXNjdXNzaW9uIG92ZXIgZHRzIHZzLiBkcml2ZXItdGFibGUgd2hlbiB0aGUKPiA+ IHR5cGUtYyBkcml2ZXIgd2FzIGludHJvZHVjZWQsIGJ1dCBJIGVpdGhlciBtaXNzZWQgaXQgb3Ig d2Fzbid0IGZpcm0gZW5vdWdoCj4gPiBiYWNrIHRoZW4gOy0pIC4KPiA+IAo+ID4gSGVuY2UgdGhl ICJ3ZSdsbCBuZWVkIHRvIGxpdmUgd2l0aCBpdCIgZm9yIHRoZSB0eXBlLWMgcGh5LCBidXQgc2hv dWxkIG5vdAo+ID4gZG8gc2ltaWxhciB0aGluZ3MgaW4gZnV0dXJlIGRyaXZlcnMuCj4gCj4gU28g SSBndWVzcyBub3cgd2UncmUganVzdCB3YWl0aW5nIGZvciBzb21lIGFncmVlbWVudCBmcm9tIEtp c2hvbiB0aGF0Cj4gaGUncyB3aWxsaW5nIHRvIGxhbmQgdGhlIFBIWSBjaGFuZ2U/ICBIZWlrbzog cHJlc3VtYWJseSB5b3UgY291bGQKPiBhcHBseSB0aGUgRFAgY2hhbmdlIHRvIGRybS1taXNjPyAg Li4ub3IgaXMgdGhlcmUgc29tZSBvdGhlciBwcm9jZXNzCj4gbmVlZGVkIHRoZXJlPwoKSSB3YXMg bGFnZ2luZyBiZWhpbmQgYSBiaXQgd2l0aCB0aGUgZHJtLW1pc2MgYWNjb3VudCByZXF1ZXN0IGJ1 dCBoYXZlCmRvbmUgc28gbm93LiBTbyBvbmNlIEkgZ290IHRoZSBoYW5nIG9mIGhvdyBkcm0tbWlz YyB3b3JrcyBhbmQgS2lzaG9uCmhhcyBwaWNrZWQgdGhlIHBoeS1wYXJ0IEkgY2FuIG1vc3QgbGlr ZWx5IHB1c2ggdGhlIGRybSBwYXJ0IChvciBTYW5keSwKZGVwZW5kaW5nIG9uIHdobyBpcyBmYXN0 ZXIpLgoKQXMgZm9yIHByb2Nlc3MsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgc3BlY2lhbCBjYXJl IG5lY2Vzc2FyeS4gV2hlbgp5b3UgZ2V0IHRoZSBpbnRlcm1lZGlhdGUgY2FzZSBvZiBwaHktY2hh bmdlIGJ1dCBubyBkcm0tY2hhbmdlCmV2ZXJ5dGhpbmcgd2lsbCBqdXN0IHJldmVydCB0byBob3cg aXQgd29ya3Mgbm93IGFueXdheS4KCgpIZWlrbwpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0 cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9s aXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: heiko@sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=) Date: Mon, 04 Dec 2017 22:53:03 +0100 Subject: [PATCH 0/4] Move DP phy switch to PHY driver In-Reply-To: References: <1486712654-15431-1-git-send-email-zyw@rock-chips.com> <4091462.xo23GTqF41@diego> Message-ID: <4518665.CiImf8ftzB@diego> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson: > On Sun, Dec 3, 2017 at 11:46 PM, Heiko St?bner wrote: > > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong: > >> On 2017?12?02? 05:58, Heiko Stuebner wrote: > >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson: > >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong wrote: > >> >>> 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. > > > > Actually, I was agreeing with Doug, that we probably don't need to rework > > the type-c phy driver. As most properties for it are in the devicetree > > right now we'll need to support them for backwards-compatiblity anyway. > > > > And yes, there probably was discussion over dts vs. driver-table when the > > type-c driver was introduced, but I either missed it or wasn't firm enough > > back then ;-) . > > > > Hence the "we'll need to live with it" for the type-c phy, but should not > > do similar things in future drivers. > > So I guess now we're just waiting for some agreement from Kishon that > he's willing to land the PHY change? Heiko: presumably you could > apply the DP change to drm-misc? ...or is there some other process > needed there? I was lagging behind a bit with the drm-misc account request but have done so now. So once I got the hang of how drm-misc works and Kishon has picked the phy-part I can most likely push the drm part (or Sandy, depending on who is faster). As for process, I don't think there is special care necessary. When you get the intermediate case of phy-change but no drm-change everything will just revert to how it works now anyway. Heiko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753100AbdLDVxO convert rfc822-to-8bit (ORCPT ); Mon, 4 Dec 2017 16:53:14 -0500 Received: from gloria.sntech.de ([95.129.55.99]:57566 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752783AbdLDVxM (ORCPT ); Mon, 4 Dec 2017 16:53:12 -0500 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Doug Anderson Cc: Chris Zhong , 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 Subject: Re: [PATCH 0/4] Move DP phy switch to PHY driver Date: Mon, 04 Dec 2017 22:53:03 +0100 Message-ID: <4518665.CiImf8ftzB@diego> User-Agent: KMail/5.2.3 (Linux/4.13.0-1-amd64; KDE/5.37.0; x86_64; ; ) In-Reply-To: References: <1486712654-15431-1-git-send-email-zyw@rock-chips.com> <4091462.xo23GTqF41@diego> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson: > On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner wrote: > > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong: > >> On 2017年12月02日 05:58, Heiko Stuebner wrote: > >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson: > >> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong wrote: > >> >>> 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. > > > > Actually, I was agreeing with Doug, that we probably don't need to rework > > the type-c phy driver. As most properties for it are in the devicetree > > right now we'll need to support them for backwards-compatiblity anyway. > > > > And yes, there probably was discussion over dts vs. driver-table when the > > type-c driver was introduced, but I either missed it or wasn't firm enough > > back then ;-) . > > > > Hence the "we'll need to live with it" for the type-c phy, but should not > > do similar things in future drivers. > > So I guess now we're just waiting for some agreement from Kishon that > he's willing to land the PHY change? Heiko: presumably you could > apply the DP change to drm-misc? ...or is there some other process > needed there? I was lagging behind a bit with the drm-misc account request but have done so now. So once I got the hang of how drm-misc works and Kishon has picked the phy-part I can most likely push the drm part (or Sandy, depending on who is faster). As for process, I don't think there is special care necessary. When you get the intermediate case of phy-change but no drm-change everything will just revert to how it works now anyway. Heiko