From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932236AbdJZENW (ORCPT ); Thu, 26 Oct 2017 00:13:22 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:35976 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750895AbdJZENU (ORCPT ); Thu, 26 Oct 2017 00:13:20 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0CB786034E Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=architt@codeaurora.org Subject: Re: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting To: Brian Norris , Sean Paul , Philippe CORNU 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 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> From: Archit Taneja Message-ID: Date: Thu, 26 Oct 2017 09:43:12 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20171026010946.GA33225@google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project