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