Messages in this thread | | | Date | Tue, 4 Aug 2020 17:39:46 +0530 | From | Vinod Koul <> | Subject | Re: [PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660 |
| |
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.
Yes sure the question was not for a new phy but about the whole msm/dsi/phy code and future for it.
-- ~Vinod
| |