On Tue, 2016-04-12 at 12:23 +0530, Shubhangi Shrivastava wrote:
> Since commit 30d9aa4265fe ("drm/i915: Read sink_count dpcd always"),
> the status of a DP connector depends on its sink count value.
> However, some eDP panels don't set that value appropriately,
> causing them to be reported as disc
On Mon, 2016-04-11 at 10:11 -0700, Jim Bride wrote:
> In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
> much needed clean-up was done, but unfortunately part of the change
> broke DP MST. The real issue was setting the connector state to
> disconnected in the MST case, which i
On 07/04/16 22:26, Yu Dai wrote:
On 04/07/2016 10:21 AM, Dave Gordon wrote:
During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one whi
On 11/04/16 17:40, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 03:57:21PM +0100, Tvrtko Ursulin wrote:
On 11/04/16 15:44, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:
On 08/04/16 12:11, Chris Wilson wrote:
When called because we have run out of vmap ad
== Series Details ==
Series: drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse() (rev3)
URL : https://patchwork.freedesktop.org/series/5390/
State : failure
== Summary ==
Series 5390v3 drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()
http://patchwork.freedesktop.org/api/1.0/series/5
== Series Details ==
Series: Fixing up relocation of secure buffers?
URL : https://patchwork.freedesktop.org/series/5550/
State : failure
== Summary ==
Series 5550v1 Fixing up relocation of secure buffers?
http://patchwork.freedesktop.org/api/1.0/series/5550/revisions/1/mbox/
Test gem_basic:
== Series Details ==
Series: series starting with [1/4] drm/i915: Prevent machine death on Ivybridge
context switching (rev2)
URL : https://patchwork.freedesktop.org/series/5484/
State : warning
== Summary ==
Series 5484v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/s
On Fri, Apr 01, 2016 at 09:53:17PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Take a bigger hammer to the underrun suppression on ILK. Instead of
> trying to suppress them at specific points in the modeset sequence just
> silence them across the entire sequence. This ge
On Fri, Apr 01, 2016 at 09:53:19PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The underruns we were seeing when enabling eDP port A on ILK seem to
> have been caused by prematurely clearing the LP1+ watermark values when
> disabling LP1+ watermarks. Now that the waterma
== Series Details ==
Series: drm/i915: Fixing eDP detection on certain platforms (rev4)
URL : https://patchwork.freedesktop.org/series/5408/
State : failure
== Summary ==
Series 5408v4 drm/i915: Fixing eDP detection on certain platforms
http://patchwork.freedesktop.org/api/1.0/series/5408/revi
Hi Mark,
On Tue, 12 Apr 2016 05:42:03 +0100
Mark Brown wrote:
> On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
>
> > Is there any reason for calling set_machine_constraints() after
> > device_register() in regulator_register()?
>
> I'm not sure there's a strong one, we don't
From: Tvrtko Ursulin
We can use the new pin/lazy unpin API for simplicity
and more performance in the execlist submission paths.
v2:
* Fix error handling and convert more users.
* Compact some names for readability.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/
== Series Details ==
Series: mm/vmalloc: Keep a separate lazy-free list
URL : https://patchwork.freedesktop.org/series/5574/
State : success
== Summary ==
Series 5574v1 mm/vmalloc: Keep a separate lazy-free list
http://patchwork.freedesktop.org/api/1.0/series/5574/revisions/1/mbox/
Test gem_b
On Mon, Apr 11, 2016 at 07:29:13PM +0300, Imre Deak wrote:
> On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The vlv/chv display irq setup was a bit of mess after I ran out of steam
> > when working on it last. Fix it up so that we just have
On Fri, Apr 01, 2016 at 09:53:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Once again ILK is unhappy if we clear out the LP1+ watermark levels
> outright, and instead we must disable the levels we don't want while
> still leaving the actual programmed watermark level
On Mon, Apr 11, 2016 at 09:45:11PM +0200, Daniel Vetter wrote:
> Hi all,
>
> New -testing cycle with cool stuff:
> - make modeset hw state checker atomic aware (Maarten)
> - close races in gpu stuck detection/seqno reading (Chris)
> - tons&tons of small improvements from Chris Wilson all over the
== Series Details ==
Series: drm/i915: Use new i915_gem_object_pin_map for LRC
URL : https://patchwork.freedesktop.org/series/5580/
State : failure
== Summary ==
Series 5580v1 drm/i915: Use new i915_gem_object_pin_map for LRC
http://patchwork.freedesktop.org/api/1.0/series/5580/revisions/1/mbo
On Tue, Apr 12, 2016 at 09:52:28AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We can use the new pin/lazy unpin API for simplicity
> and more performance in the execlist submission paths.
>
> v2:
> * Fix error handling and convert more users.
> * Compact some names for readabili
On Mon, 11 Apr 2016, Jim Bride wrote:
> In order to include monitor name information in debugfs
> output we needed to add a function that would extract the
> monitor name from the EDID, and that function needed to
> reside in the file where the rest of the EDID helper
> functions are implemented.
On Tue, Apr 12, 2016 at 09:24:53AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Use new i915_gem_object_pin_map for LRC
> URL : https://patchwork.freedesktop.org/series/5580/
> State : failure
>
> == Summary ==
>
> Series 5580v1 drm/i915: Use new i915_gem_object_pin_map
On 12/04/16 10:30, Chris Wilson wrote:
> On Tue, Apr 12, 2016 at 09:52:28AM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> We can use the new pin/lazy unpin API for simplicity
>> and more performance in the execlist submission paths.
>>
>> v2:
>>* Fix error handling and convert mo
On Mon, 11 Apr 2016, Jim Bride wrote:
> Modify the debugfs output for i915_dp_mst_info to list the source port for
> the DP MST topology in question.
>
> v2: rebase
> v3: rebase
>
> cc: Jani Nikula
> Signed-off-by: Jim Bride
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs
On Tue, Apr 12, 2016 at 10:36:39AM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/16 10:30, Chris Wilson wrote:
> > On Tue, Apr 12, 2016 at 09:52:28AM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> We can use the new pin/lazy unpin API for simplicity
> >> and more performance in the
On Tue, Apr 12, 2016 at 09:52:28AM +0100, Tvrtko Ursulin wrote:
> -static void lrc_setup_hardware_status_page(struct intel_engine_cs *engine,
> -struct drm_i915_gem_object
> *default_ctx_obj)
> +static int
> +lrc_setup_hws(struct intel_engine_cs *engine,
> +
On Mon, Apr 11, 2016 at 05:50:09PM +0100, Peter Antoine wrote:
> The MOCS registers were added in Gen9 and define the caching policy.
> The registers are split into two sets. The first set controls the
> EDRAM policy and have a set for each engine, the second set controls
> the L3 policy. The two s
On 12/04/16 10:21, Ville Syrjälä wrote:
On Mon, Apr 11, 2016 at 09:45:11PM +0200, Daniel Vetter wrote:
Hi all,
New -testing cycle with cool stuff:
- make modeset hw state checker atomic aware (Maarten)
- close races in gpu stuck detection/seqno reading (Chris)
- tons&tons of small improvements
On Tue, Apr 12, 2016 at 10:37:22AM +0200, Boris Brezillon wrote:
> Mark Brown wrote:
> > On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
> > I'm not sure there's a strong one, we don't really use the class device
> > for anything, but without doing a full audit I couldn't guarant
On ti, 2016-04-12 at 12:05 +0300, Ville Syrjälä wrote:
> On Mon, Apr 11, 2016 at 07:29:13PM +0300, Imre Deak wrote:
> > On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > The vlv/chv display irq setup was a bit of mess after I ran out
On Mon, 28 Mar 2016, Lyude wrote:
> Resending this because it looks like replying to my previous series of patches
> causes patchwork to pick up patches from the original version of this and
> try to apply them along with this one.
Lyude, these don't seem to apply cleanly, please rebase and repos
On Mon, 2016-04-11 at 16:30 +0300, Ville Syrjälä wrote:
> On Thu, Mar 17, 2016 at 12:23:10PM +0200, Mika Kahola wrote:
> > It was noticed on bug #94087 that module parameter
> > i915.edp_vswing=2 that should override the VBT setting
> > to use default voltage swing (400 mV) was not applied
> > for
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The registers frobbed by vlv_init_display_clock_gating() libve inside
> the disp2d power well, so frobbing them while the power well is down
> results in unclaimed register access warning (and of cour
On Tue, 12 Apr 2016 11:09:38 +0100
Mark Brown wrote:
> On Tue, Apr 12, 2016 at 10:37:22AM +0200, Boris Brezillon wrote:
> > Mark Brown wrote:
> > > On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
>
> > > I'm not sure there's a strong one, we don't really use the class device
>
On 12/04/16 10:43, Chris Wilson wrote:
On Tue, Apr 12, 2016 at 09:52:28AM +0100, Tvrtko Ursulin wrote:
-static void lrc_setup_hardware_status_page(struct intel_engine_cs *engine,
- struct drm_i915_gem_object
*default_ctx_obj)
+static int
+lrc_setup_hws(
On Fri, 2016-04-08 at 17:59 +0300, Jani Nikula wrote:
> The whole file is ignored on CONFIG_ACPI=n.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 6 --
> 1 file changed, 6 deletions(-)
> diff --git a/drivers/gpu/dr
On Fri, Apr 08, 2016 at 05:59:49PM +0300, Jani Nikula wrote:
> The whole file is ignored on CONFIG_ACPI=n.
That's an issue as we can't then acquire the opregion->vbt (which itself
is not acpi dependent). Shrug no modern system can boot without acpi (at
least not if you want more than cpu etc), so
On Thu, Mar 31, 2016 at 01:26:03PM +0200, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
On Fri, Apr 01, 2016 at 11:04:10PM +0300, Ville Syrjälä wrote:
> On Tue, Mar 22, 2016 at 04:08:39PM +0100, Maarten Lankhorst wrote:
> > Op 22-03-16 om 15:58 schreef Ville Syrjälä:
> > > On Tue, Mar 22, 2016 at 03:42:14PM +0100, Maarten Lankhorst wrote:
> > >> __drm_atomic_helper_plane_destroy_state
On Wed, Mar 30, 2016 at 10:03:24PM +0200, Boris Brezillon wrote:
> Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a
> new function to test whether a PWM device is enabled or not without
> manipulating PWM internal fields.
> Hiding this is necessary if we want to smoothly mo
On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> The PWM period will be set when calling pwm_config. Remove this useless
> call to pwm_set_period(), which might mess up with the internal PWM state.
>
> Signed-off-by: Boris Brezillon
> Acked-by: Lee Jones
> ---
> drivers/video/
On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> pwm->period field is not supposed to be changed by PWM users. The only
> ones authorized to change it are the PWM core and PWM drivers.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/video/backlight/lm3630a_bl.c | 3 +--
> 1
On Fri, Apr 01, 2016 at 10:38:09AM +0200, Gerd Hoffmann wrote:
> On Mi, 2016-03-30 at 11:51 +0200, Daniel Vetter wrote:
> > No need to confuse userspace like this.
>
> Reviewed-by: Gerd Hoffmann
This and the bochs one applied to drm-misc, thanks for your review.
-Daniel
--
Daniel Vetter
Softwar
On Wed, Mar 30, 2016 at 10:03:27PM +0200, Boris Brezillon wrote:
> PWM devices are not protected against concurrent accesses. The lock in
> pwm_device might let PWM users think it is, but it's actually only
> protecting the enabled state.
>
> Removing this lock should be fine as long as all PWM us
Hi Thierry,
On Tue, 12 Apr 2016 13:22:46 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:27PM +0200, Boris Brezillon wrote:
> > PWM devices are not protected against concurrent accesses. The lock in
> > pwm_device might let PWM users think it is, but it's actually only
> > protecting
On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> Currently the PWM core mixes the current PWM state with the per-platform
> reference config (specified through the PWM lookup table, DT definition or
> directly hardcoded in PWM drivers).
>
> Create a pwm_args struct to store this
On Tue, Apr 12, 2016 at 01:32:55PM +0200, Boris Brezillon wrote:
> Hi Thierry,
>
> On Tue, 12 Apr 2016 13:22:46 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:27PM +0200, Boris Brezillon wrote:
> > > PWM devices are not protected against concurrent accesses. The lock in
> > >
On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> The PWM state, represented by its period, duty_cycle and polarity,
> is currently directly stored in the PWM device.
> Declare a pwm_state structure embedding those field so that we can later
> use this struct to atomically update a
On Tue, Apr 12, 2016 at 01:25:07PM +0300, Imre Deak wrote:
> On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The registers frobbed by vlv_init_display_clock_gating() libve inside
> > the disp2d power well, so frobbing them while the power wel
On Wed, Mar 30, 2016 at 10:03:39PM +0200, Boris Brezillon wrote:
[...]
> @@ -145,7 +146,11 @@ static inline void pwm_get_state(const struct pwm_device
> *pwm,
>
> static inline bool pwm_is_enabled(const struct pwm_device *pwm)
> {
> - return test_bit(PWMF_ENABLED, &pwm->flags);
> + str
Chris,
If the test is ok, can you review-by this patch.
Thanks,
Peter.
On Tue, 22 Mar 2016, Peter Antoine wrote:
Chris.
Can these patches be reviewed without the tests or are they blocked waiting
for the tests.
Are the patches acceptable?
Thanks,
Peter.
On Tue, 15 Mar 2016, Peter Antoin
On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> DPINVGTT lives inside the disp2d power well so we can't frob it unless
> we know the power well is active. Let's this stuff into
> vlv_display_irq_reset() which is only called at the right times so th
On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Enable the unclaimd register detection stuff on vlv/chv since we've
> now
> fixed the known problems during suspend.
>
> This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
>
> Signed-off-
On Tue, 12 Apr 2016 13:39:12 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > Currently the PWM core mixes the current PWM state with the per-platform
> > reference config (specified through the PWM lookup table, DT definition or
> > directly hard
On Tue, 12 Apr 2016 13:49:04 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > The PWM state, represented by its period, duty_cycle and polarity,
> > is currently directly stored in the PWM device.
> > Declare a pwm_state structure embedding those
On Mon, Apr 11, 2016 at 12:50:44PM +0300, Jani Nikula wrote:
> On Mon, 07 Mar 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When the GMBUS based i2c transfer times out, we try to fall back to
> > bit-banging and retry the operation that way. However if the bit-banging
On Mon, Apr 11, 2016 at 11:09:57AM +0300, Jani Nikula wrote:
> On Mon, 11 Apr 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We've had problems on several occasions with using the panel type
> > from the VBT block 40. Usually it seems to be 2, which often
> > doesn't gi
On Tue, Apr 12, 2016 at 02:04:12PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 13:39:12 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > > Currently the PWM core mixes the current PWM state with the per-platform
> > > reference confi
On Tue, 12 Apr 2016, Chris Wilson wrote:
> On Fri, Apr 08, 2016 at 05:59:49PM +0300, Jani Nikula wrote:
>> The whole file is ignored on CONFIG_ACPI=n.
>
> That's an issue as we can't then acquire the opregion->vbt (which itself
> is not acpi dependent). Shrug no modern system can boot without acpi
On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 13:49:04 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > > The PWM state, represented by its period, duty_cycle and polarity,
> > > is currently directly
On Tue, 12 Apr 2016 14:21:41 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 13:49:04 +0200
> > Thierry Reding wrote:
> >
> > > On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > > > The PWM state, represen
On 12/04/16 12:57, Daniel Vetter wrote:
On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
Color management properties are a bit of an odd use case because
they're not marked as atomic properties. Currently we're not updating
the non atomic values so the drm_crtc_state is out of
On Tue, 12 Apr 2016 14:20:29 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 02:04:12PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 13:39:12 +0200
> > Thierry Reding wrote:
> >
> > > On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > > > Currently the PWM core
From: Tvrtko Ursulin
We can use the new pin/lazy unpin API for simplicity
and more performance in the execlist submission paths.
v2:
* Fix error handling and convert more users.
* Compact some names for readability.
v3:
* intel_lr_context_free was not unpinning.
* Special case for GPU r
On Tue, 12 Apr 2016 13:39:12 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > Currently the PWM core mixes the current PWM state with the per-platform
> > reference config (specified through the PWM lookup table, DT definition or
> > directly hard
On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 14:21:41 +0200
> Thierry Reding wrote:
>
> > On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > > On Tue, 12 Apr 2016 13:49:04 +0200
> > > Thierry Reding wrote:
> > >
> > > > On Wed, Mar 30,
On Tue, Apr 12, 2016 at 02:05:05PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We can use the new pin/lazy unpin API for simplicity
> and more performance in the execlist submission paths.
>
> v2:
> * Fix error handling and convert more users.
> * Compact some names for readabili
On Tue, Apr 12, 2016 at 03:06:27PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 13:39:12 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > > Currently the PWM core mixes the current PWM state with the per-platform
> > > reference confi
On Thu, Apr 07, 2016 at 04:56:00PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Rather than blindly waking up all forcewake domains on command
> submission, we can teach each engine what is (or are) the correct
> one to take.
>
> On platforms with multiple forcewake domains like VLV,
On 12/04/16 14:12, Chris Wilson wrote:
On Tue, Apr 12, 2016 at 02:05:05PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We can use the new pin/lazy unpin API for simplicity
and more performance in the execlist submission paths.
v2:
* Fix error handling and convert more users.
* Com
On Tue, 12 Apr 2016 15:11:18 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 14:21:41 +0200
> > Thierry Reding wrote:
> >
> > > On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 Apr 2016 13:
On Tue, Apr 12, 2016 at 02:19:54PM +0100, Tvrtko Ursulin wrote:
>
> On 12/04/16 14:12, Chris Wilson wrote:
> >On Tue, Apr 12, 2016 at 02:05:05PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>We can use the new pin/lazy unpin API for simplicity
> >>and more performance in the exec
On 08/04/16 08:02, Patchwork wrote:
== Series Details ==
Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent
forcewake auto-release timeout across kernel configs
URL : https://patchwork.freedesktop.org/series/5424/
State : failure
== Summary ==
Series 5424v1 Series wi
From: Tvrtko Ursulin
Chris Wilson points out that we can remove them from the array
since they are always written to with raw accessors.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 4
1 file changed, 4 deletions(-)
diff --git a/drive
From: Tvrtko Ursulin
Knowledge of which register per platform belonds in which
forcewake domain was embedded in the MMIO accessors themselves.
Extract it into standalone macros so they can be used from
new code in the following patches.
This causes GCC to compile some of the MMIO accessors slig
From: Tvrtko Ursulin
Rather than blindly waking up all forcewake domains on command
submission, we can teach each engine what is (or are) the correct
one to take.
On platforms with multiple forcewake domains like VLV, CHV, SKL
and BXT, this has the potential of lowering the GPU and CPU
power use
In commit 0a798eb92e6dcc1cba45d13d7b75a523e5d0fc4c
Author: Chris Wilson
Date: Fri Apr 8 12:11:11 2016 +0100
drm/i915: Refactor duplicate object vmap functions
the vmap function that returned NULL on error was replaced by one that
returned an error pointer instead. Not all callsites were up
When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he
suggested replacing some use of kmap(i915_gem_object_get_dirty_page())
with a plain i915_gem_object_pin_map(). This raised the question of who
should mark the page as dirty (or the mapping case, the object).
We can write simple
On Tue, Apr 12, 2016 at 02:33:45PM +0100, Tvrtko Ursulin wrote:
>
> On 08/04/16 08:02, Patchwork wrote:
> > Test kms_flip:
> > Subgroup basic-flip-vs-dpms:
> > pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
>
> Old friend unclaimed access prior to suspending:
> https:/
The newly-introduced function i915_gem_object_pin_map() returns an
ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we
must check for. And it's nicer not to assign such a pointer-or-error to
a structure being filled in until after it's been validated, so we
should keep it local
On 12/04/16 14:43, Ville Syrjälä wrote:
On Tue, Apr 12, 2016 at 02:33:45PM +0100, Tvrtko Ursulin wrote:
On 08/04/16 08:02, Patchwork wrote:
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Old friend unclaimed access pr
We started to use PIPE_CONTROL to write render ring seqno in order to
combat seqno write vs interrupt generation problems. This was introduced
by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt
generation on gen8+ execlists").
On gen8+ size of PIPE_CONTROL with Post Sync Operatio
On Tue, Apr 12, 2016 at 02:46:16PM +0100, Dave Gordon wrote:
> The newly-introduced function i915_gem_object_pin_map() returns an
> ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we
> must check for. And it's nicer not to assign such a pointer-or-error to
> a structure being
Michał Winiarski writes:
> [ text/plain ]
> We started to use PIPE_CONTROL to write render ring seqno in order to
> combat seqno write vs interrupt generation problems. This was introduced
> by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt
> generation on gen8+ execlists").
>
On 30 March 2016 at 10:51, Daniel Vetter wrote:
> No need to confuse userspace like this.
>
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/vir
On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 15:11:18 +0200
> Thierry Reding wrote:
>
> > On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > > On Tue, 12 Apr 2016 14:21:41 +0200
> > > Thierry Reding wrote:
> > >
> > > > On Tue, Apr 12,
== Series Details ==
Series: drm/i915: Use new i915_gem_object_pin_map for LRC (rev2)
URL : https://patchwork.freedesktop.org/series/5580/
State : failure
== Summary ==
Series 5580v2 drm/i915: Use new i915_gem_object_pin_map for LRC
http://patchwork.freedesktop.org/api/1.0/series/5580/revision
On Tue, 12 Apr 2016, Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> > pwm->period field is not supposed to be changed by PWM users. The only
> > ones authorized to change it are the PWM core and PWM drivers.
> >
> > Signed-off-by: Boris Brezillon
> > -
On Tue, 12 Apr 2016 16:05:46 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 15:11:18 +0200
> > Thierry Reding wrote:
> >
> > > On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 Apr 2016 14:
On Tue, 12 Apr 2016, Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> > The PWM period will be set when calling pwm_config. Remove this useless
> > call to pwm_set_period(), which might mess up with the internal PWM state.
> >
> > Signed-off-by: Boris Bre
On Tue, Apr 12, 2016 at 03:16:53PM +0100, Lee Jones wrote:
> On Tue, 12 Apr 2016, Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> > > The PWM period will be set when calling pwm_config. Remove this useless
> > > call to pwm_set_period(), which might m
On Tue, Apr 12, 2016 at 03:16:13PM +0100, Lee Jones wrote:
> On Tue, 12 Apr 2016, Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> > > pwm->period field is not supposed to be changed by PWM users. The only
> > > ones authorized to change it are the PWM
From: Tim Gore
WaEnableSamplerGPGPUPreemptionSupport fixes a problem
related to mid thread pre-emption.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a
== Series Details ==
Series: series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of
register forcewake domains
URL : https://patchwork.freedesktop.org/series/5593/
State : failure
== Summary ==
Series 5593v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0
This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.
intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vb
>-Original Message-
>From: Conselvan De Oliveira, Ander
>Sent: Monday, April 11, 2016 6:07 PM
>To: intel-gfx@lists.freedesktop.org; R, Durgadoss
>Cc: ville.syrj...@linux.intel.com
>Subject: Re: [PATCHv3 2/4] drm/i915: Store the dpll config in
>crtc_state->shared_dpll
>
>On Wed, 2016-04-06
On 12/04/16 15:29, Patchwork wrote:
== Series Details ==
Series: series starting with [resend-for-CI,1/3] drm/i915: Extract knowledge of
register forcewake domains
URL : https://patchwork.freedesktop.org/series/5593/
State : failure
== Summary ==
Series 5593v1 Series without cover letter
h
From: Tvrtko Ursulin
Split the hardware status page into setup and initialisation,
where setup means setting up the driver state to support the
engine, and initialization means programming the hardware
with the before set up state.
This way the design matches the design of the engine setup/init
From: Tvrtko Ursulin
We can use the new pin/lazy unpin API for simplicity
and more performance in the execlist submission paths.
v2:
* Fix error handling and convert more users.
* Compact some names for readability.
v3:
* intel_lr_context_free was not unpinning.
* Special case for GPU r
On Tue, 12 Apr 2016, Emil Velikov wrote:
> On 30 March 2016 at 10:51, Daniel Vetter wrote:
> > No need to confuse userspace like this.
> >
> > Cc: Gerd Hoffmann
> > Cc: Dave Airlie
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> > 1 fil
On Tue, Apr 12, 2016 at 04:32:19PM +0200, Maarten Lankhorst wrote:
> This function is useful for gen2 intel devices which have no frame
> counter, but need a way to determine the current vblank count without
> racing with the vblank interrupt handler.
>
> intel_pipe_update_start checks if no vblan
1 - 100 of 179 matches
Mail list logo
