On Thu, 2013-10-24 at 16:13 +0800, Aaron Lu wrote:
On 10/16/2013 07:33 AM, Rafael J. Wysocki wrote:
On Friday, October 11, 2013 09:27:42 PM Aaron Lu wrote:
v5:
1 Introduce video.use_native_backlight module parameter and set its
value to false by default as suggested by Rafael. For Win8
On Fri, Oct 25, 2013 at 12:27:42AM +, Liu, Chuansheng wrote:
Hello Chris and Ben,
-Original Message-
From: Ben Widawsky [mailto:b...@bwidawsk.net]
Sent: Friday, October 25, 2013 4:57 AM
To: Chris Wilson; Liu, Chuansheng; daniel.vet...@ffwll.ch; airl...@linux.ie;
On Fri, Oct 25, 2013 at 05:46:53AM +0200, Bas Wijnen wrote:
On Wed, Oct 23, 2013 at 09:28:28AM +0100, Chris Wilson wrote:
No worries, if you can run
addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215
that should give me the information needed to pinpoint the
On Thu, Oct 24, 2013 at 06:24:18PM -0200, Rodrigo Vivi wrote:
If Userspace isn't using MI_PREDICATE all slices must be enabled for
backward compatibility.
If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will
force
all slices on.
v2: fix the inverted logic for
Hi Dave,
Just the edp bpp fix from Jani plus the pipe bpp readout code from Ville
to make it work. There's a 3 pipe ivb regression fix pending from me, but
Ville's review convinced me that my first stab is broken.
Cheers, Daniel
The following changes since commit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le lun. 14 oct. 2013 11:33:29 CEST, Jani Nikula a écrit :
On Mon, 14 Oct 2013, Nicolas Devillers devillers.nico...@gmail.com wrote:
Unfortunately this seems to cause others unpexected issue like ACPI
unstability and crash on suspend/resume.
I
From: Paulo Zanoni paulo.r.zan...@intel.com
This test is based on pc8.c. It copies most of the tests from pc8.c,
but it depends on runtime PM status changes (parsed from sysfs)
instead of PC8 residency changes (parsed from the MSR registers).
There's also a test that checks for PC8 residency.
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by
In the future we'll need to support multiple power wells, so prepare for
that here. Create a new power domains struct which contains all
power domain/well specific fields. Since we'll have one lock protecting
all power wells, move power_well-lock to the new struct too.
No functional change.
The only real need for this field was in
i915_{request,release}_power_well, but there we can get at it by a
container_of magic. Also since in the future we'll have multiple power
wells each with its own power_well struct it makes sense to remove the
field from there where it'd be just redundancy.
Similarly rename the other related functions in the power domain
interface.
Higher level driver code calling these functions knows only about power
domains, not the underlying power wells which may be different on
different platforms. Also these functions really init/cleanup/resume
power domains
Jesse, hey
I work for ISG FSP/OTM boot loader team under Khadker Islam. I've recently run
into an issue that blocks FSP/OTM from supporting Tizen IVI 3.0 running Bay
Trail B3 silicon on Bayley Bay board.
Log file with the failure is attached. The failure is very consistent, happens
every time
2013/10/24 Ben Widawsky benjamin.widaw...@intel.com:
We were turning this on for ILK regardless of whether or not we use FBC.
We can save the slightest amount of power if we don't disable it when
not using FBC.
Finally someone did what I requested months ago:
2013/10/24 Ben Widawsky benjamin.widaw...@intel.com:
We were turning this on for SNB regardless of whether or not we use FBC.
We can save the slightest amount of power if we don't disable it when
not using FBC.
The workaround should be bit 9 for SNB.
First, see comment in patch 3. So you're
2013/10/24 Ben Widawsky benjamin.widaw...@intel.com:
Production IVB does not need it. I confirmed this with Art.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
1 file changed, 10
2013/10/24 Ben Widawsky benjamin.widaw...@intel.com:
Production HSW does not need it. I confirmed this with Art.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
I just hope these things don't start uncovering bugs :)
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
2013/10/25 Imre Deak imre.d...@intel.com:
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first
2013/10/25 Imre Deak imre.d...@intel.com:
The only real need for this field was in
i915_{request,release}_power_well, but there we can get at it by a
container_of magic. Also since in the future we'll have multiple power
wells each with its own power_well struct it makes sense to remove the
2013/10/25 Imre Deak imre.d...@intel.com:
Similarly rename the other related functions in the power domain
interface.
Higher level driver code calling these functions knows only about power
domains, not the underlying power wells which may be different on
different platforms. Also these
Since the Mesa merge window is closing soon, I'm finally getting back on
this. I've pushed a rebase of my old Mesa branch to my fd.o repo
http://cgit.freedesktop.org/~idr/mesa/log/?h=robustness3
I have a couple questions...
1. Has any of this landed an a kernel tree anywhere?
2. Has any
20 matches
Mail list logo
