From: Rob Clark <robdclark@gmail.com> 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> Subject: Re: [PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660 Date: Tue, 4 Aug 2020 07:49:44 -0700 [thread overview] Message-ID: <CAF6AEGttPJSy+PcspPgxj2OELEyh2Xj-Gm2Uiv7Pcv6JMDE-tg@mail.gmail.com> (raw) In-Reply-To: <20200804120946.GQ12965@vkoul-mobl> 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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com> To: Vinod Koul <vkoul@kernel.org> Cc: Krzysztof Wilczynski <kw@linux.com>, Jeffrey Hugo <jeffrey.l.hugo@gmail.com>, David Airlie <airlied@linux.ie>, Michael Turquette <mturquette@baylibre.com>, dri-devel <dri-devel@lists.freedesktop.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, AngeloGioacchino Del Regno <kholk11@gmail.com>, Sam Ravnborg <sam@ravnborg.org>, linux-clk <linux-clk@vger.kernel.org>, Konrad Dybcio <konradybcio@gmail.com>, Kishon Vijay Abraham I <kishon@ti.com>, martin.botka1@gmail.com, Andy Gross <agross@kernel.org>, Brian Masney <masneyb@onstation.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Xiaozhe Shi <xiaozhes@codeaurora.org>, Rob Herring <robh+dt@kernel.org>, Sean Paul <sean@poorly.run>, Ben Dooks <ben.dooks@codethink.co.uk>, Felipe Balbi <balbi@kernel.org>, Stephen Boyd <sboyd@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Linux USB List <linux-usb@vger.kernel.org>, Harigovindan P <harigovi@codeaurora.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, zhengbin <zhengbin13@huawei.com>, Manu Gautam <mgautam@codeaurora.org>, freedreno <freedreno@lists.freedesktop.org> Subject: Re: [PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660 Date: Tue, 4 Aug 2020 07:49:44 -0700 [thread overview] Message-ID: <CAF6AEGttPJSy+PcspPgxj2OELEyh2Xj-Gm2Uiv7Pcv6JMDE-tg@mail.gmail.com> (raw) In-Reply-To: <20200804120946.GQ12965@vkoul-mobl> 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-08-04 14:49 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-26 11:11 [PATCH 0/9] SDM630/36/60 driver enablement Konrad Dybcio 2020-07-26 11:11 ` Konrad Dybcio 2020-07-26 11:11 ` [PATCH 1/9] clk: qcom: gcc-sdm660: Add missing modem reset Konrad Dybcio 2020-07-26 11:11 ` Konrad Dybcio 2020-07-27 19:43 ` Stephen Boyd 2020-07-27 19:58 ` Konrad Dybcio 2020-07-27 19:58 ` Konrad Dybcio 2020-07-27 22:16 ` Stephen Boyd 2020-07-26 11:11 ` [PATCH 2/9] phy: qcom-qusb2: Add support for SDM630/660 Konrad Dybcio 2020-07-26 11:11 ` Konrad Dybcio 2020-07-31 20:26 ` Rob Herring 2020-07-31 20:26 ` Rob Herring 2020-07-26 11:12 ` [PATCH 3/9] drivers: usb: dwc3-qcom: Add sdm660 compatible Konrad Dybcio 2020-07-26 11:12 ` Konrad Dybcio 2020-07-31 20:26 ` Rob Herring 2020-07-31 20:26 ` Rob Herring 2020-07-26 11:12 ` [PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660 Konrad Dybcio 2020-07-26 11:12 ` Konrad Dybcio 2020-08-03 11:00 ` Vinod Koul 2020-08-03 11:00 ` Vinod Koul 2020-08-03 16:06 ` Rob Clark 2020-08-03 16:06 ` Rob Clark 2020-08-04 12:09 ` Vinod Koul 2020-08-04 12:09 ` Vinod Koul 2020-08-04 14:49 ` Rob Clark [this message] 2020-08-04 14:49 ` Rob Clark 2020-07-26 11:12 ` [PATCH 5/9] drm/msm/mdp5: Add MDP5 configuration for SDM630 Konrad Dybcio 2020-07-26 11:12 ` Konrad Dybcio 2020-07-26 11:12 ` [PATCH 6/9] drm/msm/dsi: Add DSI configuration for SDM660 Konrad Dybcio 2020-07-26 11:12 ` Konrad Dybcio 2020-07-26 11:12 ` [PATCH 7/9] drm/msm/mdp5: Add MDP5 configuration for SDM636/660 Konrad Dybcio 2020-07-26 11:12 ` Konrad Dybcio 2020-07-26 11:12 ` [PATCH 8/9] clk: qcom: gcc-sdm660: Fix up gcc_mss_mnoc_bimc_axi_clk Konrad Dybcio 2020-07-26 11:12 ` Konrad Dybcio 2020-07-27 19:41 ` Stephen Boyd 2020-07-27 19:58 ` Konrad Dybcio 2020-07-27 19:58 ` Konrad Dybcio 2020-07-27 22:20 ` Stephen Boyd 2020-07-26 11:12 ` [PATCH 9/9] soc/qcom: Add REVID driver Konrad Dybcio 2020-07-26 11:12 ` Konrad Dybcio 2020-07-26 11:29 ` Greg Kroah-Hartman 2020-07-26 11:29 ` Greg Kroah-Hartman 2020-07-26 11:40 ` Konrad Dybcio 2020-07-26 11:40 ` Konrad Dybcio 2020-07-26 12:04 ` Greg Kroah-Hartman 2020-07-26 12:04 ` Greg Kroah-Hartman 2020-07-26 18:43 ` kernel test robot 2020-07-26 21:36 ` kernel test robot 2020-07-27 18:13 ` Rob Herring 2020-07-27 18:13 ` Rob Herring 2020-07-27 18:13 ` Rob Herring 2020-07-27 18:13 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAF6AEGttPJSy+PcspPgxj2OELEyh2Xj-Gm2Uiv7Pcv6JMDE-tg@mail.gmail.com \ --to=robdclark@gmail.com \ --cc=agross@kernel.org \ --cc=airlied@linux.ie \ --cc=balbi@kernel.org \ --cc=ben.dooks@codethink.co.uk \ --cc=bjorn.andersson@linaro.org \ --cc=daniel@ffwll.ch \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=gregkh@linuxfoundation.org \ --cc=harigovi@codeaurora.org \ --cc=jcrouse@codeaurora.org \ --cc=jeffrey.l.hugo@gmail.com \ --cc=kholk11@gmail.com \ --cc=kishon@ti.com \ --cc=konradybcio@gmail.com \ --cc=kw@linux.com \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=martin.botka1@gmail.com \ --cc=masneyb@onstation.org \ --cc=mgautam@codeaurora.org \ --cc=mturquette@baylibre.com \ --cc=robh+dt@kernel.org \ --cc=sam@ravnborg.org \ --cc=sboyd@kernel.org \ --cc=sean@poorly.run \ --cc=vkoul@kernel.org \ --cc=xiaozhes@codeaurora.org \ --cc=zhengbin13@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.