| Message ID | 20210911131922.387964-1-marijn.suijten@somainline.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Use "ref" clocks from firmware for DSI PLL VCO parent | expand |
Quoting Marijn Suijten (2021-09-11 06:19:19) > All DSI PHY/PLL drivers were referencing their VCO parent clock by a > global name, most of which don't exist or have been renamed. These > clock drivers seem to function fine without that except the 14nm driver > for sdm6xx [1]. > > At the same time all DTs provide a "ref" clock as per the requirements > of dsi-phy-common.yaml, but the clock is never used. This patchset puts > that clock to use without relying on a global clock name, so that all > dependencies are explicitly defined in DT (the firmware) in the end. I can take this through clk tree if it helps avoid conflicts. There are some other patches to sdm660.c in the clk tree already.
On 2021-09-14 14:44:01, Stephen Boyd wrote: > Quoting Marijn Suijten (2021-09-11 06:19:19) > > All DSI PHY/PLL drivers were referencing their VCO parent clock by a > > global name, most of which don't exist or have been renamed. These > > clock drivers seem to function fine without that except the 14nm driver > > for sdm6xx [1]. > > > > At the same time all DTs provide a "ref" clock as per the requirements > > of dsi-phy-common.yaml, but the clock is never used. This patchset puts > > that clock to use without relying on a global clock name, so that all > > dependencies are explicitly defined in DT (the firmware) in the end. > > I can take this through clk tree if it helps avoid conflicts. There are > some other patches to sdm660.c in the clk tree already. Might be useful to maintain proper ordering of these dependent patches but it's up to Dmitry and Rob to decide, whom I'm sending this mail directly to so that they can chime in.
Hi all, On 2021-09-18 16:40:38, Marijn Suijten wrote: > On 2021-09-14 14:44:01, Stephen Boyd wrote: > > Quoting Marijn Suijten (2021-09-11 06:19:19) > > > All DSI PHY/PLL drivers were referencing their VCO parent clock by a > > > global name, most of which don't exist or have been renamed. These > > > clock drivers seem to function fine without that except the 14nm driver > > > for sdm6xx [1]. > > > > > > At the same time all DTs provide a "ref" clock as per the requirements > > > of dsi-phy-common.yaml, but the clock is never used. This patchset puts > > > that clock to use without relying on a global clock name, so that all > > > dependencies are explicitly defined in DT (the firmware) in the end. > > > > I can take this through clk tree if it helps avoid conflicts. There are > > some other patches to sdm660.c in the clk tree already. > > Might be useful to maintain proper ordering of these dependent patches > but it's up to Dmitry and Rob to decide, whom I'm sending this mail > directly to so that they can chime in. Dependent patch [3] landed in 5.15 and [2] made it into 5.16 rc's - is it time to pick this series up and if so through what tree? Repeating the links from patch 1/2: [2]: https://lore.kernel.org/linux-arm-msm/20210830175739.143401-1-marijn.suijten@somainline.org/ [3]: https://lore.kernel.org/linux-arm-msm/20210829203027.276143-2-marijn.suijten@somainline.org/ Thanks! - marijn
On 14/12/2021 22:46, Marijn Suijten wrote: > Hi all, > > On 2021-09-18 16:40:38, Marijn Suijten wrote: >> On 2021-09-14 14:44:01, Stephen Boyd wrote: >>> Quoting Marijn Suijten (2021-09-11 06:19:19) >>>> All DSI PHY/PLL drivers were referencing their VCO parent clock by a >>>> global name, most of which don't exist or have been renamed. These >>>> clock drivers seem to function fine without that except the 14nm driver >>>> for sdm6xx [1]. >>>> >>>> At the same time all DTs provide a "ref" clock as per the requirements >>>> of dsi-phy-common.yaml, but the clock is never used. This patchset puts >>>> that clock to use without relying on a global clock name, so that all >>>> dependencies are explicitly defined in DT (the firmware) in the end. >>> >>> I can take this through clk tree if it helps avoid conflicts. There are >>> some other patches to sdm660.c in the clk tree already. >> >> Might be useful to maintain proper ordering of these dependent patches >> but it's up to Dmitry and Rob to decide, whom I'm sending this mail >> directly to so that they can chime in. > > Dependent patch [3] landed in 5.15 and [2] made it into 5.16 rc's - is > it time to pick this series up and if so through what tree? I'd also second the idea of merging these two patches into 5.17. Most probably it'd be easier to merge both of them through the clk tree. Or we can take the first patch into drm-msm (but then we'd have a dependency between msm-next and clk-qcom-next). Bjorn, Stephen? > > Repeating the links from patch 1/2: > [2]: https://lore.kernel.org/linux-arm-msm/20210830175739.143401-1-marijn.suijten@somainline.org/ > [3]: https://lore.kernel.org/linux-arm-msm/20210829203027.276143-2-marijn.suijten@somainline.org/
Quoting Dmitry Baryshkov (2021-12-15 12:02:37) > On 14/12/2021 22:46, Marijn Suijten wrote: > > Hi all, > > > > On 2021-09-18 16:40:38, Marijn Suijten wrote: > >> On 2021-09-14 14:44:01, Stephen Boyd wrote: > >>> Quoting Marijn Suijten (2021-09-11 06:19:19) > >>>> All DSI PHY/PLL drivers were referencing their VCO parent clock by a > >>>> global name, most of which don't exist or have been renamed. These > >>>> clock drivers seem to function fine without that except the 14nm driver > >>>> for sdm6xx [1]. > >>>> > >>>> At the same time all DTs provide a "ref" clock as per the requirements > >>>> of dsi-phy-common.yaml, but the clock is never used. This patchset puts > >>>> that clock to use without relying on a global clock name, so that all > >>>> dependencies are explicitly defined in DT (the firmware) in the end. > >>> > >>> I can take this through clk tree if it helps avoid conflicts. There are > >>> some other patches to sdm660.c in the clk tree already. > >> > >> Might be useful to maintain proper ordering of these dependent patches > >> but it's up to Dmitry and Rob to decide, whom I'm sending this mail > >> directly to so that they can chime in. > > > > Dependent patch [3] landed in 5.15 and [2] made it into 5.16 rc's - is > > it time to pick this series up and if so through what tree? > > I'd also second the idea of merging these two patches into 5.17. > Most probably it'd be easier to merge both of them through the clk tree. > Or we can take the first patch into drm-msm (but then we'd have a > dependency between msm-next and clk-qcom-next). > > Bjorn, Stephen? > Sounds fine to take through clk tree.
On 2021-12-15 16:43:45, Stephen Boyd wrote: > Quoting Dmitry Baryshkov (2021-12-15 12:02:37) > > On 14/12/2021 22:46, Marijn Suijten wrote: > > > Hi all, > > > > > > On 2021-09-18 16:40:38, Marijn Suijten wrote: > > >> On 2021-09-14 14:44:01, Stephen Boyd wrote: > > >>> Quoting Marijn Suijten (2021-09-11 06:19:19) > > >>>> All DSI PHY/PLL drivers were referencing their VCO parent clock by a > > >>>> global name, most of which don't exist or have been renamed. These > > >>>> clock drivers seem to function fine without that except the 14nm driver > > >>>> for sdm6xx [1]. > > >>>> > > >>>> At the same time all DTs provide a "ref" clock as per the requirements > > >>>> of dsi-phy-common.yaml, but the clock is never used. This patchset puts > > >>>> that clock to use without relying on a global clock name, so that all > > >>>> dependencies are explicitly defined in DT (the firmware) in the end. > > >>> > > >>> I can take this through clk tree if it helps avoid conflicts. There are > > >>> some other patches to sdm660.c in the clk tree already. > > >> > > >> Might be useful to maintain proper ordering of these dependent patches > > >> but it's up to Dmitry and Rob to decide, whom I'm sending this mail > > >> directly to so that they can chime in. > > > > > > Dependent patch [3] landed in 5.15 and [2] made it into 5.16 rc's - is > > > it time to pick this series up and if so through what tree? > > > > I'd also second the idea of merging these two patches into 5.17. > > Most probably it'd be easier to merge both of them through the clk tree. > > Or we can take the first patch into drm-msm (but then we'd have a > > dependency between msm-next and clk-qcom-next). > > > > Bjorn, Stephen? > > > > Sounds fine to take through clk tree. Thanks Stephen, would be great to take this in through the clk tree for 5.17. I don't have anything to add that could possibly warrant a v3, only msm8996 remains with the "xo" clock but that needs more work in other drivers and is best dealt with separately. Please take v2, assuming there are enough acks/reviews :) - Marijn
All DSI PHY/PLL drivers were referencing their VCO parent clock by a global name, most of which don't exist or have been renamed. These clock drivers seem to function fine without that except the 14nm driver for sdm6xx [1]. At the same time all DTs provide a "ref" clock as per the requirements of dsi-phy-common.yaml, but the clock is never used. This patchset puts that clock to use without relying on a global clock name, so that all dependencies are explicitly defined in DT (the firmware) in the end. [1]: https://lore.kernel.org/linux-arm-msm/386db1a6-a1cd-3c7d-a88e-dc83f8a1be96@somainline.org/ Changes since v2: - Added Stephen's a-b and Angelo's r-bs; - Added .name fallback in msm8974's dsi_phy_28nm for a more graceful transition period; - Documented possible breakage in 1/2 if firmware isn't updated in parallel with the kernel. Changes since v1: - Dropped "arm: dts: qcom: apq8064: Use 27MHz PXO clock as DSI PLL reference" which has made its way into 5.15-fixes in advance of this patchset landing in 5.16; - Added Fixes: tags for commits that added missing "ref" clocks to DT while this firmware clock was never used (until this patchset); - Documented missing/wrong and later-added clocks (by aforementioned patches) in patch 1/2 more clearly. Marijn Suijten (2): drm/msm/dsi: Use "ref" fw clock instead of global name for VCO parent clk: qcom: gcc-sdm660: Remove transient global "xo" clock drivers/clk/qcom/gcc-sdm660.c | 14 -------------- drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 4 +++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 4 +++- 6 files changed, 15 insertions(+), 19 deletions(-) -- 2.33.0