On Wed, Aug 13, 2014 at 03:40:24PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 02:09:22PM +0100, Chris Wilson wrote:
> > On Wed, Aug 13, 2014 at 03:04:02PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
> > > > On Wed, Aug 13, 2014 at 02:46
On Wed, Aug 13, 2014 at 05:50:38PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > The current error state harks back to the era of just a single VM. For
> > full-ppgtt, we capture every bo on every VM. It behoves us to then print
> > every bo for every VM, which we currently fail to do
Regards
Shashank
On 8/13/2014 5:44 PM, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 06:08:20PM +0530, shashank.sha...@intel.com wrote:
From: Shashank Sharma
The current hdmi_detect() function is getting called from
many places, few of these are:
1. HDMI hot plug interrupt bottom half
2. get_re
On Wed, Aug 13, 2014 at 10:25 PM, Rusty Russell wrote:
> Jani Nikula writes:
>> This is a generic version of Daniel's patch [1] letting us have unsafe
>> module parameters (experimental, debugging, testing, etc.) that taint
>> the kernel when set. Quoting Daniel,
>
> OK, I think the idea is fine,
On 08/12/2014 07:11 AM, Jani Nikula wrote:
This series adds support for backlight class sysfs bl_power attribute
for eDP panels, which allows switching the backlight on/off. This is
done using the eDP panel power control as a sub-state of everything else
being enabled. Patch 4 also makes 0 bright
Hi Everyone,
I am an Operating system developer and I'm working on a project for
which I wanted to understand the working of Intel Graphics Driver.
Being somewhat new in this field, Can I ask anyone to point me where
should I start digging in the code? I mean where the graphic driver
initializes c
> Ville noticed that we can call ibx_digital_port_connected() which accesses
> the HW without holding any power well/runtime pm reference. Fix this by
> holding a display port power domain reference around the whole hpd_pulse
> handler.
>
> Signed-off-by: Imre Deak
Makes sense to me,
Reviewed-by
Jani Nikula writes:
> This is a generic version of Daniel's patch [1] letting us have unsafe
> module parameters (experimental, debugging, testing, etc.) that taint
> the kernel when set. Quoting Daniel,
OK, I think the idea is fine, but we'll probably only want this for
a few types (eg. int and
From: Sagar Kamble
With this change, intel_runtime_suspend and intel_runtime_resume functions
become completely platform agnostic. Platform specific suspend/resume
changes are moved to intel_suspend_complete and intel_resume_prepare.
Cc: Imre Deak
Cc: Paulo Zanoni
Cc: Daniel Vetter
Cc: Jani N
From: Sagar Kamble
On VLV, post S0i3 during i915_drm_thaw following issue is observed during ring
initialization.
[ 335.604039] [drm:stop_ring] ERROR render ring :timed out trying to stop ring
[ 336.607340] [drm:stop_ring] ERROR render ring :timed out trying to stop ring
[ 336.607345] [drm:init_
The series seems fine to me.
Reviewed-by: Ville Syrjälä
for the rest as well.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Aug 13, 2014 at 03:07:29PM +, Daniel, Thomas wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, August 11, 2014 10:25 PM
> > To: Daniel, Thomas
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject
On Wed, Aug 13, 2014 at 01:34:28PM +, Daniel, Thomas wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, August 11, 2014 9:57 PM
> > To: Daniel, Thomas
> > Cc: intel-gfx@lists.freedesktop.org
> > Su
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, August 11, 2014 10:25 PM
> To: Daniel, Thomas
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 27/43] drm/i915/bdw: Render state init for
> Execli
Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM ref
On Wed, Aug 13, 2014 at 01:34:15PM +, Daniel, Thomas wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, August 11, 2014 3:21 PM
> > To: Daniel, Thomas
> > Cc: intel-gfx@lists.freedesktop.org
> > Su
Atm we may retrain the DP link even if the CRTC is inactive through
HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak
Reviewed-by: Ville S
Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD->DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.
Note that runtime suspend doesn't have the same problem, since there the
RPM ref held by VDD provides already the ne
Ville noticed that we can call ibx_digital_port_connected() which accesses
the HW without holding any power well/runtime pm reference. Fix this by
holding a display port power domain reference around the whole hpd_pulse
handler.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 19 +
Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.
Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling
On Fri, 8 Aug 2014 15:14:15 +0200
Daniel Vetter wrote:
> Adding relevant mailing lists.
>
> On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross wrote:
> > I'm just about to create a patch for full PAT support in the Linux
> > kernel, including Xen. For this purpose I introduce a translation
> > betwe
On Wed, 2014-08-13 at 16:47 +0300, Imre Deak wrote:
> On Tue, 2014-08-12 at 16:21 +0530, sagar.a.kam...@intel.com wrote:
> > From: Sagar Kamble
>
> The change is substantial enough that you should add a commit message
> explaining what it fixes and how. There are further useful guidelines on
> th
Chris Wilson writes:
> The current error state harks back to the era of just a single VM. For
> full-ppgtt, we capture every bo on every VM. It behoves us to then print
> every bo for every VM, which we currently fail to do and so miss vital
> information in the error state.
>
> v2: Use the vma a
On Tue, 2014-08-12 at 16:21 +0530, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
The change is substantial enough that you should add a commit message
explaining what it fixes and how. There are further useful guidelines on
this topic in Documentation/SubmittingPatches.
In the future, you
On Wed, 23 Jul 2014, Hans de Goede wrote:
> Hi,
>
> On 07/22/2014 08:52 AM, Daniel Vetter wrote:
>> On Tue, Jul 22, 2014 at 8:42 AM, Hans de Goede wrote:
>>> Hi Jani et al,
>>>
>>> A friend of mine Bertrik Sikken (in the Cc) his backlight control
>>> stopped working for him on his Samsung N150Plu
On Wed, Aug 13, 2014 at 02:09:22PM +0100, Chris Wilson wrote:
> On Wed, Aug 13, 2014 at 03:04:02PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
> > > On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
> > > > On Wed, Aug 13, 2014 at 01:09
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, August 11, 2014 3:21 PM
> To: Daniel, Thomas
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 08/43] drm/i915/bdw: Add a context and an
> engine p
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, August 11, 2014 9:57 PM
> To: Daniel, Thomas
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 21/43] drm/i915/bdw: Emission of requests
> with log
On Wed, Aug 13, 2014 at 03:04:02PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
> > On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
> > > > Rather than take and release
On Wed, Aug 13, 2014 at 01:58:30PM +0100, Chris Wilson wrote:
> On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
> > > Rather than take and release the console_lock() around a non-existent
> > > DRM_I915_FBDEV, move the
On Wed, Aug 13, 2014 at 02:46:53PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
> > Rather than take and release the console_lock() around a non-existent
> > DRM_I915_FBDEV, move the lock acquisation into the callee where it will
> > be compiled out by
On Wed, Aug 13, 2014 at 01:09:46PM +0100, Chris Wilson wrote:
> Rather than take and release the console_lock() around a non-existent
> DRM_I915_FBDEV, move the lock acquisation into the callee where it will
> be compiled out by the config option entirely. This includes moving the
> deferred fb_set
On Wed, Aug 13, 2014 at 12:45:11PM +0100, Chris Wilson wrote:
> On Wed, Aug 13, 2014 at 01:32:31PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 13, 2014 at 11:51:55AM +0100, Chris Wilson wrote:
> > > From: Daniel Vetter
> > >
> > > That's right, back to where it was!
> > >
> > > This effectively
On Tue, Aug 12, 2014 at 06:08:20PM +0530, shashank.sha...@intel.com wrote:
> From: Shashank Sharma
>
> The current hdmi_detect() function is getting called from
> many places, few of these are:
> 1. HDMI hot plug interrupt bottom half
> 2. get_resources() IOCTL family
> 3. drm_helper_probe_single
On Wed, Aug 13, 2014 at 01:12:12PM +0530, Sharma, Shashank wrote:
> On 8/13/2014 11:46 AM, Chris Wilson wrote:
> >On Wed, Aug 13, 2014 at 11:34:02AM +0530, Sharma, Shashank wrote:
> >>5. We want this code routine only to be executed for commercial (like
> >>android) platforms, whereas others ge
Rather than take and release the console_lock() around a non-existent
DRM_I915_FBDEV, move the lock acquisation into the callee where it will
be compiled out by the config option entirely. This includes moving the
deferred fb_set_suspend() dance and encapsulating it entirely within
intel_fbdev.c.
On Wed, Aug 13, 2014 at 01:39:22PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 12:32:33PM +0100, Chris Wilson wrote:
> > On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
> > > > +static void intel_fbdev_set_
On Wed, Aug 13, 2014 at 01:39:22PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 12:32:33PM +0100, Chris Wilson wrote:
> > On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
> > > This one here must be synchronous.
> >
> > Right, but notice that we synchronize the work afterwar
On Wed, Aug 13, 2014 at 01:32:08PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 11:51:54AM +0100, Chris Wilson wrote:
> > As we use WC updates of the PTE, we are responsible for notifying the
> > hardware when to flush its TLBs. Do so after we zap all the PTEs before
> > suspend (and the B
On Wed, Aug 13, 2014 at 01:32:31PM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 11:51:55AM +0100, Chris Wilson wrote:
> > From: Daniel Vetter
> >
> > That's right, back to where it was!
> >
> > This effectively reverts
>
> Hm, why?
Becuase it doesn't belong in i915_gem_gtt.c since the
On Wed, Aug 13, 2014 at 12:14:12PM +0100, Chris Wilson wrote:
> Ville pointed out the GCCism __builtin_types_compatible_p() that we
> could use to replace our heavily casted presumption __I915__ macro that
> was based on comparing struct sizes.
>
> Signed-off-by: Chris Wilson
Yeah, that looks a
On Wed, Aug 13, 2014 at 12:32:33PM +0100, Chris Wilson wrote:
> On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
> > > Rather than take and release the console_lock() around a non-existent
> > > DRM_I915_FBDEV, move the
On Wed, Aug 13, 2014 at 11:57:05AM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 845/865 support different cursor sizes as well, albeit a bit differently
> than later platforms. Add the necessary code to make them work.
>
> Untested due to lack of hardware.
>
> v2: Warn
On Wed, Aug 13, 2014 at 01:26:40PM +0200, Daniel Vetter wrote:
> On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
> > Rather than take and release the console_lock() around a non-existent
> > DRM_I915_FBDEV, move the lock acquisation into the callee where it will
> > be compiled out by
On Wed, Aug 13, 2014 at 11:51:55AM +0100, Chris Wilson wrote:
> From: Daniel Vetter
>
> That's right, back to where it was!
>
> This effectively reverts
Hm, why?
-Daniel
>
> commit 9aa2062bb850e665b3b673b53bd90127d1215490
> Author: Daniel Vetter
> Date: Wed Aug 6 15:04:46 2014 +0200
>
>
On Wed, Aug 13, 2014 at 11:51:54AM +0100, Chris Wilson wrote:
> As we use WC updates of the PTE, we are responsible for notifying the
> hardware when to flush its TLBs. Do so after we zap all the PTEs before
> suspend (and the BIOS tries to read our GTT).
>
> Signed-off-by: Chris Wilson
Imo woul
On Tue, Aug 12, 2014 at 03:15:17PM +0100, Chris Wilson wrote:
> Rather than take and release the console_lock() around a non-existent
> DRM_I915_FBDEV, move the lock acquisation into the callee where it will
> be compiled out by the config option entirely. This includes moving the
> deferred fb_set
Ville pointed out the GCCism __builtin_types_compatible_p() that we
could use to replace our heavily casted presumption __I915__ macro that
was based on comparing struct sizes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 3 ---
drivers/gpu/drm/i915/i915_drv.h | 12
From: Daniel Vetter
That's right, back to where it was!
This effectively reverts
commit 9aa2062bb850e665b3b673b53bd90127d1215490
Author: Daniel Vetter
Date: Wed Aug 6 15:04:46 2014 +0200
drm/i915: Move i915_gem_chipset_flush to where it belongs
Signed-off-by: Chris Wilson
Cc: Daniel V
As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_g
If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE
will silently fail. This leads to an indefinite hang as WAITACTIVE never
returns causing lockups on boot. This issue becomes apparent when the
kernel driver does not install a fbdev for kernel to use for consoles
and plymouth
Make backlight class sysfs bl_power a sub-state of backlight enabled, if
a backlight power connector callback is defined. It's up to the
connector callback to handle the sub-state, typically in a way that
respects panel power sequencing.
v2: Post the version that does not oops. *facepalm*.
Signed
From: Ville Syrjälä
845/865 support different cursor sizes as well, albeit a bit differently
than later platforms. Add the necessary code to make them work.
Untested due to lack of hardware.
v2: Warn but accept invalid stride (Chris)
Rewrite the cursor size checks for other platforms (Chris
On Tue, Aug 12, 2014 at 09:51:13PM +0100, Chris Wilson wrote:
> On Tue, Aug 12, 2014 at 10:37:21PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 12, 2014 at 10:30 PM, Chris Wilson
> > wrote:
> > > On Tue, Aug 12, 2014 at 10:19:20PM +0200, Daniel Vetter wrote:
> > >> On Tue, Aug 12, 2014 at 9:33 PM,
On 8/13/2014 11:46 AM, Chris Wilson wrote:
On Wed, Aug 13, 2014 at 11:34:02AM +0530, Sharma, Shashank wrote:
I know. That is orthogonal to the tweaks I was suggesting. Also if you
feel you need to add details to your rationale, then your changelog is
incomplete.
-Chris
Thanks Chris,
Please f
On Tue, Aug 12, 2014 at 07:39:55PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 845/865 support different cursor sizes as well, albeit a bit differently
> than later platforms. Add the necessary code to make them work.
>
> Untested due to lack of hardware.
>
> Signed-of
On Tue, Aug 12, 2014 at 07:39:55PM +0300, ville.syrj...@linux.intel.com wrote:
> /* Check for which cursor types we support */
> - if (!((width == 64 && height == 64) ||
> - (width == 128 && height == 128 && !IS_GEN2(dev)) ||
> - (width == 256 && he
On Tue, Aug 12, 2014 at 07:39:55PM +0300, ville.syrj...@linux.intel.com wrote:
> /* Check for which cursor types we support */
> - if (!((width == 64 && height == 64) ||
> - (width == 128 && height == 128 && !IS_GEN2(dev)) ||
> - (width == 256 && he
58 matches
Mail list logo
