From: Paz Zcharya <pazz@chromium.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Subrata Banik <subratabanik@google.com>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
intel-gfx@lists.freedesktop.org,
Marcin Wojtas <mwojtas@chromium.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Sean Paul <seanpaul@chromium.org>,
matthew.auld@intel.com, Daniel Vetter <daniel@ffwll.ch>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Drew Davenport <ddavenport@chromium.org>,
David Airlie <airlied@gmail.com>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute
Date: Tue, 28 Nov 2023 01:20:46 +0000 [thread overview]
Message-ID: <ZWVAbpzBq9wN2WFy@google.com> (raw)
In-Reply-To: <6f08cfee-a60b-4f6e-b69a-20517c563259@intel.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Paz Zcharya <pazz@chromium.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Subrata Banik <subratabanik@google.com>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
intel-gfx@lists.freedesktop.org,
Marcin Wojtas <mwojtas@chromium.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Sean Paul <seanpaul@chromium.org>,
matthew.auld@intel.com, Rodrigo Vivi <rodrigo.vivi@intel.com>,
Drew Davenport <ddavenport@chromium.org>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute
Date: Tue, 28 Nov 2023 01:20:46 +0000 [thread overview]
Message-ID: <ZWVAbpzBq9wN2WFy@google.com> (raw)
In-Reply-To: <6f08cfee-a60b-4f6e-b69a-20517c563259@intel.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Paz Zcharya <pazz@chromium.org>
To: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
Subrata Banik <subratabanik@google.com>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Sean Paul <seanpaul@chromium.org>,
matthew.auld@intel.com, Daniel Vetter <daniel@ffwll.ch>,
Marcin Wojtas <mwojtas@chromium.org>,
Drew Davenport <ddavenport@chromium.org>,
David Airlie <airlied@gmail.com>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute
Date: Tue, 28 Nov 2023 01:20:46 +0000 [thread overview]
Message-ID: <ZWVAbpzBq9wN2WFy@google.com> (raw)
In-Reply-To: <6f08cfee-a60b-4f6e-b69a-20517c563259@intel.com>
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
next prev parent reply other threads:[~2023-11-28 1:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-05 17:27 [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute Paz Zcharya
2023-11-05 17:27 ` Paz Zcharya
2023-11-05 17:27 ` Paz Zcharya
2023-11-05 18:19 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
2023-11-15 3:13 ` [Intel-gfx] [PATCH] " Rodrigo Vivi
2023-11-15 3:13 ` Rodrigo Vivi
2023-11-15 3:13 ` Rodrigo Vivi
2023-11-17 23:01 ` Paz Zcharya
2023-11-17 23:01 ` Paz Zcharya
2023-11-17 23:01 ` Paz Zcharya
2023-11-21 12:06 ` Andrzej Hajda
2023-11-21 12:06 ` Andrzej Hajda
2023-11-22 13:26 ` Andrzej Hajda
2023-11-22 13:26 ` Andrzej Hajda
2023-11-28 1:20 ` Paz Zcharya [this message]
2023-11-28 1:20 ` Paz Zcharya
2023-11-28 1:20 ` Paz Zcharya
2023-11-28 3:47 ` Paz Zcharya
2023-11-28 3:47 ` Paz Zcharya
2023-11-28 3:47 ` Paz Zcharya
2023-11-28 11:12 ` Andrzej Hajda
2023-11-28 11:12 ` Andrzej Hajda
2023-11-28 11:12 ` Andrzej Hajda
2023-11-28 11:19 ` Paz Zcharya
2023-11-28 11:19 ` Paz Zcharya
2023-11-28 11:19 ` Paz Zcharya
2023-11-30 16:24 ` Paz Zcharya
2023-11-30 16:24 ` Paz Zcharya
2023-11-30 16:24 ` Paz Zcharya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZWVAbpzBq9wN2WFy@google.com \
--to=pazz@chromium.org \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=daniel@ffwll.ch \
--cc=ddavenport@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.auld@intel.com \
--cc=mwojtas@chromium.org \
--cc=nirmoy.das@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=seanpaul@chromium.org \
--cc=subratabanik@google.com \
--cc=tvrtko.ursulin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.