Re: [PATCH 1/9] dt-bindings: mfd: Add bindings for SAM9X7 LCD controller
On 21/06/23 13:17, Nicolas Ferre wrote: > On 16/06/2023 at 08:44, Manikandan M - I67131 wrote: >> On 14/06/23 20:10, Nicolas Ferre wrote: >>> On 13/06/2023 at 20:21, Conor Dooley wrote: On Tue, Jun 13, 2023 at 08:17:13PM +0200, Krzysztof Kozlowski wrote: > On 13/06/2023 09:04, Manikandan Muralidharan wrote: >> Add new compatible string for the XLCD controller on SAM9X7 SoC. >> >> Signed-off-by: Manikandan Muralidharan >> --- >> Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt >> b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt >> index 5f8880cc757e..7c77b6bf4adb 100644 >> --- a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt >> +++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt >> @@ -8,6 +8,7 @@ Required properties: >> "atmel,sama5d3-hlcdc" >> "atmel,sama5d4-hlcdc" >> "microchip,sam9x60-hlcdc" >> + "microchip,sam9x7-xlcdc" > Google says sam9x7 is a series, not a SoC. Please add compatibles for > specific SoCs, not for series. We had this one a few weeks ago, see https://lore.kernel.org/all/add5e49e-8416-ba9f-819a-da944938c...@microchip.com/ and its parents. Outcome of that seemed to be that using "sam9x7" was fine. >>> >>> And it's where it begins to be funny, as the LCD is precisely one aspect >>> where we differentiate between sam9x75, sam9x72 and sam9x70... >>> So please Manikandan sort this out if difference between these chips >>> will be better handled with different compatibility string, in >>> particular about //, LVDS and MIPI-DSI variants! >> Yes Sure, I will replace the compatible as s/sam9x7/sam9x75/g to handle >> the different variants of sam9x7 better. > > Moving to sam9x75 is probably good. But what is your plan for > differentiating parallel and LVDS (on sam9x72) and precisely this > sam9x75 variant which in addition has MIPI-DSI? In sam9x75 with support for LVDS and MIPI, Parallel interfacing peripherals, the additions performed on the LCD controller driver is the same.Considering the LCDC IP used in sam9x75, there are no registers sets that needs modification per connecting peripheral variants, only the clock and DRM_ENCODER_MODE_XXX (set by connecting peripheral driver) differs, which can be handled in DT, atmel-lcdc MFD driver and peripheral driver. In future, sam9x72 with XLCD controller can be differentiated with sam9x72 compatible string and with a IP version flag(is_xlcdc_v2) in its driver data if an upgraded XLCD IP is used with difference in bits or register set exist compared to current IP. > > Regards, > Nicolas > > -- Thanks and Regards, Manikandan M.
Re: [PATCH v4 1/2] drm/mediatek: Add ability to support dynamic connector selection
Re: [PATCH 1/2] drm/msm/dpu: fix DSC 1.2 block lengths
On 2023-06-23 15:12:06, Abhinav Kumar wrote: > > > On 6/23/2023 1:28 PM, Marijn Suijten wrote: > > On 2023-06-23 14:37:12, Dmitry Baryshkov wrote: > > > >>> In fact I asked to make it 0xf00 + 0x10 or 0xf80 + 0x10 to also cover > >>> the CTL registers, but that change didn't make it through. 0x29c is an > >>> arbitrary number that I have no clue what it was based on. > >> > >> This should have been NAKed. or at least TODOed. > > > > As usual ;) - add new features first, fix the fundamentals... later? > > > > - Marijn > > I think you yourself found out that this was not an arbitary number but > we atleast wanted to cover the full encoder set. > > So fundamentals are always sound sometimes understanding is not ;) The fundamentals are not sound until the CTL block/register can be dumped ;) - Marijn
Re: [PATCH] drm/amd/amdgpu: Properly tune the size of struct
Hi Su, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.4-rc7 next-20230623] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Su-Hui/drm-amd-amdgpu-Properly-tune-the-size-of-struct/20230620-130013 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230620045919.492128-1-suhui%40nfschina.com patch subject: [PATCH] drm/amd/amdgpu: Properly tune the size of struct config: m68k-randconfig-r093-20230625 (https://download.01.org/0day-ci/archive/20230626/202306260550.sinebmd3-...@intel.com/config) compiler: m68k-linux-gcc (GCC) 12.3.0 reproduce: (https://download.01.org/0day-ci/archive/20230626/202306260550.sinebmd3-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202306260550.sinebmd3-...@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:275:21: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:275:21: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:275:21: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:275:21: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:275:21: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:275:21: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:280:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:280:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:280:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:280:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:280:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:280:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:281:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:281:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:281:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:281:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:281:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:281:34: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:306:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:306:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:306:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:306:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:306:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:306:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:307:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:307:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:307:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:307:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:307:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:307:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:308:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:308:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:308:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:308:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:308:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:308:30: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:314:40: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:314:40: sparse: sparse: cast to restricted __le32 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c:314:40: sparse: sparse: cast to restricted __le32 drive
Re: [PATCH 11/15] drm/msm/dsi: Add 14nm phy configuration for SM6125
On 2023-06-24 03:49:25, Konrad Dybcio wrote:
> On 24.06.2023 02:41, Marijn Suijten wrote:
> > SM6125 features only a single PHY (despite a secondary PHY PLL source
> > being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
> > sources for this "trinket" SoC do not define the typical "vcca"
> > regulator to be available nor used.
> >
> > Signed-off-by: Marijn Suijten
> > ---
> The introduced ops are identical to 2290, modulo regulator..
Sure, I can create a "drop unused regulators from 14nm qcm2290 config"
and a second "reuse qcm2290 14nm dsi phy for sm6125" patch, instead of
this one.
> But the regulator is absent on both (VDD_MX powers it instead), so
In the DT patch you requested me to use CX instead of MX... Which one is
it?
Also note that I moved it from DSI PHY to DSI0 because that's where the
rpmpd opps reside.
- Marijn
> feel free to clean that up and reuse it ;)
>
> Konrad
> > 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 | 15 +++
> > 3 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > index 9d5795c58a98..8688ed502dcf 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> > @@ -559,6 +559,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
> > .data = _phy_14nm_2290_cfgs },
> > { .compatible = "qcom,dsi-phy-14nm-660",
> > .data = _phy_14nm_660_cfgs },
> > + { .compatible = "qcom,dsi-phy-14nm-6125",
> > + .data = _phy_14nm_6125_cfgs },
> > { .compatible = "qcom,dsi-phy-14nm-8953",
> > .data = _phy_14nm_8953_cfgs },
> > #endif
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> > index 8b640d174785..ebf915f5e6c6 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
> > @@ -52,6 +52,7 @@ extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_14nm_2290_cfgs;
> > +extern const struct msm_dsi_phy_cfg dsi_phy_14nm_6125_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_14nm_8953_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs;
> > extern const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs;
> > diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
> > b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
> > index 3ce45b023e63..5d43c9ec69ae 100644
> > --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
> > +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
> > @@ -1068,6 +1068,21 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs =
> > {
> > .num_dsi_phy = 2,
> > };
> >
> > +const struct msm_dsi_phy_cfg dsi_phy_14nm_6125_cfgs = {
> > + .has_phy_lane = true,
> > + .ops = {
> > + .enable = dsi_14nm_phy_enable,
> > + .disable = dsi_14nm_phy_disable,
> > + .pll_init = dsi_pll_14nm_init,
> > + .save_pll_state = dsi_14nm_pll_save_state,
> > + .restore_pll_state = dsi_14nm_pll_restore_state,
> > + },
> > + .min_pll_rate = VCO_MIN_RATE,
> > + .max_pll_rate = VCO_MAX_RATE,
> > + .io_start = { 0x5e94400 },
> > + .num_dsi_phy = 1,
> > +};
> > +
> > const struct msm_dsi_phy_cfg dsi_phy_14nm_8953_cfgs = {
> > .has_phy_lane = true,
> > .regulator_data = dsi_phy_14nm_17mA_regulators,
> >
Re: [PATCH 08/15] drm/msm/dpu: Add SM6125 support
On 2023-06-24 03:47:27, Konrad Dybcio wrote:
> On 24.06.2023 02:41, Marijn Suijten wrote:
> > Add definitions for the display hardware used on the Qualcomm SM6125
> > platform.
> >
> > Signed-off-by: Marijn Suijten
> > ---
> [...]
>
> > +static const struct dpu_perf_cfg sm6125_perf_data = {
> > + .max_bw_low = 410,
> > + .max_bw_high = 410,
> > + .min_core_ib = 240,
> > + .min_llcc_ib = 80,
> While Dmitry will likely validate other values
Lovely.
> I can tell you already that this SoC has no LLCC.
Copy-paste error on downstream?
https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/LA.UM.9.11.c25/arch/arm64/boot/dts/qcom/trinket-sde.dtsi#L146
- Marijn
>
> Konrad
> > + .min_dram_ib = 80,
> > + .min_prefill_lines = 24,
> > + .danger_lut_tbl = {0xf, 0x, 0x0},
> > + .safe_lut_tbl = {0xfff8, 0xf000, 0x},
> > + .qos_lut_tbl = {
> > + {.nentry = ARRAY_SIZE(sm8150_qos_linear),
> > + .entries = sm8150_qos_linear
> > + },
> > + {.nentry = ARRAY_SIZE(sc7180_qos_macrotile),
> > + .entries = sc7180_qos_macrotile
> > + },
> > + {.nentry = ARRAY_SIZE(sc7180_qos_nrt),
> > + .entries = sc7180_qos_nrt
> > + },
> > + /* TODO: macrotile-qseed is different from macrotile */
> > + },
> > + .cdp_cfg = {
> > + {.rd_enable = 1, .wr_enable = 1},
> > + {.rd_enable = 1, .wr_enable = 0}
> > + },
> > + .clk_inefficiency_factor = 105,
> > + .bw_inefficiency_factor = 120,
> > +};
> > +
> > +const struct dpu_mdss_cfg dpu_sm6125_cfg = {
> > + .caps = _dpu_caps,
> > + .ubwc = _ubwc_cfg,
> > + .mdp_count = ARRAY_SIZE(sm6125_mdp),
> > + .mdp = sm6125_mdp,
> > + .ctl_count = ARRAY_SIZE(sm6125_ctl),
> > + .ctl = sm6125_ctl,
> > + .sspp_count = ARRAY_SIZE(sm6125_sspp),
> > + .sspp = sm6125_sspp,
> > + .mixer_count = ARRAY_SIZE(sm6125_lm),
> > + .mixer = sm6125_lm,
> > + .dspp_count = ARRAY_SIZE(sm6125_dspp),
> > + .dspp = sm6125_dspp,
> > + .pingpong_count = ARRAY_SIZE(sm6125_pp),
> > + .pingpong = sm6125_pp,
> > + .intf_count = ARRAY_SIZE(sm6125_intf),
> > + .intf = sm6125_intf,
> > + .vbif_count = ARRAY_SIZE(sdm845_vbif),
> > + .vbif = sdm845_vbif,
> > + .perf = _perf_data,
> > + .mdss_irqs = BIT(MDP_SSPP_TOP0_INTR) | \
> > +BIT(MDP_SSPP_TOP0_INTR2) | \
> > +BIT(MDP_SSPP_TOP0_HIST_INTR) | \
> > +BIT(MDP_INTF0_INTR) | \
> > +BIT(MDP_INTF1_INTR) | \
> > +BIT(MDP_INTF1_TEAR_INTR),
> > +};
> > +
> > +#endif
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > index 0de507d4d7b7..8a02bbdaae8a 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> > @@ -33,6 +33,9 @@
> > #define VIG_SC7180_MASK \
> > (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4))
> >
> > +#define VIG_SM6125_MASK \
> > + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
> > +
> > #define VIG_SC7180_MASK_SDMA \
> > (VIG_SC7180_MASK | BIT(DPU_SSPP_SMART_DMA_V2))
> >
> > @@ -348,6 +351,8 @@ static const struct dpu_sspp_sub_blks sc7280_vig_sblk_0
> > =
> >
> > static const struct dpu_sspp_sub_blks sm6115_vig_sblk_0 =
> > _VIG_SBLK("0", 2, DPU_SSPP_SCALER_QSEED4);
> > +static const struct dpu_sspp_sub_blks sm6125_vig_sblk_0 =
> > + _VIG_SBLK("0", 3, DPU_SSPP_SCALER_QSEED3LITE);
> >
> > static const struct dpu_sspp_sub_blks sm8250_vig_sblk_0 =
> > _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED4);
> > @@ -762,6 +767,7 @@ static const struct dpu_qos_lut_entry sc7180_qos_nrt[]
> > = {
> >
> > #include "catalog/dpu_5_0_sm8150.h"
> > #include "catalog/dpu_5_1_sc8180x.h"
> > +#include "catalog/dpu_5_4_sm6125.h"
> >
> > #include "catalog/dpu_6_0_sm8250.h"
> > #include "catalog/dpu_6_2_sc7180.h"
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > index b860784ade72..4314235cb2b8 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> > @@ -861,6 +861,7 @@ extern const struct dpu_mdss_cfg dpu_sc8180x_cfg;
> > extern const struct dpu_mdss_cfg dpu_sm8250_cfg;
> > extern const struct dpu_mdss_cfg dpu_sc7180_cfg;
> > extern const struct dpu_mdss_cfg dpu_sm6115_cfg;
> > +extern const struct dpu_mdss_cfg dpu_sm6125_cfg;
> > extern const struct dpu_mdss_cfg dpu_sm6350_cfg;
> > extern const struct dpu_mdss_cfg dpu_qcm2290_cfg;
> > extern const struct dpu_mdss_cfg dpu_sm6375_cfg;
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > index aa8499de1b9f..a1c7ffb6dffb 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > +++
Re: [PATCH 06/15] dt-bindings: display/msm: sc7180-dpu: Describe SM6125
On 2023-06-24 11:12:52, Krzysztof Kozlowski wrote:
> On 24/06/2023 02:41, Marijn Suijten wrote:
> > SM6125 is identical to SM6375 except that while downstream also defines
> > a throttle clock, its presence results in timeouts whereas SM6375
> > requires it to not observe any timeouts.
>
> Then it should not be allowed, so you need either "else:" block or
> another "if: properties: compatible:" to disallow it. Because in current
> patch it would be allowed.
That means this binding is wrong/incomplete for all other SoCs then.
clock(-name)s has 6 items, and sets `minItems: 6`. Only for sm6375-dpu
does it set `minItems: 7`, but an else case is missing.
Shall I send a Fixes: ed41005f5b7c ("dt-bindings: display/msm:
sc7180-dpu: Describe SM6350 and SM6375") for that, and should maxItems:
6 be the default under clock(-name)s or in an else:?
- Marijn
Re: [PATCH 03/15] dt-bindings: clock: qcom,dispcc-sm6125: Require GCC PLL0 DIV clock
On 2023-06-24 11:08:54, Krzysztof Kozlowski wrote:
> On 24/06/2023 03:45, Konrad Dybcio wrote:
> > On 24.06.2023 02:41, Marijn Suijten wrote:
> >> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> >> be passed from DT, and should be required by the bindings.
> >>
> >> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
> >> bindings")
> >> Signed-off-by: Marijn Suijten
> >> ---
> > Ideally, you'd stick it at the bottom of the list, as the items: order
> > is part of the ABI
>
> Yes, please add them to the end. Order is fixed.
Disagreed for bindings that declare clock-names and when the driver
adheres to it, see my reply to Konrad's message.
- Marijn
Re: [PATCH 03/15] dt-bindings: clock: qcom,dispcc-sm6125: Require GCC PLL0 DIV clock
On 2023-06-24 03:45:02, Konrad Dybcio wrote:
> On 24.06.2023 02:41, Marijn Suijten wrote:
> > The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> > be passed from DT, and should be required by the bindings.
> >
> > Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
> > bindings")
> > Signed-off-by: Marijn Suijten
> > ---
> Ideally, you'd stick it at the bottom of the list, as the items: order
> is part of the ABI
This isn't an ABI break, as this driver nor its bindings require/declare
a fixed order: they declare a relation between clocks and clock-names.
This orders the GCC clock just like other dispccs. And the previous
patch dropped the unused cfg_ahb_clk from the bindings, so all bets are
off anyway.
- Marijn
>
> Konrad
> > Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
> > b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
> > index 2acf487d8a2f..11ec154503a3 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
> > @@ -23,6 +23,7 @@ properties:
> >clocks:
> > items:
> >- description: Board XO source
> > + - description: GPLL0 div source from GCC
> >- description: Byte clock from DSI PHY0
> >- description: Pixel clock from DSI PHY0
> >- description: Pixel clock from DSI PHY1
> > @@ -32,6 +33,7 @@ properties:
> >clock-names:
> > items:
> >- const: bi_tcxo
> > + - const: gcc_disp_gpll0_div_clk_src
> >- const: dsi0_phy_pll_out_byteclk
> >- const: dsi0_phy_pll_out_dsiclk
> >- const: dsi1_phy_pll_out_dsiclk
> > @@ -65,12 +67,14 @@ examples:
> >compatible = "qcom,sm6125-dispcc";
> >reg = <0x5f0 0x2>;
> >clocks = < RPM_SMD_XO_CLK_SRC>,
> > + < GCC_DISP_GPLL0_DIV_CLK_SRC>,
> > <_phy 0>,
> > <_phy 1>,
> > <_phy 1>,
> > <_phy 0>,
> > <_phy 1>;
> >clock-names = "bi_tcxo",
> > +"gcc_disp_gpll0_div_clk_src",
> > "dsi0_phy_pll_out_byteclk",
> > "dsi0_phy_pll_out_dsiclk",
> > "dsi1_phy_pll_out_dsiclk",
> >
Re: [PATCH 02/15] dt-bindings: clock: qcom,dispcc-sm6125: Remove unused GCC_DISP_AHB_CLK
On 2023-06-24 11:08:30, Krzysztof Kozlowski wrote:
> On 24/06/2023 02:41, Marijn Suijten wrote:
> > The downsteam driver for dispcc only ever gets and puts this clock
> > without ever using it in the clocktree; this unnecessary workaround was
> > never ported to mainline, hence the driver doesn't consume this clock
> > and shouldn't be required by the bindings.
> >
> > Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock
> > bindings")
> > Signed-off-by: Marijn Suijten
> > ---
>
> In perfect would we would like to know whether hardware needs this clock
> enabled/controlled, not whether some driver needs it. I understand
> though that with lack of proper docs we rely on drivers, so:
It might only use this to figure out if those clocks have already probed
or are available. The logic goes as follows:
clk = devm_clk_get(>dev, "cfg_ahb_clk");
if (IS_ERR(clk)) {
if (PTR_ERR(clk) != -EPROBE_DEFER)
dev_err(>dev, "Unable to get ahb clock handle\n");
return PTR_ERR(clk);
}
devm_clk_put(>dev, clk);
Nothing else uses/parents cfg_ahb_clk. Maybe with clk_ignore_unused or
similar, it gets turned on but never off again?
Indeed, a lack of documentation and comment from the manufacturer makes
it impossible to know, and ignoring it (as the driver already does)
works just fine.
> Reviewed-by: Krzysztof Kozlowski
Thanks!
- Marijn
>
> Best regards,
> Krzysztof
>
Re: [PATCH 15/15] arm64: dts: qcom: sm6125-seine: Configure MDSS, DSI and panel
On 2023-06-24 04:06:04, Konrad Dybcio wrote:
> > + sde_dsi_sleep: sde-dsi-sleep-state {
> > + pins = "gpio90";
> > + function = "gpio";
> > + drive-strength = <2>;
> > + bias-pull-down;
> > + };
> s/sde/mdss as per Dmitry's recent request
Makes sense, SDE doesn't mean anything on mainline.
- Marijn
Re: [PATCH 14/15] arm64: dts: qcom: sm6125: Add display hardware nodes
On 2023-06-24 04:05:07, Konrad Dybcio wrote:
> On 24.06.2023 02:41, Marijn Suijten wrote:
> > Add the DT nodes that describe the MDSS hardware on SM6125, containing
> > one MDP (display controller) together with a single DSI and DSI PHY. No
> > DisplayPort support is added for now.
> >
> > Signed-off-by: Marijn Suijten
> > ---
> > arch/arm64/boot/dts/qcom/sm6125.dtsi | 190
> > ++-
> > 1 file changed, 186 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > index 7d78b4e48ebe..6852dacf54e6 100644
> > --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > @@ -1204,16 +1204,198 @@ sram@469 {
> > reg = <0x0469 0x1>;
> > };
> >
> > + mdss: display-subsystem@5e0 {
> > + compatible = "qcom,sm6125-mdss";
> > + reg = <0x05e0 0x1000>;
> > + reg-names = "mdss";
> > +
> > + power-domains = < MDSS_GDSC>;
> > +
> > + clocks = < GCC_DISP_AHB_CLK>,
> > +< DISP_CC_MDSS_AHB_CLK>,
> > +< DISP_CC_MDSS_MDP_CLK>;
> > + clock-names = "iface", "ahb", "core";
> One per line would be nice
Sure, it's all over the place elsewhere though.
> > +
> > + interrupts = ;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > +
> > + iommus = <_smmu 0x400 0x0>;
> > +
> Every node has a different scramble of property orders :P
>
> To roughly align with what I ask most people to do (and what I should
> work on codifying and automating ehhh) would be:
Exactly. Until this automated - or even documented - there is barely
any point to manually deal with this.
> [compat]
> [reg]
>
> [interrupt]
Also interrupt-cells here, since that's only related to
interrupt-controller; and not interrupts=<>;?
>
> [clock]
>
> [reset]
> (btw there should be a MDSS_CORE reset at DISP_CC+0x2000, try writing 1 there
> and see if MDSS dies)
>
> [opp]
> [pd]
>
> [iommus]
> [icc]
>
> [phy]
>
> [addresssizeranges]
>
> [status]
Sure, have reordered them like this for v2.
>
> > + status = "disabled";
> > +
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + mdss_mdp: display-controller@5e01000 {
> > + compatible = "qcom,sm6125-dpu";
> > + reg = <0x05e01000 0x83208>,
> > + <0x05eb 0x2008>;
> > + reg-names = "mdp", "vbif";
> > +
> > + clocks = < GCC_DISP_HF_AXI_CLK>,
> > +< DISP_CC_MDSS_AHB_CLK>,
> > +< DISP_CC_MDSS_ROT_CLK>,
> > +< DISP_CC_MDSS_MDP_LUT_CLK>,
> > +< DISP_CC_MDSS_MDP_CLK>,
> > +< DISP_CC_MDSS_VSYNC_CLK>;
> > + clock-names = "bus",
> > + "iface",
> > + "rot",
> > + "lut",
> > + "core",
> > + "vsync";
> > + assigned-clocks = <
> > DISP_CC_MDSS_VSYNC_CLK>;
> > + assigned-clock-rates = <1920>;
> > +
> > + operating-points-v2 = <_opp_table>;
> > + power-domains = < SM6125_VDDCX>;
> > +
> > + interrupt-parent = <>;
> > + interrupts = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + dpu_intf1_out: endpoint {
> > + remote-endpoint =
> > <_dsi0_in>;
> > + };
> > + };
> > + };
> > +
> > + mdp_opp_table: opp-table {
> > + compatible = "operating-points-v2";
> > +
> > + opp-19200 {
> > + opp-hz = /bits/ 64 <19200>;
> > + required-opps =
> > <_opp_low_svs>;
> > + };
> > +
> > + opp-25600 {
> > +
Re: [PATCH 00/15] drm/msm: Add SM6125 MDSS/DPU hardware and enable Sony Xperia 10 II panel
On 2023-06-24 03:42:46, Konrad Dybcio wrote:
> On 24.06.2023 02:40, Marijn Suijten wrote:
> > Bring up the SM6125 DPU now that all preliminary series (such as INTF
> > TE) have been merged (for me to test the hardware properly)
> We should not repeat the same mistake in the future.. Finding a
> balance between releasing early and releasing what we can declare
> working and tested code is hard, but we wy overstayed on
> this one..
I don't understand what you mean by "mistake" at all. Yes the DPU
catalog portion of this series sat in my local branch for a very long
time. Yes it had to be rebased on top of conflicts many many times.
However, that time has also been used to fix and extend DPU where
necessary, instead of submitting a half-broken or half-incomplete
catalog entry...
Re "we overstayed": you could have asked to clean up and send my patch,
so I don't take this as a mistake on my part as you are completely aware
of my time schedule ;)
> Konrad
> , and most
Also here, don't forget to re-quote my message if you break half-way in
the line.
> > other conflicting work (barring ongoing catalog *improvements*) has made
> > its way in as well or is still being discussed.
>
> >
> > The second part of the series complements that by immediately utilizing
> > this hardware in DT, and even enabling the MDSS/DSI nodes complete with
> > a 6.0" 1080x2520 panel for Sony's Seine PDX201 (Xperia 10 II).
> >
> > The last patch ("sm6125-seine: Configure MDSS, DSI and panel") depends
> > on (an impending v2 of) my Sony panel collection series [1].
> >
> > [1]:
> > https://lore.kernel.org/linux-arm-msm/20230521-drm-panels-sony-v1-0-541c341d6...@somainline.org/
> >
> > ---
> > Marijn Suijten (15):
> > arm64: dts: qcom: sm6125: Sort spmi_bus node numerically by reg
> > dt-bindings: clock: qcom,dispcc-sm6125: Remove unused GCC_DISP_AHB_CLK
> > dt-bindings: clock: qcom,dispcc-sm6125: Require GCC PLL0 DIV clock
> > dt-bindings: clock: qcom,dispcc-sm6125: Allow power-domains property
> > dt-bindings: display/msm: dsi-controller-main: Document SM6125
> > dt-bindings: display/msm: sc7180-dpu: Describe SM6125
> > dt-bindings: display/msm: Add SM6125 MDSS
> > drm/msm/dpu: Add SM6125 support
> > drm/msm/mdss: Add SM6125 support
> > dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant
> > drm/msm/dsi: Add 14nm phy configuration for SM6125
> > arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock
> > arm64: dts: qcom: sm6125: Add dispcc node
> > arm64: dts: qcom: sm6125: Add display hardware nodes
> > arm64: dts: qcom: sm6125-seine: Configure MDSS, DSI and panel
> >
> > .../bindings/clock/qcom,dispcc-sm6125.yaml | 17 +-
> > .../bindings/display/msm/dsi-controller-main.yaml | 2 +
> > .../bindings/display/msm/dsi-phy-14nm.yaml | 1 +
> > .../bindings/display/msm/qcom,sc7180-dpu.yaml | 1 +
> > .../bindings/display/msm/qcom,sm6125-mdss.yaml | 206 +
> > .../dts/qcom/sm6125-sony-xperia-seine-pdx201.dts | 59 +
> > arch/arm64/boot/dts/qcom/sm6125.dtsi | 244
> > +++--
> > .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 173 +++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 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 | 15 ++
> > drivers/gpu/drm/msm/msm_mdss.c | 8 +
> > 15 files changed, 712 insertions(+), 25 deletions(-)
> > ---
> > base-commit: 8d2be868b42c08290509c60515865f4de24ea704
> > change-id: 20230624-sm6125-dpu-aedc9637ee7b
> >
> > Best regards,
Re: [PATCH 01/15] arm64: dts: qcom: sm6125: Sort spmi_bus node numerically by reg
On 2023-06-24 03:43:21, Konrad Dybcio wrote:
> On 24.06.2023 02:40, Marijn Suijten wrote:
> > This node has always resided in the wrong spot, making it somewhat
> > harder to contribute new node entries while maintaining proper sorting
> > around it. Move the node up to sit after hsusb_phy1 where it maintains
> > proper numerial
> numerical
Thanks.
> sorting on the (first of its many) reg address property.
Why was this continuation of the line not re-quoted? Makes your reply
super-hard to read.
- Marijn
> >
> > Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125")
> > Signed-off-by: Marijn Suijten
> > ---
> Reviewed-by: Konrad Dybcio
>
> Konrad
> > arch/arm64/boot/dts/qcom/sm6125.dtsi | 38
> > ++--
> > 1 file changed, 19 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > index a596baa6ce3e..722dde560bec 100644
> > --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > @@ -679,6 +679,24 @@ hsusb_phy1: phy@1613000 {
> > status = "disabled";
> > };
> >
> > + spmi_bus: spmi@1c4 {
> > + compatible = "qcom,spmi-pmic-arb";
> > + reg = <0x01c4 0x1100>,
> > + <0x01e0 0x200>,
> > + <0x03e0 0x10>,
> > + <0x03f0 0xa>,
> > + <0x01c0a000 0x26000>;
> > + reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
> > + interrupt-names = "periph_irq";
> > + interrupts = ;
> > + qcom,ee = <0>;
> > + qcom,channel = <0>;
> > + #address-cells = <2>;
> > + #size-cells = <0>;
> > + interrupt-controller;
> > + #interrupt-cells = <4>;
> > + };
> > +
> > rpm_msg_ram: sram@45f {
> > compatible = "qcom,rpm-msg-ram";
> > reg = <0x045f 0x7000>;
> > @@ -1184,27 +1202,9 @@ sram@469 {
> > reg = <0x0469 0x1>;
> > };
> >
> > - spmi_bus: spmi@1c4 {
> > - compatible = "qcom,spmi-pmic-arb";
> > - reg = <0x01c4 0x1100>,
> > - <0x01e0 0x200>,
> > - <0x03e0 0x10>,
> > - <0x03f0 0xa>,
> > - <0x01c0a000 0x26000>;
> > - reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
> > - interrupt-names = "periph_irq";
> > - interrupts = ;
> > - qcom,ee = <0>;
> > - qcom,channel = <0>;
> > - #address-cells = <2>;
> > - #size-cells = <0>;
> > - interrupt-controller;
> > - #interrupt-cells = <4>;
> > - };
> > -
> > apps_smmu: iommu@c60 {
> > compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500",
> > "arm,mmu-500";
> > - reg = <0xc60 0x8>;
> > + reg = <0x0c60 0x8>;
> > interrupts = ,
> > ,
> > ,
> >
Re: [PATCH v2 2/6] drm/i915/gt: Clear all bits from GEN12_FF_MODE2
On Sat, Jun 24, 2023 at 10:17:53AM -0700, Lucas De Marchi wrote:
> Right now context workarounds don't do a rmw and instead only write to
> the register. Since 2 separate programmings to the same register are
> coalesced into a single write, this is not problematic for
> GEN12_FF_MODE2 since both TDS and GS timer are going to be written
> together and the other remaining bits be zeroed.
>
> However in order to fix other workarounds that may want to preserve the
> unrelated bits in the same register, context workarounds need to
> be changed to a rmw. To prepare for that, move the programming of
> GEN12_FF_MODE2 to a single place so the value passed for "clear" can
> be all the bits. Otherwise the second workaround would be dropped as
> it'd be detected as overwriting a previously programmed workaround.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 51 +++--
> 1 file changed, 17 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 8f8346df3c18..7d48bd57b6ef 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -693,40 +693,11 @@ static void dg2_ctx_gt_tuning_init(struct
> intel_engine_cs *engine,
> 0, false);
> }
>
> -/*
> - * These settings aren't actually workarounds, but general tuning settings
> that
> - * need to be programmed on several platforms.
> - */
> -static void gen12_ctx_gt_tuning_init(struct intel_engine_cs *engine,
> - struct i915_wa_list *wal)
> -{
> - /*
> - * Although some platforms refer to it as Wa_1604555607, we need to
> - * program it even on those that don't explicitly list that
> - * workaround.
> - *
> - * Note that the programming of this register is further modified
> - * according to the FF_MODE2 guidance given by Wa_1608008084:gen12.
> - * Wa_1608008084 tells us the FF_MODE2 register will return the wrong
> - * value when read. The default value for this register is zero for all
> - * fields and there are no bit masks. So instead of doing a RMW we
> - * should just write TDS timer value. For the same reason read
> - * verification is ignored.
> - */
> - wa_add(wal,
> -GEN12_FF_MODE2,
> -FF_MODE2_TDS_TIMER_MASK,
> -FF_MODE2_TDS_TIMER_128,
> -0, false);
> -}
> -
> static void gen12_ctx_workarounds_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = engine->i915;
>
> - gen12_ctx_gt_tuning_init(engine, wal);
> -
> /*
>* Wa_1409142259:tgl,dg1,adl-p
>* Wa_1409347922:tgl,dg1,adl-p
> @@ -748,15 +719,27 @@ static void gen12_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
>
> /*
> - * Wa_16011163337
> + * Wa_16011163337 - GS_TIMER
> + *
> + * TDS_TIMER: Although some platforms refer to it as Wa_1604555607, we
> + * need to program it even on those that don't explicitly list that
> + * workaround.
> + *
> + * Note that the programming of GEN12_FF_MODE2 is further modified
> + * according to the FF_MODE2 guidance given by Wa_1608008084.
> + * Wa_1608008084 tells us the FF_MODE2 register will return the wrong
> + * value when read from the CPU.
>*
> - * Like in gen12_ctx_gt_tuning_init(), read verification is ignored due
> - * to Wa_1608008084.
> + * The default value for this register is zero for all fields.
> + * So instead of doing a RMW we should just write the desired values
> + * for TDS and GS timers. Note that since the readback can't be trusted,
> + * the clear mask is just set to ~0 to make sure other bits are not
> + * inadvertently set. For the same reason read verification is ignored.
>*/
> wa_add(wal,
> GEN12_FF_MODE2,
> -FF_MODE2_GS_TIMER_MASK,
> -FF_MODE2_GS_TIMER_224,
> +~0,
> +FF_MODE2_TDS_TIMER_128 | FF_MODE2_GS_TIMER_224,
> 0, false);
>
> if (!IS_DG1(i915)) {
> --
> 2.40.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2 4/6] drm/vkms: Add ConfigFS scaffolding to VKMS
Hi Jim, On 6/23/23 19:23, Jim Shargo wrote: This change adds the basic scaffolding for ConfigFS, including setting up the default directories. It does not allow for the registration of configfs-backed devices, which is complex and provided in a follow-up commit. This CL includes docs about using ConfigFS with VKMS, but I'll summarize in brief here as well (assuming ConfigFS is mounted at /config/): To create a new device, you can do so via `mkdir /config/vkms/my-device`. This will create a number of directories and files automatically: /config `-- vkms `-- my-device |-- connectors |-- crtcs |-- encoders |-- planes `-- enabled You can then configure objects by mkdir'ing in each of the directories. When you're satisfied, you can `echo 1 > /config/vkms/my-device/enabled`. This will create a new device according to your configuration. For now, this will fail, but the next change will add support for it. Signed-off-by: Jim Shargo --- Documentation/gpu/vkms.rst | 17 +- drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/vkms/Makefile| 1 + drivers/gpu/drm/vkms/vkms_configfs.c | 646 +++ drivers/gpu/drm/vkms/vkms_drv.c | 52 ++- drivers/gpu/drm/vkms/vkms_drv.h | 92 +++- drivers/gpu/drm/vkms/vkms_output.c | 5 + 7 files changed, 799 insertions(+), 15 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index ba04ac7c2167..2c342ef0fb7b 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -51,6 +51,12 @@ To disable the driver, use :: sudo modprobe -r vkms +Configuration With ConfigFS +=== + +.. kernel-doc:: drivers/gpu/drm/vkms/vkms_configfs.c + :doc: ConfigFS Support for VKMS + Testing With IGT @@ -135,22 +141,15 @@ project. Runtime Configuration - -We want to be able to reconfigure vkms instance without having to reload the -module. Use/Test-cases: +We want to vkms instances without having to reload the module. Such I believe that there is a verb missing here. +configuration can be added as extensions to vkms's ConfigFS support. Use-cases: - Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of compositors). -- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of - them first). - - Change output configuration: Plug/unplug screens, change EDID, allow changing the refresh rate. -The currently proposed solution is to expose vkms configuration through -configfs. All existing module options should be supported through configfs -too. - Writeback support - diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index afb3b2f5f425..71eb913b378f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -262,6 +262,7 @@ config DRM_VKMS depends on DRM && MMU select DRM_KMS_HELPER select DRM_GEM_SHMEM_HELPER + select CONFIGFS_FS select CRC32 default n help diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile index 1b28a6a32948..6b83907ad554 100644 --- a/drivers/gpu/drm/vkms/Makefile +++ b/drivers/gpu/drm/vkms/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only vkms-y := \ + vkms_configfs.o \ vkms_drv.o \ vkms_plane.o \ vkms_output.o \ diff --git a/drivers/gpu/drm/vkms/vkms_configfs.c b/drivers/gpu/drm/vkms/vkms_configfs.c new file mode 100644 index ..544024735d19 --- /dev/null +++ b/drivers/gpu/drm/vkms/vkms_configfs.c @@ -0,0 +1,646 @@ +// SPDX-License-Identifier: GPL-2.0+ + +#include +#include +#include + +#include +#include + +#include "vkms_drv.h" + +/** + * DOC: ConfigFS Support for VKMS + * + * VKMS is instrumented with support for configuration via :doc:`ConfigFS + * <../filesystems/configfs>`. + * + * With VKMS installed, you can mount ConfigFS at ``/config/`` like so:: + * + * mkdir -p /config/ + * sudo mount -t configfs none /config + * + * This allows you to configure multiple virtual devices in addition to an + * immutable "default" device created by the driver at initialization time. Note + * that the default device is immutable because we cannot pre-populate ConfigFS + * directories with normal files. + * + * To set up a new device, create a new directory under the VKMS configfs + * directory:: + * + * mkdir /config/vkms/test + * + * With your device created you'll find an new directory ready to be + * configured:: + * + * /config + * `-- vkms + * |-- default + * | `-- enabled + * `-- test + * |-- connectors + * |-- crtcs + * |-- encoders + * |-- planes + * `-- enabled I
Re: [PATCH v2 6/6] drm/vkms: Add a module param to enable/disable the default device
Hi Jim,
On 6/23/23 19:23, Jim Shargo wrote:
In many testing circumstances, we will want to just create a new device
and test against that. If we create a default device, it can be annoying
to have to manually select the new device instead of choosing the only
one that exists.
The param, enable_default, is defaulted to true to maintain backwards
compatibility.
Signed-off-by: Jim Shargo
---
drivers/gpu/drm/vkms/vkms_drv.c | 44 ++---
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 314a04659c5f..1cb56c090a65 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -42,17 +42,26 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
+static bool enable_default_device = true;
+module_param_named(enable_default_device, enable_default_device, bool, 0444);
+MODULE_PARM_DESC(enable_default_device,
+"Enable/Disable creating the default device");
Wouldn't be better to just call it "enable_default"?
Also, could you add this parameter to vkms_config debugfs file?
Best Regards,
- Maíra
+
static bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
-MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
+MODULE_PARM_DESC(enable_cursor,
+"Enable/Disable cursor support for the default device");
static bool enable_writeback = true;
module_param_named(enable_writeback, enable_writeback, bool, 0444);
-MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector
support");
+MODULE_PARM_DESC(
+ enable_writeback,
+ "Enable/Disable writeback connector support for the default device");
static bool enable_overlay;
module_param_named(enable_overlay, enable_overlay, bool, 0444);
-MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
+MODULE_PARM_DESC(enable_overlay,
+"Enable/Disable overlay support for the default device");
DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
@@ -278,10 +287,7 @@ void vkms_remove_device(struct vkms_device *vkms_device)
static int __init vkms_init(void)
{
int ret;
- struct platform_device *pdev;
- struct vkms_device_setup vkms_device_setup = {
- .configfs = NULL,
- };
+ struct platform_device *default_pdev = NULL;
ret = platform_driver_register(_platform_driver);
if (ret) {
@@ -289,19 +295,27 @@ static int __init vkms_init(void)
return ret;
}
- pdev = platform_device_register_data(NULL, DRIVER_NAME, 0,
-_device_setup,
-sizeof(vkms_device_setup));
- if (IS_ERR(pdev)) {
- DRM_ERROR("Unable to register default vkms device\n");
- platform_driver_unregister(_platform_driver);
- return PTR_ERR(pdev);
+ if (enable_default_device) {
+ struct vkms_device_setup vkms_device_setup = {
+ .configfs = NULL,
+ };
+
+ default_pdev = platform_device_register_data(
+ NULL, DRIVER_NAME, 0, _device_setup,
+ sizeof(vkms_device_setup));
+ if (IS_ERR(default_pdev)) {
+ DRM_ERROR("Unable to register default vkms device\n");
+ platform_driver_unregister(_platform_driver);
+ return PTR_ERR(default_pdev);
+ }
}
ret = vkms_init_configfs();
if (ret) {
DRM_ERROR("Unable to initialize configfs\n");
- platform_device_unregister(pdev);
+ if (default_pdev)
+ platform_device_unregister(default_pdev);
+
platform_driver_unregister(_platform_driver);
}
Re: [PATCH v2 2/6] drm/vkms: Support multiple DRM objects (crtcs, etc.) per VKMS device
Hi Jim,
On 6/23/23 19:23, Jim Shargo wrote:
This change supports multiple CRTCs, encoders, connectors instead of one
of each per device.
Since ConfigFS-based devices will support multiple crtcs, it's useful to
move all of the writeback/composition data from being per-"output" to
being per-CRTC.
Since there's still only ever one CRTC, this should be a no-op refactor.
Signed-off-by: Jim Shargo
---
drivers/gpu/drm/vkms/vkms_composer.c | 28 +++---
drivers/gpu/drm/vkms/vkms_crtc.c | 95 +++-
drivers/gpu/drm/vkms/vkms_drv.c | 14 +--
drivers/gpu/drm/vkms/vkms_drv.h | 65 +-
drivers/gpu/drm/vkms/vkms_output.c| 123 ++
drivers/gpu/drm/vkms/vkms_plane.c | 44 ++---
drivers/gpu/drm/vkms/vkms_writeback.c | 26 +++---
7 files changed, 252 insertions(+), 143 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 1636ce3a79f9..75fa42e0ec07 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -230,13 +230,13 @@ void vkms_composer_worker(struct work_struct *work)
composer_work);
struct drm_crtc *crtc = crtc_state->base.crtc;
struct vkms_writeback_job *active_wb = crtc_state->active_writeback;
- struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
+ struct vkms_crtc *vkms_crtc = drm_crtc_to_vkms_crtc(crtc);
bool crc_pending, wb_pending;
u64 frame_start, frame_end;
u32 crc32 = 0;
int ret;
- spin_lock_irq(>composer_lock);
+ spin_lock_irq(_crtc->composer_lock);
frame_start = crtc_state->frame_start;
frame_end = crtc_state->frame_end;
crc_pending = crtc_state->crc_pending;
@@ -244,7 +244,7 @@ void vkms_composer_worker(struct work_struct *work)
crtc_state->frame_start = 0;
crtc_state->frame_end = 0;
crtc_state->crc_pending = false;
- spin_unlock_irq(>composer_lock);
+ spin_unlock_irq(_crtc->composer_lock);
/*
* We raced with the vblank hrtimer and previous work already computed
@@ -262,10 +262,10 @@ void vkms_composer_worker(struct work_struct *work)
return;
if (wb_pending) {
- drm_writeback_signal_completion(>wb_connector, 0);
- spin_lock_irq(>composer_lock);
+ drm_writeback_signal_completion(_crtc->wb_connector, 0);
+ spin_lock_irq(_crtc->composer_lock);
crtc_state->wb_pending = false;
- spin_unlock_irq(>composer_lock);
+ spin_unlock_irq(_crtc->composer_lock);
}
/*
@@ -315,25 +315,25 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
char *src_name,
return 0;
}
-void vkms_set_composer(struct vkms_output *out, bool enabled)
+void vkms_set_composer(struct vkms_crtc *vkms_crtc, bool enabled)
{
bool old_enabled;
if (enabled)
- drm_crtc_vblank_get(>crtc);
+ drm_crtc_vblank_get(_crtc->base);
- spin_lock_irq(>lock);
- old_enabled = out->composer_enabled;
- out->composer_enabled = enabled;
- spin_unlock_irq(>lock);
+ spin_lock_irq(_crtc->lock);
+ old_enabled = vkms_crtc->composer_enabled;
+ vkms_crtc->composer_enabled = enabled;
+ spin_unlock_irq(_crtc->lock);
if (old_enabled)
- drm_crtc_vblank_put(>crtc);
+ drm_crtc_vblank_put(_crtc->base);
}
int vkms_set_crc_source(struct drm_crtc *crtc, const char *src_name)
{
- struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
+ struct vkms_crtc *out = drm_crtc_to_vkms_crtc(crtc);
bool enabled = false;
int ret = 0;
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 515f6772b866..d91e49c53adc 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -11,35 +11,34 @@
static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
{
- struct vkms_output *output = container_of(timer, struct vkms_output,
- vblank_hrtimer);
- struct drm_crtc *crtc = >crtc;
+ struct vkms_crtc *vkms_crtc = timer_to_vkms_crtc(timer);
+ struct drm_crtc *crtc = _crtc->base;
struct vkms_crtc_state *state;
u64 ret_overrun;
bool ret, fence_cookie;
fence_cookie = dma_fence_begin_signalling();
- ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
- output->period_ns);
+ ret_overrun = hrtimer_forward_now(_crtc->vblank_hrtimer,
+ vkms_crtc->period_ns);
if (ret_overrun != 1)
pr_warn("%s: vblank timer overrun\n", __func__);
- spin_lock(>lock);
+ spin_lock(_crtc->lock);
ret =
Re: [PATCH v2 1/6] drm/vkms: Back VKMS with DRM memory management instead of static objects
Hi Jim,
Thanks for working on this great feature for the VKMS!
On 6/23/23 19:23, Jim Shargo wrote:
This is a small refactor to make ConfigFS support easier. Once we
support ConfigFS, there can be multiple devices instantiated by the
driver, and so moving everything into managed memory makes things much
easier.
This should be a no-op refactor.
Signed-off-by: Jim Shargo
---
drivers/gpu/drm/vkms/vkms_drv.c| 130 +++--
drivers/gpu/drm/vkms/vkms_drv.h| 4 +-
drivers/gpu/drm/vkms/vkms_output.c | 6 +-
3 files changed, 72 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index e3c9c9571c8d..f07454fff046 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -9,10 +9,12 @@
* the GPU in DRM API tests.
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -37,8 +39,6 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static struct vkms_config *default_config;
-
static bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
@@ -92,13 +92,13 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state
*old_state)
static int vkms_config_show(struct seq_file *m, void *data)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *dev = entry->dev;
- struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
+ struct drm_info_node *drm_info = m->private;
The VKMS already moved to the new DRM debugfs interface, there is no
need to move back to the old interface. I believe you should keep
using struct drm_debugfs_entry.
Also, that's probably the reason why the vkms_config file is not being
properly updated:
[root@fedora ~]# modprobe vkms enable_overlay=1 enable_cursor=1
enable_writeback=1
[root@fedora ~]# cd /sys/kernel/debug/dri/0
[root@fedora 0]# cat vkms_config
writeback=0
cursor=0
overlay=0
+ struct vkms_device *vkms_device =
+ drm_device_to_vkms_device(drm_info->minor->dev);
- seq_printf(m, "writeback=%d\n", vkmsdev->config->writeback);
- seq_printf(m, "cursor=%d\n", vkmsdev->config->cursor);
- seq_printf(m, "overlay=%d\n", vkmsdev->config->overlay);
+ seq_printf(m, "writeback=%d\n", vkms_device->config.writeback);
+ seq_printf(m, "cursor=%d\n", vkms_device->config.cursor);
+ seq_printf(m, "overlay=%d\n", vkms_device->config.overlay);
return 0;
}
@@ -155,114 +155,120 @@ static int vkms_modeset_init(struct vkms_device
*vkmsdev)
return vkms_output_init(vkmsdev, 0);
}
-static int vkms_create(struct vkms_config *config)
+static int vkms_platform_probe(struct platform_device *pdev)
{
int ret;
- struct platform_device *pdev;
struct vkms_device *vkms_device;
+ void *grp;
- pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
- ret = -ENOMEM;
- goto out_unregister;
+ grp = devres_open_group(>dev, NULL, GFP_KERNEL);
+ if (!grp) {
+ return -ENOMEM;
}
vkms_device = devm_drm_dev_alloc(>dev, _driver,
struct vkms_device, drm);
if (IS_ERR(vkms_device)) {
ret = PTR_ERR(vkms_device);
- goto out_devres;
+ goto out_release_group;
}
+
vkms_device->platform = pdev;
- vkms_device->config = config;
- config->dev = vkms_device;
+ vkms_device->config.cursor = enable_cursor;
+ vkms_device->config.writeback = enable_writeback;
+ vkms_device->config.overlay = enable_overlay;
ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
DMA_BIT_MASK(64));
-
if (ret) {
DRM_ERROR("Could not initialize DMA support\n");
- goto out_devres;
+ goto out_release_group;
}
ret = drm_vblank_init(_device->drm, 1);
if (ret) {
DRM_ERROR("Failed to vblank\n");
- goto out_devres;
+ goto out_release_group;
}
ret = vkms_modeset_init(vkms_device);
- if (ret)
- goto out_devres;
+ if (ret) {
+ DRM_ERROR("Unable to initialize modesetting\n");
+ goto out_release_group;
+ }
drm_debugfs_add_files(_device->drm, vkms_config_debugfs_list,
ARRAY_SIZE(vkms_config_debugfs_list));
ret = drm_dev_register(_device->drm, 0);
- if (ret)
- goto out_devres;
+ if (ret) {
+ DRM_ERROR("Unable to register device\n");
+ return ret;
Shouldn't
Re: [PATCH 24/39] drm: renesas: shmobile: Unify plane allocation
On Sun, Jun 25, 2023 at 10:58:17AM +0200, Geert Uytterhoeven wrote: > On Fri, Jun 23, 2023 at 8:50 PM Laurent Pinchart wrote: > > On Fri, Jun 23, 2023 at 07:55:22PM +0200, Geert Uytterhoeven wrote: > > > On Fri, Jun 23, 2023 at 6:50 PM Laurent Pinchart wrote: > > > > On Thu, Jun 22, 2023 at 11:21:36AM +0200, Geert Uytterhoeven wrote: > > > > > Unify primary and overlay plane allocation: > > > > > - Enhance shmob_drm_plane_create() so it can be used to create the > > > > > primary plane, too, > > > > > - Move overlay plane creation next to primary plane creation. > > > > > > > > > > As overlay plane index zero now means the primary plane, this requires > > > > > shifting all overlay plane indices by one. > > > > > > > > Do you use index zero to identify the primary plane just for > > > > shmob_drm_plane_create(), or somewhere else too ? If it's just to create > > > > the plane, you could instead pass the plane type to the function. > > > > > > Index zero is just used for the creation. > > > I guess this sort of goes together with my question below... > > > > > > > > Signed-off-by: Geert Uytterhoeven > > > > > --- > > > > > Perhaps it would be better to not use dynamic allocation, but store > > > > > "struct drm_plane primary" and "struct shmob_drm_plane planes[5]" in > > > > > struct drm_shmob_device instead, like is done for the crtc and > > > > > encoder? > > > > > > ... as embedding separate primary and planes[] would also get rid of > > > the need to adjust the plane indices when converting from logical to > > > physical > > > overlay plane indices. > > > > Do they need to be embedded for that, or could you simple keep the index > > as it is ? > > If the plane type would be passed explicitly, they would not need to be > embedded for that. > > Then the question becomes: does it make sense to unify primary and > overlay plane handling? Good point. I don't mind much either way, it depends on how much code duplication it would remove I suppose. -- Regards, Laurent Pinchart
Re: [PATCH v6 3/3] drm/virtio: Support sync objects
Hi Dmitry,
On Sun, Jun 25, 2023 at 2:41 PM Dmitry Osipenko
wrote:
> On 6/25/23 11:47, Geert Uytterhoeven wrote:
> > On Sun, Apr 16, 2023 at 1:55 PM Dmitry Osipenko
> > wrote:
> >> Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
> >> support is needed by native context VirtIO-GPU Mesa drivers, it also will
> >> be used by Venus and Virgl contexts.
> >>
> >> Reviewed-by; Emil Velikov
> >> Signed-off-by: Dmitry Osipenko
> >
> > Thanks for your patch!
> >
> >> --- a/drivers/gpu/drm/virtio/virtgpu_submit.c
> >> +++ b/drivers/gpu/drm/virtio/virtgpu_submit.c
> >
> >> +static int
> >> +virtio_gpu_parse_deps(struct virtio_gpu_submit *submit)
> >> +{
> >> + struct drm_virtgpu_execbuffer *exbuf = submit->exbuf;
> >> + struct drm_virtgpu_execbuffer_syncobj syncobj_desc;
> >> + size_t syncobj_stride = exbuf->syncobj_stride;
> >> + u32 num_in_syncobjs = exbuf->num_in_syncobjs;
> >> + struct drm_syncobj **syncobjs;
> >> + int ret = 0, i;
> >> +
> >> + if (!num_in_syncobjs)
> >> + return 0;
> >> +
> >> + /*
> >> +* kvalloc at first tries to allocate memory using kmalloc and
> >> +* falls back to vmalloc only on failure. It also uses GFP_NOWARN
> >
> > GFP_NOWARN does not exist.
>
> https://elixir.bootlin.com/linux/v6.4-rc7/source/include/linux/gfp_types.h#L38
That line defines "__GFP_NOWARN", not "GFP_NOWARN".
C is case- and underscore-sensitive. as is "git grep -w" ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v3 1/3] drm/bridge: dw-hdmi: change YUV420 selection logic at clock setup
Right now clocking value selection code is prioritising RGB, YUV444 modes
over YUV420 for HDMI2 sinks. However, because of the bus format selection
procedure in dw-hdmi, for HDMI2 sinks YUV420 is the format that will always
be picked during the drm bridge chain check stage.
Later on dw_hdmi_setup will configure a colour space based on the bus
format that doesn't match the pixel value we had calculated as described
above.
Fix it by bringing back dw-hdmi bus format check when picking the right
pixel clock.
Signed-off-by: Adrián Larumbe
Acked-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++
drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++--
include/drm/bridge/dw_hdmi.h | 2 ++
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 3b40e0fdca5c..e6a456b72610 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3346,6 +3346,12 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+bool dw_hdmi_bus_fmt_is_420(struct dw_hdmi *hdmi)
+{
+ return hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_out_bus_format);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_bus_fmt_is_420);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 3d046878ce6c..b49bb0d86efe 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -379,8 +379,8 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
mode->clock > 34 ? 40 : 10);
if (drm_mode_is_420_only(display, mode) ||
- (!is_hdmi2_sink &&
-drm_mode_is_420_also(display, mode)))
+ (!is_hdmi2_sink && drm_mode_is_420_also(display, mode)) ||
+ dw_hdmi_bus_fmt_is_420(hdmi))
mode_is_420 = true;
/* Enable clocks */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index f668e75fbabe..6a46baa0737c 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -206,4 +206,6 @@ void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void
*data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+bool dw_hdmi_bus_fmt_is_420(struct dw_hdmi *hdmi);
+
#endif /* __IMX_HDMI_H__ */
--
2.40.0
[PATCH v3 3/3] drm/bridge: dw-hdmi: remove dead code and fix indentation
The hdmi_datamap enum is no longer in use. Also reindent enable_audio's
call params.
Signed-off-by: Adrián Larumbe
Acked-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 3a788316e2e5..69c0e80b8525 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -49,20 +49,6 @@
#define HDMI14_MAX_TMDSCLK 34000
-enum hdmi_datamap {
- RGB444_8B = 0x01,
- RGB444_10B = 0x03,
- RGB444_12B = 0x05,
- RGB444_16B = 0x07,
- YCbCr444_8B = 0x09,
- YCbCr444_10B = 0x0B,
- YCbCr444_12B = 0x0D,
- YCbCr444_16B = 0x0F,
- YCbCr422_8B = 0x16,
- YCbCr422_10B = 0x14,
- YCbCr422_12B = 0x12,
-};
-
static const u16 csc_coeff_default[3][4] = {
{ 0x2000, 0x, 0x, 0x },
{ 0x, 0x2000, 0x, 0x },
@@ -856,10 +842,10 @@ static void dw_hdmi_gp_audio_enable(struct dw_hdmi *hdmi)
if (pdata->enable_audio)
pdata->enable_audio(hdmi,
- hdmi->channels,
- hdmi->sample_width,
- hdmi->sample_rate,
- hdmi->sample_non_pcm);
+ hdmi->channels,
+ hdmi->sample_width,
+ hdmi->sample_rate,
+ hdmi->sample_non_pcm);
}
static void dw_hdmi_gp_audio_disable(struct dw_hdmi *hdmi)
--
2.40.0
[PATCH v3 2/3] drm/bridge: dw-hdmi: truly enforce 420-only formats when drm mode demands it
The current output bus format selection logic is enforcing YUV420 even
when the drm mode allows for other bus formats as well.
Fix it by adding check for 420-only drm modes.
Signed-off-by: Adrián Larumbe
Acked-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index e6a456b72610..3a788316e2e5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2710,9 +2710,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
/* Default 8bit fallback */
output_fmts[i++] = MEDIA_BUS_FMT_UYYVYY8_0_5X24;
- *num_output_fmts = i;
-
- return output_fmts;
+ if (drm_mode_is_420_only(info, mode)) {
+ *num_output_fmts = i;
+ return output_fmts;
+ }
}
/*
--
2.40.0
[PATCH v3 0/3] Add additional YUV420 bus format check for dw-meson's bridge enable
This is a belated follow-up on
https://lore.kernel.org/dri-devel/20220515204412.2733803-1-adrian.laru...@collabora.com
Commit e67f6037ae1be34b2b68 ("drm/meson: split out encoder from meson_dw_hdmi")
broke 4K display modes for me, and I discovered it was because the right
pixel clock wasn't being chosen in dw_hdmi_phy_init. I misinterpreted the
reason as a problem in figuring out whether we want to enforce YUV420 mode,
but it turned out to be a mismatch between what dw-meson code is doing and
the way the bus format is being picked by the dw-hdmi bus output format drm
helper.
I fixed it by bringing back dw-hdmi bus format check in dw-meson.
The second patch makes sure YUV420 bus format is the only one being
returned by dw-hdmi's output format bridge function when that's the only
drm mode allowed.
Changelog:
v3:
- Change commit message for all three commits to accurately
reflect the modified files' subsystem.
- Add v1's Acked-by tags from subsystem maintainer
v2:
- Add commit message to patch number 3 in the series
Adrián Larumbe (3):
drm/bridge: dw-hdmi: change YUV420 selection logic at clock setup
drm/bridge: dw-hdmi: truly enforce 420-only formats when drm mode
demands it
drm/bridge: dw-hdmi: remove dead code and fix indentation
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 35 +--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 +--
include/drm/bridge/dw_hdmi.h | 2 ++
3 files changed, 18 insertions(+), 23 deletions(-)
--
2.40.0
Re: [PATCH v6 3/3] drm/virtio: Support sync objects
On 6/25/23 11:47, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Sun, Apr 16, 2023 at 1:55 PM Dmitry Osipenko
> wrote:
>> Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
>> support is needed by native context VirtIO-GPU Mesa drivers, it also will
>> be used by Venus and Virgl contexts.
>>
>> Reviewed-by; Emil Velikov
>> Signed-off-by: Dmitry Osipenko
>
> Thanks for your patch!
>
>> --- a/drivers/gpu/drm/virtio/virtgpu_submit.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_submit.c
>
>> +static int
>> +virtio_gpu_parse_deps(struct virtio_gpu_submit *submit)
>> +{
>> + struct drm_virtgpu_execbuffer *exbuf = submit->exbuf;
>> + struct drm_virtgpu_execbuffer_syncobj syncobj_desc;
>> + size_t syncobj_stride = exbuf->syncobj_stride;
>> + u32 num_in_syncobjs = exbuf->num_in_syncobjs;
>> + struct drm_syncobj **syncobjs;
>> + int ret = 0, i;
>> +
>> + if (!num_in_syncobjs)
>> + return 0;
>> +
>> + /*
>> +* kvalloc at first tries to allocate memory using kmalloc and
>> +* falls back to vmalloc only on failure. It also uses GFP_NOWARN
>
> GFP_NOWARN does not exist.
https://elixir.bootlin.com/linux/v6.4-rc7/source/include/linux/gfp_types.h#L38
--
Best regards,
Dmitry
[PATCH v2 09/15] drm/msm/hdmi: simplify extp clock handling
With the extp being the only "power" clock left, remove the surrounding
loops and handle the extp clock directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 24 ---
drivers/gpu/drm/msm/hdmi/hdmi.h| 6 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 33 ++
3 files changed, 18 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 0fc3df43aa70..a2780aba6d3c 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -248,13 +248,11 @@ static const struct hdmi_platform_config
hdmi_tx_8960_config = {
};
static const char *pwr_reg_names_8x74[] = {"core-vdda", "core-vcc"};
-static const char *pwr_clk_names_8x74[] = {"extp"};
static const char *hpd_clk_names_8x74[] = {"iface", "core", "mdp_core",
"alt_iface"};
static unsigned long hpd_clk_freq_8x74[] = {0, 1920, 0, 0};
static const struct hdmi_platform_config hdmi_tx_8974_config = {
HDMI_CFG(pwr_reg, 8x74),
- HDMI_CFG(pwr_clk, 8x74),
HDMI_CFG(hpd_clk, 8x74),
.hpd_freq = hpd_clk_freq_8x74,
};
@@ -495,24 +493,10 @@ static int msm_hdmi_dev_probe(struct platform_device
*pdev)
hdmi->hpd_clks[i] = clk;
}
- hdmi->pwr_clks = devm_kcalloc(>dev,
- config->pwr_clk_cnt,
- sizeof(hdmi->pwr_clks[0]),
- GFP_KERNEL);
- if (!hdmi->pwr_clks)
- return -ENOMEM;
-
- for (i = 0; i < config->pwr_clk_cnt; i++) {
- struct clk *clk;
-
- clk = msm_clk_get(pdev, config->pwr_clk_names[i]);
- if (IS_ERR(clk))
- return dev_err_probe(dev, PTR_ERR(clk),
-"failed to get pwr clk: %s\n",
-config->pwr_clk_names[i]);
-
- hdmi->pwr_clks[i] = clk;
- }
+ hdmi->extp_clk = devm_clk_get_optional(>dev, "extp");
+ if (IS_ERR(hdmi->extp_clk))
+ return dev_err_probe(dev, PTR_ERR(hdmi->extp_clk),
+"failed to get extp clock\n");
hdmi->hpd_gpiod = devm_gpiod_get_optional(>dev, "hpd", GPIOD_IN);
/* This will catch e.g. -EPROBE_DEFER */
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index e8dbee50637f..2d405da63bd0 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -51,7 +51,7 @@ struct hdmi {
struct regulator_bulk_data *hpd_regs;
struct regulator_bulk_data *pwr_regs;
struct clk **hpd_clks;
- struct clk **pwr_clks;
+ struct clk *extp_clk;
struct gpio_desc *hpd_gpiod;
@@ -98,10 +98,6 @@ struct hdmi_platform_config {
const char **hpd_clk_names;
const long unsigned *hpd_freq;
int hpd_clk_cnt;
-
- /* clks that need to be on for screen pwr (ie pixel clk): */
- const char **pwr_clk_names;
- int pwr_clk_cnt;
};
struct hdmi_bridge {
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 9b1391d27ed3..62ce1455f974 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -25,7 +25,7 @@ static void msm_hdmi_power_on(struct drm_bridge *bridge)
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
const struct hdmi_platform_config *config = hdmi->config;
- int i, ret;
+ int ret;
pm_runtime_get_sync(>pdev->dev);
@@ -33,21 +33,15 @@ static void msm_hdmi_power_on(struct drm_bridge *bridge)
if (ret)
DRM_DEV_ERROR(dev->dev, "failed to enable pwr regulator: %d\n",
ret);
- if (config->pwr_clk_cnt > 0) {
+ if (hdmi->extp_clk) {
DBG("pixclock: %lu", hdmi->pixclock);
- ret = clk_set_rate(hdmi->pwr_clks[0], hdmi->pixclock);
- if (ret) {
- DRM_DEV_ERROR(dev->dev, "failed to set pixel clk: %s
(%d)\n",
- config->pwr_clk_names[0], ret);
- }
- }
+ ret = clk_set_rate(hdmi->extp_clk, hdmi->pixclock);
+ if (ret)
+ DRM_DEV_ERROR(dev->dev, "failed to set extp clk rate:
%d\n", ret);
- for (i = 0; i < config->pwr_clk_cnt; i++) {
- ret = clk_prepare_enable(hdmi->pwr_clks[i]);
- if (ret) {
- DRM_DEV_ERROR(dev->dev, "failed to enable pwr clk: %s
(%d)\n",
- config->pwr_clk_names[i], ret);
- }
+ ret = clk_prepare_enable(hdmi->extp_clk);
+ if (ret)
+ DRM_DEV_ERROR(dev->dev, "failed to enable
[PATCH v2 14/15] drm/msm/hdmi: switch to generic PHY subsystem
Change the MSM HDMI driver to use generic PHY subsystem. Moving PHY
drivers allows better code sharing with the rest of the PHY system.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 6 ---
drivers/gpu/drm/msm/hdmi/hdmi.c| 58 +++--
drivers/gpu/drm/msm/hdmi/hdmi.h| 72 +-
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 58 +
4 files changed, 45 insertions(+), 149 deletions(-)
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 8d02d8c33069..908c79702864 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -23,12 +23,6 @@ msm-$(CONFIG_DRM_MSM_HDMI) += \
hdmi/hdmi_bridge.o \
hdmi/hdmi_hpd.o \
hdmi/hdmi_i2c.o \
- hdmi/hdmi_phy.o \
- hdmi/hdmi_phy_8960.o \
- hdmi/hdmi_phy_8996.o \
- hdmi/hdmi_phy_8x60.o \
- hdmi/hdmi_phy_8x74.o \
- hdmi/hdmi_pll_8960.o \
msm-$(CONFIG_DRM_MSM_MDP4) += \
disp/mdp4/mdp4_crtc.o \
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index a2780aba6d3c..5c50ae57f107 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
@@ -72,44 +73,6 @@ static void msm_hdmi_destroy(struct hdmi *hdmi)
msm_hdmi_i2c_destroy(hdmi->i2c);
}
-static void msm_hdmi_put_phy(struct hdmi *hdmi)
-{
- if (hdmi->phy_dev) {
- put_device(hdmi->phy_dev);
- hdmi->phy = NULL;
- hdmi->phy_dev = NULL;
- }
-}
-
-static int msm_hdmi_get_phy(struct hdmi *hdmi)
-{
- struct platform_device *pdev = hdmi->pdev;
- struct platform_device *phy_pdev;
- struct device_node *phy_node;
-
- phy_node = of_parse_phandle(pdev->dev.of_node, "phys", 0);
- if (!phy_node) {
- DRM_DEV_ERROR(>dev, "cannot find phy device\n");
- return -ENXIO;
- }
-
- phy_pdev = of_find_device_by_node(phy_node);
- of_node_put(phy_node);
-
- if (!phy_pdev)
- return dev_err_probe(>dev, -EPROBE_DEFER, "phy driver is
not ready\n");
-
- hdmi->phy = platform_get_drvdata(phy_pdev);
- if (!hdmi->phy) {
- put_device(_pdev->dev);
- return dev_err_probe(>dev, -EPROBE_DEFER, "phy driver is
not ready\n");
- }
-
- hdmi->phy_dev = _pdev->dev;
-
- return 0;
-}
-
/* construct hdmi at bind/probe time, grab all the resources. If
* we are to EPROBE_DEFER we want to do it here, rather than later
* at modeset_init() time
@@ -510,37 +473,32 @@ static int msm_hdmi_dev_probe(struct platform_device
*pdev)
if (hdmi->hpd_gpiod)
gpiod_set_consumer_name(hdmi->hpd_gpiod, "HDMI_HPD");
- ret = msm_hdmi_get_phy(hdmi);
- if (ret) {
+ hdmi->phy = devm_phy_get(>dev, NULL);
+ if (IS_ERR(hdmi->phy)) {
DRM_DEV_ERROR(>dev, "failed to get phy\n");
- return ret;
+ return PTR_ERR(hdmi->phy);
}
ret = devm_pm_runtime_enable(>dev);
if (ret)
- goto err_put_phy;
+ goto err;
platform_set_drvdata(pdev, hdmi);
ret = component_add(>dev, _hdmi_ops);
if (ret)
- goto err_put_phy;
+ goto err;
return 0;
-err_put_phy:
- msm_hdmi_put_phy(hdmi);
+err:
return ret;
}
static int msm_hdmi_dev_remove(struct platform_device *pdev)
{
- struct hdmi *hdmi = dev_get_drvdata(>dev);
-
component_del(>dev, _hdmi_ops);
- msm_hdmi_put_phy(hdmi);
-
return 0;
}
@@ -565,12 +523,10 @@ static struct platform_driver msm_hdmi_driver = {
void __init msm_hdmi_register(void)
{
- msm_hdmi_phy_driver_register();
platform_driver_register(_hdmi_driver);
}
void __exit msm_hdmi_unregister(void)
{
platform_driver_unregister(_hdmi_driver);
- msm_hdmi_phy_driver_unregister();
}
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 46ae7ef9bc98..d68ac7aaf1f2 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -19,7 +19,6 @@
#include "msm_drv.h"
#include "hdmi.xml.h"
-struct hdmi_phy;
struct hdmi_platform_config;
struct hdmi_audio {
@@ -56,8 +55,7 @@ struct hdmi {
struct gpio_desc *hpd_gpiod;
- struct hdmi_phy *phy;
- struct device *phy_dev;
+ struct phy *phy;
struct i2c_adapter *i2c;
struct drm_connector *connector;
@@ -125,74 +123,6 @@ static inline u32 hdmi_qfprom_read(struct hdmi *hdmi, u32
reg)
return msm_readl(hdmi->qfprom_mmio + reg);
}
-/*
- * hdmi phy:
- */
-
-enum hdmi_phy_type {
- MSM_HDMI_PHY_8x60,
- MSM_HDMI_PHY_8960,
- MSM_HDMI_PHY_8x74,
- MSM_HDMI_PHY_8996,
- MSM_HDMI_PHY_MAX,
-};
-
-struct
[PATCH v2 12/15] drm/msm/hdmi: set infoframes on all pre_enable calls
In consequent modeset calls, the atomic_pre_enable() will be called
several times without calling atomic_post_disable() inbetween. Thus
iframes will not be updated for the next mode. Fix this by setting the
iframe outside of the !power_on check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index f9293f7d8f34..bb10b35194ff 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -141,10 +141,11 @@ static void msm_hdmi_bridge_atomic_pre_enable(struct
drm_bridge *bridge,
msm_hdmi_phy_resource_enable(phy);
msm_hdmi_power_on(bridge);
hdmi->power_on = true;
- if (hdmi->hdmi_mode) {
- msm_hdmi_config_avi_infoframe(hdmi);
- msm_hdmi_audio_update(hdmi);
- }
+ }
+
+ if (hdmi->hdmi_mode) {
+ msm_hdmi_config_avi_infoframe(hdmi);
+ msm_hdmi_audio_update(hdmi);
}
msm_hdmi_phy_powerup(phy, hdmi->pixclock);
--
2.39.2
[PATCH v2 13/15] drm/msm/hdmi: pair msm_hdmi_phy_powerup with msm_hdmi_phy_powerdown
In preparation to converting MSM HDMI driver to use PHY framework, which
requires phy_power_on() calls to be paired with phy_power_off(), add a
conditional call to msm_hdmi_phy_powerdown() before the call to
msm_hdmi_phy_powerup().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.h| 1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 2d405da63bd0..46ae7ef9bc98 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -42,6 +42,7 @@ struct hdmi {
/* video state: */
bool power_on;
+ bool phy_power_on;
unsigned long int pixclock;
void __iomem *mmio;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index bb10b35194ff..1bbd76e595af 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -148,7 +148,11 @@ static void msm_hdmi_bridge_atomic_pre_enable(struct
drm_bridge *bridge,
msm_hdmi_audio_update(hdmi);
}
+ if (hdmi->phy_power_on)
+ msm_hdmi_phy_powerdown(phy);
+
msm_hdmi_phy_powerup(phy, hdmi->pixclock);
+ hdmi->phy_power_on = true;
msm_hdmi_set_mode(hdmi, true);
@@ -170,6 +174,7 @@ static void msm_hdmi_bridge_atomic_post_disable(struct
drm_bridge *bridge,
msm_hdmi_set_mode(hdmi, false);
msm_hdmi_phy_powerdown(phy);
+ hdmi->phy_power_on = false;
if (hdmi->power_on) {
power_off(bridge);
--
2.39.2
[PATCH v2 06/15] phy: qualcomm: add MSM8974 HDMI PHY support
Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
Signed-off-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/Kconfig| 2 +-
drivers/phy/qualcomm/Makefile | 1 +
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 327
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 1 +
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 1 +
5 files changed, 331 insertions(+), 1 deletion(-)
create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 460ad8298f86..f6e48cc58bad 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -51,7 +51,7 @@ config PHY_QCOM_HDMI
select GENERIC_PHY
help
Enable this to support the Qualcomm HDMI PHY presend on 32-bit
platforms:
- MSM8260, MSM8660, MSM8960, APQ8060 and APQ8064.
+ MSM8260, MSM8660, MSM8960, MSM8974, APQ8060, APQ8064, APQ8074 and
APQ8084.
Note, this driver is not used on MSM899x platforms, which use
PHY_QCOM_QMP_HDMI instead.
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index 4c06498c709d..e331323b954b 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_QCOM_HDMI) += phy-qcom-hdmi.o
phy-qcom-hdmi-y := \
phy-qcom-hdmi-preqmp.o \
+ phy-qcom-hdmi-28hpm.o \
phy-qcom-hdmi-28lpm.o \
obj-$(CONFIG_PHY_QCOM_PCIE2) += phy-qcom-pcie2.o
diff --git a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
new file mode 100644
index ..d3bf67e743aa
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark
+ * Copyright (c) 2023, Linaro Ltd.
+ */
+
+#include
+#include
+
+#include "phy-qcom-hdmi-preqmp.h"
+#include "phy-qcom-uniphy.h"
+
+#define REG_HDMI_8x74_ANA_CFG0 0x
+#define REG_HDMI_8x74_ANA_CFG1 0x0004
+#define REG_HDMI_8x74_ANA_CFG2 0x0008
+#define REG_HDMI_8x74_ANA_CFG3 0x000c
+#define REG_HDMI_8x74_PD_CTRL0 0x0010
+#define REG_HDMI_8x74_PD_CTRL1 0x0014
+#define REG_HDMI_8x74_GLB_CFG 0x0018
+#define REG_HDMI_8x74_DCC_CFG0 0x001c
+#define REG_HDMI_8x74_DCC_CFG1 0x0020
+#define REG_HDMI_8x74_TXCAL_CFG0 0x0024
+#define REG_HDMI_8x74_TXCAL_CFG1 0x0028
+#define REG_HDMI_8x74_TXCAL_CFG2 0x002c
+#define REG_HDMI_8x74_TXCAL_CFG3 0x0030
+#define REG_HDMI_8x74_BIST_CFG0
0x0034
+#define REG_HDMI_8x74_BIST_PATN0 0x003c
+#define REG_HDMI_8x74_BIST_PATN1 0x0040
+#define REG_HDMI_8x74_BIST_PATN2 0x0044
+#define REG_HDMI_8x74_BIST_PATN3 0x0048
+#define REG_HDMI_8x74_STATUS 0x005c
+
+#define HDMI_8974_VCO_MAX_FREQ 18UL
+#define HDMI_8974_VCO_MIN_FREQ 6UL
+
+#define HDMI_8974_COMMON_DIV 5
+
+static void qcom_uniphy_setup(void __iomem *base, unsigned int ref_freq,
+ bool sdm_mode,
+ bool ref_freq_mult_2,
+ bool dither,
+ unsigned int refclk_div,
+ unsigned int vco_freq)
+{
+ unsigned int int_ref_freq = ref_freq * (ref_freq_mult_2 ? 2 : 1);
+ unsigned int div_in_freq = vco_freq / refclk_div;
+ unsigned int dc_offset = div_in_freq / int_ref_freq - 1;
+ unsigned int sdm_freq_seed;
+ unsigned int val;
+ unsigned int remain = div_in_freq - (dc_offset + 1) * int_ref_freq;
+ sdm_freq_seed = mult_frac(remain, 0x1, int_ref_freq);
+
+ val = (ref_freq_mult_2 ? BIT(0) : 0) |
+ ((refclk_div - 1) << 2);
+ writel(val, base + UNIPHY_PLL_REFCLK_CFG);
+
+ writel(sdm_mode ? 0 : 0x40 + dc_offset, base + UNIPHY_PLL_SDM_CFG0);
+
+ writel(dither ? 0x40 + dc_offset: 0, base + UNIPHY_PLL_SDM_CFG1);
+
+ writel(sdm_freq_seed & 0xff, base + UNIPHY_PLL_SDM_CFG2);
+
+ writel((sdm_freq_seed >> 8) & 0xff, base + UNIPHY_PLL_SDM_CFG3);
+
+ writel(sdm_freq_seed >> 16, base + UNIPHY_PLL_SDM_CFG4);
+
+ ref_freq = ref_freq * 5 / 1000;
+ writel(ref_freq & 0xff, base + UNIPHY_PLL_CAL_CFG8);
+
+ writel(ref_freq >> 8, base + UNIPHY_PLL_CAL_CFG9);
+
+ vco_freq
[PATCH v2 08/15] drm/msm/hdmi: move the alt_iface clock to the hpd list
According to the vendor kernel [1] , the alt_iface clock should be
enabled together with the rest of HPD clocks, to make HPD to work
properly.
[1]
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/commit/e07a5487e521e57f76083c0a6e2f995414ac6d03
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 3132105a2a43..0fc3df43aa70 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -248,9 +248,9 @@ static const struct hdmi_platform_config
hdmi_tx_8960_config = {
};
static const char *pwr_reg_names_8x74[] = {"core-vdda", "core-vcc"};
-static const char *pwr_clk_names_8x74[] = {"extp", "alt_iface"};
-static const char *hpd_clk_names_8x74[] = {"iface", "core", "mdp_core"};
-static unsigned long hpd_clk_freq_8x74[] = {0, 1920, 0};
+static const char *pwr_clk_names_8x74[] = {"extp"};
+static const char *hpd_clk_names_8x74[] = {"iface", "core", "mdp_core",
"alt_iface"};
+static unsigned long hpd_clk_freq_8x74[] = {0, 1920, 0, 0};
static const struct hdmi_platform_config hdmi_tx_8974_config = {
HDMI_CFG(pwr_reg, 8x74),
--
2.39.2
[PATCH v2 07/15] phy: qualcomm: add MSM8x60 HDMI PHY support
Add support for HDMI PHY on Qualcomm MSM8x60 / APQ8060 platforms.
Signed-off-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/Makefile | 1 +
drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c | 184
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 32 ++--
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 1 +
4 files changed, 204 insertions(+), 14 deletions(-)
create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index e331323b954b..a02f2b499d84 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -10,6 +10,7 @@ phy-qcom-hdmi-y := \
phy-qcom-hdmi-preqmp.o \
phy-qcom-hdmi-28hpm.o \
phy-qcom-hdmi-28lpm.o \
+ phy-qcom-hdmi-45nm.o \
obj-$(CONFIG_PHY_QCOM_PCIE2) += phy-qcom-pcie2.o
diff --git a/drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c
b/drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c
new file mode 100644
index ..31e1e9f2d037
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark
+ * Copyright (c) 2023, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "phy-qcom-hdmi-preqmp.h"
+
+#define REG_HDMI_8x60_PHY_REG0 0x
+#define HDMI_8x60_PHY_REG0_DESER_DEL_CTRL__MASK
0x001c
+
+#define REG_HDMI_8x60_PHY_REG1 0x0004
+#define HDMI_8x60_PHY_REG1_DTEST_MUX_SEL__MASK 0x00f0
+#define HDMI_8x60_PHY_REG1_OUTVOL_SWING_CTRL__MASK 0x000f
+
+#define REG_HDMI_8x60_PHY_REG2 0x0008
+#define HDMI_8x60_PHY_REG2_PD_DESER0x0001
+#define HDMI_8x60_PHY_REG2_PD_DRIVE_1 0x0002
+#define HDMI_8x60_PHY_REG2_PD_DRIVE_2 0x0004
+#define HDMI_8x60_PHY_REG2_PD_DRIVE_3 0x0008
+#define HDMI_8x60_PHY_REG2_PD_DRIVE_4 0x0010
+#define HDMI_8x60_PHY_REG2_PD_PLL 0x0020
+#define HDMI_8x60_PHY_REG2_PD_PWRGEN 0x0040
+#define HDMI_8x60_PHY_REG2_RCV_SENSE_EN
0x0080
+
+#define REG_HDMI_8x60_PHY_REG3 0x000c
+#define HDMI_8x60_PHY_REG3_PLL_ENABLE 0x0001
+
+#define REG_HDMI_8x60_PHY_REG4 0x0010
+
+#define REG_HDMI_8x60_PHY_REG5 0x0014
+
+#define REG_HDMI_8x60_PHY_REG6 0x0018
+
+#define REG_HDMI_8x60_PHY_REG7 0x001c
+
+#define REG_HDMI_8x60_PHY_REG8 0x0020
+
+#define REG_HDMI_8x60_PHY_REG9 0x0024
+
+#define REG_HDMI_8x60_PHY_REG10
0x0028
+
+#define REG_HDMI_8x60_PHY_REG11
0x002c
+
+#define REG_HDMI_8x60_PHY_REG12
0x0030
+#define HDMI_8x60_PHY_REG12_RETIMING_EN
0x0001
+#define HDMI_8x60_PHY_REG12_PLL_LOCK_DETECT_EN 0x0002
+#define HDMI_8x60_PHY_REG12_FORCE_LOCK 0x0010
+
+static int qcom_hdmi_msm8x60_phy_power_on(struct qcom_hdmi_preqmp_phy
*hdmi_phy)
+{
+ unsigned long pixclock = hdmi_phy->hdmi_opts.pixel_clk_rate;
+
+ /* De-serializer delay D/C for non-lbk mode: */
+ hdmi_phy_write(hdmi_phy, REG_HDMI_8x60_PHY_REG0,
+ FIELD_PREP(HDMI_8x60_PHY_REG0_DESER_DEL_CTRL__MASK, 3));
+
+ if (pixclock == 27000) {
+ /* video_format == HDMI_VFRMT_720x480p60_16_9 */
+ hdmi_phy_write(hdmi_phy, REG_HDMI_8x60_PHY_REG1,
+
FIELD_PREP(HDMI_8x60_PHY_REG1_DTEST_MUX_SEL__MASK, 5) |
+
FIELD_PREP(HDMI_8x60_PHY_REG1_OUTVOL_SWING_CTRL__MASK, 3));
+ } else {
+ hdmi_phy_write(hdmi_phy, REG_HDMI_8x60_PHY_REG1,
+
FIELD_PREP(HDMI_8x60_PHY_REG1_DTEST_MUX_SEL__MASK, 5) |
+
FIELD_PREP(HDMI_8x60_PHY_REG1_OUTVOL_SWING_CTRL__MASK, 4));
+ }
+
+ /* No matter what, start from the power down mode: */
+ hdmi_phy_write(hdmi_phy, REG_HDMI_8x60_PHY_REG2,
+ HDMI_8x60_PHY_REG2_PD_PWRGEN |
+ HDMI_8x60_PHY_REG2_PD_PLL |
+ HDMI_8x60_PHY_REG2_PD_DRIVE_4 |
+ HDMI_8x60_PHY_REG2_PD_DRIVE_3 |
+ HDMI_8x60_PHY_REG2_PD_DRIVE_2 |
+ HDMI_8x60_PHY_REG2_PD_DRIVE_1 |
+
[PATCH v2 11/15] drm/msm/hdmi: switch to atomic_pre_enable/post_disable
In preparation of reworking the HDMI mode setting, switch pre_enable and
post_disable callbacks to their atomic variants.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index fbcf4dd91cd9..f9293f7d8f34 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -128,7 +128,8 @@ static void msm_hdmi_config_avi_infoframe(struct hdmi *hdmi)
hdmi_write(hdmi, REG_HDMI_INFOFRAME_CTRL1, val);
}
-static void msm_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
@@ -154,7 +155,8 @@ static void msm_hdmi_bridge_pre_enable(struct drm_bridge
*bridge)
msm_hdmi_hdcp_on(hdmi->hdcp_ctrl);
}
-static void msm_hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
struct hdmi *hdmi = hdmi_bridge->hdmi;
@@ -291,8 +293,13 @@ static enum drm_mode_status
msm_hdmi_bridge_mode_valid(struct drm_bridge *bridge
}
static const struct drm_bridge_funcs msm_hdmi_bridge_funcs = {
- .pre_enable = msm_hdmi_bridge_pre_enable,
- .post_disable = msm_hdmi_bridge_post_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+
+ .atomic_pre_enable = msm_hdmi_bridge_atomic_pre_enable,
+ .atomic_post_disable = msm_hdmi_bridge_atomic_post_disable,
+
.mode_set = msm_hdmi_bridge_mode_set,
.mode_valid = msm_hdmi_bridge_mode_valid,
.get_edid = msm_hdmi_bridge_get_edid,
--
2.39.2
[PATCH v2 15/15] drm/msm/hdmi: drop old HDMI PHY code
Drop source files used by old HDMI PHY and HDMI PLL drivers.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 217 ---
drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 51 --
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 765 ---
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 141 -
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 44 --
drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c | 458 --
6 files changed, 1676 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy.c
delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c
delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c
delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
deleted file mode 100644
index 9780107e1cc9..
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
+++ /dev/null
@@ -1,217 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2016, The Linux Foundation. All rights reserved.
- */
-
-#include
-
-#include "hdmi.h"
-
-static int msm_hdmi_phy_resource_init(struct hdmi_phy *phy)
-{
- struct hdmi_phy_cfg *cfg = phy->cfg;
- struct device *dev = >pdev->dev;
- int i, ret;
-
- phy->regs = devm_kcalloc(dev, cfg->num_regs, sizeof(phy->regs[0]),
-GFP_KERNEL);
- if (!phy->regs)
- return -ENOMEM;
-
- phy->clks = devm_kcalloc(dev, cfg->num_clks, sizeof(phy->clks[0]),
-GFP_KERNEL);
- if (!phy->clks)
- return -ENOMEM;
-
- for (i = 0; i < cfg->num_regs; i++)
- phy->regs[i].supply = cfg->reg_names[i];
-
- ret = devm_regulator_bulk_get(dev, cfg->num_regs, phy->regs);
- if (ret) {
- if (ret != -EPROBE_DEFER)
- DRM_DEV_ERROR(dev, "failed to get phy regulators:
%d\n", ret);
-
- return ret;
- }
-
- for (i = 0; i < cfg->num_clks; i++) {
- struct clk *clk;
-
- clk = msm_clk_get(phy->pdev, cfg->clk_names[i]);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
- DRM_DEV_ERROR(dev, "failed to get phy clock: %s (%d)\n",
- cfg->clk_names[i], ret);
- return ret;
- }
-
- phy->clks[i] = clk;
- }
-
- return 0;
-}
-
-int msm_hdmi_phy_resource_enable(struct hdmi_phy *phy)
-{
- struct hdmi_phy_cfg *cfg = phy->cfg;
- struct device *dev = >pdev->dev;
- int i, ret = 0;
-
- pm_runtime_get_sync(dev);
-
- ret = regulator_bulk_enable(cfg->num_regs, phy->regs);
- if (ret) {
- DRM_DEV_ERROR(dev, "failed to enable regulators: (%d)\n", ret);
- return ret;
- }
-
- for (i = 0; i < cfg->num_clks; i++) {
- ret = clk_prepare_enable(phy->clks[i]);
- if (ret)
- DRM_DEV_ERROR(dev, "failed to enable clock: %s (%d)\n",
- cfg->clk_names[i], ret);
- }
-
- return ret;
-}
-
-void msm_hdmi_phy_resource_disable(struct hdmi_phy *phy)
-{
- struct hdmi_phy_cfg *cfg = phy->cfg;
- struct device *dev = >pdev->dev;
- int i;
-
- for (i = cfg->num_clks - 1; i >= 0; i--)
- clk_disable_unprepare(phy->clks[i]);
-
- regulator_bulk_disable(cfg->num_regs, phy->regs);
-
- pm_runtime_put_sync(dev);
-}
-
-void msm_hdmi_phy_powerup(struct hdmi_phy *phy, unsigned long int pixclock)
-{
- if (!phy || !phy->cfg->powerup)
- return;
-
- phy->cfg->powerup(phy, pixclock);
-}
-
-void msm_hdmi_phy_powerdown(struct hdmi_phy *phy)
-{
- if (!phy || !phy->cfg->powerdown)
- return;
-
- phy->cfg->powerdown(phy);
-}
-
-static int msm_hdmi_phy_pll_init(struct platform_device *pdev,
-enum hdmi_phy_type type)
-{
- int ret;
-
- switch (type) {
- case MSM_HDMI_PHY_8960:
- ret = msm_hdmi_pll_8960_init(pdev);
- break;
- case MSM_HDMI_PHY_8996:
- ret = msm_hdmi_pll_8996_init(pdev);
- break;
- /*
-* we don't have PLL support for these, don't report an error for now
-*/
- case MSM_HDMI_PHY_8x60:
- case MSM_HDMI_PHY_8x74:
- default:
- ret = 0;
- break;
- }
-
- return ret;
-}
-
-static int msm_hdmi_phy_probe(struct platform_device *pdev)
-{
- struct device *dev = >dev;
- struct hdmi_phy *phy;
- int ret;
-
- phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
- if (!phy)
- return -ENODEV;
-
- phy->cfg = (struct hdmi_phy_cfg
[PATCH v2 10/15] drm/msm/hdmi: correct indentation of HDMI bridge functions
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 62ce1455f974..fbcf4dd91cd9 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -291,12 +291,12 @@ static enum drm_mode_status
msm_hdmi_bridge_mode_valid(struct drm_bridge *bridge
}
static const struct drm_bridge_funcs msm_hdmi_bridge_funcs = {
- .pre_enable = msm_hdmi_bridge_pre_enable,
- .post_disable = msm_hdmi_bridge_post_disable,
- .mode_set = msm_hdmi_bridge_mode_set,
- .mode_valid = msm_hdmi_bridge_mode_valid,
- .get_edid = msm_hdmi_bridge_get_edid,
- .detect = msm_hdmi_bridge_detect,
+ .pre_enable = msm_hdmi_bridge_pre_enable,
+ .post_disable = msm_hdmi_bridge_post_disable,
+ .mode_set = msm_hdmi_bridge_mode_set,
+ .mode_valid = msm_hdmi_bridge_mode_valid,
+ .get_edid = msm_hdmi_bridge_get_edid,
+ .detect = msm_hdmi_bridge_detect,
};
static void
--
2.39.2
[PATCH v2 04/15] phy: qcom-uniphy: add more registers from display PHYs
Import register definitions from 28nm DSI and HDMI PHYs, adding more UNI PHY registers. Signed-off-by: Dmitry Baryshkov --- drivers/phy/qualcomm/phy-qcom-uniphy.h | 33 ++ 1 file changed, 33 insertions(+) diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h index d8be32b5317c..4be9bda37fa3 100644 --- a/drivers/phy/qualcomm/phy-qcom-uniphy.h +++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h @@ -8,8 +8,19 @@ /* PHY registers */ #define UNIPHY_PLL_REFCLK_CFG 0x000 +#define UNIPHY_PLL_POSTDIV1_CFG0x004 +#define UNIPHY_PLL_CHGPUMP_CFG 0x008 +#define UNIPHY_PLL_VCOLPF_CFG 0x00c +#define UNIPHY_PLL_VREG_CFG0x010 #define UNIPHY_PLL_PWRGEN_CFG 0x014 +#define UNIPHY_PLL_DMUX_CFG0x018 +#define UNIPHY_PLL_AMUX_CFG0x01c #define UNIPHY_PLL_GLB_CFG 0x020 +#define UNIPHY_PLL_POSTDIV2_CFG0x024 +#define UNIPHY_PLL_POSTDIV3_CFG0x028 +#define UNIPHY_PLL_LPFR_CFG0x02c +#define UNIPHY_PLL_LPFC1_CFG 0x030 +#define UNIPHY_PLL_LPFC2_CFG 0x034 #define UNIPHY_PLL_SDM_CFG00x038 #define UNIPHY_PLL_SDM_CFG10x03c #define UNIPHY_PLL_SDM_CFG20x040 @@ -22,11 +33,33 @@ #define UNIPHY_PLL_LKDET_CFG0 0x05c #define UNIPHY_PLL_LKDET_CFG1 0x060 #define UNIPHY_PLL_LKDET_CFG2 0x064 +#define UNIPHY_PLL_TEST_CFG0x068 #define UNIPHY_PLL_CAL_CFG00x06c +#define UNIPHY_PLL_CAL_CFG10x070 +#define UNIPHY_PLL_CAL_CFG20x074 +#define UNIPHY_PLL_CAL_CFG30x078 +#define UNIPHY_PLL_CAL_CFG40x07c +#define UNIPHY_PLL_CAL_CFG50x080 +#define UNIPHY_PLL_CAL_CFG60x084 +#define UNIPHY_PLL_CAL_CFG70x088 #define UNIPHY_PLL_CAL_CFG80x08c #define UNIPHY_PLL_CAL_CFG90x090 #define UNIPHY_PLL_CAL_CFG10 0x094 #define UNIPHY_PLL_CAL_CFG11 0x098 +#define UNIPHY_PLL_EFUSE_CFG 0x09c +#define UNIPHY_PLL_DEBUG_BUS_SEL 0x0a0 +#define UNIPHY_PLL_CTRL_42 0x0a4 +#define UNIPHY_PLL_CTRL_43 0x0a8 +#define UNIPHY_PLL_CTRL_44 0x0ac +#define UNIPHY_PLL_CTRL_45 0x0b0 +#define UNIPHY_PLL_CTRL_46 0x0b4 +#define UNIPHY_PLL_CTRL_47 0x0b8 +#define UNIPHY_PLL_CTRL_48 0x0bc #define UNIPHY_PLL_STATUS 0x0c0 +#define UNIPHY_PLL_DEBUG_BUS0 0x0c4 +#define UNIPHY_PLL_DEBUG_BUS1 0x0c8 +#define UNIPHY_PLL_DEBUG_BUS2 0x0cc +#define UNIPHY_PLL_DEBUG_BUS3 0x0d0 +#define UNIPHY_PLL_CTRL_54 0x0d4 #endif -- 2.39.2
[PATCH v2 00/15] drm/msm/hdmi & phy: use generic PHY framework
The MSM HDMI PHYs have been using the ad-hoc approach / API instead of using the generic API framework. Move all the PHYs to drivers/phy/qualcomm and rework them to use generic PHY framework. This way all the QMP-related code is kept close. Also in future this will allow us to use a common set of functions to setup msm8974 HDMI PHY, 28nm DSI PHY and apq8964 SATA PHY (which all use UNI PLL internally). This also causes some design changes. Currently on msm8996 the HDMI PLL implements clock's set_rate(), while other HDMI PHY drivers used the ad-hoc PHY API for setting the PLL rate (this includes in-tree msm8960 driver and posted, but not merged, msm8974 driver). This might result in the PLL being set to one rate, while the rest of the PHY being tuned to work at another rate. Adopt the latter idea and always use phy_configure() to tune the PHY and set the PLL rate. Changes since v1: - Changed msm8960 / apq8064 to calculate register data instead of using fixed tables. This extends the list of supported modes. (Implementation is based on mdss-hdmi-pll-28lpm.c from msm-4.14). - Fixed the reprogramming of PLL rate on apq8064. - Merged all non-QMP HDMI PHY drivers into a common PHY_QCOM_HDMI driver (suggested by Rob Clark) Dmitry Baryshkov (14): phy: qualcomm: add QMP HDMI PHY driver phy: qcom: apq8064-sata: extract UNI PLL register defines phy: qcom-uniphy: add more registers from display PHYs phy: qualcomm: add legacy HDMI PHY driver phy: qualcomm: add MSM8974 HDMI PHY support phy: qualcomm: add MSM8x60 HDMI PHY support drm/msm/hdmi: move the alt_iface clock to the hpd list drm/msm/hdmi: simplify extp clock handling drm/msm/hdmi: correct indentation of HDMI bridge functions drm/msm/hdmi: switch to atomic_pre_enable/post_disable drm/msm/hdmi: set infoframes on all pre_enable calls drm/msm/hdmi: pair msm_hdmi_phy_powerup with msm_hdmi_phy_powerdown drm/msm/hdmi: switch to generic PHY subsystem drm/msm/hdmi: drop old HDMI PHY code Sandor Yu (1): phy: Add HDMI configuration options drivers/gpu/drm/msm/Makefile | 6 - drivers/gpu/drm/msm/hdmi/hdmi.c | 86 +- drivers/gpu/drm/msm/hdmi/hdmi.h | 79 +- drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 108 ++- drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 217 - drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 51 -- drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 765 -- drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 141 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 44 - drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c | 458 --- drivers/phy/qualcomm/Kconfig | 21 + drivers/phy/qualcomm/Makefile | 13 + drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +- drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c| 327 drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c| 439 ++ drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c | 184 + drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 211 + drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 81 ++ drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c | 184 + .../phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c | 441 ++ drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h | 75 ++ drivers/phy/qualcomm/phy-qcom-uniphy.h| 65 ++ include/linux/phy/phy-hdmi.h | 33 + include/linux/phy/phy.h | 7 +- 24 files changed, 2162 insertions(+), 1897 deletions(-) delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy.c delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c delete mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy.h create mode 100644 include/linux/phy/phy-hdmi.h -- 2.39.2
[PATCH v2 05/15] phy: qualcomm: add legacy HDMI PHY driver
Add the driver for pre-QMP Qualcomm HDMI PHYs. Currently it suppports Qualcomm MSM8960 / APQ8064 platforms, other platforms will come later. Signed-off-by: Dmitry Baryshkov --- drivers/phy/qualcomm/Kconfig| 14 + drivers/phy/qualcomm/Makefile | 6 + drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c | 439 drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 206 + drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 79 5 files changed, 744 insertions(+) create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c create mode 100644 drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig index 4521fc9b9ced..460ad8298f86 100644 --- a/drivers/phy/qualcomm/Kconfig +++ b/drivers/phy/qualcomm/Kconfig @@ -42,6 +42,20 @@ config PHY_QCOM_IPQ806X_SATA depends on OF select GENERIC_PHY +config PHY_QCOM_HDMI + tristate "Qualcomm MSM8x60/MSM8960/MSM8974 HDMI PHY driver" + depends on ARCH_QCOM || COMPILE_TEST + depends on OF + depends on COMMON_CLK + default DRM_MSM_HDMI && ARCH_QCOM && ARM + select GENERIC_PHY + help + Enable this to support the Qualcomm HDMI PHY presend on 32-bit platforms: + MSM8260, MSM8660, MSM8960, APQ8060 and APQ8064. + + Note, this driver is not used on MSM899x platforms, which use + PHY_QCOM_QMP_HDMI instead. + config PHY_QCOM_PCIE2 tristate "Qualcomm PCIe Gen2 PHY Driver" depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST) diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile index 32e27ffb7af6..4c06498c709d 100644 --- a/drivers/phy/qualcomm/Makefile +++ b/drivers/phy/qualcomm/Makefile @@ -4,6 +4,12 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o obj-$(CONFIG_PHY_QCOM_EDP) += phy-qcom-edp.o obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o +obj-$(CONFIG_PHY_QCOM_HDMI)+= phy-qcom-hdmi.o + +phy-qcom-hdmi-y := \ + phy-qcom-hdmi-preqmp.o \ + phy-qcom-hdmi-28lpm.o \ + obj-$(CONFIG_PHY_QCOM_PCIE2) += phy-qcom-pcie2.o obj-$(CONFIG_PHY_QCOM_QMP_COMBO) += phy-qcom-qmp-combo.o diff --git a/drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c b/drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c new file mode 100644 index ..64e043f3f0e2 --- /dev/null +++ b/drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c @@ -0,0 +1,439 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2013 Red Hat + * Author: Rob Clark + * Copyright (c) 2023, Linaro Ltd. + */ + +#include +#include + +#include "phy-qcom-hdmi-preqmp.h" + +#define REG_HDMI_8960_PHY_REG0 0x + +#define REG_HDMI_8960_PHY_REG1 0x0004 + +#define REG_HDMI_8960_PHY_REG2 0x0008 + +#define REG_HDMI_8960_PHY_REG3 0x000c + +#define REG_HDMI_8960_PHY_REG4 0x0010 + +#define REG_HDMI_8960_PHY_REG5 0x0014 + +#define REG_HDMI_8960_PHY_REG6 0x0018 + +#define REG_HDMI_8960_PHY_REG7 0x001c + +#define REG_HDMI_8960_PHY_REG8 0x0020 + +#define REG_HDMI_8960_PHY_REG9 0x0024 + +#define REG_HDMI_8960_PHY_REG10 0x0028 + +#define REG_HDMI_8960_PHY_REG11 0x002c + +#define REG_HDMI_8960_PHY_REG12 0x0030 +#define HDMI_8960_PHY_REG12_SW_RESET 0x0020 +#define HDMI_8960_PHY_REG12_PWRDN_B0x0080 + +#define REG_HDMI_8960_PHY_REG_BIST_CFG 0x0034 + +#define REG_HDMI_8960_PHY_DEBUG_BUS_SEL 0x0038 + +#define REG_HDMI_8960_PHY_REG_MISC00x003c + +#define REG_HDMI_8960_PHY_REG13 0x0040 + +#define REG_HDMI_8960_PHY_REG14 0x0044 + +#define REG_HDMI_8960_PHY_REG15 0x0048 + +#define REG_HDMI_8960_PHY_PLL_REFCLK_CFG 0x + +#define REG_HDMI_8960_PHY_PLL_CHRG_PUMP_CFG0x0004 + +#define REG_HDMI_8960_PHY_PLL_LOOP_FLT_CFG00x0008 + +#define REG_HDMI_8960_PHY_PLL_LOOP_FLT_CFG10x000c + +#define REG_HDMI_8960_PHY_PLL_IDAC_ADJ_CFG 0x0010 + +#define REG_HDMI_8960_PHY_PLL_I_VI_KVCO_CFG0x0014 + +#define
[PATCH v2 03/15] phy: qcom: apq8064-sata: extract UNI PLL register defines
The "uni" PLL is shared between several PHYS: APQ8064's SATA, MSM8974/APQ8084 HDMI, MSM8916 DSI, MSM8974/APQ8084 DSI. Signed-off-by: Dmitry Baryshkov --- drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +- drivers/phy/qualcomm/phy-qcom-uniphy.h | 32 2 files changed, 33 insertions(+), 22 deletions(-) create mode 100644 drivers/phy/qualcomm/phy-qcom-uniphy.h diff --git a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c index 8814f4322adf..e9c272c1e97e 100644 --- a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c +++ b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c @@ -15,28 +15,7 @@ #include #include -/* PHY registers */ -#define UNIPHY_PLL_REFCLK_CFG 0x000 -#define UNIPHY_PLL_PWRGEN_CFG 0x014 -#define UNIPHY_PLL_GLB_CFG 0x020 -#define UNIPHY_PLL_SDM_CFG00x038 -#define UNIPHY_PLL_SDM_CFG10x03C -#define UNIPHY_PLL_SDM_CFG20x040 -#define UNIPHY_PLL_SDM_CFG30x044 -#define UNIPHY_PLL_SDM_CFG40x048 -#define UNIPHY_PLL_SSC_CFG00x04C -#define UNIPHY_PLL_SSC_CFG10x050 -#define UNIPHY_PLL_SSC_CFG20x054 -#define UNIPHY_PLL_SSC_CFG30x058 -#define UNIPHY_PLL_LKDET_CFG0 0x05C -#define UNIPHY_PLL_LKDET_CFG1 0x060 -#define UNIPHY_PLL_LKDET_CFG2 0x064 -#define UNIPHY_PLL_CAL_CFG00x06C -#define UNIPHY_PLL_CAL_CFG80x08C -#define UNIPHY_PLL_CAL_CFG90x090 -#define UNIPHY_PLL_CAL_CFG10 0x094 -#define UNIPHY_PLL_CAL_CFG11 0x098 -#define UNIPHY_PLL_STATUS 0x0C0 +#include "phy-qcom-uniphy.h" #define SATA_PHY_SER_CTRL 0x100 #define SATA_PHY_TX_DRIV_CTRL0 0x104 diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h new file mode 100644 index ..d8be32b5317c --- /dev/null +++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h @@ -0,0 +1,32 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2014, The Linux Foundation. All rights reserved. + */ + +#ifndef PHY_QCOM_UNIPHY_H +#define PHY_QCOM_UNIPHY_H + +/* PHY registers */ +#define UNIPHY_PLL_REFCLK_CFG 0x000 +#define UNIPHY_PLL_PWRGEN_CFG 0x014 +#define UNIPHY_PLL_GLB_CFG 0x020 +#define UNIPHY_PLL_SDM_CFG00x038 +#define UNIPHY_PLL_SDM_CFG10x03c +#define UNIPHY_PLL_SDM_CFG20x040 +#define UNIPHY_PLL_SDM_CFG30x044 +#define UNIPHY_PLL_SDM_CFG40x048 +#define UNIPHY_PLL_SSC_CFG00x04c +#define UNIPHY_PLL_SSC_CFG10x050 +#define UNIPHY_PLL_SSC_CFG20x054 +#define UNIPHY_PLL_SSC_CFG30x058 +#define UNIPHY_PLL_LKDET_CFG0 0x05c +#define UNIPHY_PLL_LKDET_CFG1 0x060 +#define UNIPHY_PLL_LKDET_CFG2 0x064 +#define UNIPHY_PLL_CAL_CFG00x06c +#define UNIPHY_PLL_CAL_CFG80x08c +#define UNIPHY_PLL_CAL_CFG90x090 +#define UNIPHY_PLL_CAL_CFG10 0x094 +#define UNIPHY_PLL_CAL_CFG11 0x098 +#define UNIPHY_PLL_STATUS 0x0c0 + +#endif -- 2.39.2
[PATCH v2 02/15] phy: qualcomm: add QMP HDMI PHY driver
Port Qualcomm QMP HDMI PHY to the generic PHY framework. Split the
generic part and the msm8996 part. When adding support for msm8992/4 and
msm8998 (which also employ QMP for HDMI PHY), one will have to provide
the PLL programming part only.
Signed-off-by: Dmitry Baryshkov
---
drivers/phy/qualcomm/Kconfig | 7 +
drivers/phy/qualcomm/Makefile | 5 +
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c | 184
.../phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c | 441 ++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h | 75 +++
5 files changed, 712 insertions(+)
create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c
create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h
diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 97ca5952e34e..4521fc9b9ced 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -68,6 +68,13 @@ config PHY_QCOM_QMP_COMBO
Enable this to support the QMP Combo PHY transceiver that is used
with USB3 and DisplayPort controllers on Qualcomm chips.
+config PHY_QCOM_QMP_HDMI
+ tristate "Qualcomm QMP HDMI PHY Driver"
+ default PHY_QCOM_QMP && DRM_MSM_HDMI
+ help
+ Enable this to support the QMP HDMI PHY transceiver that is used
+ with HDMI output on Qualcomm MSM8996 chips.
+
config PHY_QCOM_QMP_PCIE
tristate "Qualcomm QMP PCIe PHY Driver"
depends on PCI || COMPILE_TEST
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index b030858e0f8d..32e27ffb7af6 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -7,11 +7,16 @@ obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) +=
phy-qcom-ipq806x-sata.o
obj-$(CONFIG_PHY_QCOM_PCIE2) += phy-qcom-pcie2.o
obj-$(CONFIG_PHY_QCOM_QMP_COMBO) += phy-qcom-qmp-combo.o
+obj-$(CONFIG_PHY_QCOM_QMP_HDMI)+= phy-qcom-qmp-hdmi.o
obj-$(CONFIG_PHY_QCOM_QMP_PCIE)+= phy-qcom-qmp-pcie.o
obj-$(CONFIG_PHY_QCOM_QMP_PCIE_8996) += phy-qcom-qmp-pcie-msm8996.o
obj-$(CONFIG_PHY_QCOM_QMP_UFS) += phy-qcom-qmp-ufs.o
obj-$(CONFIG_PHY_QCOM_QMP_USB) += phy-qcom-qmp-usb.o
+phy-qcom-qmp-hdmi-y := \
+ phy-qcom-qmp-hdmi-base.o \
+ phy-qcom-qmp-hdmi-msm8996.o \
+
obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
obj-$(CONFIG_PHY_QCOM_SNPS_EUSB2) += phy-qcom-snps-eusb2.o
obj-$(CONFIG_PHY_QCOM_EUSB2_REPEATER) += phy-qcom-eusb2-repeater.o
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
b/drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
new file mode 100644
index ..08132b3f82af
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+
+#include "phy-qcom-qmp-hdmi.h"
+
+int qmp_hdmi_phy_init(struct phy *phy)
+{
+ struct qmp_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
+
+ return pm_runtime_resume_and_get(hdmi_phy->dev);
+}
+
+int qmp_hdmi_phy_configure(struct phy *phy, union phy_configure_opts *opts)
+{
+const struct phy_configure_opts_hdmi *hdmi_opts = >hdmi;
+ struct qmp_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
+int ret = 0;
+
+memcpy(_phy->hdmi_opts, hdmi_opts, sizeof(*hdmi_opts));
+
+return ret;
+}
+
+int qmp_hdmi_phy_exit(struct phy *phy)
+{
+ struct qmp_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
+
+ pm_runtime_put_noidle(hdmi_phy->dev);
+
+ return 0;
+}
+
+static int __maybe_unused qmp_hdmi_runtime_resume(struct device *dev)
+{
+ struct qmp_hdmi_phy *hdmi_phy = dev_get_drvdata(dev);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(hdmi_phy->supplies),
hdmi_phy->supplies);
+ if (ret)
+ return ret;
+
+ ret = clk_bulk_prepare_enable(ARRAY_SIZE(hdmi_phy->clks),
hdmi_phy->clks);
+ if (ret)
+ goto out_disable_supplies;
+
+ return 0;
+
+out_disable_supplies:
+ regulator_bulk_disable(ARRAY_SIZE(hdmi_phy->supplies),
hdmi_phy->supplies);
+
+ return ret;
+}
+
+static int __maybe_unused qmp_hdmi_runtime_suspend(struct device *dev)
+{
+ struct qmp_hdmi_phy *hdmi_phy = dev_get_drvdata(dev);
+
+ clk_bulk_disable_unprepare(ARRAY_SIZE(hdmi_phy->clks), hdmi_phy->clks);
+ regulator_bulk_disable(ARRAY_SIZE(hdmi_phy->supplies),
hdmi_phy->supplies);
+
+ return 0;
+}
+
+static int qmp_hdmi_probe(struct platform_device *pdev)
+{
+ struct clk_init_data init = {
+ .name = "hdmipll",
+ .parent_data = (const struct clk_parent_data[]) {
+ { .fw_name = "xo", .name = "xo_board" },
+ },
+ .flags = CLK_GET_RATE_NOCACHE,
+
[PATCH v2 01/15] phy: Add HDMI configuration options
From: Sandor Yu
Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The parameters added here are based on HDMI PHY
implementation practices. The current set of parameters
should cover the potential users.
Signed-off-by: Sandor Yu
Signed-off-by: Dmitry Baryshkov
---
include/linux/phy/phy-hdmi.h | 33 +
include/linux/phy/phy.h | 7 ++-
2 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 include/linux/phy/phy-hdmi.h
diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
new file mode 100644
index ..73a32eb535b0
--- /dev/null
+++ b/include/linux/phy/phy-hdmi.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2022 NXP
+ */
+
+#ifndef __PHY_HDMI_H_
+#define __PHY_HDMI_H_
+
+enum hdmi_phy_colorspace {
+ HDMI_PHY_COLORSPACE_RGB,
+ HDMI_PHY_COLORSPACE_YUV422,
+ HDMI_PHY_COLORSPACE_YUV444,
+ HDMI_PHY_COLORSPACE_YUV420,
+ HDMI_PHY_COLORSPACE_RESERVED4,
+ HDMI_PHY_COLORSPACE_RESERVED5,
+ HDMI_PHY_COLORSPACE_RESERVED6,
+};
+
+/**
+ * struct phy_configure_opts_hdmi - HDMI configuration set
+ * @pixel_clk_rate:Pixel clock of video modes in KHz.
+ * @bpc: Maximum bits per color channel.
+ * @color_space: Colorspace in enum hdmi_phy_colorspace.
+ *
+ * This structure is used to represent the configuration state of a HDMI phy.
+ */
+struct phy_configure_opts_hdmi {
+ unsigned int pixel_clk_rate;
+ unsigned int bpc;
+ enum hdmi_phy_colorspace color_space;
+};
+
+#endif /* __PHY_HDMI_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f6d607ef0e80..94d489a8a163 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
@@ -42,7 +43,8 @@ enum phy_mode {
PHY_MODE_MIPI_DPHY,
PHY_MODE_SATA,
PHY_MODE_LVDS,
- PHY_MODE_DP
+ PHY_MODE_DP,
+ PHY_MODE_HDMI,
};
enum phy_media {
@@ -60,11 +62,14 @@ enum phy_media {
* the DisplayPort protocol.
* @lvds: Configuration set applicable for phys supporting
* the LVDS phy mode.
+ * @hdmi: Configuration set applicable for phys supporting
+ * the HDMI phy mode.
*/
union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
struct phy_configure_opts_lvds lvds;
+ struct phy_configure_opts_hdmi hdmi;
};
/**
--
2.39.2
Re: [PATCH v2] Documentation/gpu: Add a VM_BIND async draft document
Hi Thomas, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm/drm-next drm-tip/drm-tip next-20230623] [cannot apply to linus/master v6.4-rc7] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/Documentation-gpu-Add-a-VM_BIND-async-draft-document/20230621-180712 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230621100435.54425-1-thomas.hellstrom%40linux.intel.com patch subject: [PATCH v2] Documentation/gpu: Add a VM_BIND async draft document reproduce: (https://download.01.org/0day-ci/archive/20230625/202306251715.vhtkaevg-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202306251715.vhtkaevg-...@intel.com/ All warnings (new ones prefixed by >>): >> Documentation/gpu/drm-vm-bind-async.rst:95: WARNING: Title underline too >> short. >> Documentation/gpu/drm-vm-bind-async.rst: WARNING: document isn't included in >> any toctree vim +95 Documentation/gpu/drm-vm-bind-async.rst 93 94 Multi-operation VM_BIND IOCTL error handling and interrupts > 95 96 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH] drm/gma500: Replace kmap{,_atomic}() with page_address()
On Wed, Jun 21, 2023 at 12:31:40AM +0200, Fabio M. De Francesco wrote:
> On martedì 20 giugno 2023 20:01:48 CEST Sumitra Sharma wrote:
> > Remove unnecessary calls to kmap{,_atomic}() when acquiring
> > pages using GFP_DMA32.
> >
> > The GFP_DMA32 uses the DMA32 zone to satisfy the allocation
> > requests. Therefore, pages allocated with GFP_DMA32 cannot
> > come from Highmem.
> >
> > Avoid using calls to kmap_local_page() / kunmap_local() and
> > kmap() / kunmap() in the psb_mmu_alloc_pd function. Instead,
> > utilize page_address().
> >
> > Remove the usage of kmap_atomic() / kunmap_atomic() in the
> > psb_mmu_alloc_pt function. Use page_address() instead.
> >
> > Substitute kmap_atomic(pt->p) / kunmap_atomic(pt->v) calls
> > in the psb_mmu_pt_alloc_map_lock() and psb_mmu_pt_unmap_unlock()
> > functions with page_address(pt->p). This is possible as
> > pt = psb_mmu_alloc_pt(pd) allocates a page using
> > pt->p = alloc_page(GFP_DMA32).
>
> Sumitra,
>
> I'm sorry because this patch cannot acked with this commit message.
>
> This commit message is missing two _really_ important information. Therefore,
> it is not acked. Please check again what I write below and either add the
> missing information or change the code accordingly...
>
> You should assure everybody that the code between the old kmap_atomic() /
> kunmap_atomic() doesn't depend either on implicit pagefault_disable() or
> preempt_disable() calls or both.
>
> Please read again the section of the Highmem's documentation regarding
> kmap_atomic() at https://docs.kernel.org/mm/highmem.html
>
> In particular take care to read and understand what "[] the code between
> calls
> to kmap_atomic() and kunmap_atomic() may implicitly depend on the side
> effects
> of atomic mappings, i.e. disabling page faults or preemption, or both. In
> that
> case, explicit calls to pagefault_disable() or preempt_disable() or both must
> be made in conjunction with the use of kmap_local_page().".
>
> Please study carefully also the following patch from Zhao, suggested by Ira
> and reviewed by Ira and I: "[PATCH v2 3/9] drm/i915: Use kmap_local_page() in
> gem/i915_gem_shmem.c". It's not yet reached upstream so you need to find it
> in
> lore.kernel.org at
> https://lore.kernel.org/lkml/20230329073220.3982460-4-zhao1@linux.intel.com/
>
> Please note that, in turn, that patch also contains a link to a patch from
> Ira
> who too had to disable faults (https://lore.kernel.org/all/
> 20220813220034.806698-1-ira.we...@intel.com)
>
> I haven't yet looked at your code. If any sections do depend on those
> implicit
> disables, you should act accordingly and add one or both of the above-
> mentioned calls, even in cases where you get rid of local mappings.
>
> Instead if the sections don't depend on the mentioned side effects, you
> should
> write something like what I wrote in "[PATCH] NFS: Convert kmap_atomic() to
> kmap_local_folio()" that you can find at https://lore.kernel.org/lkml/
> 20230503172411.3356-1-fmdefrance...@gmail.com/ or, by by using "git show
> 4b71e2416ec4".
>
> Thanks for working on this,
>
> Fabio
>
Hi Fabio,
Thank you for notifying the mistakes I made in this patch. I am directly
working on the changes.
Regards
Sumitra
> >
> > Suggested-by: Ira Weiny
> > Signed-off-by: Sumitra Sharma
> > ---
> > drivers/gpu/drm/gma500/mmu.c | 17 +
> > 1 file changed, 5 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
> > index a70b01ccdf70..59aa5661e56a 100644
> > --- a/drivers/gpu/drm/gma500/mmu.c
> > +++ b/drivers/gpu/drm/gma500/mmu.c
> > @@ -184,20 +184,15 @@ struct psb_mmu_pd *psb_mmu_alloc_pd(struct
> > psb_mmu_driver *driver, pd->invalid_pte = 0;
> > }
> >
> > - v = kmap_local_page(pd->dummy_pt);
> > + v = page_address(pd->dummy_pt);
> > for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> > v[i] = pd->invalid_pte;
> >
> > - kunmap_local(v);
> > -
> > - v = kmap_local_page(pd->p);
> > + v = page_address(pd->p);
> > for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> > v[i] = pd->invalid_pde;
> >
> > - kunmap_local(v);
> > -
> > - clear_page(kmap(pd->dummy_page));
> > - kunmap(pd->dummy_page);
> > + clear_page(page_address(pd->dummy_page));
> >
> > pd->tables = vmalloc_user(sizeof(struct psb_mmu_pt *) * 1024);
> > if (!pd->tables)
> > @@ -279,7 +274,7 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
> > psb_mmu_pd *pd)
> >
> > spin_lock(lock);
> >
> > - v = kmap_atomic(pt->p);
> > + v = page_address(pt->p);
> > clf = (uint8_t *) v;
> > ptes = (uint32_t *) v;
> > for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
> > @@ -293,7 +288,6 @@ static struct psb_mmu_pt *psb_mmu_alloc_pt(struct
> > psb_mmu_pd *pd) }
> > mb();
> > }
> > - kunmap_atomic(v);
> > spin_unlock(lock);
> >
> > pt->count = 0;
> > @@ -339,7
Re: Add me to Developer group
Please open an issue here by filling the "User verification" template: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/new
[PATCH] drm/ttm: Remove duplicate assignments to ttm->caching
The parameter 'caching' has already been assigned to
'ttm->caching', so 'ttm_cached' is redundant.
Fixes: 1b4ea4c5980f ("drm/ttm: set the tt caching state at creation time")
Signed-off-by: Feng Jiang
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index ab725d9d14a6..1ce4b36ab33b 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -137,7 +137,6 @@ static void ttm_tt_init_fields(struct ttm_tt *ttm,
unsigned long extra_pages)
{
ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT) +
extra_pages;
- ttm->caching = ttm_cached;
ttm->page_flags = page_flags;
ttm->dma_address = NULL;
ttm->swap_storage = NULL;
--
2.41.0
Add me to Developer group
Hi! I want to contribute to the modetest tool a few patches, which I had developed during my work. https://gitlab.freedesktop.org/mesa/mesa/-/issues/9197#note_1958102 Best regards, Vostokov Nikita
Re: [PATCH 24/39] drm: renesas: shmobile: Unify plane allocation
Hi Laurent,
On Fri, Jun 23, 2023 at 8:50 PM Laurent Pinchart
wrote:
> On Fri, Jun 23, 2023 at 07:55:22PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jun 23, 2023 at 6:50 PM Laurent Pinchart wrote:
> > > On Thu, Jun 22, 2023 at 11:21:36AM +0200, Geert Uytterhoeven wrote:
> > > > Unify primary and overlay plane allocation:
> > > > - Enhance shmob_drm_plane_create() so it can be used to create the
> > > > primary plane, too,
> > > > - Move overlay plane creation next to primary plane creation.
> > > >
> > > > As overlay plane index zero now means the primary plane, this requires
> > > > shifting all overlay plane indices by one.
> > >
> > > Do you use index zero to identify the primary plane just for
> > > shmob_drm_plane_create(), or somewhere else too ? If it's just to create
> > > the plane, you could instead pass the plane type to the function.
> >
> > Index zero is just used for the creation.
> > I guess this sort of goes together with my question below...
> >
> > > > Signed-off-by: Geert Uytterhoeven
> > > > ---
> > > > Perhaps it would be better to not use dynamic allocation, but store
> > > > "struct drm_plane primary" and "struct shmob_drm_plane planes[5]" in
> > > > struct drm_shmob_device instead, like is done for the crtc and encoder?
> >
> > ... as embedding separate primary and planes[] would also get rid of
> > the need to adjust the plane indices when converting from logical to
> > physical
> > overlay plane indices.
>
> Do they need to be embedded for that, or could you simple keep the index
> as it is ?
If the plane type would be passed explicitly, they would not need to be
embedded for that.
Then the question becomes: does it make sense to unify primary and
overlay plane handling?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [28/39] drm: renesas: shmobile: Use drm_crtc_handle_vblank()
Hi Sui,
On Sat, Jun 24, 2023 at 11:33 AM Sui Jingfeng wrote:
> I'm fine with this patch but I I don't see the benefit.
>
> This reply is more about my personal question.
>
> On 2023/6/22 17:21, Geert Uytterhoeven wrote:
> > Replace the call to the legacy drm_handle_vblank() function with a call
> > to the new drm_crtc_handle_vblank() helper.
> >
> > Signed-off-by: Geert Uytterhoeven
> > Reviewed-by: Laurent Pinchart
> Reviewed-by: Sui Jingfeng
> > ---
> > drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> > b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> > index c98e2bdd888c3274..6eaf2c5a104f451a 100644
> > --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> > +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> > @@ -86,7 +86,7 @@ static irqreturn_t shmob_drm_irq(int irq, void *arg)
> > spin_unlock_irqrestore(>irq_lock, flags);
> >
> > if (status & LDINTR_VES) {
> > - drm_handle_vblank(dev, 0);
> > + drm_crtc_handle_vblank(>crtc.base);
>
>
> After switching to drm_crtc_handle_vblank(),
>
> your driver need another deference to the pointer of 'struct drm_crtc'
> to get the pointer of 'struct drm_device';
>
> Plus another call to get the index(display pipe) of the CRTC by calling
> drm_crtc_index(crtc).
That is correct.
> Consider that shmob-drm support only one display pipe,
>
> is it that the switching is less straight forward than the original
> implement ?
>
>
> ```
>
> /**
> * drm_crtc_handle_vblank - handle a vblank event
> * @crtc: where this event occurred
> *
> * Drivers should call this routine in their vblank interrupt handlers to
> * update the vblank counter and send any signals that may be pending.
> *
> * This is the native KMS version of drm_handle_vblank().
> *
> * Note that for a given vblank counter value drm_crtc_handle_vblank()
> * and drm_crtc_vblank_count() or drm_crtc_vblank_count_and_time()
> * provide a barrier: Any writes done before calling
> * drm_crtc_handle_vblank() will be visible to callers of the later
> * functions, if the vblank count is the same or a later one.
> *
> * See also _vblank_crtc.count.
> *
> * Returns:
> * True if the event was successfully handled, false on failure.
> */
> bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
> {
> return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
> }
>
> ```
>
> Is it that drm_crtc_handle_vblank() function is preferred over
> drm_handle_vblank() in the future?
>
> I'm fine with this question answered.
I think the native KMS version is preferred over the legacy version, cfr.
/**
* drm_handle_vblank - handle a vblank event
[...]
* This is the legacy version of drm_crtc_handle_vblank().
*/
bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v6 3/3] drm/virtio: Support sync objects
Hi Dmitry,
On Sun, Apr 16, 2023 at 1:55 PM Dmitry Osipenko
wrote:
> Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
> support is needed by native context VirtIO-GPU Mesa drivers, it also will
> be used by Venus and Virgl contexts.
>
> Reviewed-by; Emil Velikov
> Signed-off-by: Dmitry Osipenko
Thanks for your patch!
> --- a/drivers/gpu/drm/virtio/virtgpu_submit.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_submit.c
> +static int
> +virtio_gpu_parse_deps(struct virtio_gpu_submit *submit)
> +{
> + struct drm_virtgpu_execbuffer *exbuf = submit->exbuf;
> + struct drm_virtgpu_execbuffer_syncobj syncobj_desc;
> + size_t syncobj_stride = exbuf->syncobj_stride;
> + u32 num_in_syncobjs = exbuf->num_in_syncobjs;
> + struct drm_syncobj **syncobjs;
> + int ret = 0, i;
> +
> + if (!num_in_syncobjs)
> + return 0;
> +
> + /*
> +* kvalloc at first tries to allocate memory using kmalloc and
> +* falls back to vmalloc only on failure. It also uses GFP_NOWARN
GFP_NOWARN does not exist.
> +* internally for allocations larger than a page size, preventing
> +* storm of KMSG warnings.
> +*/
> + syncobjs = kvcalloc(num_in_syncobjs, sizeof(*syncobjs), GFP_KERNEL);
> + if (!syncobjs)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_in_syncobjs; i++) {
> + u64 address = exbuf->in_syncobjs + i * syncobj_stride;
> + struct dma_fence *fence;
> +
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] drm/nouveau: Remove the unused variable entry
Variable entry is not effectively used, so delete it.
drivers/gpu/drm/nouveau/nouveau_connector.c:1298:7: warning: variable 'entry'
set but not used.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5596
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index f75c6f09dd2a..3a267b793afa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1295,11 +1295,8 @@ nouveau_connector_create(struct drm_device *dev,
/* attempt to parse vbios connector type and hotplug gpio */
nv_connector->dcb = olddcb_conn(dev, index);
if (nv_connector->dcb) {
- u32 entry = ROM16(nv_connector->dcb[0]);
- if (olddcb_conntab(dev)[3] >= 4)
- entry |= (u32)ROM16(nv_connector->dcb[2]) << 16;
-
nv_connector->type = nv_connector->dcb[0];
+
if (drm_conntype_from_dcb(nv_connector->type) ==
DRM_MODE_CONNECTOR_Unknown) {
NV_WARN(drm, "unknown connector type %02x\n",
--
2.20.1.7.g153144c
Re: [PATCH 10/15] dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant
On 24/06/2023 15:48, Dmitry Baryshkov wrote: > On 24/06/2023 03:41, Marijn Suijten wrote: >> Document availability of the 14nm DSI PHY on SM6125. >> >> Signed-off-by: Marijn Suijten >> --- >> Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> index a43e11d3b00d..60b590f21138 100644 >> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml >> @@ -18,6 +18,7 @@ properties: >> - qcom,dsi-phy-14nm >> - qcom,dsi-phy-14nm-2290 >> - qcom,dsi-phy-14nm-660 >> + - qcom,dsi-phy-14nm-6125 > > Should we start using standard scheme, so "qcom,sm6125-dsi-phy-14nm" ? I guess the earlier the better. Best regards, Krzysztof
