gt; - Check also if new/old_dbuf_state is not NULL, before getting single pipe
> and active pipes.
>
> Signed-off-by: Stanislav Lisovskiy
Thank you for this patch, Stanislav!
We tested it on a MTL-U based Chromebook (Screebo),
using different configurations (eDP, eDP + HDM
after_ DDB reallocation(i.e
> plane programming).
>
> Signed-off-by: Stanislav Lisovskiy
Thank you for this patch, Stanislav!
We tested it on a MTL-U based Chromebook (Screebo),
using different configurations (eDP, eDP + HDMI, HDMI, etc.), and
it worked well -- joined the mbus + no visual is
On Thu, Feb 01, 2024 at 11:22:16AM +0200, Jani Nikula wrote:
> On Wed, 31 Jan 2024, Paz Zcharya wrote:
> > Commit 8015bee0bfec ("drm/i915/display: Add framework to add parameters
> > specific to display") added the file intel_display_debugfs_params.c,
>
der file is breaking the ChromeOS build -- add an explicit include
to fix that.
Signed-off-by: Paz Zcharya
---
drivers/gpu/drm/i915/display/intel_display_debugfs_params.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs_params.c
b/drivers/
g/patch/570811/?series=127130=2
In addition, it solved the issue with the new GOP.
I tested it on two different devices with Meteor Lake and it worked perfectly:
no i915 errors, no flickers or observable issues.
Tested-by: Paz Zcharya
re we don't accidentlally pin it partially over the
> original ggtt range (as that would corrupt the original PTEs)
> we reserve the original range temporarily during this process.
>
> v2: Try to pin explicitly to ggtt offset 0 as otherwise DG2 puts it
> even higher (atm we have no PIN_L
gt; to pin the object into the final location in the ggtt...
>
> Cc: Paz Zcharya
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Ville Syrjälä
Hi Ville,
Thank you so much for this incredible series.
It solves the issue regarding MTL initial plane readout
that Andrzej Hajda and I worked on
ts
> as LMEM region.start==0, but for LMEMBAR stolen objects
> region.start!=0.
>
> TODO: perhaps just set smem_start=0 always as our .fb_mmap()
> implementation no longer depends on it? Need to double check
> it's not needed for anything else...
>
> Cc: Paz Zcharya
>
On Tue, Jan 16, 2024 at 09:56:32AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There's no reason the caller of intel_initial_plane_config() should
> have to loop over the CRTCs. Pull the loop into the function to
> make life simpler for the caller.
>
> Cc: Pa
the dma address from the pte as well
>
> Cc: Paz Zcharya
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Ville Syrjälä
Hi Ville,
Thank you so much for this incredible series.
It solves the issue regarding MTL initial plane readout
that Andrzej Hajda and I worked on in
https://patch
On Tue, Jan 16, 2024 at 09:56:30AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The address we read from the PTE is a dma address, not a physical
> address. Rename the variable to say so.
>
> Cc: Paz Zcharya
> Reviewed-by: Andrzej Hajda
> Signed-off-by:
v3 09/16] drm/i915: Fix MTL initial plane readout
> >
> > From: Ville Syrjälä
> >
> > MTL stolen memory looks more like local memory, so use the (now fixed) lmem
> > path when doing the initial plane readout.
>
> Looks Good to me.
> Reviewed-by: Uma Shankar
gt; memory region. We don't need to check the size as
> > i915_gem_object_create_region_at() should later fail if the object size
> > exceeds
> > the region size.
>
> Looks Good to me.
> Reviewed-by: Uma Shankar
>
> > Cc: Paz Zcharya
> > Signed-off-by: Vi
gt; > - should abstract the PTE decoding to avoid details leaking all over
> > - should probably do the readout for all the planes before
> > we touch anything (including the PTEs) so that we truly read
> >out the BIOS state
> >
> > Cc: Paz Zcharya
> > Revi
On Thu, Jan 25, 2024 at 12:28:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 0x108100 and 0x1080c0 have been around since snb. Rename the
> defines appropriately.
>
> v2: Rebase
>
> Cc: Paz Zcharya
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Ville
t
> (assuming the GPU is alive and well)?
>
> v2: Keep using MI_UPDATE_GTT on VM guests
> v3: use i915_direct_stolen_access()
>
> Cc: Paz Zcharya
> Cc: Nirmoy Das
> Signed-off-by: Ville Syrjälä
Hi Ville,
Thank you so much for this incredible series.
It solves the
; v3: Check register 0x138914 to see if pcode did its job
> Add some debug prints
>
> Cc: Paz Zcharya
> Cc: Nirmoy Das
> Cc: Joonas Lahtinen
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Ville Syrjälä
Hi Ville,
Thank you so much fo
ebugs to do similar
> > things elsewhere.
> >
> > Cc: Paz Zcharya
> > Reviewed-by: Andrzej Hajda
> > Signed-off-by: Ville Syrjälä
> Reviewed-by: Nirmoy Das
Hi Ville,
Thank you so much for this incredible series.
It solves the issue regarding MTL in
n debugging stuff.
> >
> > Cc: Paz Zcharya
> > Reviewed-by: Andrzej Hajda
> > Signed-off-by: Ville Syrjälä
> Reviewed-by: Nirmoy Das
Hi Ville,
Thank you so much for this incredible series.
It solves the issue regarding MTL initial plane readout
that Andrzej Hajda a
struct intel_memory_region *M;
> > @@
> > - M->io_start
> > + M->io.start
> >
> > @@
> > struct intel_memory_region M;
> > @@
> > - M.io_start
> > + M.io.start
> >
> > @@
> > expression M;
> > @@
> > - M->io_size
>
n points to system memory, starting at 0
- on DG2, it uses lmem region which starts at 0 as well
- on MTL, stolen_region points to stolen-local which starts at 0x80
Changes from v1:
- Add an if statement for gen7-, where there is a 1:1 mapping
Signed-off-by: Paz Zcharya
-
On Tue, Nov 28, 2023 at 12:12:08PM +0100, Andrzej Hajda wrote:
> On 28.11.2023 04:47, Paz Zcharya wrote:
> >
> > On Mon, Nov 27, 2023 at 8:20 PM Paz Zcharya wrote:
> > >
> > > On 21.11.2023 13:06, Andrzej Hajda wrote:
> > >
> > > > The
y, starting at 0
- on DG2, it uses lmem region which starts at 0 as well
- on MTL, stolen_region points to stolen-local which starts at 0x80
Signed-off-by: Paz Zcharya
---
.../drm/i915/display/intel_plane_initial.c| 45 +--
1 file changed, 22 insertions(+), 23 deletions(-)
dif
On Tue, Nov 28, 2023 at 12:12:08PM +0100, Andrzej Hajda wrote:
> On 28.11.2023 04:47, Paz Zcharya wrote:
> >
> > On Mon, Nov 27, 2023 at 8:20 PM Paz Zcharya wrote:
> >
> > Hey Andrzej,
> >
> > On a second thought, what do you think about something l
On Mon, Nov 27, 2023 at 8:20 PM Paz Zcharya 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 +,
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
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:
> > Fix the value of variable `phys_base` to be the relative offset in
> > stolen memory, and not the absolute offset of the GSM.
>
> to me it loo
m_object_create_region
i915_gem_object_create_region_at
initial_plane_vma
intel_alloc_initial_plane_obj
intel_find_initial_plane_obj
intel_crtc_initial_plane_config
[drm:_i915_gem_object_stolen_init] creating preallocated stolen
object: stolen_offset=0x, size=0x008ca000
Sign
On Wed, Nov 01, 2023 at 06:26:47AM +, Hogander, Jouni wrote:
> On Tue, 2023-10-31 at 23:21 +0000, Paz Zcharya wrote:
> > Currently, i915 fails fastset if both the sink and the source support
> > any version of PSR and regardless of the configuration setting of the
> &g
. Accordingly, do not fail fastset
if PSR2 is not enabled.
Signed-off-by: Paz Zcharya
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
drivers/gpu/drm/i915/display/intel_psr.h | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git
30 matches
Mail list logo
