* assume ELK doesn't need this.
Yeah, ELK = Eagle Lake, CTG = Cantiga. Both are old gen5 platforms IIRC.
Matt
>
> Lucas De Marchi
>
> >
> > BR,
> > Jani.
> >
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
;> + INTEL_JASPERLAKE,
> >>/* gen12 */
> >>INTEL_TIGERLAKE,
> >>INTEL_ROCKETLAKE,
> >> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> >> index 7eeecb07c9a1..1b5e09cfa11e 100644
> >> --- a/include/drm/i915_pciids.h
> >> +++ b/include/drm/i915_pciids.h
> >> @@ -579,15 +579,18 @@
> >>INTEL_VGA_DEVICE(0x8A51, info), \
> >>INTEL_VGA_DEVICE(0x8A5D, info)
> >>
> >> -/* EHL/JSL */
> >> +/* EHL */
> >> #define INTEL_EHL_IDS(info) \
> >>INTEL_VGA_DEVICE(0x4500, info), \
> >>INTEL_VGA_DEVICE(0x4571, info), \
> >>INTEL_VGA_DEVICE(0x4551, info), \
> >>INTEL_VGA_DEVICE(0x4541, info), \
> >> - INTEL_VGA_DEVICE(0x4E71, info), \
> >>INTEL_VGA_DEVICE(0x4557, info), \
> >> - INTEL_VGA_DEVICE(0x4555, info), \
> >> + INTEL_VGA_DEVICE(0x4555, info)
> >> +
> >> +/* JSL */
> >> +#define INTEL_JSL_IDS(info) \
> >> + INTEL_VGA_DEVICE(0x4E71, info), \
> >>INTEL_VGA_DEVICE(0x4E61, info), \
> >>INTEL_VGA_DEVICE(0x4E57, info), \
> >>INTEL_VGA_DEVICE(0x4E55, info), \
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
nitialization step")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1094
> Signed-off-by: Nathan Chancellor
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
rts.
> >
> >> Overall I like the idea, but too lazy to review.
> >
> > Cool. General comments on the idea was all I was looking for for the
> > moment. Spare yor review cycles for the next version ;)
> >
> >> Oh, some kselftests for this stuff would be lovely.
> >
> > I'll look into it.
> >
> > thanks,
> > Gerd
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
ral comments on the idea was all I was looking for for the
> > moment. Spare yor review cycles for the next version ;)
> >
> >> Oh, some kselftests for this stuff would be lovely.
> >
> > I'll look into it.
> >
> > thanks,
> > Gerd
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
t;
> > Date: Sun Dec 3 11:01:47 2017 -0500
> >
> > Linux 4.15-rc2
> >
> > https://github.com/downor/linux_hyper_dmabuf.git hyper_dmabuf_integration_v3
> >
> > ___
> > dri-devel mailing
: Sun Dec 3 11:01:47 2017 -0500
> >
> > Linux 4.15-rc2
> >
> > https://github.com/downor/linux_hyper_dmabuf.git hyper_dmabuf_integration_v3
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
On Mon, Jul 31, 2017 at 10:36:05AM +0200, Jean Delvare wrote:
> Hi Matt, Mauro,
>
> On Thu, 17 Mar 2016 15:18:20 +0100, Jean Delvare wrote:
> > On Tue, 8 Mar 2016 10:32:37 -0800, Matt Roper wrote:
> > > A couple of the EDAC drivers have a nice memdev_dmi_entry structur
On Mon, Jul 31, 2017 at 10:36:05AM +0200, Jean Delvare wrote:
> Hi Matt, Mauro,
>
> On Thu, 17 Mar 2016 15:18:20 +0100, Jean Delvare wrote:
> > On Tue, 8 Mar 2016 10:32:37 -0800, Matt Roper wrote:
> > > A couple of the EDAC drivers have a nice memdev_dmi_entry structur
ermark programming (v11)
>
>
> Nothing from the graphics developers? Come on, here is someone who
> found a specific patch that causes a problem, and no one responds?
>
> Why isn't this fixed by reverting the above mentioned patch in Linus's
> tree already? Or, is there
ermark programming (v11)
>
>
> Nothing from the graphics developers? Come on, here is someone who
> found a specific patch that causes a problem, and no one responds?
>
> Why isn't this fixed by reverting the above mentioned patch in Linus's
> tree already? Or, is there
es: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
> > Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
> > Signed-off-by: Lyude <cp...@redhat.com>
> > [omitting CC for stable, since this patch will need to be changed for
>
0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
> > Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
> > Signed-off-by: Lyude
> > [omitting CC for stable, since this patch will need to be changed for
> &g
On Wed, Aug 03, 2016 at 02:14:53PM -0700, Matt Roper wrote:
...
>
> I imagine we'll eventually probably want to create a new display vfunc
> to handle platform-specific pipe-level stuff that needs to happen under
> vblank evasion (like the scalers and linetime WM we have today) to kee
On Wed, Aug 03, 2016 at 02:14:53PM -0700, Matt Roper wrote:
...
>
> I imagine we'll eventually probably want to create a new display vfunc
> to handle platform-specific pipe-level stuff that needs to happen under
> vblank evasion (like the scalers and linetime WM we have today) to kee
On Tue, Aug 02, 2016 at 02:20:33PM -0700, Matt Roper wrote:
> On Tue, Aug 02, 2016 at 02:52:51PM -0400, Lyude wrote:
> > Thanks to Ville for suggesting this as a potential solution to pipe
> > underruns on Skylake.
> >
> > On Skylake all of the registers for co
On Tue, Aug 02, 2016 at 02:20:33PM -0700, Matt Roper wrote:
> On Tue, Aug 02, 2016 at 02:52:51PM -0400, Lyude wrote:
> > Thanks to Ville for suggesting this as a potential solution to pipe
> > underruns on Skylake.
> >
> > On Skylake all of the registers for co
se needs braces, you need to put them on both branches).
> + if (result == 1)
As I mentioned before, the 1=off looks confusing if someone isn't
looking at the bspec carefully. Using a #define for the various 0x1's
in this patch might help clarify the code slightly.
se needs braces, you need to put them on both branches).
> + if (result == 1)
As I mentioned before, the 1=off looks confusing if someone isn't
looking at the bspec carefully. Using a #define for the various 0x1's
in this patch might help clarify the code slightly.
With
bdf5e ("drm/i915/skl: Program the DDB allocation")
> Signed-off-by: Lyude <cp...@redhat.com>
> [omitting CC for stable, since this patch will need to be changed for
> such backports first]
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Daniel Vette
8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
> Signed-off-by: Lyude
> [omitting CC for stable, since this patch will need to be changed for
> such backports first]
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
> Cc: Hans de Goede
> Cc: M
for stable, since this patch will need to be changed for
> such backports first]
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Radhakrishna Sripada <radhakrishna.srip...@intel.com>
> Cc: Hans de
his patch will need to be changed for
> such backports first]
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
> Cc: Hans de Goede
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 74
&
vblank evasion
>
> Changes since v3:
> - Rebase against new SAGV patch changes
>
> Changes since v4:
> - Add a parameter to choose what skl_wm_values struct to use when
>writing new plane watermarks
>
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Wate
vblank evasion
>
> Changes since v3:
> - Rebase against new SAGV patch changes
>
> Changes since v4:
> - Add a parameter to choose what skl_wm_values struct to use when
>writing new plane watermarks
>
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Comput
ate if we have a change in
active pipes. I think what you meant to write was "...we'll need to
modify the watermarks on all active *planes*. Since those *planes*
won't..."
Aside from the commit message, I believe the logic is correct, so you
can consider this
Reviewed-by: Matt
ate if we have a change in
active pipes. I think what you meant to write was "...we'll need to
modify the watermarks on all active *planes*. Since those *planes*
won't..."
Aside from the commit message, I believe the logic is correct, so you
can consider this
Reviewed-by: M
te(): (temp & 0x1) indicates disabled, 0x0
>enabled
> - Call skl_sagv_enable/disable() from pre/post-plane updates
> Changes since v3:
> - Use time_before() to compare timeout to jiffies
> Changes since v2:
> - Really apply minor style nitpicks to patch this time
>
te(): (temp & 0x1) indicates disabled, 0x0
>enabled
> - Call skl_sagv_enable/disable() from pre/post-plane updates
> Changes since v3:
> - Use time_before() to compare timeout to jiffies
> Changes since v2:
> - Really apply minor style nitpicks to patch this time
>
> we've got enough workarounds to make this tolerable. I've shown this to
> > matt roper, but I should probably post what I've been trying to do for
> > you as well.
> >
> > So the approach I came up with is here
> >
> > https://github.com/lyude/linux/tree/wip/skl-fi
> we've got enough workarounds to make this tolerable. I've shown this to
> > matt roper, but I should probably post what I've been trying to do for
> > you as well.
> >
> > So the approach I came up with is here
> >
> > https://github.com/lyude/linux/tree/wip/skl-fi
On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
> > This is completely untested (and probably horribly broken/buggy), but
> > here's a quick mockup of the general approach I was thinking for
> > en
On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
> > This is completely untested (and probably horribly broken/buggy), but
> > here's a quick mockup of the general approach I was thinking for
> > en
mically during plane updates
> drm/i915/skl: Always wait for pipes to update after a flush
>
> Matt Roper (1):
> drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
>
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h |
mically during plane updates
> drm/i915/skl: Always wait for pipes to update after a flush
>
> Matt Roper (1):
> drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
>
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h |
ing vblank evasion
>
> Changes since v3:
> - Rebase against new SAGV patch changes
>
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
> Signed-off-by: Lyude <cp...@redhat.com>
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä <ville.syrj...@
ng vblank evasion
>
> Changes since v3:
> - Rebase against new SAGV patch changes
>
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
> Signed-off-by: Lyude
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakris
com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Radhakrishna Sripada <radhakrishna.srip...@intel.com>
> Cc: Hans de Goede <hdego...@redhat.com>
> Cc: Matt Roper <matthew.d.ro...@intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers
very time we have to update the watermark values because the cursor was
> moving between screens will introduce a rather noticable lag for users.
>
> Signed-off-by: Lyude
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
>
minor style nitpicks to patch this time
> Changes since v1:
> - Added comments about this probably being one of the requirements to
>fixing Skylake's watermark issues
> - Minor style nitpicks from Matt Roper
> - Disable these functions on Broxton, since it doesn't have an SAGV
>
minor style nitpicks to patch this time
> Changes since v1:
> - Added comments about this probably being one of the requirements to
>fixing Skylake's watermark issues
> - Minor style nitpicks from Matt Roper
> - Disable these functions on Broxton, since it doesn't have an SAGV
>
k Computation")
> Signed-off-by: Lyude <cp...@redhat.com>
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Radhakrishna Sripada <radhakrishna.srip...@intel.com>
> Cc: Ha
N9() instead of IS_SKYLAKE() since these fixes apply to more
>then just Skylake
> - Update description to make it clear this patch doesn't fix everything
> - Check if pipes were actually changed before writing watermarks
>
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark
com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Radhakrishna Sripada <radhakrishna.srip...@intel.com>
> Cc: Hans de Goede <hdego...@redhat.com>
> Cc: Matt Roper <matthew.d.ro...@intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers
very time we have to update the watermark values because the cursor was
> moving between screens will introduce a rather noticable lag for users.
>
> Signed-off-by: Lyude
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
>
. (Jean)
Cc: Mauro Carvalho Chehab <mche...@osg.samsung.com>
Cc: Jean Delvare <jdelv...@suse.com>
Cc: linux-e...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Roper <matthew.d.ro...@intel.com>
---
drivers/edac/ghes_edac.c | 28 +--
. (Jean)
Cc: Mauro Carvalho Chehab
Cc: Jean Delvare
Cc: linux-e...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Roper
---
drivers/edac/ghes_edac.c | 28 +--
drivers/edac/i7core_edac.c | 47 +++---
include
soon as well.
Cc: Mauro Carvalho Chehab <mche...@osg.samsung.com>
Cc: Jean Delvare <jdelv...@suse.com>
Cc: linux-e...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Roper <matthew.d.ro...@intel.com>
---
drivers/edac/ghes_edac.c | 26 --
soon as well.
Cc: Mauro Carvalho Chehab
Cc: Jean Delvare
Cc: linux-e...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Roper
---
drivers/edac/ghes_edac.c | 26 --
drivers/edac/i7core_edac.c | 25 -
include/linux/dmi.h
0x4a/0x140
> > > > [] process_one_work+0x1fd/0x670
> > > > [] ? process_one_work+0x16c/0x670
> > > > [] worker_thread+0x4e/0x450
> > > > [] ? process_one_work+0x670/0x670
> > > > [] kthread+0x101/0x120
> > > > [] ? k
0x4a/0x140
> > > > [] process_one_work+0x1fd/0x670
> > > > [] ? process_one_work+0x16c/0x670
> > > > [] worker_thread+0x4e/0x450
> > > > [] ? process_one_work+0x670/0x670
> > > > [] kthread+0x101/0x120
> > > > [] ? k
handler [i915]]
> *ERROR* CPU pipe A FIFO underrun
>
> Always setting the panes to enabled fixes this error.
>
> Helped-by: Matt Roper
> Signed-off-by: Thomas Gummerer
Seems like a reasonable short-term workaround and returns us to how the
code used to behaves.
Reviewed-by: Ma
setting the panes to enabled fixes this error.
Helped-by: Matt Roper matthew.d.ro...@intel.com
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
Seems like a reasonable short-term workaround and returns us to how the
code used to behaves.
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
fb->bits_per_pixel / 8;
else
- p->pri.bytes_per_pixel = 0;
+ p->pri.bytes_per_pixel = 4;
p->cur.bytes_per_pixel = 4;
/*
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling &
= 4;
p-cur.bytes_per_pixel = 4;
/*
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling Development
Intel Corporation
(916) 356-2795
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
>intel_crtc->cursor_width = state->base.crtc_w;
> >>intel_crtc->cursor_height = state->base.crtc_h;
> >>
> >> - if (intel_crtc->active)
> >> + if (intel_crtc->active) {
> >> + if (old_width != intel_crtc->cursor_wi
://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling Development
Intel Corporation
(916) 356-2795
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Bug 93711 <https://bugzilla.kernel.org/show_bug.cgi?id=93711>
>
> Is this a problem with drm-intel-nightly? In particular see
>
> commit afd65eb4cc0578a9c07d621acdb8a570e2782bf7
> Author: Matt Roper
> Date: Tue Feb 3 13:10:04 2015 -0800
>
> drm/i915: Ensure plane->state->fb stay
Author: Matt Roper matthew.d.ro...@intel.com
Date: Tue Feb 3 13:10:04 2015 -0800
drm/i915: Ensure plane-state-fb stays in sync with plane-fb
Matt, do you think this fixes the described issue? Can we backport to
drm-intel-fixes (and v4.0)?
BR,
Jani.
Yeah, Xi's patch should
This won't solve the case if userspace uses a different framebuffer for
each update (while trying to update faster than the refresh rate). Is
there any existing userspace that behaves this way that we can test
with?
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling &
framebuffer for
each update (while trying to update faster than the refresh rate). Is
there any existing userspace that behaves this way that we can test
with?
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling Development
Intel Corporation
(916) 356-2795
--
To unsubscribe from
evel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
--
To unsubscribe from this list: send the line "unsubscribe
/listinfo/dri-devel
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling Development
Intel Corporation
(916) 356-2795
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
63 matches
Mail list logo
