[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACu1E7EDmLPhUFyouD=W6n+U7=oo7+6PY0Gz9=3pVpT2Qu9Z6w@mail.gmail.com>
Date: Fri, 9 Jan 2026 14:11:19 -0500
From: Connor Abbott <cwabbott0@...il.com>
To: Konrad Dybcio <konradybcio@...nel.org>
Cc: Bjorn Andersson <andersson@...nel.org>, Kees Cook <kees@...nel.org>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>, Rob Clark <robin.clark@....qualcomm.com>,
Sean Paul <sean@...rly.run>, Akhil P Oommen <akhilpo@....qualcomm.com>,
Dmitry Baryshkov <lumag@...nel.org>, Abhinav Kumar <abhinav.kumar@...ux.dev>,
Jessica Zhang <jesszhan0024@...il.com>, Marijn Suijten <marijn.suijten@...ainline.org>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-hardening@...r.kernel.org,
dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH v3 0/3] Retrieve information about DDR from SMEM
On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <konradybcio@...nel.org> wrote:
>
> SMEM allows the OS to retrieve information about the DDR memory.
> Among that information, is a semi-magic value called 'HBB', or Highest
> Bank address Bit, which multimedia drivers (for hardware like Adreno
> and MDSS) must retrieve in order to program the IP blocks correctly.
>
> This series introduces an API to retrieve that value, uses it in the
> aforementioned programming sequences and exposes available DDR
> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More
> information can be exposed in the future, as needed.
>
> Patch 3 should really be merged after 1&2
No. The HBB value currently returned by the bootloader is *not* always
the same as what we use currently, because some SoCs (like SM8250)
with the same DT ship with multiple different DRAM configurations and
we've been using a sub-optimal value the whole time. After all, that's
the whole point of using the bootloader value. But patches 1&2 will
only make the DPU use the bootloader value for HBB, not the GPU. So on
one of the affected SoCs, it will introduce a mismatch. You can't
change anything until the GPU side uses the new ubwc config as its
source of truth.
Connor
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
> ---
> Changes in v3:
> - Support v6 and v7 DDRInfo (v7 is used on e.g. Hamoa)
> - Handle rare cases of DDRInfo v5 with additional trailing data
> - Rebase/adjust to SSoT UBWC
> - Expose hbb value in debugfs
> - cosmetic changes
> - Link to v2: https://lore.kernel.org/r/20250410-topic-smem_dramc-v2-0-dead15264714@oss.qualcomm.com
>
> Changes in v2:
> - Avoid checking for < 0 on unsigned types
> - Overwrite Adreno UBWC data to keep the data shared with userspace
> coherent with what's programmed into the hardware
> - Call get_hbb() in msm_mdss_enable() instead of all UBWC setup
> branches separately
> - Pick up Bjorn's rb on patch 1
> - Link to v1: https://lore.kernel.org/r/20250409-topic-smem_dramc-v1-0-94d505cd5593@oss.qualcomm.com
>
> ---
> Konrad Dybcio (3):
> soc: qcom: smem: Expose DDR data from SMEM
> soc: qcom: ubwc: Get HBB from SMEM
> drm/msm/adreno: Trust the SSoT UBWC config
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 11 +-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 82 +------
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 -
> drivers/soc/qcom/Makefile | 3 +-
> drivers/soc/qcom/smem.c | 14 +-
> drivers/soc/qcom/smem.h | 9 +
> drivers/soc/qcom/smem_dramc.c | 408 ++++++++++++++++++++++++++++++++
> drivers/soc/qcom/ubwc_config.c | 69 ++++--
> include/linux/soc/qcom/smem.h | 4 +
> 9 files changed, 485 insertions(+), 120 deletions(-)
> ---
> base-commit: fc4e91c639c0af93d63c3d5bc0ee45515dd7504a
> change-id: 20250409-topic-smem_dramc-6467187ac865
>
> Best regards,
> --
> Konrad Dybcio <konrad.dybcio@....qualcomm.com>
>
Powered by blists - more mailing lists