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(-)
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
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.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@oss.qualcomm.com>
On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <konradybcio@kernel.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@oss.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@oss.qualcomm.com> >
On 1/9/26 8:11 PM, Connor Abbott wrote: > On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <konradybcio@kernel.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. You're right, sorry for that Konrad
On Fri, Jan 09, 2026 at 02:11:19PM -0500, Connor Abbott wrote: > On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <konradybcio@kernel.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. Which, unfortunately, also means that Iris / Venus must also start using the UBWC config API beforehand. -- With best wishes Dmitry
On Fri, Jan 9, 2026 at 11:11 AM Connor Abbott <cwabbott0@gmail.com> wrote:
>
> On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <konradybcio@kernel.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.
Hmm, how is this even working today if DPU is using HBB from the
global table but GPU is not? Are we just getting lucky with
compositors that don't know about modifiers and end up scanning out
linear?
We do log warnings when the global ubwc config does not match the
"fixed up" config.. google search for those msgs doesn't seem to turn
up anything other than the patch which introduced them. Idk if that
is conclusive in any way, but I hope that means we could just delete
the fixup code on the GPU side. I suppose we could add:
*cfg = *common_cfg;
after the warning as a first step. That would maybe get some bug
reports along with enough details in dmesg?
BR,
-R
> Connor
>
> >
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.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@oss.qualcomm.com>
> >
On Fri, Jan 9, 2026 at 3:41 PM Rob Clark <rob.clark@oss.qualcomm.com> wrote: > > On Fri, Jan 9, 2026 at 11:11 AM Connor Abbott <cwabbott0@gmail.com> wrote: > > > > On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <konradybcio@kernel.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. > > Hmm, how is this even working today if DPU is using HBB from the > global table but GPU is not? Are we just getting lucky with > compositors that don't know about modifiers and end up scanning out > linear? It works out as well as it's always worked out, i.e. we try to make GPU and DPU config match and pray that we didn't mess it up. At least now we'll get a warning when they don't match. > > We do log warnings when the global ubwc config does not match the > "fixed up" config.. google search for those msgs doesn't seem to turn > up anything other than the patch which introduced them. Idk if that > is conclusive in any way, but I hope that means we could just delete > the fixup code on the GPU side. I suppose we could add: > > *cfg = *common_cfg; > > after the warning as a first step. That would maybe get some bug > reports along with enough details in dmesg? Yes, the plan was always to delete the fixup code in the GPU config. And even that first step would be enough to prevent regressions when switching to the bootloader HBB value. There is a problem in that ubwc_swizzle isn't as well tested. Older parts supporting UBWC 1.0-3.0 partially or entirely ignore ubwc_swizzle, because it wasn't configurable back then, but we rely on it being set correctly in Mesa for VK_EXT_host_image_copy and sparse textures. So if ubwc_swizzle is incorrect you probably wouldn't notice, until you hit the HIC codepath in zink or some game using sparse textures. I think we fixed up all the cases where it was incorrectly set to 0x1 instead of 0x7, but it would be worth it to check again. Connor > > BR, > -R > > > Connor > > > > > > > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.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@oss.qualcomm.com> > > >
On Fri, Jan 9, 2026 at 1:03 PM Connor Abbott <cwabbott0@gmail.com> wrote: > > On Fri, Jan 9, 2026 at 3:41 PM Rob Clark <rob.clark@oss.qualcomm.com> wrote: > > > > On Fri, Jan 9, 2026 at 11:11 AM Connor Abbott <cwabbott0@gmail.com> wrote: > > > > > > On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <konradybcio@kernel.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. > > > > Hmm, how is this even working today if DPU is using HBB from the > > global table but GPU is not? Are we just getting lucky with > > compositors that don't know about modifiers and end up scanning out > > linear? > > It works out as well as it's always worked out, i.e. we try to make > GPU and DPU config match and pray that we didn't mess it up. At least > now we'll get a warning when they don't match. I mean, upstream we kinda have a lack of feedback metrics other than people reporting bugs... so maybe the first step is to break it with *cfg = *common_cfg; and see what happens. > > > > We do log warnings when the global ubwc config does not match the > > "fixed up" config.. google search for those msgs doesn't seem to turn > > up anything other than the patch which introduced them. Idk if that > > is conclusive in any way, but I hope that means we could just delete > > the fixup code on the GPU side. I suppose we could add: > > > > *cfg = *common_cfg; > > > > after the warning as a first step. That would maybe get some bug > > reports along with enough details in dmesg? > > Yes, the plan was always to delete the fixup code in the GPU config. > And even that first step would be enough to prevent regressions when > switching to the bootloader HBB value. > > There is a problem in that ubwc_swizzle isn't as well tested. Older > parts supporting UBWC 1.0-3.0 partially or entirely ignore > ubwc_swizzle, because it wasn't configurable back then, but we rely on > it being set correctly in Mesa for VK_EXT_host_image_copy and sparse > textures. So if ubwc_swizzle is incorrect you probably wouldn't > notice, until you hit the HIC codepath in zink or some game using > sparse textures. I think we fixed up all the cases where it was > incorrectly set to 0x1 instead of 0x7, but it would be worth it to > check again. There are a lot more things out there than there are things running games that would hit that. Idk about zink, but there is a gallium driver. Either way, we don't have metrics feedback so the only option is to break things with enough info in dmesg to figure out what is going wrong AFAICT. BR, -R > > Connor > > > > > BR, > > -R > > > > > Connor > > > > > > > > > > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.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@oss.qualcomm.com> > > > >
On 1/8/26 15:21, Konrad Dybcio 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 > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.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, Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK root@qemuarm64:~# cat /sys/kernel/debug/qcom_smem/ dram_frequencies hbb root@qemuarm64:~# cat /sys/kernel/debug/qcom_smem/dram_frequencies 200000000 547200000 768000000 1555200000 1708800000 2092800000 2736000000 3187200000 3686400000 4224000000 root@qemuarm64:~# cat /sys/kernel/debug/qcom_smem/hbb 16 Thanks, Neil
Hi,
On 1/8/26 15:21, Konrad Dybcio 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
While trying it, I got the following warning:
In function ‘smem_dram_parse_v3_data’,
inlined from ‘smem_dram_parse’ at drivers/soc/qcom/smem_dramc.c:380:3:
drivers/soc/qcom/smem_dramc.c:216:31: warning: iteration 13 invokes undefined behavior [-Waggressive-loop-optimizations]
216 | if (freq_entry->freq_khz && freq_entry->enabled)
| ~~~~~~~~~~^~~~~~~~~~
drivers/soc/qcom/smem_dramc.c:213:27: note: within this loop
213 | for (int i = 0; i < num_freq_entries; i++) {
| ~~^~~~~~~~~~~~~~~~~~
Neil
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.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,
On 1/9/26 9:20 AM, Neil Armstrong wrote:
> Hi,
>
> On 1/8/26 15:21, Konrad Dybcio 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
>
>
> While trying it, I got the following warning:
>
> In function ‘smem_dram_parse_v3_data’,
> inlined from ‘smem_dram_parse’ at drivers/soc/qcom/smem_dramc.c:380:3:
> drivers/soc/qcom/smem_dramc.c:216:31: warning: iteration 13 invokes undefined behavior [-Waggressive-loop-optimizations]
> 216 | if (freq_entry->freq_khz && freq_entry->enabled)
> | ~~~~~~~~~~^~~~~~~~~~
> drivers/soc/qcom/smem_dramc.c:213:27: note: within this loop
> 213 | for (int i = 0; i < num_freq_entries; i++) {
> | ~~^~~~~~~~~~~~~~~~~~
clang didn't seem to care..
A (really grumpy) solution would be to add:
diff --git a/drivers/soc/qcom/smem_dramc.c b/drivers/soc/qcom/smem_dramc.c
index 017bb894a91b..dc2cd7e13b88 100644
--- a/drivers/soc/qcom/smem_dramc.c
+++ b/drivers/soc/qcom/smem_dramc.c
@@ -78,7 +78,7 @@ struct ddr_freq_table {
/* V3 */
struct ddr_freq_plan_v3 {
- struct ddr_freq_table ddr_freq[MAX_DDR_FREQ_NUM_V3]; /* NOTE: some have 14 like v5 */
+ struct ddr_freq_table ddr_freq[MAX_DDR_FREQ_NUM_V3];
u8 num_ddr_freqs;
phys_addr_t clk_period_address;
};
@@ -91,6 +91,21 @@ struct ddr_details_v3 {
u8 num_channels;
};
+/* Some V3 structs have an additional frequency level */
+struct ddr_freq_plan_v3_14freqs {
+ struct ddr_freq_table ddr_freq[MAX_DDR_FREQ_NUM_V3 + 1];
+ u8 num_ddr_freqs;
+ phys_addr_t clk_period_address;
+};
+
+struct ddr_details_v3_14freqs {
+ u8 manufacturer_id;
+ u8 device_type;
+ struct ddr_part_details ddr_params[MAX_CHAN_NUM];
+ struct ddr_freq_plan_v3_14freqs ddr_freq_tbl;
+ u8 num_channels;
+};
+
/* V4 */
struct ddr_details_v4 {
u8 manufacturer_id;
@@ -201,16 +216,11 @@ int qcom_smem_dram_get_hbb(void)
}
EXPORT_SYMBOL_GPL(qcom_smem_dram_get_hbb);
-static void smem_dram_parse_v3_data(struct smem_dram *dram, void *data, bool additional_freq_entry)
+static void smem_dram_parse_v3_data(struct smem_dram *dram, void *data)
{
- /* This may be 13 or 14 */
- int num_freq_entries = MAX_DDR_FREQ_NUM_V3;
struct ddr_details_v3 *details = data;
- if (additional_freq_entry)
- num_freq_entries++;
-
- for (int i = 0; i < num_freq_entries; i++) {
+ for (int i = 0; i < MAX_DDR_FREQ_NUM_V3; i++) {
struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
if (freq_entry->freq_khz && freq_entry->enabled)
@@ -218,6 +228,18 @@ static void smem_dram_parse_v3_data(struct smem_dram *dram, void *data, bool add
}
}
+static void smem_dram_parse_v3_14freqs_data(struct smem_dram *dram, void *data)
+{
+ struct ddr_details_v3_14freqs *details = data;
+
+ for (int i = 0; i < MAX_DDR_FREQ_NUM_V3 + 1; i++) {
+ struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
+
+ if (freq_entry->freq_khz && freq_entry->enabled)
+ dram->frequencies[dram->num_frequencies++] = 1000 * freq_entry->freq_khz;
+ }
+}
+
static void smem_dram_parse_v4_data(struct smem_dram *dram, void *data)
{
struct ddr_details_v4 *details = data;
@@ -273,8 +295,7 @@ static int smem_dram_infer_struct_version(size_t size)
if (size == sizeof(struct ddr_details_v3))
return INFO_V3;
- if (size == sizeof(struct ddr_details_v3)
- + sizeof(struct ddr_freq_table))
+ if (size == sizeof(struct ddr_details_v3_14freqs))
return INFO_V3_WITH_14_FREQS;
if (size == sizeof(struct ddr_details_v4))
@@ -374,10 +395,10 @@ struct dentry *smem_dram_parse(struct device *dev)
switch (ver) {
case INFO_V3:
- smem_dram_parse_v3_data(dram, data, false);
+ smem_dram_parse_v3_data(dram, data);
break;
case INFO_V3_WITH_14_FREQS:
- smem_dram_parse_v3_data(dram, data, true);
+ smem_dram_parse_v3_14freqs_data(dram, data);
break;
case INFO_V4:
smem_dram_parse_v4_data(dram, data);
A less grumpy one that I'm not sure would make the compiler happy would be:
diff --git a/drivers/soc/qcom/smem_dramc.c b/drivers/soc/qcom/smem_dramc.c
index 017bb894a91b..3653402fa70c 100644
--- a/drivers/soc/qcom/smem_dramc.c
+++ b/drivers/soc/qcom/smem_dramc.c
@@ -206,15 +206,16 @@ static void smem_dram_parse_v3_data(struct smem_dram *dram, void *data, bool add
/* This may be 13 or 14 */
int num_freq_entries = MAX_DDR_FREQ_NUM_V3;
struct ddr_details_v3 *details = data;
+ struct ddr_freq_table *freq_entry;
if (additional_freq_entry)
num_freq_entries++;
- for (int i = 0; i < num_freq_entries; i++) {
- struct ddr_freq_table *freq_entry = &details->ddr_freq_tbl.ddr_freq[i];
+ freq_entry = details->ddr_freq_tbl.ddr_freq;
+ for (int i = 0; i < num_freq_entries; i++) {
if (freq_entry->freq_khz && freq_entry->enabled)
- dram->frequencies[dram->num_frequencies++] = 1000 * freq_entry->freq_khz;
+ dram->frequencies[dram->num_frequencies++] = 1000 * (freq_entry++)->freq_khz;
}
}
WDYT?
Konrad
© 2016 - 2026 Red Hat, Inc.