On Monday 16 November 2015 08:16 PM, Ander Conselvan De Oliveira wrote:
On Mon, 2015-11-16 at 16:33 +0200, Ander Conselvan De Oliveira wrote:
On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote:
Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_d
Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
during modes enumeration as well which will result
in multiple dpcd operations. So this patch tries
to solve both these by bringing all DPCD
On Monday 16 November 2015 08:03 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote:
Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
This patch moves probing for panel, DPCD read etc to another
function intel_dp_long_pulse, while intel_dp_detect returns
the status as connected or disconnected depending on
whether the edid is available or not.
This change will be required by further patches in the series
to avoid performing multi
On Monday 16 November 2015 07:10 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote:
This patch moves probing for panel, DPCD read etc to another
function intel_dp_long_pulse, while intel_dp_detect returns
the status as connected or disconnect
So, this is probably the 3rd time I send such a report with different
kernels and get 0 response.
Is this a write only list and no one is really seeing any of them, or is
this an unknown/known problem that no one can work on?
Thanks,
Marc
On Sat, Nov 14, 2015 at 07:25:15AM -0800, Marc MERLIN wrot
Extend the same reasoning as in the patch listed below. It's not an
error for the workaround list to be empty if no workarounds are needed.
commit 02235808b61cd9382d224b0df263193006dd9913
Author: Francisco Jerez
Date: Wed Oct 7 14:44:01 2015 +0300
drm/i915: Don't warn if th
On Mon, 2015-11-16 at 16:57 -0200, Paulo Zanoni wrote:
> 2015-11-13 22:56 GMT-02:00 Rodrigo Vivi :
> > The ultimate goal here is to remove the dependency we
> > currently have on audio driver power to get PSR working.
> >
> > With audio driver runtime PM disabled the Hardware tracking
> > believes
On Mon, Nov 16, 2015 at 8:28 PM, Imre Deak wrote:
> On ma, 2015-11-16 at 15:01 +0100, Patrik Jakobsson wrote:
>> Handle DC off as a power well where enabling the power well will prevent
>> the DMC to enter selected DC states (required around modesets and Aux
>> A). Disabling the power well will al
On ma, 2015-11-16 at 15:01 +0100, Patrik Jakobsson wrote:
> Handle DC off as a power well where enabling the power well will prevent
> the DMC to enter selected DC states (required around modesets and Aux
> A). Disabling the power well will allow DC states again. For now the
> highest DC state is D
2015-11-11 19:20 GMT-02:00 Rodrigo Vivi :
> At the beginning it was masked to allow PSR at all.
> Than it got removed later by my
> commit 09108b90f040 ("drm/i915: PSR: Remove Low Power HW tracking mask.")
> in order to trying fixing one case reported at intel-gfx mailing list
> where we were missi
On ma, 2015-11-16 at 15:01 +0100, Patrik Jakobsson wrote:
> v2: Use _unsafe (Jani)
> v3: Allow specifying specific DC-states instead of just DC6 (Imre)
>
> Signed-off-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_params.c | 6 +
2015-11-13 22:56 GMT-02:00 Rodrigo Vivi :
> The ultimate goal here is to remove the dependency we
> currently have on audio driver power to get PSR working.
>
> With audio driver runtime PM disabled the Hardware tracking
> believes graphics is fully active and prevent PSR Entry, or
> in other words
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_
On Wed, Nov 11, 2015 at 01:19:58PM -0800, Rodrigo Vivi wrote:
> According to VESA spec: "If a Source device receives and IRQ_HPD
> while in a PSR active state, and cannot identify what caused the
> IRQ_HPD to be generated, based on Sink device status registers,
> the Source device can take implemen
2015-11-12 20:46 GMT-02:00 Rodrigo Vivi :
> Commit (89251b17) intended to remove this line and let only one
> DP_PSR_EN_CFG set, but it was wrong and this call is now duplicated
> at the code.
>
> Also "& ~DP_PSR_MAIN_LINK_ACTIVE" doesn't do anything at all. It
> was like that since I introduced th
On Mon, Nov 02, 2015 at 05:18:36PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 02, 2015 at 04:14:08PM +0100, Robert Fekete wrote:
> > Adds clarification of the rotation property bits. I.e. rotation is
> > counter clockwise and that reflects are applied before any rotation.
> >
> > v2: Re
On Mon, Nov 16, 2015 at 10:02 AM, wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
Ok, so after trying it we saw that we really cannot trust on aux mutex.At
least not on all SKL/KBL
It worked in a KBL but failed on a SKL that I have here...
So without aux mutex option we still need to get sink_crc more reliable and
I see only 2 quick ways here:
- This read wake
- Return -EBUSY t
Hi Daniel,
could you please ignore patch 5 in this series and merge the 4 first
patches.
The aux mutex is really unreliable and doesn't help on all SKLs so better
to just ignore that.
Thanks,
Rodrigo.
On Thu, Nov 12, 2015 at 11:03 AM Rodrigo Vivi
wrote:
> On Thu, Nov 12, 2015 at 10:56 AM Vivi
Hi Daniel,
All 4 patches in this series are reviewed and ready to merge,
could you please merge them?
Thanks,
Rodrigo.
On Fri, Nov 13, 2015 at 10:42 AM Vivi, Rodrigo
wrote:
> On Fri, 2015-11-13 at 17:08 +0200, Ville Syrjälä wrote:
> > On Wed, Nov 11, 2015 at 11:37:06AM -0800, Rodrigo Vivi wrot
On Mon, 16 Nov 2015, Maarten Lankhorst
wrote:
> When diagnosing a unrelated bug for someone on irc, it would seem the
> hardware can
> be brought up by the BIOS with the embedded displayport using the SPLL for
> spread spectrum.
>
> Right now this is not handled well in i915, and it calculates
Hi,
On 11/11/15 17:11, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Drivers shouldn't clobber the passed in addfb ioctl parameters.
i915 was doing just that. To prevent it from happening again,
pass the struct around as const, starting all the way from
internal_framebuffer_create(
Handle DC off as a power well where enabling the power well will prevent
the DMC to enter selected DC states (required around modesets and Aux
A). Disabling the power well will allow DC states again. For now the
highest DC state is DC6 for Skylake and DC5 for Broxton but will be
configurable for Sk
On Sun, Nov 01, 2015 at 02:22:00PM +0100, Lukas Wunner wrote:
> I noticed that intel_fbdev->our_mode is unused. Introduced by
> 79e539453b34 ("DRM: i915: add mode setting support").
>
> Then I noticed that intel_fbdev->fbdev_list is unused as well.
> Introduced by 386516744ba4 ("drm/fb: fix fbdev
From: Ville Syrjälä
Properly double the hdisplay/vdisplay timings that we use as the primary
plane size with stereo doubled modes. Otherwise the modeset gets
rejected on machines where the primary plane must be fullscreen, and on
the rest only the first eye would get a visible plane.
Cc: Daniel
From: Ville Syrjälä
To aid in debugging failures, print the src,dst,clip rectangles
when drm_plane_helper_check_update() fails.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/driv
From: Ville Syrjälä
Allow the caller to specify a "prefix" string to drm_rect_debug_print()
to make it easier to see which drm_rect is being printed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 7 ---
drivers/gpu/drm/i915/intel_sprite.c | 8
include/drm/
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 7857163..d5693b7 100644
--- a/drivers/gpu/
From: Ville Syrjälä
We don't allow ARGB anymore on primary planes on most platforms,
so use XRGB instead as the format.
Signed-off-by: Ville Syrjälä
---
tests/kms_3d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_3d.c b/tests/kms_3d.c
index de923ed..4cf
From: Ville Syrjälä
Would be nice to see how many stereo modes we managed to extract from
the EDID if it doesn't match the expected 13. So use igt_assert_eq()
which prints the real count on failure.
Signed-off-by: Ville Syrjälä
---
tests/kms_3d.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
On Mon, 2015-11-16 at 16:33 +0200, Ander Conselvan De Oliveira wrote:
> On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote:
> > Current DP detection has DPCD operations split across
> > intel_dp_hpd_pulse and intel_dp_detect which contains
> > duplicates as well. Also intel_dp_detect is
CABC stands for the Content Adaptive Backlight Control.
In the normal display the backlight which we see is due to the
backlight which is being modulated by the filter, which is inturn
dependent on the image. In brief the CABC does the histogram
analysis of the image and then controls the filter an
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion h
For dual link panel scenarios there are new fileds added in the
VBT which indicate on which port the PWM cntrl and CABC ON/OFF
commands needs to be sent.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Yetunde Adebisi
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c | 13 +
dri
On Mon, Nov 16, 2015 at 03:01:07PM +0100, Patrik Jakobsson wrote:
> Handle DC off as a power well where enabling the power well will prevent
> the DMC to enter selected DC states (required around modesets and Aux
> A). Disabling the power well will allow DC states again. For now the
> highest DC st
On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote:
> Current DP detection has DPCD operations split across
> intel_dp_hpd_pulse and intel_dp_detect which contains
> duplicates as well. Also intel_dp_detect is called
> during modes enumeration as well which will result
> in multiple dpc
On Thu, Nov 12, 2015 at 11:37:11AM +0200, Jani Nikula wrote:
> On Wed, 11 Nov 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Chris requested that I try to reorder the DP AUX patches in the last
> > register type safety series [1] to form a better story. Here is the
> >
v2: Use _unsafe (Jani)
v3: Allow specifying specific DC-states instead of just DC6 (Imre)
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_params.c | 6 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 14 +++---
3 files
Handle DC off as a power well where enabling the power well will prevent
the DMC to enter selected DC states (required around modesets and Aux
A). Disabling the power well will allow DC states again. For now the
highest DC state is DC6 for Skylake and DC5 for Broxton but will be
configurable for Sk
On Mon, Nov 16, 2015 at 03:22:23PM +0200, Joonas Lahtinen wrote:
> Cc: Thomas Wood
> Cc: Chris Wilson
> Cc: Damien Lespiau
> Signed-off-by: Joonas Lahtinen
> ---
> lib/igt_core.c | 113
> ++---
> tests/Makefile.sources | 1 +
> tests/igt_c
v2: Add explanation of the fixed power well bits (Imre)
Signed-off-by: Patrik Jakobsson
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e6d88f5..0f3849f 100
From: Ville Syrjälä
Introduce intel_display_port_aux_power_domain() which simply returns
the appropriate AUX power domain for a specific port, and then replace
the intel_display_port_power_domain() with calls to the new function
in the DP code. As long as we're not actually enabling the port we d
When diagnosing a unrelated bug for someone on irc, it would seem the hardware
can
be brought up by the BIOS with the embedded displayport using the SPLL for
spread spectrum.
Right now this is not handled well in i915, and it calculates the crtc needs to
be reprogrammed on the first modeset with
On Fri, 2015-11-06 at 17:58 +0530, Shubhangi Shrivastava wrote:
> This patch moves probing for panel, DPCD read etc to another
> function intel_dp_long_pulse, while intel_dp_detect returns
> the status as connected or disconnected depending on
> whether the edid is available or not.
Why is the cha
On 14 November 2015 at 03:08, Vivek Kasireddy wrote:
> On Fri, 13 Nov 2015 15:59:21 +
> Thomas Wood wrote:
>
>> On 5 November 2015 at 01:34, Vivek Kasireddy
>> wrote:
>> > In some cases, we just need one valid (connected) output to perform
>> > a test. This macro can help in these situations
On Mon, Nov 16, 2015 at 12:55:37PM +, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 12:08:08PM +, Tvrtko Ursulin wrote:
> >
> > On 16/11/15 11:12, Chris Wilson wrote:
> > >On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
> > >>On 15/11/15 13:32, Chris Wilson wrote:
> > >>>+s
On Wed, 04 Nov 2015, Paulo Zanoni wrote:
> 2015-11-04 17:25 GMT-02:00 Imre Deak :
>> After Damien's D3 fix I started to get runtime suspend residency for the
>> first time and that revealed a breakage on the set_caching IOCTL path
>> that accesses the HW but doesn't take an RPM ref. Fix this up.
>
On Fri, 13 Nov 2015, Bob Paauwe wrote:
> On Fri, 13 Nov 2015 19:29:41 +0200
> Mika Kuoppala wrote:
>
>> When we set and later readback a frequency value through
>> sysfs interface, igt/pm_rpm assumes that we get same value back
>> if it matches hw granularity.
>>
>> On bxt we have found out that
Cc: Thomas Wood
Cc: Chris Wilson
Cc: Damien Lespiau
Signed-off-by: Joonas Lahtinen
---
lib/igt_core.c | 113 ++---
tests/Makefile.sources | 1 +
tests/igt_capture.c| 93
3 files changed, 200 ins
On Mon, Nov 16, 2015 at 01:41:54PM +0100, Maarten Lankhorst wrote:
> Op 16-11-15 om 13:35 schreef Jani Nikula:
> > On Mon, 16 Nov 2015, Maarten Lankhorst wrote:
> >> If an atomic update fails intel_crtc->atomic may have have some values left
> >> from the last atomic check. One example is atomic->
On Mon, Nov 16, 2015 at 12:50:13PM +0100, Maarten Lankhorst wrote:
> If an atomic update fails intel_crtc->atomic may have have some values left
> from the last atomic check. One example is atomic->wait_for_vblank,
> which results in spurious errors in kms_flip.
>
> Testcase: kms_flip
> Reported-b
On 16/11/15 12:55, Chris Wilson wrote:
On Mon, Nov 16, 2015 at 12:08:08PM +, Tvrtko Ursulin wrote:
On 16/11/15 11:12, Chris Wilson wrote:
On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
On 15/11/15 13:32, Chris Wilson wrote:
+static u64 local_clock_us(unsigned *cpu)
+{
+
On Mon, Nov 16, 2015 at 12:08:08PM +, Tvrtko Ursulin wrote:
>
> On 16/11/15 11:12, Chris Wilson wrote:
> >On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
> >>On 15/11/15 13:32, Chris Wilson wrote:
> >>>+static u64 local_clock_us(unsigned *cpu)
> >>>+{
> >>>+ u64 t;
> >>>+
> >>
On Mon, 09 Nov 2015, Ander Conselvan De Oliveira wrote:
> Reviewed-by: Ander Conselvan de Oliveira
Pushed to drm-intel-fixes, thanks for the review.
BR,
Jani.
>
> On Thu, 2015-11-05 at 11:49 +0200, Jani Nikula wrote:
>> Unsurprisingly macbooks have backlights, just the VBT doesn't seem to
>>
On Mon, 16 Nov 2015, Maarten Lankhorst
wrote:
> Op 13-11-15 om 18:16 schreef ville.syrj...@linux.intel.com:
>> From: Ville Syrjälä
>>
>> Let's set crtc_y to 0 instead of setting src_y twice.
>>
>> Multiple assignments in one statement is a good way to hide bugs.
>> Please don't do that.
>>
>> Cc
Op 16-11-15 om 13:35 schreef Jani Nikula:
> On Mon, 16 Nov 2015, Maarten Lankhorst wrote:
>> If an atomic update fails intel_crtc->atomic may have have some values left
>> from the last atomic check. One example is atomic->wait_for_vblank,
>> which results in spurious errors in kms_flip.
> Please
On Mon, 16 Nov 2015, Maarten Lankhorst wrote:
> If an atomic update fails intel_crtc->atomic may have have some values left
> from the last atomic check. One example is atomic->wait_for_vblank,
> which results in spurious errors in kms_flip.
Please add the "spurious errors" you see in the commit
Op 13-11-15 om 18:16 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Let's set crtc_y to 0 instead of setting src_y twice.
>
> Multiple assignments in one statement is a good way to hide bugs.
> Please don't do that.
>
> Cc: Maarten Lankhorst
> Fixes: be5651f2d581 ("drm/i915: Upd
On 16/11/15 11:12, Chris Wilson wrote:
On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
Hi,
On 15/11/15 13:32, Chris Wilson wrote:
When waiting for high frequency requests, the finite amount of time
required to set up the irq and wait upon it limits the response rate. By
busyw
Hi,
On 16 November 2015 at 11:49, Maarten Lankhorst wrote:
> If an atomic update fails intel_crtc->atomic may have have some values left
> from the last atomic check. One example is atomic->wait_for_vblank,
> which results in spurious errors in kms_flip.
>
> Testcase: kms_flip
> Reported-by: Vill
If an atomic update fails intel_crtc->atomic may have have some values left
from the last atomic check. One example is atomic->wait_for_vblank,
which results in spurious errors in kms_flip.
Testcase: kms_flip
Reported-by: Ville Syrjälä
Cc: sta...@vger.kernel.org #v4.3
Signed-off-by: Maarten Lankh
On 16/11/15 11:22, Chris Wilson wrote:
On Mon, Nov 16, 2015 at 09:54:10AM +, Tvrtko Ursulin wrote:
Hi,
On 15/11/15 13:32, Chris Wilson wrote:
The busywait in __i915_spin_request() does not respect pending signals
and so may consume the entire timeslice for the task instead of
returning t
On Mon, Nov 16, 2015 at 09:54:10AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 15/11/15 13:32, Chris Wilson wrote:
> >The busywait in __i915_spin_request() does not respect pending signals
> >and so may consume the entire timeslice for the task instead of
> >returning to userspace to handle the s
On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 15/11/15 13:32, Chris Wilson wrote:
> >When waiting for high frequency requests, the finite amount of time
> >required to set up the irq and wait upon it limits the response rate. By
> >busywaiting on the request compl
Hi,
On 15/11/15 13:32, Chris Wilson wrote:
When waiting for high frequency requests, the finite amount of time
required to set up the irq and wait upon it limits the response rate. By
busywaiting on the request completion for a short while we can service
the high frequency waits as quick as pos
Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify
a command to be run after a patch is applied. Use eval so enviroment
variables can be overriden with the option. For example:
DIM_POST_APPLY_ACTION="EDITOR=\"gedit -w\" git commit --amend"
v2: Initialize variable with defaul
Hi,
On 15/11/15 13:32, Chris Wilson wrote:
The busywait in __i915_spin_request() does not respect pending signals
and so may consume the entire timeslice for the task instead of
returning to userspace to handle the signal.
Obviously correct to break the spin, but if spending a jiffie to react
68 matches
Mail list logo
