Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200726111215.22361-1-konradybcio@gmail.com> <20200726111215.22361-5-konradybcio@gmail.com>
 <20200803110016.GL12965@vkoul-mobl> <CAF6AEGtW29BtJPq1xDEtvtkPHFVWEd_QJk5FpJEQPbmofnS64Q@mail.gmail.com>
 <20200804120946.GQ12965@vkoul-mobl>
In-Reply-To: <20200804120946.GQ12965@vkoul-mobl>
From:   Rob Clark <robdclark@gmail.com>
Date:   Tue, 4 Aug 2020 07:49:44 -0700
Message-ID: <CAF6AEGttPJSy+PcspPgxj2OELEyh2Xj-Gm2Uiv7Pcv6JMDE-tg@mail.gmail.com>
Subject: Re: [PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660
To:     Vinod Koul <vkoul@kernel.org>
Cc:     Konrad Dybcio <konradybcio@gmail.com>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        martin.botka1@gmail.com, Sean Paul <sean@poorly.run>,
        David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Rob Herring <robh+dt@kernel.org>,
        Andy Gross <agross@kernel.org>,
        Kishon Vijay Abraham I <kishon@ti.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Felipe Balbi <balbi@kernel.org>,
        Jordan Crouse <jcrouse@codeaurora.org>,
        zhengbin <zhengbin13@huawei.com>,
        Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
        AngeloGioacchino Del Regno <kholk11@gmail.com>,
        Ben Dooks <ben.dooks@codethink.co.uk>,
        Krzysztof Wilczynski <kw@linux.com>,
        Harigovindan P <harigovi@codeaurora.org>,
        Brian Masney <masneyb@onstation.org>,
        Sam Ravnborg <sam@ravnborg.org>,
        Xiaozhe Shi <xiaozhes@codeaurora.org>,
        Manu Gautam <mgautam@codeaurora.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        freedreno <freedreno@lists.freedesktop.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux USB List <linux-usb@vger.kernel.org>,
        linux-clk <linux-clk@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Aug 4, 2020 at 5:09 AM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 03-08-20, 09:06, Rob Clark wrote:
> > On Mon, Aug 3, 2020 at 4:00 AM Vinod Koul <vkoul@kernel.org> 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 <konradybcio@gmail.com>
> > > > ---
> > > >  .../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.

I'm not aware of any re-use that would be possible by splitting it
out.. if there were, it would be a more compelling argument.

It does increase the complexity and possibilities for getting kernel
config wrong.  There are devices like the aarch64 laptops which do not
have a debug serial port, where debugging issues like that can be a
pain when you get no display.  OTOH that might be balanced out a bit
by using a common framework/api that others are familiar with.

Overall, nowhere near high enough on my priority list to spend time
on.. there are bigger fires.  If someone was really motivated about
this and wanted to send (tested) patches, then I'd take a look and see
how it turned out.

BR,
-R

> Yes sure the question was not for a new phy but about the whole
> msm/dsi/phy code and future for it.
>
> --
> ~Vinod