Makes it really hard to reason about these since there are dependency
loops. Also if you touch them and don't know what you're doing you get
to keep all the pieces.
Also sweep over all options and mark everything which isn't clearly
just a harmless debug helper thing of one of the official functio
On Mon, Jun 29, 2015 at 02:46:41PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 29, 2015 at 02:42:25PM +0300, Jani Nikula wrote:
> > On Mon, 29 Jun 2015, Mika Kahola wrote:
> > > On Mon, 2015-06-29 at 14:24 +0300, Jani Nikula wrote:
> > >> On Tue, 16 Jun 2015, Jani Nikula wrote:
> > >> > On Tue, 16
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6655
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Mon, Jun 29, 2015 at 05:44:40PM +0300, Jani Nikula wrote:
> On Mon, 29 Jun 2015, Dave Gordon wrote:
> > On 29/06/15 12:39, Jani Nikula wrote:
> >> On Wed, 06 May 2015, Daniel Vetter wrote:
> >>> On Thu, Apr 30, 2015 at 01:54:41PM +0100, Dave Gordon wrote:
> On 29/04/15 17:10, yu@intel
On Mon, Jun 29, 2015 at 12:17:33PM +0100, Chris Wilson wrote:
> Michał Winiarski found a really evil way to trigger a struct_mutex
> deadlock with userptr. He found that if he allocated a userptr bo and
> then GTT mmaped another bo, or even itself, at the same address as the
> userptr using MAP_FIX
On Mon, Jun 29, 2015 at 01:35:06PM +0300, Antti Koskipää wrote:
> Looks fine to me.
>
> Reviewed-by: Antti Koskipää
>
>
> On 06/25/2015 11:11 AM, David Weinehall wrote:
> > This patch adds support for 0.85V VccIO on Skylake Y,
> > separate buffer translation tables for Skylake U,
> > and suppor
On Mon, Jun 29, 2015 at 05:18:21PM +0530, Ramalingam C wrote:
>
> On Friday 26 June 2015 10:38 PM, Daniel Vetter wrote:
> >On Fri, Jun 26, 2015 at 07:21:53PM +0530, Ramalingam C wrote:
> >>If crtc is in clone mode, DRRS will be disabled. Because if the both
> >>the displays are not sharing the sam
On Mon, Jun 29, 2015 at 08:28:53PM +0530, Ramalingam C wrote:
>
> On Friday 26 June 2015 10:41 PM, Daniel Vetter wrote:
> >On Fri, Jun 26, 2015 at 07:21:55PM +0530, Ramalingam C wrote:
> >>During the DRRS state transitions we are modifying the clock and
> >>hence the vrefresh rate.
> >>
> >>So we
On Mon, Jun 29, 2015 at 04:52:14PM +0530, Ramalingam C wrote:
> On Friday 26 June 2015 10:46 PM, Daniel Vetter wrote:
> >On Fri, Jun 26, 2015 at 07:21:44PM +0530, Ramalingam C wrote:
> >- Static DRRS and generalized seamless DRRS are imo separate features and
> > we should split the patch series.
On Mon, Jun 29, 2015 at 02:31:22PM +0300, Ander Conselvan De Oliveira wrote:
> On Fri, 2015-06-26 at 18:28 +0300, Ander Conselvan De Oliveira wrote:
> > Hi all,
> >
> > I've been looking into creating custom fields in Bugzilla to help sort
> > our bugs in a more manageable way.
>
> [...]
>
> > S
On Mon, Jun 29, 2015 at 04:30:40PM +0530, Sivakumar Thulasimani wrote:
> From: "Thulasimani, Sivakumar"
>
> HPD storm is detected in intel_hpd_irq_handler and disabled for respective
> port immediately but polling is enabled only in i915_hotplug_work_func and
> not in i915_digport_work_func. This
From: John Harrison
An earlier patch was added to reserve space in the ring buffer for the
commands issued during 'add_request()'. The initial version was
pessimistic in the way it handled buffer wrapping and would cause
premature wraps and thus waste ring space.
This patch updates the code to b
On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state
> from the pipe_config in intel_dsi_get_config(). This avoids spurious
> state checker warnings. We already did it this wa
Currently, when the firwmare isn't loaded, we don't enable DC6
(obviously!) but the disable path tries unconditionally to disable DC6.
[drm:i915_power_well_enable] enabling power well 1
[drm:i915_power_well_enable] enabling MISC IO power well
[drm:i915_power_well_enable] enabling power well 2
This code is all dead code since we want to go up to DC6, always.
Cc: A.Sunil Kamath
Cc: Suketu Shah
Cc Animesh Manna
Signed-off-by: Damien Lespiau
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 99 +
1 file changed, 13 insertions
On Mon, 2015-06-29 at 17:44 +0100, Damien Lespiau wrote:
> This code is all dead code since we want to go up to DC6, always.
On BXT DC6 is not available, so we can only go to DC5. It's disabled on
BXT atm, since runtime PM isn't enabled either.
> Cc: A.Sunil Kamath
> Cc: Suketu Shah
> Cc Animes
On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote:
> On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state
> > from the pipe_config in intel_dsi_get_config().
On Mon, Jun 29, 2015 at 07:54:42PM +0300, Imre Deak wrote:
> On Mon, 2015-06-29 at 17:44 +0100, Damien Lespiau wrote:
> > This code is all dead code since we want to go up to DC6, always.
>
> On BXT DC6 is not available, so we can only go to DC5. It's disabled on
> BXT atm, since runtime PM isn't
On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote:
> > On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > VLV/CHV don't use the DPLL with DSI, so jus
On Mon, 2015-06-29 at 17:59 +0100, Damien Lespiau wrote:
> On Mon, Jun 29, 2015 at 07:54:42PM +0300, Imre Deak wrote:
> > On Mon, 2015-06-29 at 17:44 +0100, Damien Lespiau wrote:
> > > This code is all dead code since we want to go up to DC6, always.
> >
> > On BXT DC6 is not available, so we can
But DC5 needed for BXT
- Sunil
>-Original Message-
>From: Lespiau, Damien
>Sent: Monday, June 29, 2015 10:15 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Kamath, Sunil; Shah, Suketu J
>Subject: [PATCH 1/2] drm/i915/skl: Remove of the DC5 code
>
>This code is all dead code since we want t
On Mon, Jun 29, 2015 at 08:08:59PM +0300, Imre Deak wrote:
> On Mon, 2015-06-29 at 17:59 +0100, Damien Lespiau wrote:
> > On Mon, Jun 29, 2015 at 07:54:42PM +0300, Imre Deak wrote:
> > > On Mon, 2015-06-29 at 17:44 +0100, Damien Lespiau wrote:
> > > > This code is all dead code since we want to go
From: Ville Syrjälä
Stolen gets trashed during hibernation, so storing contexts there
is not a very good idea. On my IVB machines this leads to a totally
dead GPU on resume. A reboot is required to resurrect it. So let's
not store contexts where they will get trampled.
This reverts commit 149c86
On Thu, 18 Jun 2015 10:42:45 +0200
Patrik Jakobsson wrote:
> This patch adds many of the DRM and KMS ioctls. The rest can be added as
> needed.
>
> * drm.c: Decode DRM_IOCTL_VERSION
> * drm.c: Decode DRM_IOCTL_GET_UNIQUE
> * drm.c: Decode DRM_IOCTL_GET_MAGIC
> * drm.c: Decode DRM_IOCTL_WAIT_VBLA
On Thu, 18 Jun 2015 10:42:44 +0200
Patrik Jakobsson wrote:
> There are more ioctls to add but the ones in this patch are most
> commonly used.
>
> * Makefile.am: Add compilation of drm_i915.c
> * drm.c: Dispatch i915 ioctls
> * drm_i915.c: Decode DRM_IOCTL_I915_GETPARAM
> * drm_i915.c: Decode DR
On Mon, 29 Jun 2015 12:47:20 +0200
Patrik Jakobsson wrote:
> On Thu, Jun 18, 2015 at 10:42:40AM +0200, Patrik Jakobsson wrote:
> > This set of patches adds a dispatcher for handling DRM ioctls. The
> > kernel headers for DRM might not be available on all distributions
> > so we depend on libdrm f
Hi Tvrtko,
On Mon, Jun 29, 2015 at 04:15:08PM +0100, Tvrtko Ursulin wrote:
> On 06/29/2015 03:39 PM, Lukas Wunner wrote:
> >On Mon, Jun 15, 2015 at 11:49:52AM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>We had two failure modes here:
> >>
> >>1.
> >>Deadlock in intelfb_alloc fa
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6657
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Mon, Jun 29, 2015 at 08:28:35PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Stolen gets trashed during hibernation, so storing contexts there
> is not a very good idea. On my IVB machines this leads to a totally
> dead GPU on resume. A reboot is required to resurrect
On Mon, Jun 29, 2015 at 08:53:12PM +0100, Chris Wilson wrote:
> On Mon, Jun 29, 2015 at 08:28:35PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Stolen gets trashed during hibernation, so storing contexts there
> > is not a very good idea. On my IVB machines this lea
On Mon, Jun 29, 2015 at 06:31:16PM +0200, Daniel Vetter wrote:
> I think we can condense the older platforms down a lot, maybe even just
> GEN2, GEN3, GEN4. Or at least group desktop and mobile together, i.e.
>
> I8XX, I915, I945, G33/PNV, I965, G4X (we put both under that tag usually).
I would a
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6658
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
There are cases we need to mark dirty/damaged areas, specially with
operations that touches frontbuffer directly. To cover these cases
this patch introduces the optional fb_dirty operation.
Signed-off-by: Rodrigo Vivi
---
drivers/video/fbdev/core/cfbcopyarea.c | 3 +++
drivers/video/fbdev/core/c
This patch introduces a frontbuffer invalidation on dirty fb
user callback.
It is mainly used for DIRTYFB drm ioctl, but can be extended
for fbdev use on following patch.
This patch itself already solves the biggest PSR known issue, that is
missed screen updates during boot, mainly when there is
Now that we have fb user dirty invalidating frontbuffer and we have
the new fbdev dirty callback let's merge them.
So it doesn't matter if fbcon throught fbdev or splash screen throught
drm_ioctl_dirtyfb, in any case we will have frontbuffer properly
invalidated and power savings features that rel
With fb_dirty op in place we can simplify stuff here.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/udl/udl_fb.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 5fc16ce..68
Now that we have fb user dirty invalidating frontbuffer and we have
the new fbdev dirty callback let's merge them.
So it doesn't matter if fbcon throught fbdev or splash screen throught
drm_ioctl_dirtyfb, in any case we will have frontbuffer properly
invalidated and power savings features that rel
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6660
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6664
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6665
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Reviewed-by: Sonika Jindal
On 6/23/2015 2:05 AM, Imre Deak wrote:
Move the helper next to the PLL helpers of the other platforms for
clarity.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1 file changed, 10 insertions(+)
On 6/29/2015 10:07 PM, Daniel Vetter wrote:
On Mon, Jun 29, 2015 at 04:30:40PM +0530, Sivakumar Thulasimani wrote:
From: "Thulasimani, Sivakumar"
HPD storm is detected in intel_hpd_irq_handler and disabled for respective
port immediately but polling is enabled only in i915_hotplug_work_func
> This patch swaps src width and height for dbuf/wm calculations
> when rotation is 90/270 as per hw requirements.
>
> Signed-off-by: Chandra Konduru
Do we have an igt which provokes underruns and hence can test this
automatically? Very tall/narrow buffers should do it I think.
-Daniel
Yes. Righ
Crystal Cove PMIC - Backlight control
Tested by Brian Loften, blofte...@gmail.com confirmed working on ASUS
T100TA, 15.04 i386 Ubuntu Gnome -- suspend resume is functioning normally,
backlight controls work before and after resume using slide and meta keys
on keyboard
On Mon, Jun 29, 2015 at 10:1
Tested by Brian Loften, "Brain Wreck" blofte...@gmail.com confirmed working
on ASUS T100TA, kernel 20150629 -next running 15.04 i386 Ubuntu Gnome --
suspend resume is functioning normally, backlight controls work before and
after resume using slide controls and meta keys on keyboard
O
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6667
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
From: Shashank Sharma
This patch adds the intel_connector initialized to intel_hdmi
display, during the init phase, just like the other encoders do.
This attachment is very useful when we need to extract the connector
pointer during the hotplug handler function
Signed-off-by: Shashank Sharma
--
From: Shashank Sharma
This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.
The reason behind addition of this separate function needs
brief explaination. The current implementation of hdmi_detect
From: Shashank Sharma
This patch makes sure that the HDMI detect function
reads EDID only when its forced to do it. All the other
times, it uses the connector->detect_edid which was cached
during hotplug handling in the hdmi_probe() function. As the
probe function gets called before detect in the
On Mon, 2015-06-29 at 21:05 +0100, Chris Wilson wrote:
> On Mon, Jun 29, 2015 at 08:53:12PM +0100, Chris Wilson wrote:
> > On Mon, Jun 29, 2015 at 08:28:35PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Stolen gets trashed during hibernation, so storing c
On Monday 29 June 2015 09:57 PM, Daniel Vetter wrote:
On Mon, Jun 29, 2015 at 04:52:14PM +0530, Ramalingam C wrote:
On Friday 26 June 2015 10:46 PM, Daniel Vetter wrote:
On Fri, Jun 26, 2015 at 07:21:44PM +0530, Ramalingam C wrote:
- Static DRRS and generalized seamless DRRS are imo separate f
On Mon, Jun 29, 2015 at 01:44:43PM -0700, Rodrigo Vivi wrote:
> This patch introduces a frontbuffer invalidation on dirty fb
> user callback.
>
> It is mainly used for DIRTYFB drm ioctl, but can be extended
> for fbdev use on following patch.
>
> This patch itself already solves the biggest PSR k
101 - 152 of 152 matches
Mail list logo
