Message ID | 20220629225331.357308-1-marijn.suijten@somainline.org (mailing list archive) |
---|---|
Headers | show |
Series | drm/msm/dsi_phy: Replace parent names with clk_hw pointers | expand |
On 30/06/2022 01:53, Marijn Suijten wrote: > parent_hw pointers are easier to manage and cheaper to use than > repeatedly formatting the parent name and subsequently leaving the clk > framework to perform lookups based on that name. > > This series starts out by adding extra constructors for divider, mux and > fixed-factor clocks that have parent_hw(s) pointer argument(s) instead > of some DT index or name. Followed by individual patches performing the > conversion, one DSI PHY at a time. > > dsi_phy_28nm_8960 includes an extra fixup to replace "eternal" > devm_kzalloc allocations (for the lifetime of the device) with > stack-local char arrays, like all the other DSI PHY drivers. > > (Questions from v1 cover letter regarding the future of these drivers > is omitted for brevity.) > > And with enough future improvements out of the way, let's round out this > patch-series by stating that it has been successfully tested on: > > - Sony Nile Discovery (Xperia XA2 Ultra): 14nm; > - Sony Seine PDX201 (Xperia 10II): 14nm; > - Sony Loire Suzu (Xperia X): 28nm. > > And no diff is observed in debugfs's clk_summary. > > Unfortunately all other devices in my collection with a 7/10nm DSI PHY > have a DSC panel which we have yet to get working. > > Changes since v2: > - in fixed-factor: > - Reorder if - else if change to consume less diff; > - Go over 80-char column lint when adding new arguments to function > calls, instead of reflowing all arguments to adhere to this limit; > also consuming less diff. > > v2: https://lore.kernel.org/linux-arm-msm/20220601220747.1145095-1-marijn.suijten@somainline.org/ > > Changes since v1: > > - Moved indentation changes to separate patch (Dmitry); > - dsi_phy_28nm_8960: move clock name allocation removal prior to > parent_hw refactor; > - Remove vco_name stack-local char array in favour of reusing clk_name > (Dmitry); > - Inserted additional patch to replace hardcoded char-array length > constant 32 with sizeof(clk_name). > > v1: https://lore.kernel.org/linux-arm-msm/20220523213837.1016542-1-marijn.suijten@somainline.org/T/#u > > Marijn Suijten (11): > clk: divider: Introduce devm_clk_hw_register_divider_parent_hw() > clk: mux: Introduce devm_clk_hw_register_mux_parent_hws() > clk: fixed-factor: Introduce *clk_hw_register_fixed_factor_parent_hw() Stephen, do we stand a chance of landing patches 1-3 into 5.20? We would like to merge the series into 5.21 through the msm-next. Landing clk patches in 5.20 would save us from using immutable branches, etc. > drm/msm/dsi/phy: Reindent and reflow multiline function calls > drm/msm/dsi_phy_28nm_8960: Use stack memory for temporary clock names > drm/msm/dsi/phy: Replace hardcoded char-array length with sizeof() > drm/msm/dsi_phy_28nm_8960: Replace parent names with clk_hw pointers > drm/msm/dsi_phy_28nm: Replace parent names with clk_hw pointers > drm/msm/dsi_phy_14nm: Replace parent names with clk_hw pointers > drm/msm/dsi_phy_10nm: Replace parent names with clk_hw pointers > drm/msm/dsi_phy_7nm: Replace parent names with clk_hw pointers > > drivers/clk/clk-fixed-factor.c | 45 ++++- > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 165 +++++++++--------- > drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 55 +++--- > drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 117 ++++++------- > .../gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 90 +++++----- > drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 156 ++++++++--------- > include/linux/clk-provider.h | 34 ++++ > 7 files changed, 351 insertions(+), 311 deletions(-) >
Quoting Dmitry Baryshkov (2022-07-14 03:19:12) > On 30/06/2022 01:53, Marijn Suijten wrote: > > Marijn Suijten (11): > > clk: divider: Introduce devm_clk_hw_register_divider_parent_hw() > > clk: mux: Introduce devm_clk_hw_register_mux_parent_hws() > > clk: fixed-factor: Introduce *clk_hw_register_fixed_factor_parent_hw() > > Stephen, do we stand a chance of landing patches 1-3 into 5.20? We would > like to merge the series into 5.21 through the msm-next. Landing clk > patches in 5.20 would save us from using immutable branches, etc. > Sure I can land the first three patches now for 5.20