On 18/09/2019 18:31, Stuart Summers wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559
Unless there was some discussion I missed we can't just turn it on to
work around a SKIP in IGT. Feature was deliberately limited to Icelake
and even there just to a sub-set of possible c
-Original Message-
From: Souza, Jose
Sent: Wednesday, September 18, 2019 11:14 PM
To: Singh, Gaurav K ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix S0ix/S3 suspend stress issue
On Wed, 2019-09-18 at 11:23 +0530, Gaurav K Singh wrote:
> During S0ix/S3 s
Would the following be appropriate fix?
if (connector || connector->base.status == connector_status_connected) {
ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
if (ret) {
DRM_ERROR("failed to update payload %d\n", ret);
== Series Details ==
Series: drm/i915: Engine relative MMIO (rev8)
URL : https://patchwork.freedesktop.org/series/57117/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6917 -> Patchwork_14452
Summary
---
**FAILURE**
Quoting Daniele Ceraolo Spurio (2019-09-19 02:53:30)
> Our assumption that the we can ask the HW to lock the SFC even if not
> currently in use does not match the HW commitment. The expectation from
> the HW is that SW will not try to lock the SFC if the engine is not
> using it and if we do that t
== Series Details ==
Series: drm/i915: Allow set context SSEU on platforms after gen 11
URL : https://patchwork.freedesktop.org/series/66870/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14447_full
S
On 18/09/2019 23:28, Summers, Stuart wrote:
> On Wed, 2019-09-18 at 19:31 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: drm/i915: Allow set context SSEU on platforms after gen 11
>> URL : https://patchwork.freedesktop.org/series/66870/
>> State : success
>>
>> == Summary ==
>>
>>
Op 18-09-2019 om 17:07 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
> planes' max resolution. This has the nasty implication that modes on the
> connectors' mode list may not be usable when the user asks for a
> fullscreen
On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the beha
Quoting Tvrtko Ursulin (2019-09-19 10:34:15)
>
> On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
> > Our assumption that the we can ask the HW to lock the SFC even if not
> > currently in use does not match the HW commitment. The expectation from
> > the HW is that SW will not try to lock the S
On 19/09/2019 10:34, Tvrtko Ursulin wrote:
On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engi
On 18/09/2019 15:54, Chris Wilson wrote:
When using virtual engines, the rq->engine is not stable until we hold
the engine->active.lock (as the virtual engine may be exchanged with the
sibling). Since commit 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
we may retire a request concurrentl
On 18/09/2019 15:54, Chris Wilson wrote:
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence whil
On 18/09/2019 15:54, Chris Wilson wrote:
As not only is the signal->timeline volatile, so will be acquiring the
timeline's HWSP. We must first carefully acquire the timeline from the
signaling request and then lock the timeline. With the removal of the
struct_mutex serialisation of request const
Insert structure members names into their descriptions to follow
kernel-doc format
Signed-off-by: Anna Karas
---
drivers/gpu/drm/i915/i915_drv.h | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915
Quoting Anna Karas (2019-09-19 11:49:28)
> Insert structure members names into their descriptions to follow
> kernel-doc format
>
> Signed-off-by: Anna Karas
Lgtm,
Reviewed-by: Chris Wilson
> -
> Intel Finland Oy
> Registered
Op 08-07-2019 om 14:53 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> While not all platforms allow us to change the cdclk frequency
> we should still verify that the fixed cdclk frequency isn't
> too low. To that end let's cook up a .modeset_calc_cdclk()
> implementation that only does the min_
Op 08-07-2019 om 14:53 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> We need to insert stuff between the plane and crtc .atomic_check()
> drm_atomic_helper_check_planes() doesn't allow us to do that so
> stop using it and hand roll the loops instead.
>
> Signed-off-by: Ville Syrjälä
> ---
> .
Quoting Tvrtko Ursulin (2019-09-19 11:48:25)
>
> On 18/09/2019 15:54, Chris Wilson wrote:
> > As not only is the signal->timeline volatile, so will be acquiring the
> > timeline's HWSP. We must first carefully acquire the timeline from the
> > signaling request and then lock the timeline. With the
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the corre
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not dis
As not only is the signal->timeline volatile, so will be acquiring the
timeline's HWSP. We must first carefully acquire the timeline from the
signaling request and then lock the timeline. With the removal of the
struct_mutex serialisation of request construction, we can have multiple
timelines acti
On Thu, Sep 19, 2019 at 07:23:30AM +, S, Srinivasan wrote:
> Would the following be appropriate fix?
>
> if (connector || connector->base.status ==
> connector_status_connected) {
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> if (ret) {
>
== Series Details ==
Series: Docs: fix incorrect use of kernel-doc format in structure description.
URL : https://patchwork.freedesktop.org/series/66922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6919 -> Patchwork_14453
On Wed, 18 Sep 2019, Manasi Navare wrote:
> On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com wrote:
>> From: Srinivasan S
>>
>> This patch avoids DP MST payload error message in dmesg, as it is trying
>> to read the payload from the disconnected DP MST device. After the unplug
>>
On Thu, 19 Sep 2019, Chris Wilson wrote:
> Quoting Anna Karas (2019-09-19 11:49:28)
>> Insert structure members names into their descriptions to follow
>> kernel-doc format
>>
>> Signed-off-by: Anna Karas
>
> Lgtm,
> Reviewed-by: Chris Wilson
Yes, apart from subject prefix. Maybe something li
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a
volatile, rcu pointer
URL : https://patchwork.freedesktop.org/series/66923/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e13eda0cac6a drm/i915: Mark i915_request.timeline as a
== Series Details ==
Series: drm/i915/tgl: Implement Wa_1406941453
URL : https://patchwork.freedesktop.org/series/66886/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14448_full
Summary
---
**F
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a
volatile, rcu pointer
URL : https://patchwork.freedesktop.org/series/66923/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Mark i915_request
On Wed, 18 Sep 2019, "Sharma, Swati2" wrote:
> On 18-Sep-19 3:31 PM, Jani Nikula wrote:
>> On Tue, 17 Sep 2019, Swati Sharma wrote:
>>> For icl+, have hw read out to create hw blob of gamma
>>> lut values. icl+ platforms supports multi segmented gamma
>>> mode, add hw lut creation for this mode.
On Wed, 2019-07-10 at 17:43 -0700, Furquan Shaikh wrote:
> Max backlight value for the panel was being calculated using byte
> count i.e. 0x if 2 bytes are supported for backlight brightness
> and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
> determines the number of active contr
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a
volatile, rcu pointer
URL : https://patchwork.freedesktop.org/series/66923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6919 -> Patchwork_14454
=
Chris Wilson writes:
> Check that we are correctly invalidating the TLB at the start of a
> batch after updating the GTT.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 227 ++
> 1 file c
On 19/09/2019 12:19, Chris Wilson wrote:
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasin
On Wed, Sep 11, 2019 at 2:19 PM Chris Wilson wrote:
> Quoting Balestrieri, Francesco (2019-09-11 13:03:25)
> > On 04/09/2019, 13.33, "Intel-gfx on behalf of Daniel Vetter"
> >
> > wrote:
> >
> > On Mon, Aug 26, 2019 at 2:21 PM Abdiel Janulgue
> > > - ret = create_mmap_offset(obj)
== Series Details ==
Series: series starting with [1/2] drm/i915: Future-proof DDC pin mapping
URL : https://patchwork.freedesktop.org/series/66887/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14449_full
Quoting Mika Kuoppala (2019-09-19 13:57:45)
> Chris Wilson writes:
>
> > Check that we are correctly invalidating the TLB at the start of a
> > batch after updating the GTT.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Daniele Ceraolo Spurio
> > ---
> > drivers/gpu/drm/i9
On Wed, Sep 18, 2019 at 04:21:06PM -0400, Sean Paul wrote:
> On Wed, Sep 18, 2019 at 07:02:18PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 18, 2019 at 11:24:09AM -0400, Sean Paul wrote:
> > > On Wed, Sep 18, 2019 at 06:07:07PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > >
Check that we are correctly invalidating the TLB at the start of a
batch after updating the GTT.
v2: Comments and hold the request reference while spinning
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 308
Quoting Tvrtko Ursulin (2019-09-19 14:02:19)
>
> On 19/09/2019 12:19, Chris Wilson wrote:
> > +static struct intel_timeline *get_timeline(struct i915_request *rq)
> > +{
> > + struct intel_timeline *tl;
> > +
> > + /*
> > + * Even though we are holding the engine->active.lock here, th
From: Ville Syrjälä
The bar values are little endian, not big endian. The pack
function did it right but the unpack got it wrong. Fix it.
Cc: sta...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Martin Bugge
Cc: Hans Verkuil
Cc: Thierry Reding
Cc: Mauro Carvalho Chehab
Fixes: 2c676f378
On 17/09/2019 19:56, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-17 13:37:55)
On 02/09/2019 05:02, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 82db2b783123..9a8c307c5aeb 100644
--- a/drivers/gpu/drm/i915/ge
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-09-19 13:57:45)
>> Chris Wilson writes:
>>
>> > Check that we are correctly invalidating the TLB at the start of a
>> > batch after updating the GTT.
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Mika Kuoppala
>> > Cc: Daniele Ceraolo Spurio
Chris Wilson writes:
> Check that we are correctly invalidating the TLB at the start of a
> batch after updating the GTT.
>
> v2: Comments and hold the request reference while spinning
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
Reviewed-by: Mika Kuoppala
Quoting Mika Kuoppala (2019-09-19 14:39:59)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-09-19 13:57:45)
> >> Chris Wilson writes:
> >> > + vma = i915_vma_instance(out, vm, NULL);
> >> > + if (IS_ERR(vma)) {
> >> > + err = PTR_ERR(vma);
> >> > + goto o
Then it's better that, could we change it to DRM_DEBUG_KMS("failed to update
payload %d\n", ret); instead of DRM_ERROR("failed to update payload %d\n",
ret);, without any connector status check, would that be fine?
Regards,
-Original Message-
From: Ville Syrjälä
Sent: Thursday, Septemb
== Series Details ==
Series: TGL TC enabling (rev2)
URL : https://patchwork.freedesktop.org/series/66695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14450_full
Summary
---
**SUCCESS**
No
For completeness, add counterpart to i915_driver_modeset_probe() and
remove the asymmetry in the probe/remove parts. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git
Hi all, I started looking into cleaning up the modeset probe/remove
paths. We have a number of issues there. Modeset and non-modeset
initialization and cleanup happily mixed up. Initialization and cleanup
of various things happen at different layers in the stack.
This is tied to the previous patch
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variable to i915. Also propagate
to intel_hpd_poll_fini(). No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 38 ++--
dri
The i915 specific mode config init code is too specific and detailed to
have open in a high level function. Abstract away. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 85 +++-
1 file changed, 46 insertions(+), 39 deletions(
The code is too specific and detailed to have open in a high level
function. Abstract away. As a drive-by improvement switch to using
enableddisabled() in logging. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 39 +++-
1 file
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variable to i915. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 59 -
1 file changed, 29 insertions(+), 30 deletio
Push irq uninstall further up, by splitting i915_driver_modeset_remove()
to two, the part with working irqs before irq uninstall, and the part
after irq uninstall. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 15 +++
1 file changed, 11 inser
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variables to i915. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 69 ++--
drivers/gpu/drm/i915/display/intel_display.
Pair the gmbus setup and teardown in the same layer. This also fixes the
double gmbus teardown on the i915_driver_modeset_probe() error path.
Move the gmbus setup a bit later in the sequence to make the follow-up
refactoring easier, and to pinpoint any unexpected consequences of this
change right
Pair the irq install and uninstall in the same layer. There are no
functional changes in the happy day scenario. The cleanup paths are
currently a mess though.
Note that modeset probe pre-irq + post-irq install are matched by
modeset driver remove pre-irq + post-irq uninstall, together, but not
in
Pair the gem init and cleanup in the same layer. This moves the gem init
before the modeset init.
The error paths remain a mess.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/
Split intel_modeset_driver_remove() to two, the part with working irqs
before irq uninstall, and the part after irq uninstall.
The error path in i915_driver_modeset_probe() looks obviously weird
after this, but remains as good or broken as it ever was. No functional
changes.
Signed-off-by: Jani N
Pair the overlay init and fini in the same layer. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/di
Move some of the modeset init that does not require irqs installed or
gem initialized to before irq install and gem init.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 14 --
drivers/gpu/drm/i915/display/intel_display.h | 1 +
drivers/gpu/drm/i915/i91
Quoting Tvrtko Ursulin (2019-09-19 14:37:01)
>
> On 17/09/2019 19:56, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-09-17 13:37:55)
> >> On 02/09/2019 05:02, Chris Wilson wrote:
> >>> +void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence
> >>> *f)
> >>> +{
> >>> + G
Hi Chris,
On Wed, Sep 11, 2019 at 11:14:59AM +0100, Chris Wilson wrote:
> On older platforms, performing a GPU reset clobbers the display.
> Exercise the interactions between reset/wedge and the display and
> hopefully prevent any races creeping in.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Sy
On Wed, Sep 11, 2019 at 11:15:00AM +0100, Chris Wilson wrote:
> When using a spinner to trigger a hang, make it unpreemptable so that it
> appears like a true hang.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109661
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
>
Hi Chris,
On Wed, Sep 11, 2019 at 11:15:01AM +0100, Chris Wilson wrote:
> Use an explicit fence to circumvent the [i915] GPU hang detection rather
> than tweak the i915 specific modparam (and remove the assertion that
> such a param exists). Note, that with a bit more work, the fence could
> be us
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2019-09-19:
- Extend old HSW workaround to fix some GPU hangs on Haswell GT2
- Fix return error code on GEM mmap.
- White list a chicken bit register for push constants legacy mode on Mesa
- Fix resume issue related to GGTT restore
- Remove incorr
Quoting Jani Nikula (2019-09-19 15:03:58)
> Pair the gem init and cleanup in the same layer. This moves the gem init
> before the modeset init.
The important part here was that BIOS takeover by display is before we
clear the GGTT in i915_gem_init -> i915_init_ggtt. iirc marking up the
preallocated
From: Ville Syrjälä
We may want to dump out the calculated scaling factor(s) when
they exceed the limits. To achieve that we need to return the
error code and scaling factor separately.
Side note: the code in dpu_plane_validate_multirect_v2()
looks rather dubious on account of it not using fixed
From: Ville Syrjälä
Dump out the plane/crtc id/name in the failure debug messages.
Makes a bit easier to figure out which plane exactly has failed
when you have tons of them.
Cc: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +++--
1 file changed, 7 in
From: Ville Syrjälä
When the calculate scaling factors are out of range let's
print out the calculated value and the min/max. Should make
life a bit less confusing when decoding failure logs.
I decided to print them in decimal rather than hex. Not sure
which people prefer but maybe this is less
Quoting Andi Shyti (2019-09-19 15:08:57)
> Hi Chris,
>
> On Wed, Sep 11, 2019 at 11:14:59AM +0100, Chris Wilson wrote:
> > On older platforms, performing a GPU reset clobbers the display.
> > Exercise the interactions between reset/wedge and the display and
> > hopefully prevent any races creeping
Continuing the theme of breaking intel_pm.c up in a reasonable chunk of
powermanagement utilities, pull out the rc6 setup into its GT handler.
Based on a patch by Chris Wilson.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i91
On Wed, Sep 11, 2019 at 11:14:59AM +0100, Chris Wilson wrote:
> On older platforms, performing a GPU reset clobbers the display.
> Exercise the interactions between reset/wedge and the display and
> hopefully prevent any races creeping in.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> --
Quoting Andi Shyti (2019-09-19 15:38:40)
> Continuing the theme of breaking intel_pm.c up in a reasonable chunk of
> powermanagement utilities, pull out the rc6 setup into its GT handler.
>
> Based on a patch by Chris Wilson.
>
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
Nothing jumped out
On Thu, 19 Sep 2019, Chris Wilson wrote:
> Quoting Jani Nikula (2019-09-19 15:03:58)
>> Pair the gem init and cleanup in the same layer. This moves the gem init
>> before the modeset init.
>
> The important part here was that BIOS takeover by display is before we
> clear the GGTT in i915_gem_init
== Series Details ==
Series: drm/i915: fix SFC reset flow (rev2)
URL : https://patchwork.freedesktop.org/series/66779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14451_full
Summary
---
**SUC
== Series Details ==
Series: drm/i915/selftests: Exercise CS TLB invalidation (rev2)
URL : https://patchwork.freedesktop.org/series/66718/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e5422e652e53 drm/i915/selftests: Exercise CS TLB invalidation
-:90: WARNING:MEMORY_BARRIER: m
It is expected that processes will pass dma-buf fd between drivers, and
only using the fd themselves for mmaping and synchronisation ioctls.
However, it may be convenient for an application to read/write into the
dma-buf, for instance a test case to check the internal
dma_buf->ops->kmap interface.
== Series Details ==
Series: drm/i915/selftests: Exercise CS TLB invalidation (rev2)
URL : https://patchwork.freedesktop.org/series/66718/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6920 -> Patchwork_14455
Summary
--
Before we execute a batch, we must first issue any and all TLB
invalidations so that batch picks up the new page table entries.
Tigerlake's preparser is weakening our post-sync CS_STALL inside the
invalidate pipe-control and allowing the loading of the batch buffer
before we have setup its page tab
On Wed, Sep 18, 2019 at 05:45:27PM -0700, Souza, Jose wrote:
> On Wed, 2019-09-18 at 16:56 -0700, Matt Roper wrote:
> > The MCC hpd table is just a subset of the ICP table; we can eliminate
> > it
> > and use the ICP table everywhere. The extra pins in the table won't
> > be
> > a problem for MCC
On Wed, Sep 18, 2019 at 04:05:06PM -0700, Sripada, Radhakrishna wrote:
> Hi Daniele,
>
> Thanks for the review. Can you help me merge this pathc?
>
> Thanks,
> Radhakrishna(RK) Sripada
Applied to dinq. Thanks for the patch and review.
Matt
>
> > -Original Message-
> > From: Ceraolo
On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote:
>
> It is expected that processes will pass dma-buf fd between drivers, and
> only using the fd themselves for mmaping and synchronisation ioctls.
> However, it may be convenient for an application to read/write into the
> dma-buf, for instance a
Quoting Jani Nikula (2019-09-19 15:03:48)
> For completeness, add counterpart to i915_driver_modeset_probe() and
> remove the asymmetry in the probe/remove parts. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
__
Quoting Jani Nikula (2019-09-19 15:03:49)
> In general, prefer struct drm_i915_private * over struct drm_device *
> when either will do. Rename the local variable to i915. No functional
> changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
___
Quoting Jani Nikula (2019-09-19 15:03:50)
> In general, prefer struct drm_i915_private * over struct drm_device *
> when either will do. Rename the local variable to i915. Also propagate
> to intel_hpd_poll_fini(). No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-
Quoting Jani Nikula (2019-09-19 15:03:51)
> The code is too specific and detailed to have open in a high level
> function. Abstract away. As a drive-by improvement switch to using
> enableddisabled() in logging. No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/d
Quoting Jani Nikula (2019-09-19 15:03:52)
> The i915 specific mode config init code is too specific and detailed to
> have open in a high level function. Abstract away. No functional
> changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 85 +++--
Quoting Jani Nikula (2019-09-19 15:03:53)
> In general, prefer struct drm_i915_private * over struct drm_device *
> when either will do. Rename the local variables to i915. No functional
> changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
__
== Series Details ==
Series: video/hdmi: Fix AVI bar unpack
URL : https://patchwork.freedesktop.org/series/66930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6920 -> Patchwork_14456
Summary
---
**SUCCESS**
No re
Quoting Jani Nikula (2019-09-19 15:03:54)
> Split intel_modeset_driver_remove() to two, the part with working irqs
> before irq uninstall, and the part after irq uninstall.
>
> The error path in i915_driver_modeset_probe() looks obviously weird
> after this, but remains as good or broken as it eve
Quoting Daniel Vetter (2019-09-19 16:28:41)
> On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote:
> >
> > It is expected that processes will pass dma-buf fd between drivers, and
> > only using the fd themselves for mmaping and synchronisation ioctls.
> > However, it may be convenient for an applic
On Thu, Sep 19, 2019 at 5:53 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-09-19 16:28:41)
> > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson
> > wrote:
> > >
> > > It is expected that processes will pass dma-buf fd between drivers, and
> > > only using the fd themselves for mmaping and s
From: Ville Syrjälä
../src/sna/sna_composite.c:567:11: warning: variable ‘sx’ might be clobbered by
‘longjmp’ or ‘vfork’ [-Wclobbered]
int16_t sx = src_x + tx - (dst->pDrawable->x + dst_x);
^~
etc.
I had a quick look at a few of the cases and they seemed fine to me,
so feels like
From: Ville Syrjälä
Avoid the compiler gettings upset about us redefining
FontSetPrivate().
Signed-off-by: Ville Syrjälä
---
src/sna/sna_accel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 7fd00b9af679..934c8f662bea 100644
--- a/src/sna/s
From: Ville Syrjälä
Suppress more compiler warnings.
Signed-off-by: Ville Syrjälä
---
src/sna/meson.build | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/sna/meson.build b/src/sna/meson.build
index 4af181f37b29..b1276ab3aa6e 100644
--- a/src/sna/meson.build
+++ b/src/sna/meson.build
From: Ville Syrjälä
Random smattering of patches to eliminate compiler warnings.
Some I just suppressed out of lazyness, others I tried to
silence by adjusting the code a bit.
Afterwards the build is clean on my gcc 8.3, though with
a bunch of stuff still suppressed I'm not 100% sure that's
a go
From: Ville Syrjälä
gcc doesn't like extra stuff in the fall through comments.
Replace them with the standard form.
Signed-off-by: Ville Syrjälä
---
src/sna/gen4_render.c | 6 +++---
src/sna/gen5_render.c | 6 +++---
src/sna/gen6_render.c | 6 +++---
src/sna/gen7_render.c | 6 +++---
src/sna/g
From: Ville Syrjälä
Use an empty {} as the terminator in intel_device_match[] to avoid
the warning about missing initlizers.
Signed-off-by: Ville Syrjälä
---
src/intel_module.c | 2 +-
src/meson.build| 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/intel_module.c b/
From: Ville Syrjälä
Sprinkle fall through comments where needed.
Signed-off-by: Ville Syrjälä
---
src/intel_module.c| 1 +
src/sna/blt.c | 2 ++
src/sna/gen2_render.c | 21 +
src/sna/gen3_render.c | 24 ++--
src/sna/sna_accel.c | 3 +++
1 - 100 of 193 matches
Mail list logo
