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
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, 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
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
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 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
--
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
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
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
> 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
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
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(+)
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
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: 6660
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
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
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
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
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
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
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 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
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
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
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
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 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
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 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
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, 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
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, 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 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, 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
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
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
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
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 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
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: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 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 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 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 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 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
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 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
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 05:50:09PM +0300, Jani Nikula wrote:
> On Mon, 29 Jun 2015, Ander Conselvan De Oliveira wrote:
> > On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
> >> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote:
> >> >
> >> > This is the main drm pull request for v4.2.
>
Hi,
On 06/29/2015 03:39 PM, Lukas Wunner wrote:
Hi,
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 failure path where it calls drm_framebuffer_remove,
which grabs the struct mutex and intelfb_
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 need to update the drm_crtc->mode and the adjusted
mode in intel_crtc. So that wat
On Mon, Jun 29, 2015 at 03:56:07PM +0100, Tvrtko Ursulin wrote:
> >Yes. But I would prefer MAP_FIXED to be the first invalidate, but that
> >looks like we then need to leak the ptr.
>
> If it used mmap instead of posix_memalign and no free then what
> would it leak? MAP_FIXED would be guaranteed f
Hi All,
More i915 WARN splats. This one on a machine with Linus' latest tree
as of this morning.
josh
[7.906372] [drm] Replacing VGA console driver
[7.935724] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.942359] [drm] Driver supports precise vblank timestamp query.
On Friday 26 June 2015 10:42 PM, Daniel Vetter wrote:
On Fri, Jun 26, 2015 at 07:21:54PM +0530, Ramalingam C wrote:
For all the connectors drrs init is invoked. drrs_init will
initialize the drrs for those connectors that support DRRS.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/in
On 06/29/2015 03:25 PM, Chris Wilson wrote:
On Mon, Jun 29, 2015 at 03:15:12PM +0100, Tvrtko Ursulin wrote:
On 06/29/2015 03:07 PM, Chris Wilson wrote:
On Mon, Jun 29, 2015 at 03:01:12PM +0100, Tvrtko Ursulin wrote:
On 06/29/2015 11:59 AM, Michał Winiarski wrote:
When the the memory backin
Hi Jani,
On Mon, Jun 29, 2015 at 02:24:19PM +0300, Jani Nikula wrote:
> On Mon, 15 Jun 2015, Chris Wilson wrote:
> > There wasn't, I just rewrote it incorrectly. There's also a
> > drm_framebuffer_remove() called by intelfb_alloc which needs to be moved
> > out of the mutex. A much larger disenta
On Mon, 29 Jun 2015, Ander Conselvan De Oliveira wrote:
> On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
>> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote:
>> >
>> > This is the main drm pull request for v4.2.
>>
>> It seems to work ok for me, but it causes quite a few new warnings
Nick Hoath writes:
> On 29/06/2015 15:08, Mika Kuoppala wrote:
>>
>> Hi,
>>
>> Nick Hoath writes:
>>
>>> From: Rafael Barbalho
>>>
>>> Signed-off-by: Rafael Barbalho
>>> Signed-off-by: Nick Hoath
>>> ---
>>> drivers/gpu/drm/i915/intel_pm.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
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.com wrote:
> From: Alex Dai
>
> This is to avoid bad IO a
Hi,
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 failure path where it calls drm_framebuffer_remove,
> which grabs the struct mutex and intelfb_create (caller of intelfb_alloc) was
>
On Mon, Jun 29, 2015 at 07:46:18PM +0530, Sivakumar Thulasimani wrote:
>
>
> On 6/29/2015 5:55 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
> > again when disabling the DPLL. Having VGA mode enable
Nick Hoath writes:
> Add stepping check for A0 workarounds, and remove the associated
> FIXME tags.
> Split out unrelated WAs for later condition checking.
>
> v2: Fixed format (PeterL)
> v3: Corrected stepping check for WaDisableSDEUnitClockGating
> - Ignoring comment, following hardware spe
On Mon, Jun 29, 2015 at 03:15:12PM +0100, Tvrtko Ursulin wrote:
>
> On 06/29/2015 03:07 PM, Chris Wilson wrote:
> >On Mon, Jun 29, 2015 at 03:01:12PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 06/29/2015 11:59 AM, Michał Winiarski wrote:
> >>>When the the memory backing the userptr object is freed b
Reviewed-by: Sivakumar Thulasimani
On 6/29/2015 5:55 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Drop the spurious 'A' from the VLV/CHV ref clock enable define,
and add the "REF" to the VLV ref clock selection bit. Also
s/CLOCK/CLK/ for extra consistency.
Signed-off-by: Vill
On 29/06/2015 15:08, Mika Kuoppala wrote:
Hi,
Nick Hoath writes:
From: Rafael Barbalho
Signed-off-by: Rafael Barbalho
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/dr
On 6/29/2015 5:55 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
again when disabling the DPLL. Having VGA mode enabled even in unused
DPLLs can cause problems for CHV, so it seems wiser to always keep it
dis
On 06/29/2015 03:07 PM, Chris Wilson wrote:
On Mon, Jun 29, 2015 at 03:01:12PM +0100, Tvrtko Ursulin wrote:
On 06/29/2015 11:59 AM, Michał Winiarski wrote:
When the the memory backing the userptr object is freed by the user, it's
possible to trigger recursive deadlock caused by operations don
Hi,
Nick Hoath writes:
> From: Rafael Barbalho
>
> Signed-off-by: Rafael Barbalho
> Signed-off-by: Nick Hoath
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 32ff0
On Mon, Jun 29, 2015 at 03:01:12PM +0100, Tvrtko Ursulin wrote:
>
> On 06/29/2015 11:59 AM, Michał Winiarski wrote:
> >When the the memory backing the userptr object is freed by the user, it's
> >possible to trigger recursive deadlock caused by operations done on
> >different BO mapped in that reg
On 06/29/2015 11:59 AM, Michał Winiarski wrote:
When the the memory backing the userptr object is freed by the user, it's
possible to trigger recursive deadlock caused by operations done on
different BO mapped in that region, triggering invalidate.
Signed-off-by: Michał Winiarski
---
tests/g
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.com wrote:
From: Alex Dai
This is to avoid bad IO access caused by writing NOOP to wrap the
rin
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6654
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Nick Hoath (2):
drm/i915/bxt: Enable WaOCLCoherentLineFlush
drm/i915/bxt: Clean up bxt_init_clock_gating
Rafael Barbalho (2):
drm/i915/bxt: Enable WaVSRefCountFullforceMissDisable
drm/i915/bxt: Enable WaDSRefCountFullforceMissDisable
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/dr
Add stepping check for A0 workarounds, and remove the associated
FIXME tags.
Split out unrelated WAs for later condition checking.
v2: Fixed format (PeterL)
v3: Corrected stepping check for WaDisableSDEUnitClockGating
- Ignoring comment, following hardware spec instead. (ChrisH)
Added desc
Signed-off-by: Nick Hoath
Cc: Rafael Barbalho
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b9f6b8c..115911a 100644
--- a/drivers/gpu/drm/
From: Rafael Barbalho
Signed-off-by: Rafael Barbalho
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d635d0a..f29e575 100644
--- a/dr
From: Rafael Barbalho
Signed-off-by: Rafael Barbalho
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 32ff034..d635d0a 100644
--- a/drivers/gpu/drm/i915
The old style of memory interleaving swizzled upto the end of the
first even bank of memory, and then used the remainder as unswizzled on
the unpaired bank - i.e. swizzling is not constant for all memory. This
causes problems when we try to migrate memory and so the kernel prevents
migration at all
The section id is generated from the section title and is used to create
the html output filename, which therefore causes problems if it includes
a '/' character.
Cc: Damien Lespiau
Signed-off-by: Thomas Wood
---
lib/intel_mmio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/intel_mmi
On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote:
> >
> > This is the main drm pull request for v4.2.
>
> It seems to work ok for me, but it causes quite a few new warnings on
> my Sony VAIO Pro laptop. It's (once more) a regular i5-420
On Tue, Jun 23, 2015 at 08:36:30AM +0200, Andreas Lampersperger wrote:
> When the i915.ko identify an eDP output on a valleyview
> board, it should be more slackly. The reason for that is,
> that BIOS DATA TABLES generated with intel BMP (Binary
> Modification Program) do not set bits for NOT_HDMI
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 way for DPLL_MD, but do
it for DPLL too.
Toss in a WARN to intel_dsi_pre_enable() to make
From: Ville Syrjälä
The BIOS maybe leave the DSI PLL enabled even if the port is disabled.
The PLL doesn't seem to like being reconfigured while it's enabled so
make sure it's disabled before doing that.
The better fix would be to expose all PLLs independently of their ports
so that we could dis
From: Ville Syrjälä
While trawling the w/a database I spotted a workaround we didn't
have related to CHV DPLL pixel multiuplier setting. So I set forth
to implement it, and while doing that I ended up cleaning up the
VLV/CHV DPLL handling a bit. This also touched the DSI code a bit
and while test
From: Ville Syrjälä
Bunch of stuff needs the DPLL ref/cri clocks on both VLV and CHV,
and having VGA mode enabled causes some problems for CHV. So let's just
pull the code to configure those bits into the disp2d well enable hook.
With the DPLL disable code also fixed to leave those bits alone we
From: Ville Syrjälä
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
to either pipe B or C. So do that to make pixel repeat work on pipes
B and C. Pipe A is fine without any tricks.
Fortunately the pixel repeat
From: Ville Syrjälä
Drop the spurious 'A' from the VLV/CHV ref clock enable define,
and add the "REF" to the VLV ref clock selection bit. Also
s/CLOCK/CLK/ for extra consistency.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 6 +++---
drivers/gpu/drm/i915/intel_di
From: Ville Syrjälä
The pipe A power well is the "disp2d" well on CHV and pipe B and C wells
don't even exist. Thereforce we can remove the checks for pipe A vs.
others and just assume it's always pipe A.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 47 +++
From: Ville Syrjälä
We do the exact same steps around the disp2d/pipe A power well
enable/disable on VLV and CHV. Refactor the shared code into
some helpers.
Note that this means we now call vlv_power_sequencer_reset() before
turning off the power well, whereas before we did it after. That
doesn
From: Ville Syrjälä
We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
again when disabling the DPLL. Having VGA mode enabled even in unused
DPLLs can cause problems for CHV, so it seems wiser to always keep it
disabled. And let's just do that on all GMCH platforms to keep thi
From: Ville Syrjälä
The VLV and CHV DPLL disable and update are almost identical in
how the DPLL/DPLL_MD registers need to be set up. But the code
looks more different than it really is. Try to bring them into
line.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 63 +++
On Sun, 28 Jun 2015, Chris Wilson wrote:
> On Sun, Jun 28, 2015 at 09:19:26AM +0100, Chris Wilson wrote:
>> The old style of memory interleaving swizzled upto the end of the
>> first even bank of memory, and then used the remainder as unswizzled on
>> the unpaired bank - i.e. swizzling is not cons
On Mon, 2015-06-29 at 14:47 +0300, Jani Nikula wrote:
> On Mon, 29 Jun 2015, Ander Conselvan De Oliveira wrote:
> > i915 features:
> >
> > display - atomic
> > display - audio
> > display - DP
> > display - DP MST
> > display - DSI
> > display - eDP
> > display - FBC
> > display - HDMI
> >
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 same vrefresh, then userspace
activities based on vsync will go for toss.
Cl
On Mon, 29 Jun 2015, Chris Wilson wrote:
> On Mon, Jun 29, 2015 at 02:40:15PM +0300, Jani Nikula wrote:
>> On Thu, 07 May 2015, Chris Wilson wrote:
>> > On Wed, May 06, 2015 at 01:16:30PM +0200, Daniel Vetter wrote:
>> >> On Tue, May 05, 2015 at 09:17:29AM +0100, Chris Wilson wrote:
>> >> > [ 157
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 Jun 2015, Jani Nikula wrote:
> >> >> On Wed, 03 Jun 2015, Mika Kahola w
1 - 100 of 152 matches
Mail list logo
