Re: [PATCH v2 7/7] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs

On Wed, Apr 17, 2024 at 10:02:59PM +0200, Konrad Dybcio wrote: > Add the speedbin masks to ensure only the desired OPPs are available on > chips of a given bin. > > Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz. > > Signed-off-by: Konrad Dybcio > --- >

Re: [PATCH v2 6/7] drm/msm/adreno: Redo the speedbin assignment

On Wed, Apr 17, 2024 at 10:02:58PM +0200, Konrad Dybcio wrote: > There is no need to reinvent the wheel for simple read-match-set logic. > > Make speedbin discovery and assignment generation independent. > > This implicitly removes the bogus 0x80 / BIT(7) speed bin on A5xx, > which has no

Re: [PATCH v2 5/7] drm/msm/adreno: Define A530 speed bins explicitly

On Wed, Apr 17, 2024 at 10:02:57PM +0200, Konrad Dybcio wrote: > In preparation for commonizing the speedbin handling code. > > Signed-off-by: Konrad Dybcio > --- > drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++ > 1 file changed, 6 insertions(+) Reviewed-by: Dmitry Baryshkov -- With

Re: [PATCH v2 4/7] drm/msm/adreno: Add speedbin data for SM8550 / A740

On Wed, Apr 17, 2024 at 10:02:56PM +0200, Konrad Dybcio wrote: > Add speebin data for A740, as found on SM8550 and derivative SoCs. > > Signed-off-by: Konrad Dybcio > --- > drivers/gpu/drm/msm/adreno/adreno_device.c | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Dmitry Baryshkov

Re: [PATCH v2 3/7] drm/msm/adreno: Implement SMEM-based speed bin

On Wed, Apr 17, 2024 at 10:02:55PM +0200, Konrad Dybcio wrote: > On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is > abstracted through SMEM, instead of being directly available in a fuse. > > Add support for SMEM-based speed binning, which includes getting > "feature code" and

Re: [PATCH v2 2/7] soc: qcom: smem: Add a feature code getter

On Wed, Apr 17, 2024 at 10:02:54PM +0200, Konrad Dybcio wrote: > Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely > identifying the specific SKU and the precise speed bin (in the general > meaning of this word, anyway): a pair of values called Product Code > and Feature Code.

Re: [PATCH 7/7] drm/msm/dpu: Rename `ctx` parameter to `intf` to match other functions

On Wed, Apr 17, 2024 at 01:57:47AM +0200, Marijn Suijten wrote: > All other functions in dpu_hw_intf name the "self" parameter `intf`, > except dpu_hw_intf_setup_timing_engine() and the recently added > dpu_hw_intf_program_intf_cmd_cfg(). Clean that up for consistency. I really have mixed

Re: [PATCH 5/7] drm/msm/dpu: Correct dual-ctl -> dual-intf typo in comment

