On Wed, Nov 22, 2023 at 02:26:55PM +0100, Andrzej Hajda wrote: > > > On 21.11.2023 13:06, Andrzej Hajda wrote: > > On 18.11.2023 00:01, Paz Zcharya wrote: > > > On Tue, Nov 14, 2023 at 10:13:59PM -0500, Rodrigo Vivi wrote: > > > > On Sun, Nov 05, 2023 at 05:27:03PM +0000, Paz Zcharya wrote: > > > > > > Hi Rodrigo, thanks for the great comments. > > > > > > Apologies for using a wrong/confusing terminology. I think 'phys_base' > > > is supposed to be the offset in the GEM BO, where base (or > > > "Surface Base Address") is supposed to be the GTT offset. > > > > Since base is taken from PLANE_SURF register it should be resolvable via > > GGTT to physical address pointing to actual framebuffer. > > I couldn't find anything in the specs. > > It was quite cryptic. I meant I have not found anything about assumption > from commit history that for iGPU there should be 1:1 mapping, this is why > there was an assignment "phys_base = base". Possibly the assumption is not > valid anymore for MTL(?). > Without the assumption we need to check GGTT to determine phys address. > > > The simplest approach would be then do the same as in case of DGFX: > > gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm; > > gen8_pte_t pte; > > > > gte += base / I915_GTT_PAGE_SIZE; > > > > pte = ioread64(gte); > > phys_base = pte & I915_GTT_PAGE_MASK; > > > > Regards > > Andrzej Hey Andrzej, Sorry for the late response. I was OOO :) I tried using the code you mentioned. It translates (in the very specific case of MTL + GOP driver) to phys_base == 0080_0000h. Unfortunately, it results in a corrupted screen -- the framebuffer is filled with zeros. It seems like `i915_vma_pin_ww` already reserves and binds the GEM BO to the correct address space independently of the value of `phys_base`. The only thing `phys_base` affects is the value of `stolen->start` https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/gem/i915_gem_stolen.c#L747 So it seems to me that the maybe `phys_base` is named incorrectly and that it does not reflect the physical address, but the start offset of i915->mm.stolen_region. I'm happy to run more tests / debug further. Do you have more ideas of things to try? Many thanks, Paz
