On Tue, Feb 17, 2026 at 6:23 AM Konrad Dybcio <[email protected]> wrote: > > 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
Just to double-check the kernel, and I double-checked since then and everything seems to be right. Connor