On Wed, Apr 17, 2024 at 01:57:45AM +0200, Marijn Suijten wrote: > This comment one line down references a single, "same CTL" that controls > two interfaces, so the comment should clearly describe two interfaces > used with a single active CTL and not "two CTLs". > > Fixes: 25fdd5933e4c ("drm/msm:

[PATCH v2 7/7] arm64: dts: qcom: sm8550: Wire up GPU speed bin & more OPPs

Add the speedbin masks to ensure only the desired OPPs are available on chips of a given bin. Using this, add the binned 719 MHz OPP and the non-binned 124.8 MHz. Signed-off-by: Konrad Dybcio --- arch/arm64/boot/dts/qcom/sm8550.dtsi | 21 - 1 file changed, 20 insertions(+),

[PATCH v2 6/7] drm/msm/adreno: Redo the speedbin assignment

There is no need to reinvent the wheel for simple read-match-set logic. Make speedbin discovery and assignment generation independent. This implicitly removes the bogus 0x80 / BIT(7) speed bin on A5xx, which has no representation in hardware whatshowever. Signed-off-by: Konrad Dybcio ---

[PATCH v2 4/7] drm/msm/adreno: Add speedbin data for SM8550 / A740

Add speebin data for A740, as found on SM8550 and derivative SoCs. Signed-off-by: Konrad Dybcio --- drivers/gpu/drm/msm/adreno/adreno_device.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index

[PATCH v2 5/7] drm/msm/adreno: Define A530 speed bins explicitly

In preparation for commonizing the speedbin handling code. Signed-off-by: Konrad Dybcio --- drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c index

[PATCH v2 3/7] drm/msm/adreno: Implement SMEM-based speed bin

On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is abstracted through SMEM, instead of being directly available in a fuse. Add support for SMEM-based speed binning, which includes getting "feature code" and "product code" from said source and parsing them to form something that

[PATCH v2 2/7] soc: qcom: smem: Add a feature code getter

Recent (SM8550+ ish) Qualcomm SoCs have a new mechanism for precisely identifying the specific SKU and the precise speed bin (in the general meaning of this word, anyway): a pair of values called Product Code and Feature Code. Based on this information, we can deduce the available frequencies for

[PATCH v2 0/7] Add SMEM-based speedbin matching

Newer (SM8550+) SoCs don't seem to have a nice speedbin fuse anymore, but instead rely on a set of combinations of "feature code" (FC) and "product code" (PC) identifiers to match the bins. This series adds support for that. I suppose a qcom/for-soc immutable branch would be in order if we want

[PATCH v2 1/7] soc: qcom: Move some socinfo defines to the header

In preparation for parsing the chip "feature code" (FC) and "product code" (PC) (essentially the parameters that let us conclusively characterize the sillicon we're running on, including various speed bins), move the socinfo version defines to the public header. Signed-off-by: Konrad Dybcio ---

Re: [PATCH 6/7] drm/msm/dsi: Set PHY usescase before registering DSI host

On 2024-04-17 11:18:58, Dmitry Baryshkov wrote: > On Wed, 17 Apr 2024 at 02:57, Marijn Suijten > wrote: > > > > Ordering issues here cause an uninitalized (default STANDALONE) > > usecase to be programmed (which appears to be a MUX) in some cases > > when msm_dsi_host_register() is called,

Re: [PATCH 4/7] drm/msm/dpu: Allow configuring multiple active DSC blocks

On Wed, 17 Apr 2024 at 02:57, Marijn Suijten wrote: > > Just like the active interface and writeback block in ctl_intf_cfg_v1(), > and later the rest of the blocks in followup active-CTL fixes or > reworks, multiple calls to this function should enable additional DSC > blocks instead of

Re: [PATCH 3/7] drm/msm/dpu: Always flush the slave INTF on the CTL

On Wed, 17 Apr 2024 at 02:57, Marijn Suijten wrote: > > As we can clearly see in a downstream kernel [1], flushing the slave INTF > is skipped /only if/ the PPSPLIT topology is active. > > However, when DPU was originally submitted to mainline PPSPLIT was no > longer part of it (seems to have

Re: [PATCH 2/7] drm/msm/dsi: Pass bonded-DSI hdisplay/2 to DSC timing configuration

On Wed, 17 Apr 2024 at 02:57, Marijn Suijten wrote: > > When configuring the timing of DSI hosts (interfaces) in > dsi_timing_setup() all values written to registers are taking bonded > DSI into account by dividing the original mode width by 2 (half the > data is sent over each of the two DSI

Re: [PATCH 1/7] drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk

On Wed, 17 Apr 2024 at 02:57, Marijn Suijten wrote: > > When dual-DSI (bonded DSI) was added in commit ed9976a09b48 > ("drm/msm/dsi: adjust dsi timing for dual dsi mode") some DBG() prints > were not updated, leading to print the original mode->clock rather > than the adjusted (typically the mode

Re: [PATCH 6/7] drm/msm/dsi: Set PHY usescase before registering DSI host

On Wed, 17 Apr 2024 at 02:57, Marijn Suijten wrote: > > Ordering issues here cause an uninitalized (default STANDALONE) > usecase to be programmed (which appears to be a MUX) in some cases > when msm_dsi_host_register() is called, leading to the slave PLL in > bonded-DSI mode to source from a