Hi all,
Last -next cycle for 3.8, besides the big item of lifting the "preliminary
hw support" tag from the Haswell code, just small bits&pieces all over:
- Leftover Haswell patches and some fixes from Paulo
- LyncPoint PCH support (for hsw)
- OOM handling improvements from Chris Wilson
- connecto
From: Paulo Zanoni
Do an early return in case we don't have DDI instead of having the
whole function inside an "if" statement.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/d
On Tue, Nov 20, 2012 at 01:32:30PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Since it should be working a little bit better now.
>
> Signed-off-by: Paulo Zanoni
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
On Fri, 23 Nov 2012 15:30:40 -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> In other words, move the check from inside the function to outside it.
Don't agree with this last step. You can make the function tidier with
an early return, but it is paramount that the high level sequence inside
From: Paulo Zanoni
In other words, move the check from inside the function to outside it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 16 +++-
drivers/gpu/drm/i915/intel_display.c | 3 ++-
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/d
From: Paulo Zanoni
And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this
From: Paulo Zanoni
This function is not called on Haswell anymore.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_dis
From: Paulo Zanoni
It's not even declared on header files.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 852012b..16d3e78 100644
--
There seem to be indeed some awkwards machines around, mostly those
without OpRegion support, where the firmware changes the display hw
state behind our backs when closing the lid.
This force-restore logic has been originally introduced in
commit c1c7af60892070e4b82ad63bbfb95ae745056de0
Author: J
Hi Dave,
Two small fixes for 3.7:
- Unbreak mbp retina, this time with a much more fine-grained approach
(since the previous "completely ignore edp vbt bpp value" regressed some
machines even after fixing a bug in our dp bw code).
- Disable cloning on sdvo. It just doesn't work (yeah took us a
> It could be CABC (Content Adaptive Backlight Control) which is a similar
> technology but is implemented fully in hardware, in the panel. How you
> can disable (and IF you can disable it) depends completely on the hardware.
>
It seems to be something at software level, because when I'm in BIOS,
On Fri, Nov 23, 2012 at 12:09:26PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This function returns the VIC of the mode. This value can be used when
> creating AVI InfoFrames.
>
> Cc: Thierry Reding
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
> Signed-off-by: Paulo Za
From: Paulo Zanoni
We currently set "0" as the VIC value of the AVI InfoFrames. According
to the specs this should be fine and work for every mode, so to my
point of view we can't consider the current behavior as a bug. The
problem is that we recently received a bug report (Kernel bug #50371)
fr
From: Paulo Zanoni
This function returns the VIC of the mode. This value can be used when
creating AVI InfoFrames.
Cc: Thierry Reding
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm_edid.c | 19 +++
include/drm/
On Fri, Nov 23, 2012 at 11:46:10AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/11/22 Thierry Reding :
> > On Wed, Nov 21, 2012 at 01:39:48PM -0200, Paulo Zanoni wrote:
[...]
> >> + * @mode: mode
> >> + *
> >> + * RETURNS:
> >> + * The VIC number, 0 in case it's not a CEA-861 mode.
> >> + */
> >> +uin
Hi
2012/11/22 Thierry Reding :
> On Wed, Nov 21, 2012 at 01:39:48PM -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> We currently set "0" as the VIC value of the AVI InfoFrames. According
>> to the specs this should be fine and work for every mode, so to my
>> point of view we can't conside
On Fri, 23 Nov 2012, Chris Wilson wrote:
> On Fri, 23 Nov 2012 14:21:58 +0200, Jani Nikula
> wrote:
>> On Fri, 23 Nov 2012, Chris Wilson wrote:
>> > Some devices may respond very slowly and only flag that the reply is
>> > pending within the first 15us response window. Be kind to such devices
>
On Fri, 23 Nov 2012 14:21:58 +0200, Jani Nikula
wrote:
> On Fri, 23 Nov 2012, Chris Wilson wrote:
> > Some devices may respond very slowly and only flag that the reply is
> > pending within the first 15us response window. Be kind to such devices
> > and wait a further 15ms, before checking for t
On Fri, 23 Nov 2012, Chris Wilson wrote:
> Some devices may respond very slowly and only flag that the reply is
> pending within the first 15us response window. Be kind to such devices
> and wait a further 15ms, before checking for the pending reply. This
> moves the existing special case delay of
Some devices may respond very slowly and only flag that the reply is
pending within the first 15us response window. Be kind to such devices
and wait a further 15ms, before checking for the pending reply. This
moves the existing special case delay of 30ms down from the detection
routine into the com
On Fri, 23 Nov 2012 13:42:38 +0200, Jani Nikula
wrote:
> On Fri, 23 Nov 2012, Chris Wilson wrote:
> > Some devices may respond very slowly and only flag that the reply is
> > pending within the first 15us response window. Be kind to such devices
> > and wait a further 15ms, before checking for t
On Fri, 23 Nov 2012, Chris Wilson wrote:
> Some devices may respond very slowly and only flag that the reply is
> pending within the first 15us response window. Be kind to such devices
> and wait a further 15ms, before checking for the pending reply. This
> moves the existing special case delay of
On Fri, Nov 23, 2012 at 10:36 AM, wrote:
> I just tested this kernel
> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/2012-10-23-raring/
> same problem as with the other kernels, without nomodeset it works, but it
> doesn't with nomodeset. Do you have any ideas how we can fi
[Adding some lists to cc]
On Fri, Nov 23, 2012 at 8:12 AM, wrote:
> Am 2012-11-22 17:03, schrieb Daniel Vetter:
>
>> On Thu, Nov 22, 2012 at 4:58 PM, wrote:
>>>
>>> I think I found a bug in the 1915 driver. I'm not sure if you're the
>>> right
>>> person to talk to, anyway here's the link to m
Some devices may respond very slowly and only flag that the reply is
pending within the first 15us response window. Be kind to such devices
and wait a further 15ms, before checking for the pending reply. This
moves the existing special case delay of 30ms down from the detection
routine into the com
25 matches
Mail list logo
