[Freedreno] [PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660

[Rob Clark]

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