On 1/9/26 10:03 PM, Connor Abbott wrote: > On Fri, Jan 9, 2026 at 3:41 PM Rob Clark <[email protected]> wrote: >> >> On Fri, Jan 9, 2026 at 11:11 AM Connor Abbott <[email protected]> wrote: >>> >>> On Thu, Jan 8, 2026 at 9:22 AM Konrad Dybcio <[email protected]> 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.
Just to double-check, is your expectation to just double-check the kernel settings, or would that require some intervention on the mesa side too? Konrad
