From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932404AbdJZVcK (ORCPT ); Thu, 26 Oct 2017 17:32:10 -0400 Received: from mail-io0-f179.google.com ([209.85.223.179]:47537 "EHLO mail-io0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751886AbdJZVcJ (ORCPT ); Thu, 26 Oct 2017 17:32:09 -0400 X-Google-Smtp-Source: ABhQp+RnQpLjt1mPNwjwTStA4xKyqfNLLcT5g6QMyy5R8kxwwBxHtkTch2++Aa0KpLWFmqw7KVCL6A== Date: Thu, 26 Oct 2017 14:32:05 -0700 From: Brian Norris To: Philippe CORNU Cc: Archit Taneja , Sean Paul , Nickey Yang , "mark.yao@rock-chips.com" , "robh+dt@kernel.org" , "heiko@sntech.de" , "mark.rutland@arm.com" , "airlied@linux.ie" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linux-rockchip@lists.infradead.org" , "hl@rock-chips.com" , "zyw@rock-chips.com" , "xbl@rock-chips.com" , Kristian Kristensen Subject: Re: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting Message-ID: <20171026213204.GA55212@google.com> References: <1508903463-7254-1-git-send-email-nickey.yang@rock-chips.com> <1508903463-7254-3-git-send-email-nickey.yang@rock-chips.com> <20171025075719.4tt7lomec5x7guon@art_vandelay> <20171026010946.GA33225@google.com> <39862e7a-b03f-f5d9-54db-ff9aef294a9c@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39862e7a-b03f-f5d9-54db-ff9aef294a9c@st.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (correction zyw's email ".comg" is not a TLD!) Hi, On Thu, Oct 26, 2017 at 09:44:14AM +0000, Philippe CORNU wrote: > On 10/26/2017 06:13 AM, Archit Taneja wrote: > > On 10/26/2017 06:39 AM, Brian Norris wrote: > >> On Wed, Oct 25, 2017 at 03:57:19AM -0400, Sean Paul wrote: > >>> Archit asked a question about moving to > >>> dw-mipi-dsi > >> > >> That question made me think though: this approach seems backwards. It > >> seems like someone did copy/paste/fork, and then we're asking the > >> authors of the original driver to un-fork? It seems like this should > >> happen the other way around -- those trying to support a new incarnation > >> should have looked to try to abstract the original driver for their > >> uses first. > > > > Yes, ST wanted to replicate rockchip's version of the mipi DSI driver and > > put it in their folder. If they did that, their KMS driver would have been > > the third driver to implement a third instance of the DW DSI controller > > driver. > > Hisilicon and Rockchip being the other 2. I hadn't noticed Hisilicon's version. That's an unfortunate start :( > > It was either that or attempt at a common DSI DW bridge driver. I suggested > > the latter. > > > > The ST guys have abstracted out the PHY pieces, which they knew varied > > between > > rockchip and ST. Ideally, they should have also tried to create a RFC > > patch to > > make the rockchip driver use the bridge too. But they didn't do that, and > > the rockchip or hisilicon people were interested in even looking at it, > > even after I CC'ed them. I see. At least the current code from Philippe isn't that big, and it is indeed fairly similar. But I still think the way to get cooperation upstream is to enforce it; so there was a 3rd option to the above -- don't merge *any* new driver without posting at least an attempt to unify the existing drivers. > >> IIUC, that's exactly what Rockchip did for much of their Analogix eDP > >> code -- they reworked the Exynos DP driver to split common Analogix code > >> from any Exynos-specific bits. > > > > I get that. I had hoped either ST or Rockchip guys would have done the > > similar > > thing, but no one volunteered. :( Nickey, can you confirm that you or someone on your team will look at utilizing the common driver? Please reply to this email thread before sending another version of this series. > >> And actually, the current stuff in > >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c is completely unused. It > >> exports some functions, but I see no users of it. Is that intended? Is > > > > The ST kms driver uses it: > > > > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c > > > > I confirm STM32 chipsets use the Synopsys dw dsi bridge driver. > > I plan to improve this bridge driver by adding new features (see todos + > dsi read, command mode with bta & gpio...). > > For the first commit, I did my best to keep the source code as close as > possible to the Rockchip version, in order to ease the port for Rockchip > guys. That's nice to see, even if it still isn't ideal. > >> somebody already working on refactoring existing Rockchip code to use > >> this? > > > > I don't know. If rockchip isn't interested in doing it, we can check with > > Philippe from ST if he can try creating a RFC that converts the rockchip > > driver to use the dw-mipi-dsi driver. > > I am not really interested in doing this port for Rockchip (or Hisilicon > or i.MX...) but happy to help anyone that wants to use the dw-mipi-dsi > bridge driver :) Well, see my comments above. Your "interest" is obviously in merging code to support your own IP, but the community can *make* it your interest by requiring you do the unification before your code goes upstream. Apparently that's not the policy here though. Brian