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 suppor
2013/10/25 Imre Deak :
> 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 i
2013/10/25 Imre Deak :
> 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
2013/10/25 Imre Deak :
> 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.
>
> Th
2013/10/24 Ben Widawsky :
> Production HSW does not need it. I confirmed this with Art.
>
> Signed-off-by: Ben Widawsky
I just hope these things don't start uncovering bugs :)
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ---
> drivers/gpu/drm/i915/intel_pm.c | 10 --
2013/10/24 Ben Widawsky :
> Production IVB does not need it. I confirmed this with Art.
>
> Signed-off-by: Ben Widawsky
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/driver
2013/10/24 Ben Widawsky :
> 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 removing the WA on ILK
2013/10/24 Ben Widawsky :
> 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:
http://lists.freedesktop.org/archives/intel-gfx/2013-June/0
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 wi
On 10/16/2013 05:02 PM, Daniel Vetter wrote:
> On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote:
>> BugLink: http://bugs.launchpad.net/bugs/1195483
>>
>> This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
>>
>> Signed-off-by: Joseph Salisbury
>> Cc: Daniel Vetter
>> Cc:
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 a
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.
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.
Sign
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 intel_set
This patchset replaces
"[PATCH 6/6] drm/i915: use power get/put instead of set for power on
after init" from my previous patchset. I addressed the feedback from
Daniel and Paulo (patch 1-3) and included a related cleanup (patch 4).
Imre Deak (4):
drm/i915: prepare for multiple power wells
drm/
From: Paulo Zanoni
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.
For now, runtime PM and PC8
-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 wrote:
>> Unfortunately this seems to cause others unpexected issue like ACPI
>> unstability and crash on suspend/resume.
>> I reported the issue in the
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 828c79087cec61eaf4c76bb32c222fb
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 f
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 pinpo
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;
> >
21 matches
Mail list logo
