On Thu, Sep 19, 2013 at 12:18:35PM +0200, Daniel Vetter wrote:
> Pretty harmless since actually binding such a giant thing would be
> really hard to pull off - it doesn't fit into the gtt of any shipping
> gpu right now.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gpu_erro
On Thu, Sep 12, 2013 at 05:12:18PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> There's no reason to init a DP connector if the encoder just supports
> HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
> AUX transactions to detect if there's something there. Same goes
On Fri, Sep 20, 2013 at 10:20:59AM +0100, Chris Wilson wrote:
> In
>
> commit edc3d8848dc9fe2a470316363dab8ef211d77e01
> Author: Mika Kuoppala
> Date: Thu May 23 13:55:35 2013 +0300
>
> drm/i915: avoid big kmallocs on reading error state
>
> we introduce a two-pass mechanism for splitting
On Fri, Sep 20, 2013 at 10:31:19AM +0100, Chris Wilson wrote:
> On Fri, Sep 20, 2013 at 11:30:07AM +0530, Shanth Kumar wrote:
> > During full screen video playback on Primary Display[eDP],
> > when the player UI(player controls) is superimposed on video frame,
> > the Sprite plane is disabled and r
On 09/20/2013 01:57 PM, Paulo Zanoni wrote:
2013/9/20 Todd Previte :
On 09/20/2013 06:42 AM, Jani Nikula wrote:
Reduce AUX transactions for non-eDP.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff
Hi all,
New -testing branch with cool stuff:
- clock state handling rework from Ville
- l3 parity handling fixes for hsw from Ben
- some more watermark improvements from Ville
- ban badly behaved context from Mika
- a few vlv improvements from Jesse
- VGA power domain handling from Ville
Happy te
On Fri, Sep 13, 2013 at 11:57:04PM +0100, Chris Wilson wrote:
> We never took the lock ourselves and all callers expect the struct_mutex
> to be locked upon return (be it success or error), thereore dropping the
> lock along the error paths looks to be a vestigial error from
>
> commit db1b76ca6a7
On Thu, Sep 19, 2013 at 01:58:09PM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 02:51:10PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 19, 2013 at 01:41:53PM +0100, Chris Wilson wrote:
> > > On Thu, Sep 19, 2013 at 02:35:42PM +0200, Daniel Vetter wrote:
> > > > On Thu, Sep 19, 2013 at 2:30
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Thursday, September 19, 2013 1:15 PM
>
> On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter wrote:
> > On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote:
> >> > From: Paul Zimmerman
> >> > Sent: Thursday, September 19, 2013 11:21 AM
> From: Paul Zimmerman
> Sent: Thursday, September 19, 2013 11:21 AM
>
> > From: Dave Airlie [mailto:airl...@gmail.com]
> > Sent: Wednesday, September 18, 2013 7:40 PM
> >
> > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman
> > wrote:
> > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400G
On Thu, Sep 19, 2013 at 08:57:04AM +0200, Daniel Vetter wrote:
> On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
> > No, that's wrong. ->count_objects should never ass SHRINK_STOP.
> > Indeed, it should always return a count of objects in the cache,
> > regardless of the context.
> >
> > SHR
I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video card.
With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works
fine.
Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm:
mark context support as a legacy subsystem" is the guilty commit. If I
rever
[my keyboard my be on the fritz - it's not typing what I'm thinking...]
On Thu, Sep 19, 2013 at 06:38:22AM +1000, Dave Chinner wrote:
> On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> > On 18.09.2013 11:10, Daniel Vetter wrote:
> >
> > Just now I prepared a patch changing the sam
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> On 18.09.2013 11:10, Daniel Vetter wrote:
>
> Just now I prepared a patch changing the same function in vmscan.c
> >Also, this needs to be rebased to the new shrinker api in 3.12, I
> >simply haven't rolled my trees forward yet.
>
>
On Fri, Sep 20, 2013 at 01:56:20PM -0700, Todd Previte wrote:
> On 09/20/2013 06:42 AM, Jani Nikula wrote:
> >There is no clear cut rules or specs for the retry interval, as there
> >are many factors that affect overall response time. Increase the
> >interval, and even more so on branch devices whi
On Fri, Sep 20, 2013 at 03:05:30PM +0300, Jani Nikula wrote:
> There is plenty of evidence suggesting all of the GM45 based Acer
> laptops (including their eMachines and Packard Bell brands) use inverted
> backlight PWM. Assume this is really the case, and quirk them all.
>
> The old bugs that wer
On Fri, Sep 20, 2013 at 02:20:18PM +0300, Dan Carpenter wrote:
> The lower layers of sysfs will not allow an "offset" of more than
> GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But
> it's a little easier to audit if we don't have to worry that the
> subtraction will result in
On Fri, 20 Sep 2013 16:33:47 +0100
Damien Lespiau wrote:
> On Fri, Sep 20, 2013 at 05:54:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> > > When booting with i915.fastboot=1, we always take tha code path and end
> > > up undoing what we're t
On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote:
> 2013/9/20 Daniel Vetter :
> > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote:
> >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote:
> >> > From: Paulo Zanoni
> >> >
> >> > At the end of haswell_crtc_enable w
We've had several reports of an Asus Zenbook reporting an 18bpp eDP
display, which then proceeds to not work. Using the default 24, work
just fine. Since it appears this is somewhat common in the budding world
of eDP, make a new quirk for it, and use it.
This code has been changed several times. A
On Fri, Sep 20, 2013 at 09:55:51PM +0100, Chris Wilson wrote:
> On Fri, Sep 20, 2013 at 01:44:23PM -0700, Ben Widawsky wrote:
> > On Fri, Sep 20, 2013 at 11:43:48AM +0100, Chris Wilson wrote:
> > > On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
> > > > @@ -1117,8 +1114,25 @@ i915_gem
On Fri, Sep 20, 2013 at 09:55:51PM +0100, Chris Wilson wrote:
> On Fri, Sep 20, 2013 at 01:44:23PM -0700, Ben Widawsky wrote:
> > Furthermore, the actually pinning (pin count increment) should be
> > unnecessary, but I assume you were just trying to save me some typing.
>
> Yes, the pin-count adju
2013/9/20 Todd Previte :
> On 09/20/2013 06:42 AM, Jani Nikula wrote:
>>
>> Reduce AUX transactions for non-eDP.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm
On 09/20/2013 06:42 AM, Jani Nikula wrote:
There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.
Signed-off-by: Jani Nikula
---
d
On Fri, Sep 20, 2013 at 01:44:23PM -0700, Ben Widawsky wrote:
> On Fri, Sep 20, 2013 at 11:43:48AM +0100, Chris Wilson wrote:
> > On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
> > > @@ -1117,8 +1114,25 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > > void *data,
> > >* b
On 09/20/2013 06:42 AM, Jani Nikula wrote:
Reduce AUX transactions for non-eDP.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
On Fri, Sep 20, 2013 at 11:43:48AM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
> > @@ -1117,8 +1114,25 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> > *data,
> > * batch" bit. Hence we need to pin secure batches into the global gtt.
>
On 09/20/2013 06:42 AM, Jani Nikula wrote:
Per DP1.2 spec.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9770160..6626514 1006
2013/9/20 Ville Syrjälä :
> On Thu, Sep 19, 2013 at 05:07:26PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> After the modeset rework this really shouldn't be happening, so
>> transform it into a WARN. A stuck pipe is a bad signal and is one of
>> the things that can lead to full machine
2013/9/20 Paulo Zanoni :
> 2013/9/20 Ville Syrjälä :
>> On Thu, Sep 19, 2013 at 07:24:19PM -0300, Paulo Zanoni wrote:
>>> 2013/9/16 :
>>> > From: Ville Syrjälä
>>> >
>>> > We already restore planes during the modeset operation, so no need to do
>>> > another loop over the planes and try to restor
From: Paulo Zanoni
This workaround is described in the mode set sequence documentation.
When enabling planes for the second pipe, we need to wait for 2
vblanks on the first pipe. This should solve "a flash of screen
corruption if planes are enabled on second/third pipe during the time
that big FI
From: Paulo Zanoni
We call haswell_write_eld at mode_set time, not at crtc_enable time,
so the pipes are stopped, and it doesn't really make sense to wait for
a vblank: it just delays the modeset in 50ms.
v2: - Remove the big comment
- CC Audio developers
Cc: Wang Xingchao
Cc: Mengdong Lin
2013/9/20 Ville Syrjälä :
> On Thu, Sep 19, 2013 at 07:24:19PM -0300, Paulo Zanoni wrote:
>> 2013/9/16 :
>> > From: Ville Syrjälä
>> >
>> > We already restore planes during the modeset operation, so no need to do
>> > another loop over the planes and try to restore them again.
>>
>> What about th
2013/9/20 Ville Syrjälä :
> On Thu, Sep 19, 2013 at 05:20:49PM -0300, Paulo Zanoni wrote:
>> 2013/9/19 Chris Wilson :
>> > On Thu, Sep 19, 2013 at 05:00:35PM -0300, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> Linus recently complained about screen corruption when coming out of
>> >> D
Calculation is a little different than other platforms.
v2: update to use port_clock instead
rebase on top of Ville's changes
v3: update to new port_clock semantics - don't divide by
pixel_multiplier (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=67345
Signed-off-by: Jes
On Fri, Sep 20, 2013 at 04:12:37PM +0100, Chris Wilson wrote:
> On Fri, Sep 20, 2013 at 08:05:02AM -0700, Ben Widawsky wrote:
> > Context save and restore is by definition a slow process, however it is
> > also an infrequent process. Don't try to optimize the save restore at
> > the cost of any of
Calculation is a little different than other platforms.
v2: update to use port_clock instead
rebase on top of Ville's changes
References: https://bugs.freedesktop.org/show_bug.cgi?id=67345
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 33 ++
Future generations will be changing these registers (thanks to design
for giving us an early heads up). To help abstract, create the
definition of the base of the register block, and define all registers
relative to that.
Design has promised to not change the offsets relative to the base.
CC: Rod
Future generations will be changing these registers (thanks to design
for giving us an early heads up). To help abstract, create the
definition of the base of the register block, and define all registers
relative to that.
Design has promised to not change the offsets relative to the base.
v2: Als
2013/9/20 Daniel Vetter :
> On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote:
>> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote:
>> > From: Paulo Zanoni
>> >
>> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank
>> > with a big comment, and the message s
On Thu, Sep 19, 2013 at 05:40:15PM +0100, Damien Lespiau wrote:
> v4 was:
> http://lists.freedesktop.org/archives/dri-devel/2013-September/045340.html
>
> Changes from v4:
>
> - The kernel is now in charge of adjusting the stereo mode timings.
> - There is a per-connector opt-in boolean to ex
On Fri, Sep 20, 2013 at 08:05:02AM -0700, Ben Widawsky wrote:
> Context save and restore is by definition a slow process, however it is
> also an infrequent process. Don't try to optimize the save restore at
> the cost of any of our precious cache space. Contexts begin to get quite
> large on HSW a
On Fri, Sep 20, 2013 at 05:54:55PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> > When booting with i915.fastboot=1, we always take tha code path and end
> > up undoing what we're trying to do with adjusted_mode.
> >
> > Hopefully, as the fastboot
Context save and restore is by definition a slow process, however it is
also an infrequent process. Don't try to optimize the save restore at
the cost of any of our precious cache space. Contexts begin to get quite
large on HSW and beyond.
At least for benchmarks people seem to care about, there i
On Thu, Sep 19, 2013 at 05:40:32PM +0100, Damien Lespiau wrote:
> When booting with i915.fastboot=1, we always take tha code path and end
> up undoing what we're trying to do with adjusted_mode.
>
> Hopefully, as the fastboot hardware readout code is using adjusted_mode
> as well, it should be equ
On Thu, Sep 19, 2013 at 05:40:29PM +0100, Damien Lespiau wrote:
> When using the frame packing and a single big framebuffer, some hardware
> requires that we do everything like if we were scanning out the big
> buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
> this adjustem
Reduce AUX transactions for non-eDP.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dd780bf..f2e16a1 100644
--- a/drivers/gp
We haven't read the downstream port caps for DPCD 1.0, so don't use
them.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
in
Per DP1.2 spec.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9770160..6626514 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/
There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13
I haven't received confirmation from various bug reporters whether these
actually fix any issues, but here goes anyway.
We may want to revisit patch 2/4 in a future patch, adding some
heuristic to increase delay with each retry, and maybe taking into
account i2c bit rate capabilities if reported i
On Fri, Sep 20, 2013 at 03:24:43PM +0200, Daniel Vetter wrote:
> On Fri, Sep 20, 2013 at 12:43 PM, Chris Wilson
> wrote:
> > On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
> >> @@ -1117,8 +1114,25 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> >> *data,
> >>* bat
On Fri, Sep 20, 2013 at 3:24 PM, Daniel Vetter wrote:
> On Fri, Sep 20, 2013 at 12:43 PM, Chris Wilson
> wrote:
>> On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
>>> @@ -1117,8 +1114,25 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
>>> *data,
>>>* batch" bit. Hen
On Fri, Sep 20, 2013 at 12:43 PM, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
>> @@ -1117,8 +1114,25 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
>> *data,
>>* batch" bit. Hence we need to pin secure batches into the global gtt.
>>
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows 8 doesn't use the ACPI interf
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> The backlight control and event delivery functionality provided by
> ACPI
> video module is mixed together and registered all during video device
> enumeration time. As a result, the two functionality are also removed
> together on module unload
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> Introduce a new API for modules to query if a specific type of
> backlight
> device has been registered. This is useful for some backlight device
> provider module(e.g. ACPI video) to know if a native control
> interface(e.g. the interface creat
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> v1 has the subject of "Rework ACPI video driver" and is posted here:
> http://lkml.org/lkml/2013/9/9/74
> Since the objective is really to fix Win8 backlight issues, I changed
> the subject in this version, sorry about that.
>
> This patchset h
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/auo_dsi_display.c | 253
drivers/gpu/drm/i915/intel_dsi.c |5 +
3 files changed, 259 insertions(+)
Drop intel_dsi_device and intel_dsi_dev_ops, and switch to drm_bridge
and its own drm_bridge_funcs for sub-encoder (panel driver) callbacks.
Push DSI connector creation and initialization to bridge drivers, which
is more natural than the current approach.
Leave the connector callbacks (now prefix
Not needed or used.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 674fd49..9f87238 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/g
Not used yet, but this is similar to what the crtc helpers do with
drm_bridge callbacks. The same functions are mandatory as in crtc
helpers.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/dri
Hi all, this series converts the homebrew DSI sub-encoder model to use
the recently merged drm_bridge model instead. I hear there's fixes
coming on top of current -nightly, so we may want to get those in before
this one. High level comments still welcome; those will apply regardless
of the order in
There is plenty of evidence suggesting all of the GM45 based Acer
laptops (including their eMachines and Packard Bell brands) use inverted
backlight PWM. Assume this is really the case, and quirk them all.
The old bugs that were fixed by subsystem device specific quirks:
* https://bugs.freedeskto
The lower layers of sysfs will not allow an "offset" of more than
GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But
it's a little easier to audit if we don't have to worry that the
subtraction will result in negative values.
Signed-off-by: Dan Carpenter
diff --git a/drivers/
Signed-off-by: Damien Lespiau
---
edid-decode.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index bf0c3da..d3e3118 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -829,12 +829,26 @@ cea_hdmi_block(unsigned char *x)
"The operation is in theory redundant, and in the case of Haswell where
we have multiple outputs aliasing to the same encoder, actually harmful."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Credits-to: Chris Wilson
Tested-by: Rodrigo Vivi
Signed-off-by: Rodrigo Vivi
---
src/ux
On Thu, Sep 19, 2013 at 09:06:39PM -0700, Ben Widawsky wrote:
> @@ -1117,8 +1114,25 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
>* batch" bit. Hence we need to pin secure batches into the global gtt.
>* hsw should have this fixed, but let's be paranoid and do it
On Fri, Sep 20, 2013 at 11:30:07AM +0530, Shanth Kumar wrote:
> During full screen video playback on Primary Display[eDP],
> when the player UI(player controls) is superimposed on video frame,
> the Sprite plane is disabled and rendering happens on Primary plane.
> And when the player UI fades away
In
commit edc3d8848dc9fe2a470316363dab8ef211d77e01
Author: Mika Kuoppala
Date: Thu May 23 13:55:35 2013 +0300
drm/i915: avoid big kmallocs on reading error state
we introduce a two-pass mechanism for splitting long strings being
formatted into the error-state. The first pass finds the len
On Thu, Sep 19, 2013 at 07:07:04PM -0300, Paulo Zanoni wrote:
> 2013/9/16 :
> > From: Ville Syrjälä
> >
> > The init and resume codepaths want to handel the power well in slightly
>
> s/handel/handle/
>
> Patches 1-5: Reviewed-by: Paulo Zanoni
Up to this all merged, thanks for patches&review.
On Tue, 17 Sep 2013, Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows 8 doesn't use the ACPI interface, including
On Thu, Sep 19, 2013 at 05:07:29PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We call haswell_write_eld at mode_set time, not at crtc_enable time,
> so the pipes are stopped, and it doesn't really make sense to wait for
> a vblank: it just delays the modeset in 50ms.
>
> Leave the code
On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > At the end of haswell_crtc_enable we have an intel_wait_for_vblank
> > with a big comment, and the message suggests it's a workaround for
>
On Thu, Sep 19, 2013 at 09:18:24PM +0100, Chris Wilson wrote:
> On Thu, Sep 19, 2013 at 05:00:36PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > We currently disable the ERR_INT interrupts while running the IRQ
> > handler because we fear that if we do an unclaimed register access
> >
On Thu, Sep 19, 2013 at 07:18:54PM -0300, Paulo Zanoni wrote:
> 2013/9/16 :
> > From: Ville Syrjälä
> >
> > Call intel_uncore_early_sanitize() first thing during resume to prevent
> > stale BIOS leftovers from being reported as unclaimed register access.
>
> Just out of curiosity: do you actuall
On Thu, Sep 19, 2013 at 01:26:40PM -0700, Jesse Barnes wrote:
> Otherwise the pixel_multiplier may not be set, and who knows what else
> in the future.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> dif
On Thu, Sep 12, 2013 at 01:52:36PM -0700, Jesse Barnes wrote:
> On Thu, 12 Sep 2013 22:38:41 +0200
> Daniel Vetter wrote:
>
> > On Wed, Sep 11, 2013 at 01:43:20PM -0700, Jesse Barnes wrote:
> > > Unsupported; we just do RC6.
> > >
> > > Signed-off-by: Jesse Barnes
> >
> > You only change the s
On Thu, Sep 19, 2013 at 09:33:13AM -0700, Jesse Barnes wrote:
> Disabling it isn't really an option on these platforms, but having it
> available for power comparisons is useful.
>
> Signed-off-by: Jesse Barnes
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer,
On Thu, Sep 19, 2013 at 07:24:19PM -0300, Paulo Zanoni wrote:
> 2013/9/16 :
> > From: Ville Syrjälä
> >
> > We already restore planes during the modeset operation, so no need to do
> > another loop over the planes and try to restore them again.
>
> What about the call from intel_lid_notify()? It
From: Ville Syrjälä
VGA registers live inside the power well on HSW, so in order to write
the VGA MSR register we need the power well to be on.
We really must write to the register to properly clear the
VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when
the power well is down.
On Thu, Sep 19, 2013 at 07:05:14PM -0300, Paulo Zanoni wrote:
> 2013/9/16 :
> > From: Ville Syrjälä
> >
> > VGA registers live inside the power well on HSW, so in order to write
> > the VGA MSR register we need the power well to be on.
> >
> > We really must write to the register to properly clea
On Thu, Sep 19, 2013 at 05:07:26PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> After the modeset rework this really shouldn't be happening, so
> transform it into a WARN. A stuck pipe is a bad signal and is one of
> the things that can lead to full machine hangs.
>
> Signed-off-by: Paulo
On Thu, Sep 19, 2013 at 05:20:49PM -0300, Paulo Zanoni wrote:
> 2013/9/19 Chris Wilson :
> > On Thu, Sep 19, 2013 at 05:00:35PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> Linus recently complained about screen corruption when coming out of
> >> DPMS on his Haswell machine, and he
On Thu, Sep 19, 2013 at 05:00:38PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This workaround is described in the mode set sequence documentation.
> When enabling planes for the second pipe, we need to wait for 2
> vblanks on the first pipe. This should solve "a flash of screen
> corrupt
During full screen video playback on Primary Display[eDP],
when the player UI(player controls) is superimposed on video frame,
the Sprite plane is disabled and rendering happens on Primary plane.
And when the player UI fades away, the Primary plane is disabled,
and rendering happens on Sprite plane
From: Ben Widawsky
Building on the last patch which created the new function pointers in
the VM for bind/unbind, here we actually put those new function pointers
to use.
Split out as a separate patch to aid in review. I'm fine with squashing
into the previous patch if people request it.
v2: Upd
87 matches
Mail list logo
