From: Tvrtko Ursulin
Currently to establish whether GuC firmware has been loaded or
submission enabled (default DRM log level), one has to detect
the absence of the message saying that the load has been skipped
and infer the opposite.
It is better to log the fact GuC firmware has been loaded and
On Tue, Feb 07, 2017 at 08:50:25AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Currently to establish whether GuC firmware has been loaded or
> submission enabled (default DRM log level), one has to detect
> the absence of the message saying that the load has been skipped
> and infer
On Mon, Feb 06, 2017 at 09:51:46AM +, Chris Wilson wrote:
> Once upon a time before we had automated GPU state capture upon hangs,
> we had intel_gpu_dump. Now we come almost full circle and reinstate that
> view of the current GPU queues and registers by using the error capture
> facility to s
On Mon, Feb 06, 2017 at 02:32:17PM +0200, Joonas Lahtinen wrote:
> On ma, 2017-02-06 at 09:51 +, Chris Wilson wrote:
> > Handling the dynamic charp module parameter requires us to copy it for
> > the error state, or remember to lock it when reading (in case it used
> > with 0600).
> >
> > Sign
== Series Details ==
Series: drm/i915/guc: Log significant events at the info level (rev2)
URL : https://patchwork.freedesktop.org/series/19158/
State : success
== Summary ==
Series 19158v2 drm/i915/guc: Log significant events at the info level
https://patchwork.freedesktop.org/api/1.0/series/
On Tue, 07 Feb 2017, Rami Vanguri wrote:
> [1.] One line summary of the problem:
> Screen flickering under highest resolution (3840x2160) with external
> monitor connected to DisplayPort. This is with an X1 Carbon (3rd
> generation) and flickering only happens on external monitor and only
> on hi
Hi Chris:
Thanks for the explanation! :P Have you already sent the patch to
keep PD structure under aliasing PPGTT mode? I tried drm-intel-nightly
branch and still got kernel panic under aliasing PPGTT mode. T_T
I fixed it like this, is this acceptable as a hot fix? If it's
acceptable as
On Tue, Feb 07, 2017 at 05:22:33PM +0800, Zhi Wang wrote:
> Hi Chris:
> Thanks for the explanation! :P Have you already sent the patch
> to keep PD structure under aliasing PPGTT mode? I tried
> drm-intel-nightly branch and still got kernel panic under aliasing
> PPGTT mode. T_T
It's on the li
Following a reset, the context and page directory registers are lost.
However, the queue of requests that we resubmit after the reset may
depend upon them - the registers are restored from a context image, but
that restore may be inhibited and may simply be absent from the request
if it was in the
On 2 February 2017 at 15:02, Chris Wilson wrote:
> In the future, we need to call allocate_va_range on the aliasing-ppgtt
> which means moving the call down from the vma into the vm (which is
> more appropriate for calling the vm function).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Aul
On 2 February 2017 at 15:02, Chris Wilson wrote:
> Upon creation of the va range, it is initialised to point at scratch.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.
On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
> On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
> >
> > On Mon, 06 Feb 2017, Joonas Lahtinen
> > wrote:
> > >
> > > Convert all scripts to use /bin/sh shebang and fix all shellcheck
> > > reported problems.
> >
> > Pro-tip,
Hi,
These are GVT-g changes for 4.11 merge window, mostly for gvt init
order fix that impacted resource handling for device model, the one
i915 change has been reviewed and acked.
I can't find good tag on dinf for this now, so base on current dinf.
I can re-generate as required.
thanks
---
The
== Series Details ==
Series: drm/i915: Restore context and pd for ringbuffer submission after reset
(rev2)
URL : https://patchwork.freedesktop.org/series/19110/
State : warning
== Summary ==
Series 19110v2 drm/i915: Restore context and pd for ringbuffer submission after
reset
https://patchwo
On 2 February 2017 at 15:02, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 34 --
> 1 file changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i
On Mon, 06 Feb 2017, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor supports scrambli
After a brief discussion, we settled on a naming convention for the
conditional GEM debugging data that should be clearer to the casual
user: GEM_DEBUG
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.h | 12 ++--
drivers/gpu/d
As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
Practically we can achive only 99% of these cdclk values. So cdclk
should be calculated for the given pixclk as per that otherwise it may
lead to screen corruption for some scenarios.
Signed-off-by: Madhav Chauhan
---
drivers/g
== Series Details ==
Series: drm/i915: Rename conditional GEM execution macros
URL : https://patchwork.freedesktop.org/series/19224/
State : success
== Summary ==
Series 19224v1 drm/i915: Rename conditional GEM execution macros
https://patchwork.freedesktop.org/api/1.0/series/19224/revisions/1
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides
Chris Wilson writes:
> On Mon, Feb 06, 2017 at 07:52:15PM -, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [CI,1/2] drm/i915: Mark the end of
>> intel_ring_begin() and check in intel_ring_advance()
>> URL : https://patchwork.freedesktop.org/series/19169/
>> S
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> From: Thierry Reding
>
> This patch implements a small function that finds if a
> given CEA db is hdmi-forum vendor specific data block
> or not.
>
> Signed-off-by: Thierry Reding
> Signed-off-by: Shashank Sharma
Reviewed-by: Jose Ab
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340 MHz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
>
> This patch adds:
> - A function to detect scrambling
== Series Details ==
Series: drm/i915/glk: CDCLK calculation changes for glk
URL : https://patchwork.freedesktop.org/series/19226/
State : success
== Summary ==
Series 19226v1 drm/i915/glk: CDCLK calculation changes for glk
https://patchwork.freedesktop.org/api/1.0/series/19226/revisions/1/mbo
On Tue, Feb 07, 2017 at 05:48:46AM -0500, Madhav Chauhan wrote:
> As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> Practically we can achive only 99% of these cdclk values. So cdclk
> should be calculated for the given pixclk as per that otherwise it may
> lead to screen corru
On Tue, 07 Feb 2017, Ville Syrjälä wrote:
> On Tue, Feb 07, 2017 at 05:48:46AM -0500, Madhav Chauhan wrote:
>> As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
>> Practically we can achive only 99% of these cdclk values. So cdclk
>> should be calculated for the given pixclk as
Chris Wilson writes:
> On Mon, Jan 09, 2017 at 06:52:54PM +0200, Mika Kuoppala wrote:
>> From: Jesse Barnes
>>
>> We just need to pass in an address to execute and some flags, since we
>> don't have to worry about buffer relocation or any of the other usual
>> stuff. Takes in a fance and retur
On Tue, Feb 07, 2017 at 02:11:41PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
> >> +static struct intel_engine_cs *
> >> +exec_mm_select_engine(const struct drm_i915_private *dev_priv,
> >> +const struct drm_i915_exec_mm *exec_mm)
> >> +{
> >> + const unsigned int user_rin
The patches in this list enable MIPI DSI video mode
support for GLK platform. Tesed locally.
v2: Renamed bitfields macros as per review comments(Jani)
v3: Code alignment/abstraction as per arch (Jani review comments)
v4: Fix DSI disable sequence, pll divider checks. Review comments(Jani)
Deepak M
From: Deepak M
For GEMINILAKE, dphy param reg values are programmed in terms
of HS byte clock count while for older platforms in terms of
HS ddr clk count.
v2: Added comments to clarify ddr clock count calculation
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915
From: Deepak M
PLL divider range for GLK is different than that of
BXT, hence adding the GLK range check in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_dsi_pll.c | 20 ++--
2 f
From: Deepak M
v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Jani's Review comment for aligning code to platforms and added
wrapper functions.
v4: Corrected enable/disable seuqence as per BSPEC
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915
From: Deepak M
Dual link Z-inversion overlap field is present
in MIPI_CTRL register unlike the older platforms,
hence setting the same in this patch.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 17 +
1 file changed, 13 insertion
As per BSPEC, GLK supports MIPI DSI 8X clk only on PORT A.
Therefore only for PORT A PLL divider value should be validated.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
From: Deepak M
Program the clk lane and tlpx time count registers
to configure DSI PHY.
v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Program clk lane timing reg same as dphy param reg.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_r
From: Deepak M
Register MIPI_CLOCK_CTRL is applicable only
for BXT platform. Future platform have other
registers to program the escape clock dividers.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 25 +++--
1 file changed
From: Deepak M
v2: Addressed Jani's Review comments(renamed bit field macros)
Txesc clock divider is calculated and programmed
for geminilake platform.
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++
drivers/gpu/drm/i915/intel_dsi_pll.
We can not allow the worker to run after its fbdev, or even the module,
has been removed.
Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support")
Signed-off-by: Chris Wilson
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: dri-de...@lists.freedesktop.org
Cc: #
We can not allow the worker to run after its fbdev, or even the module,
has been removed.
Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: Chris Wilson
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: dri-de...@lists.freedesk
If "caps.buf" is already NULL then it doesn't need to be freed or set to
NULL.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..de2a55178a37 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/g
On Mon, Feb 06, 2017 at 10:34:31AM +0530, Kamble, Sagar A wrote:
>
>
> On 2/4/2017 7:40 PM, Arkadiusz Hiler wrote:
> > On Fri, Feb 03, 2017 at 01:58:33PM +0530, Sagar Arun Kamble wrote:
> > > HUC_STATUS, GUC_STATUS, SOFT_SCRATCH registers are read in debugfs
> > > and getparam ioctl. This patch c
Hello,
On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
>>> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
== Series Details ==
Series: GLK MIPI DSI VIDEO MODE PATCHES (rev4)
URL : https://patchwork.freedesktop.org/series/16542/
State : failure
== Summary ==
Series 16542v4 GLK MIPI DSI VIDEO MODE PATCHES
https://patchwork.freedesktop.org/api/1.0/series/16542/revisions/4/mbox/
Test drv_hangman:
When doing a full atomic modeset, kernel should fail if the flag
DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of
'kms_plane_lowres' testset. The testcases are 'pipe-x-allow-modeset' where
x stands for pipe in question.
For: VIZ-6955
Signed-off-by: Mika Kahola
---
tests/
On Tue, 07 Feb 2017, Joonas Lahtinen wrote:
> On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
>> On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
>> >
>> > On Mon, 06 Feb 2017, Joonas Lahtinen
>> > wrote:
>> > >
>> > > Convert all scripts to use /bin/sh shebang and fix all s
On Tue, 07 Feb 2017, Jose Abreu wrote:
>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>> +{
>> +u8 status;
>> +int ret;
>> +
>> +ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>> +if (ret < 0) {
>> +DRM_ERROR("Failed to read scram
On Sat, 04 Feb 2017, Lyude wrote:
> This adds a file in i915's debugfs directory that allows userspace to
> manually control HPD storm detection. This is mainly for hotplugging
> tests, where we might want to test HPD storm functionality or disable
> storm detection to speed up hotplugging tests w
"BIT(max) - 1" will overflow when max = 32, and GCC will complain.
We already have GENMASK for generating the mask, use it!
Signed-off-by: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
drivers/gpu/drm/i915/
On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote:
> "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> We already have GENMASK for generating the mask, use it!
>
> Signed-off-by: Joonas Lahtinen
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_device_info.c
On Tue, Feb 07, 2017 at 12:49:56PM +, Chris Wilson wrote:
> We can not allow the worker to run after its fbdev, or even the module,
> has been removed.
>
> Fixes: cfe63423d9be ("drm/fb-helper: Add
> drm_fb_helper_set_suspend_unlocked()")
> Signed-off-by: Chris Wilson
> Cc: Noralf Trønnes
>
While reviewing Chris' patches to properly cancel our async workers I
checked that this happens after the fbdev is already unregistered.
That's the case, but I found a small gap in our docs, fill that in.
Note that I don't explain what release_fbi does, because that function
will disappear in the
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
On ti, 2017-02-07 at 10:23 +, Chris Wilson wrote:
> After a brief discussion, we settled on a naming convention for the
> conditional GEM debugging data that should be clearer to the casual
> user: GEM_DEBUG
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen Cc: Tvrtko Ursulin
> Cc: Mika
On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote:
> The goal of the WARN was to catch when we are still actively using the
> fence as we go into the runtime suspend. However, the reg->pin_count is
> too coarse as it does not distinguish between exclusive ownership of the
> fence register from a
== Series Details ==
Series: series starting with [1/2] drm: Cancel drm_fb_helper_dirty_work on
unload
URL : https://patchwork.freedesktop.org/series/19230/
State : failure
== Summary ==
Series 19230v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/19230/revision
On Tue, Feb 07, 2017 at 03:10:49PM +0100, Daniel Vetter wrote:
> While reviewing Chris' patches to properly cancel our async workers I
> checked that this happens after the fbdev is already unregistered.
> That's the case, but I found a small gap in our docs, fill that in.
>
> Note that I don't ex
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/d
On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> If "caps.buf" is already NULL then it doesn't need to be freed or set to
> NULL.
>
> Signed-off-by: Dan Carpenter
> @@ -965,11 +965,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
> unsigned int cmd,
>
On ti, 2017-02-07 at 14:03 +, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 03:51:41PM +0200, Joonas Lahtinen wrote:
> >
> > "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> > We already have GENMASK for generating the mask, use it!
> >
> > Signed-off-by: Joonas Lahtinen
On 7 February 2017 at 14:29, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
Hmm afaict this patch inlines drm_fb_hel
On Tue, Feb 07, 2017 at 04:24:25PM +0200, Joonas Lahtinen wrote:
> On pe, 2017-02-03 at 12:57 +, Chris Wilson wrote:
> > @@ -2024,8 +2024,16 @@ void i915_gem_runtime_suspend(struct
> > drm_i915_private *dev_priv)
> > for (i = 0; i < dev_priv->num_fence_regs; i++) {
> > struct d
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5220a7b5e6ff..074ab22a7cf3 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -781,7 +781,9 @@ EXPORT_SYMB
On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote:
> > On Tue, 07 Feb 2017, Joonas Lahtinen
> > wrote:
> >
> > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
> > >
> > > On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
> > > >
> > > > On Mon, 06 Feb 2017, Joonas Lahtinen
On Tue, Feb 07, 2017 at 04:34:57PM +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 16:16 +0300, Dan Carpenter wrote:
> > If "caps.buf" is already NULL then it doesn't need to be freed or set to
> > NULL.
> >
> > Signed-off-by: Dan Carpenter
>
>
>
> > @@ -965,11 +965,8 @@ static long intel
On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> On 7 February 2017 at 14:29, Daniel Vetter wrote:
> > Noticed that everyone duplicates the same logic here and we could safe
> > a few lines per driver. Yay for lots of drivers to make such tiny
> > refactors worth-while!
> >
> > v2:
"caps.buf" is always NULL here and "caps.size" is always zero. The code
is a no-op and can be removed.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3f656e3a6e5a..773a45aa18f8 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++
On Tue, 07 Feb 2017, Zhenyu Wang wrote:
> Hi,
>
> These are GVT-g changes for 4.11 merge window, mostly for gvt init
> order fix that impacted resource handling for device model, the one
> i915 change has been reviewed and acked.
>
> I can't find good tag on dinf for this now, so base on current d
Hi Jani,
On 07-02-2017 13:35, Jani Nikula wrote:
> On Tue, 07 Feb 2017, Jose Abreu wrote:
>>> +bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
>>> +{
>>> + u8 status;
>>> + int ret;
>>> +
>>> + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
>>> + if (re
On Tue, 07 Feb 2017, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 15:32 +0200, Jani Nikula wrote:
>> > On Tue, 07 Feb 2017, Joonas Lahtinen
>> > wrote:
>> >
>> > On ma, 2017-02-06 at 17:40 +0100, Daniel Vetter wrote:
>> > >
>> > > On Mon, Feb 06, 2017 at 03:25:27PM +0200, Jani Nikula wrote:
>
On Tue, 07 Feb 2017, Jose Abreu wrote:
> Hi Jani,
>
>
> On 07-02-2017 13:35, Jani Nikula wrote:
>> On Tue, 07 Feb 2017, Jose Abreu wrote:
+bool drm_scdc_check_scrambling_status(struct i2c_adapter *adapter)
+{
+ u8 status;
+ int ret;
+
+ ret = drm_scdc_readb(adapte
On 07/02/17 15:22, Uwe Kleine-König wrote:
Hello,
On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
Op 31-01-17 om 0
SIGRTMAX appears to be used by valgrind now for its internal tracking,
so avoid it in the helpers.
Also add some valgrind annotations in gem_mmap, to make sure that its
accesses are tracked correctly.
Signed-off-by: Maarten Lankhorst
---
diff --git a/configure.ac b/configure.ac
index 5bdd744a075
Following a reset, the context and page directory registers are lost.
However, the queue of requests that we resubmit after the reset may
depend upon them - the registers are restored from a context image, but
that restore may be inhibited and may simply be absent from the request
if it was in the
Chris Wilson writes:
> The predominant VMA class is normal GTT, so allow gcc to emphasize that
> path and avoid unnecessary stack movement.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 61
> +++--
>
On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
> On 07/02/17 15:22, Uwe Kleine-König wrote:
> > Hello,
> >
> > On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
> >> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> >>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
> >
On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS)
When we restart the engines, and we have active requests, a request on
the first engine may complete and queue a request to the second engine
before we try to restart the second engine. That queueing of the
request may itself cause the engine to restart, and so the subsequent
handling by engine->in
Chris Wilson writes:
> Following a reset, the context and page directory registers are lost.
> However, the queue of requests that we resubmit after the reset may
> depend upon them - the registers are restored from a context image, but
> that restore may be inhibited and may simply be absent fro
On Tue, Feb 07, 2017 at 03:10:50PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> Cc: Chris Wilson
> Cc: Sean Paul
> Cc: Noralf Trønnes
> Signed
Chris Wilson writes:
> When we restart the engines, and we have active requests, a request on
> the first engine may complete and queue a request to the second engine
> before we try to restart the second engine. That queueing of the
> request may itself cause the engine to restart, and so the su
Regards
Shashank
On 2/7/2017 3:51 PM, Jani Nikula wrote:
On Mon, 06 Feb 2017, Shashank Sharma wrote:
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprin
On Tue, Feb 07, 2017 at 02:49:38PM +, Chris Wilson wrote:
> On Tue, Feb 07, 2017 at 02:38:16PM +, Emil Velikov wrote:
> > On 7 February 2017 at 14:29, Daniel Vetter wrote:
> > > Noticed that everyone duplicates the same logic here and we could safe
> > > a few lines per driver. Yay for lot
Thanks for the review Jose, my comments inline.
Regards
Shashank
On 2/7/2017 4:24 PM, Jose Abreu wrote:
Hi Shashank,
Sorry for the late review.
On 06-02-2017 13:59, Shashank Sharma wrote:
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the so
Regards
Shashank
On 2/7/2017 4:31 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0
Noticed that everyone duplicates the same logic here and we could safe
a few lines per driver. Yay for lots of drivers to make such tiny
refactors worth-while!
v2: Forgot to git add everything :(
v3: Actually remove release_fbi (Sean, Emil, Chris) ...
Cc: Chris Wilson
Cc: Sean Paul
Cc: Noralf
Regards
Shashank
On 2/7/2017 4:44 PM, Jose Abreu wrote:
Hi Shashank,
On 06-02-2017 13:59, Shashank Sharma wrote:
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340 MHz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
On Tue, Feb 07, 2017 at 05:16:03PM +0100, Daniel Vetter wrote:
> Noticed that everyone duplicates the same logic here and we could safe
> a few lines per driver. Yay for lots of drivers to make such tiny
> refactors worth-while!
>
> v2: Forgot to git add everything :(
>
> v3: Actually remove rele
== Series Details ==
Series: drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)
URL : https://patchwork.freedesktop.org/series/19240/
State : failure
== Summary ==
Series 19240v1 drm/i915: Avoid BIT(max) - 1 and use GENMASK(max, 0)
https://patchwork.freedesktop.org/api/1.0/series/19240/revis
On Tue, Feb 07, 2017 at 09:43:15PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/7/2017 4:31 PM, Jose Abreu wrote:
> > Hi Shashank,
> >
> >
> >
> > On 06-02-2017 13:59, Shashank Sharma wrote:
> > > This patch does following:
> > > - Adds a new structure (drm_hdmi_info) in d
On 02/03/2017 03:48 AM, Michal Wajdeczko wrote:
On Thu, Feb 02, 2017 at 07:42:46AM -0800, Oscar Mateo wrote:
From: Michal Wajdeczko
Prepare for an alternate GuC communication interface.
v2: Make a few functions static and name them correctly while we are at it
(Oscar)
Signed-off-by: Mich
== Series Details ==
Series: drm/i915: Restore context and pd for ringbuffer submission after reset
(rev3)
URL : https://patchwork.freedesktop.org/series/19110/
State : success
== Summary ==
Series 19110v3 drm/i915: Restore context and pd for ringbuffer submission after
reset
https://patchwo
On 02/02/2017 11:33 PM, Chris Wilson wrote:
On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
From: Michal Wajdeczko
The GuC descriptor is big in size. If we use local definition of
guc_desc we have a chance to overflow stack. Use allocated one.
v2: Rebased
v3: Split
v4: Handle E
From: Michal Wajdeczko
Prepare for an alternate GuC communication interface.
v2: Make a few functions static and name them correctly while we are at it
(Oscar)
v3: Leave an intel_guc_send_mmio interface for users that require old-style
communication
Signed-off-by: Michel Thierry
Signed-off-b
On Tue, Feb 07, 2017 at 05:58:58PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > When we restart the engines, and we have active requests, a request on
> > the first engine may complete and queue a request to the second engine
> > before we try to restart the second engine. That queuei
== Series Details ==
Series: drm/i915: Restart all engines atomically
URL : https://patchwork.freedesktop.org/series/19249/
State : success
== Summary ==
Series 19249v1 drm/i915: Restart all engines atomically
https://patchwork.freedesktop.org/api/1.0/series/19249/revisions/1/mbox/
Test gem_e
On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:
>
>
> On 02/02/2017 11:33 PM, Chris Wilson wrote:
> >On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
> >>From: Michal Wajdeczko
> >>
> >>The GuC descriptor is big in size. If we use local definition of
> >>guc_desc we have
== Series Details ==
Series: series starting with [1/2] drm/fb-helper: Explain unload sequence a bit
better (rev3)
URL : https://patchwork.freedesktop.org/series/19242/
State : failure
== Summary ==
CC drivers/acpi/acpica/uterror.o
CC drivers/acpi/acpica/utglobal.o
CC dri
On 02/07/2017 09:25 AM, Chris Wilson wrote:
On Tue, Feb 07, 2017 at 12:55:21AM -0800, Oscar Mateo wrote:
On 02/02/2017 11:33 PM, Chris Wilson wrote:
On Thu, Feb 02, 2017 at 07:27:45AM -0800, Oscar Mateo wrote:
From: Michal Wajdeczko
The GuC descriptor is big in size. If we use local defin
Op 07-02-17 om 16:35 schreef Ville Syrjälä:
> On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
>> On 07/02/17 15:22, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
> Op
1 - 100 of 129 matches
Mail list logo
