From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E94DAC433E0 for ; Tue, 4 Aug 2020 12:21:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB22D20738 for ; Tue, 4 Aug 2020 12:21:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596543672; bh=gey3esvl8wxAFJQ2OBCATSygwLbCiyTXxmuo4omuQjo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=kCPP3huj8VKmr+RK0YQ25FMZZeLv2VO3iYPsUIj490px+Wy5x8fPtu0ref+rI2/ES 7FVnSCFMjVlsm7BQ3WCaCx55LPplxi6u2OFqrABzcUx52xFaqCETDd7QgvZp6Dngzw t3mkcUX3RqRVV/d/oGsr583bB14T0kC3fvZiuFhI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726234AbgHDMSB (ORCPT ); Tue, 4 Aug 2020 08:18:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:44392 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726198AbgHDMLC (ORCPT ); Tue, 4 Aug 2020 08:11:02 -0400 Received: from localhost (unknown [122.171.202.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E70462177B; Tue, 4 Aug 2020 12:09:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596542990; bh=gey3esvl8wxAFJQ2OBCATSygwLbCiyTXxmuo4omuQjo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZZOJqEZ7ULpCVvpaR+mEa6S1b07HmtrWcayO6oiJVvACUiM9YU99kR+7yCx509uj+ PqVDfLqST8/x5f9kYzlfz0llp8qz2n58fvd10CVoYrBGEspn96gmX4MXk1wNHuwGG3 oWqka7+RyZxNSFDocwiL3Av/TJINQWNRcXQbUhdc= Date: Tue, 4 Aug 2020 17:39:46 +0530 From: Vinod Koul To: Rob Clark Cc: Konrad Dybcio , Bjorn Andersson , martin.botka1@gmail.com, Sean Paul , David Airlie , Daniel Vetter , Rob Herring , Andy Gross , Kishon Vijay Abraham I , Greg Kroah-Hartman , Michael Turquette , Stephen Boyd , Felipe Balbi , Jordan Crouse , zhengbin , Jeffrey Hugo , AngeloGioacchino Del Regno , Ben Dooks , Krzysztof Wilczynski , Harigovindan P , Brian Masney , Sam Ravnborg , Xiaozhe Shi , Manu Gautam , linux-arm-msm , dri-devel , freedreno , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List , Linux USB List , linux-clk Subject: Re: [PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660 Message-ID: <20200804120946.GQ12965@vkoul-mobl> References: <20200726111215.22361-1-konradybcio@gmail.com> <20200726111215.22361-5-konradybcio@gmail.com> <20200803110016.GL12965@vkoul-mobl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03-08-20, 09:06, Rob Clark wrote: > On Mon, Aug 3, 2020 at 4:00 AM Vinod Koul wrote: > > > > On 26-07-20, 13:12, Konrad Dybcio wrote: > > > These SoCs make use of the 14nm phy, but at different > > > addresses than other 14nm units. > > > > > > Signed-off-by: Konrad Dybcio > > > --- > > > .../devicetree/bindings/display/msm/dsi.txt | 1 + > > > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++ > > > drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + > > > drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 18 ++++++++++++++++++ > > > > Is there a reason why dsi phy needs to be here and not in phy subsystem > > drivers/phy/ ? > > *maybe* it would be possible to split out all of the dsi (and hdmi) > phy to drivers/phy. But splitting out just the new ones wouldn't be > practical (it would duplicate a lot of code, and make the rest of the > dsi code have to deal with both cases). And unlike dp/usb-c I'm not > really sure I see an advantage to justify the churn. So the question would be if it helps in reuse if we do that and does it result in a better solution than dsi code managing the phy. The advantage of framework (like phy) is that different subsystems can use a (phy) driver and common framework helps reduce duplicates. Yes sure the question was not for a new phy but about the whole msm/dsi/phy code and future for it. -- ~Vinod