On 03-08-20, 09:06, Rob Clark wrote: > On Mon, Aug 3, 2020 at 4:00 AM Vinod Koul <vkoul@xxxxxxxxxx> 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@xxxxxxxxx> > > > --- > > > .../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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
