From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932246AbdJZJpF (ORCPT ); Thu, 26 Oct 2017 05:45:05 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:62470 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751568AbdJZJpD (ORCPT ); Thu, 26 Oct 2017 05:45:03 -0400 From: Philippe CORNU To: Archit Taneja , Brian Norris , Sean Paul CC: 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.comg" , "xbl@rock-chips.com" , "Kristian Kristensen" Subject: Re: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting Thread-Topic: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting Thread-Index: AQHTTUSKYm/b+aS/6Ua2oRc+kZd3NKL0EbKAgAEgeICAADM/AIAAXH4A Date: Thu, 26 Oct 2017 09:44:14 +0000 Message-ID: <39862e7a-b03f-f5d9-54db-ff9aef294a9c@st.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> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.75.127.46] Content-Type: text/plain; charset="utf-8" Content-ID: <6B19CD35E9DC7E4FBF0A93E0C88C1C3A@st.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-26_02:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v9Q9jAgB028114 Hi, On 10/26/2017 06:13 AM, Archit Taneja wrote: > Hi, > > 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. > > 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. > >> >> 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. > >> >> 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. >> 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 :) Many thanks, Philippe :) > > Thanks, > Archit >