On Fri, Mar 08, 2013 at 10:45:53AM -0800, Jesse Barnes wrote:
> We need to set the 'allow force wake' bit to enable forcewake handling
> later on.
>
> v2: split from clock gating patch (Jani)
> check for allowwakeack (Ville)
>
> Signed-off-by: Jesse Barnes
Reviewed-by: Ville Syrjälä
> ---
On Fri, Mar 08, 2013 at 10:45:44AM -0800, Jesse Barnes wrote:
> No constant alpha yet though, that needs a new ioctl and/or property to
> get/set.
>
> v2: use drm_plane_format_cpp (Ville)
> fix up vlv_disable_plane, remove IVB bits (Ville)
> remove error path rework (Ville)
> fix compo
On Sun, Mar 17, 2013 at 10:28:55PM +0100, Daniel Vetter wrote:
> On Wed, Mar 13, 2013 at 11:21:05AM -0700, Ben Widawsky wrote:
> > More registers we can't write.
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/i915_suspend.c | 57
> > ++---
>
On Sun, Mar 17, 2013 at 10:02:44PM +0100, Daniel Vetter wrote:
> On Wed, Mar 13, 2013 at 02:06:12PM -0700, Ben Widawsky wrote:
> > v2: Move check to the top (Chris)
> > Add BUG_ON for !ivybridge, since it's all we support for now (Ben)
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/
On Sun, Mar 17, 2013 at 10:21:30PM +0100, Daniel Vetter wrote:
> On Thu, Mar 14, 2013 at 08:55:16AM -0700, Ben Widawsky wrote:
> > Interrupts, clock gating, and GMBUS are all within the, "this will hang
> > the CPU" range when we have PCH_NOP.
> >
> > There is a bit of a hack in init clock gating.
On Mon, Mar 18, 2013 at 9:59 PM, Daniel Vetter wrote:
> On Mon, Mar 18, 2013 at 8:35 PM, Stéphane Marchesin
> wrote:
>>
>>> For starters I guess we need:
>>> - drm.debug=0xe dmesg from just before that commit
>>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>>
>>> Latest ups
On Mon, Mar 18, 2013 at 8:35 PM, Stéphane Marchesin
wrote:
>
>> For starters I guess we need:
>> - drm.debug=0xe dmesg from just before that commit
>> - same for latest 3.9-rc kernels, presuming it's not broken there
>>
>> Latest upstream has a minor chance to work better I think since we've
>> im
On Mon, Mar 18, 2013 at 11:00:55AM +, Chris Wilson wrote:
> On Fri, Mar 15, 2013 at 11:02:55AM -0700, Bryce Harrington wrote:
> > And if we've had to delay booting due to not being able to set the
> > interface, fess up.
>
> I would squash this into the previous patch. Adding an infinite loop
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index bb76d90..3386b67 100644
--- a/hw/xfree86/os-sup
If other processes have had drm open previously, xserver may attempt to
open the device too early and fail, with xserver error exit "Cannot
run in framebuffer mode" or Xorg.0.log messages about "setversion 1.4
failed".
In this situation, we're receiving back -EACCES from libdrm. To address
this w
It has been suggested that the kernel may pass EAGAIN when the device is
unavailable. This hasn't been seen in practice, and examination of the
function definition in libdrm suggests EAGAIN is handled internally so
would not be seen by the xserver when making this call. So, this patch
is probably
Update: Squashes a couple commits to avoid potential hang if
git bisecting. No other changes from v1.
When starting up (on Ubuntu), X can hit an error trying to set the
version on the drm device. We believe this is a race with plymouth (or
the kernel), since adding some delay to the boot r
And if we've had to delay booting due to not being able to set the
interface, fess up.
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platfo
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 6ee219a..3ae2db1 100644
--- a/hw/xfree86/os-supp
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 69a5b8c..6ee219a 100644
--- a/hw/xfree86/
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c |1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 76f5583..69a5b8c 100644
--- a/hw/xfree86/os-support/linux/lnx_platf
On 03/14/2013 08:52 AM, Mika Kuoppala wrote:
This ioctl returns context reset status for specified context.
Signed-off-by: Mika Kuoppala
CC: i...@freedesktop.org
---
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu/drm/i915/i915_drv.c | 61 +++
dri
On 03/14/2013 08:52 AM, Mika Kuoppala wrote:
To count context losses, add struct ctx_reset_state for
both i915_hw_context and drm_i915_file_private.
drm_i915_file_private is used when there is no context.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_dma.c |4 +++-
d
On Mon, Mar 18, 2013 at 11:05:26AM +0100, Daniel Vetter wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/s
-lkml
On Sun, Mar 17, 2013 at 12:46 PM, Daniel Vetter wrote:
> On Fri, Mar 15, 2013 at 3:11 AM, Stéphane Marchesin
> wrote:
>>> drm/i915: read out the modeset hw state at load and resume time
>> This commit regresses modeset on the samsung series 5 chromebook (it
>> is basically a pineview
On Mon, 18 Mar 2013, Chris Wilson wrote:
> If we do not complete the writes to the GMBUS registers, they remain
> active for an indefinite period of time afterwards, even causing
> spurious interrupts on gm45.
>
> Signed-off-by: Chris Wilson
> Link:
> http://lkml.kernel.org/r/alpine.lnx.2.00.13
Hi Daniel,
thanks a lot for your tip. At the end it works with one of the latest
kernel (the one which is merged with the sputnik project due to a
not-working touchpad). Now my machine works perfect.
Kind regards,
Michael
Am 17.03.2013 20:38, schrieb Daniel Vetter:
On Sun, Mar 17, 2013 at
On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
> Doesn't that mean that we need these checks everywhere? Or at least a
> fixup in drm core proper?
>
> And I think we need to add trinity to our test setup eventually ;-)
Note that trinity's ioctl fuzzing is still very new (adde
On Mon, Mar 18, 2013 at 6:42 PM, Jesse Barnes wrote:
> On Mon, 18 Mar 2013 08:49:07 +0100
> Daniel Vetter wrote:
>
>> On Tue, Feb 19, 2013 at 12:11:41PM -0800, Jesse Barnes wrote:
>> > With the other bits in place, we can do this safely.
>> >
>> > v2: disable backlight on suspend to prevent prema
On Mon, 18 Mar 2013 08:49:07 +0100
Daniel Vetter wrote:
> On Tue, Feb 19, 2013 at 12:11:41PM -0800, Jesse Barnes wrote:
> > With the other bits in place, we can do this safely.
> >
> > v2: disable backlight on suspend to prevent premature enablement on resume
> >
> > Signed-off-by: Jesse Barnes
On Tue, Mar 12, 2013 at 05:53:01PM +, Chris Cummins wrote:
> This adds a html/js tool for visualizing GEN instruction source operand
> regions, similar to those used in the Programmer's Reference Manual. To
> use the tool, open the file assembler/gen_regions/gen_regions.html in
> your browser-o
On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https://bugzilla.kernel.org/show_bug.
vesa is presumed to be the generic hardware agnostic fallback framebuffer
driver for standard VGA that conflicts with the real drivers. Those
drivers already check and remove vesafb if it is previously loaded, but
in the reverse case where vesafb is loaded afterwards, the VESA driver
will proceed t
On Mon, Mar 18, 2013 at 12:51:45PM +0100, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Chris Wilson wrote:
>
> > If we do not complete the writes to the GMBUS registers, they remain
> > active for an indefinite period of time afterwards, even causing
> > spurious interrupts on gm45.
> >
> > Signed-o
If we do not complete the writes to the GMBUS registers, they remain
active for an indefinite period of time afterwards, even causing
spurious interrupts on gm45.
Signed-off-by: Chris Wilson
Link: http://lkml.kernel.org/r/alpine.lnx.2.00.1303151424140.9...@pobox.suse.cz
Cc: Shawn Starr
Cc: Jiri
On Fri, Mar 15, 2013 at 11:02:55AM -0700, Bryce Harrington wrote:
> And if we've had to delay booting due to not being able to set the
> interface, fess up.
I would squash this into the previous patch. Adding an infinite loop is
unpleasant, and therefore guaranteed to be hit on every bisection.
-C
On Mon, Mar 18, 2013 at 10:29:16AM +0100, Takashi Iwai wrote:
> At Sun, 17 Mar 2013 23:12:03 +0100,
> Daniel Vetter wrote:
> >
> > On Tue, Mar 12, 2013 at 04:32:28PM +0100, Takashi Iwai wrote:
> > > The eDP output on HP Z1 is still broken when X is started even after
> > > fixing the infinite link
Hi Greg&all,
So a recent stable backport to fix rc6 on ilk (which is disabled by
default and with dubious power savings at best, unlike rc6 on snb and
later) totally blew up all over the place:
https://bugzilla.kernel.org/show_bug.cgi?id=55291
https://lkml.org/lkml/2013/3/14/540
There might be mo
At Sun, 17 Mar 2013 23:12:03 +0100,
Daniel Vetter wrote:
>
> On Tue, Mar 12, 2013 at 04:32:28PM +0100, Takashi Iwai wrote:
> > The eDP output on HP Z1 is still broken when X is started even after
> > fixing the infinite link-train loop. The regression was introduced in
> > 3.6 kernel for cleaning
At Sun, 17 Mar 2013 22:59:22 +0100,
Daniel Vetter wrote:
>
> On Mon, Mar 11, 2013 at 06:40:16PM +0100, Takashi Iwai wrote:
> > This reverts commit 0d71068835e2610576d369d6d4cbf90e0f802a71.
> >
> > Not only that the commit introduces a bogus check (voltage_tries == 5
> > will never meet at the ins
On Mon, Mar 18, 2013 at 10:00 AM, Daniel Vetter wrote:
> - We set up the opregion stuff way before enabling interrupts. Which
> means we can probably kill all the callers of this, safe for the
> postinstall hooks. And there we only need it on the pipestate based
> machines, so maybe rename that fu
On Mon, Mar 18, 2013 at 10:00 AM, Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 9:50 AM, Jani Nikula wrote:
>> GSE interrupts are always enabled on PCH split platforms, so remove the
>> redundant enable for ASLE. Moreover, the same interrupt bit was used on all
>> PCH split platforms, even thoug
On Tue, Mar 12, 2013 at 9:50 AM, Jani Nikula wrote:
> GSE interrupts are always enabled on PCH split platforms, so remove the
> redundant enable for ASLE. Moreover, the same interrupt bit was used on all
> PCH split platforms, even though the bit definitions changed in IVB, thus
> unmasking a rese
On Tue, Feb 19, 2013 at 12:11:41PM -0800, Jesse Barnes wrote:
> With the other bits in place, we can do this safely.
>
> v2: disable backlight on suspend to prevent premature enablement on resume
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.c | 12 +---
> driv
39 matches
Mail list logo
