Hi Rodrigo,
Which platform have you observed this issue on?
This looks really strange.
Have you checked whether we are able to enter PSR at sink side or not in such
cases?
Are we sure we are not entering PSR? I mean the PSR_STATE register says it
correctly?
Regards,
Sonika
-Original Messag
Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, November 19, 2015 2:12 AM
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
{snip}
Hi!
At redhat we've been thinking about how to s
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Thursday, November 19, 2015 6:10 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Remove PSR Perf Counter for SKL+
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Thursday, November 19, 2015 6:10 AM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo; R, Durgadoss
>Subject: [PATCH 1/3] drm/i915: Also delay first activation for SKL+
>
>In certain platforms we face strange and different issues
>when a
Why not move it inside the mutex_lock/unlock on psr.lock ?
Regards,
Sonika
-Original Message-
From: Vivi, Rodrigo
Sent: Thursday, November 19, 2015 6:10 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Jindal, Sonika
Subject: [PATCH 3/3] drm/i915: Also disable PSR on Sink when d
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, November 19, 2015 2:12 AM
>
> [cc +qemu-devel, +paolo, +gerd]
>
> On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > Hi all,
> >
> > We are pleased to announce another update of Intel GVT-g for Xen.
> >
> > Intel G
In certain platforms we face strange and different issues
when activating PSR right after a modeset so quickly.
So we delayed the first activation for the platforms
where we saw the issues with 'commit d0ac896a477d
("drm/i915: Delay first PSR activation.")'.
So, let's apply the same delay on first
It is not a bad idea to disable the PSR feature on Sink
when we are disabling on the Source.
Cc: Sonika Jindal
Suggested-by: Sonika Jindal
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/
During the review/test cycle from the previous versions
I've captured few suggestions and tips and did more 3 patches
to make it more clean and avoid any kind of confusion.
Thanks,
Rodrigo.
*** BLURB HERE ***
Rodrigo Vivi (3):
drm/i915: Also delay first activation for SKL+
drm/i915: Remove P
Whenever DMC firmware put the HW into DC State a bunch
of registers including this perf counter is reset to 0 and
never restored.
So, even with PSR active and working we could still read
"Performance_Counter: 0" what will misslead people to believe
PSR is broken.
So, it is better to remove this c
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_runtime_pm.c
between commitis:
bc5f2ab11ca6 ("drm/i915/skl: Don't call intel_prepare_ddi when encoder list
isn't yet initialized.")
1b0e3a049efe ("drm/i915/skl: disable display side power
Hi Matt,
On 23 October 2015 at 01:25, Matt Roper wrote:
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> +typedef struct {
> + uint64_t v;
> +} drm_rgba_t;
> +
Humble request - please don't add typedefs. The drm subsystem (barring
legacy core and certain drivers) is relativ
On 11/17/2015 08:37 AM, Daniel Vetter wrote:
> On Fri, Oct 30, 2015 at 04:58:41PM +, Chris Wilson wrote:
>> On Fri, Oct 30, 2015 at 05:14:21PM +0100, Daniel Vetter wrote:
>>> On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote:
When accessing through the GTT from one CPU whilst co
On Wed, Nov 18, 2015 at 01:35:54PM -0800, Bob Paauwe wrote:
> On Thu, 22 Oct 2015 17:25:34 -0700
> Matt Roper wrote:
>
> > To support CRTC background color, we need a way of communicating RGB
> > color values to the DRM. However there is often a mismatch between how
> > userspace wants to repres
On Wed, 18 Nov 2015 22:30:32 +0100,
Dave Airlie wrote:
>
> On 19 November 2015 at 02:00, Takashi Iwai wrote:
> > On Wed, 18 Nov 2015 16:38:03 +0100,
> > Ville Syrjälä wrote:
> >>
> >> On Wed, Nov 18, 2015 at 04:23:06PM +0100, Takashi Iwai wrote:
> >> > Hi,
> >> >
> >> > currently a DDI port may r
When we introduced PSR we let LPSP masked allowing us to get PSR
independently from the audio runtime PM. However in one of the
attempts to get PSR enabled by default one user reported one specific
case where he would miss screen updates if scrolling the firefox in a
Gnome environment when i915 run
On Thu, 22 Oct 2015 17:25:35 -0700
Matt Roper wrote:
> SKL and BXT allow CRTC's to be programmed with a background/canvas color
> below the programmable planes. Let's expose this as a property to allow
> userspace to program a desired value.
>
> This patch is based on earlier work by Chandra Ko
On Thu, 22 Oct 2015 17:25:34 -0700
Matt Roper wrote:
> To support CRTC background color, we need a way of communicating RGB
> color values to the DRM. However there is often a mismatch between how
> userspace wants to represent the color value vs how it must be
> programmed into the hardware; th
On 19 November 2015 at 02:00, Takashi Iwai wrote:
> On Wed, 18 Nov 2015 16:38:03 +0100,
> Ville Syrjälä wrote:
>>
>> On Wed, Nov 18, 2015 at 04:23:06PM +0100, Takashi Iwai wrote:
>> > Hi,
>> >
>> > currently a DDI port may register both DP and HDMI and it shares the
>> > same encoder. The bug we'
On Wed, 2015-11-18 at 15:34 +0100, Patrik Jakobsson wrote:
> On Wed, Nov 18, 2015 at 03:57:25PM +0200, Imre Deak wrote:
> > MISSING_CASE() would have been useful to track down a recent
> > problem in
> > intel_display_port_aux_power_domain(), so add it there and a few
> > related
> > helpers. This
Em Qua, 2015-11-18 às 11:21 -0800, Rodrigo Vivi escreveu:
> When we introduced PSR we let LPSP masked allowing us to get PSR
> independently from the audio runtime PM. However in one of the
> attempts to get PSR enabled by default one user reported one specific
> case where he would miss screen upd
Em Qua, 2015-11-18 às 11:21 -0800, Rodrigo Vivi escreveu:
> The ultimate goal here is to remove the dependency we
> currently have on audio driver power to get PSR working.
> Since with audio driver runtime PM disabled the Hardware tracking
> believes graphics is fully active and prevent PSR Entry,
When we introduced PSR we let LPSP masked allowing us to get PSR
independently from the audio runtime PM. However in one of the
attempts to get PSR enabled by default one user reported one specific
case where he would miss screen updates if scrolling the firefox in a
Gnome environment when i915 run
The ultimate goal here is to remove the dependency we
currently have on audio driver power to get PSR working.
Since with audio driver runtime PM disabled the Hardware tracking
believes graphics is fully active and prevent PSR Entry, or
in other words continuously exit PSR.
So, the idea is to tran
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 implementation-specific action.
One such action can be to exit and then re-ent
On Wed, 2015-11-18 at 15:55 +0100, Daniel Vetter wrote:
> On Mon, Nov 16, 2015 at 03:59:15PM +, Rodrigo Vivi wrote:
> > Hi Daniel,
> >
> > could you please ignore patch 5 in this series and merge the 4
> > first
> > patches.
>
> I merged an earlier instance of the first 4 patches. Has anythi
On Wed, 2015-11-18 at 11:25 +0100, Daniel Vetter wrote:
> On Tue, Nov 10, 2015 at 07:49:51PM -0200, Paulo Zanoni wrote:
> > 2015-11-10 18:31 GMT-02:00 Paulo Zanoni :
> > > 2015-11-05 16:50 GMT-02:00 Rodrigo Vivi :
> > > > According to VESA DP spec TEST_CRC_COUNT (Bits 3:0) at
> > > > TEST_SINK_MISC
Add the Kabylake PCI IDs based on the following patches.
commit d97044b661d0d56b2a2ae9b2b95ab0b359b417dc
Author: Deepak S
Date: Wed Oct 28 12:19:51 2015 -0700
drm/i915/kbl: Add Kabylake PCI ID
commit 8b10c0cf21ec84618d4bf02c73c0543500ece68d
Author: Deepak S
Date: Wed Oct 28 12:21:12 20
On Wed, 2015-11-18 at 11:12 +0100, Daniel Vetter wrote:
> On Thu, Nov 05, 2015 at 10:50:04AM -0800, Rodrigo Vivi wrote:
> > PSR is still disabled by default, but even passing
> > i915.enable_psr=1
> > at this point we weren't able to get PSR working because with
> > fastboot by default in place we
On Wed, 2015-11-18 at 11:07 +0100, Daniel Vetter wrote:
> On Thu, Nov 05, 2015 at 10:50:02AM -0800, Rodrigo Vivi wrote:
> > PSR will be enabled on every post primary update when it is
> > ready and parameter allows.
> > With this we allow test cases to continue using this parameter
> > for enabling
On Wed, 2015-11-18 at 11:04 +0100, Daniel Vetter wrote:
> On Thu, Nov 05, 2015 at 09:04:02PM +, Chris Wilson wrote:
> > On Thu, Nov 05, 2015 at 10:49:59AM -0800, Rodrigo Vivi wrote:
> > > With the lock in place we can expose ips enabled/disable on sysfs
> > > for developing, debugging and infor
On Tue, 2015-11-17 at 15:08 +0100, Daniel Vetter wrote:
> On Mon, Nov 16, 2015 at 04:05:42PM +, Rodrigo Vivi wrote:
> > 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...
> >
On ke, 2015-11-18 at 17:41 +, Thomas Wood wrote:
> On 18 November 2015 at 15:44, Daniel Vetter wrote:
> > 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
> >
> > Giv
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
>
> Intel GVT-g is a full GPU virtualization solution with mediated
> pass-through, starting from 4th generation Intel Core(TM) proc
Now that the known DMC/DC issues are fixed, let's try again and
re-enable the power well support.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_run
This was totally lost when I originally created the atomic helpers.
We probably should also check possible_clones in the helpers, but
since the legacy ones didn't do that this is for a separate patch.
Reported-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Daniel Stone
Signed-off-by: Daniel Vetter
-
On 18 November 2015 at 15:44, Daniel Vetter wrote:
> 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
>
> Given that we have all that in piglit already the commit message is a bit
> t
On Wed, Nov 18, 2015 at 04:44:20PM +0100, Daniel Vetter wrote:
> 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
>
> Given that we have all that in piglit already the commit mess
On Wed, Nov 18, 2015 at 10:33:55PM +0530, Maiti, Nabendu Bikash wrote:
>
>
> On 11/18/2015 7:00 PM, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 06:48:37PM +0530, Maiti, Nabendu Bikash wrote:
> >>
> >>
> >> On 11/18/2015 6:22 PM, Ville Syrjälä wrote:
> >>> On Wed, Nov 18, 2015 at 12:19:06PM +
On 17/11/15 17:56, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 at 05:24:01PM +, Tvrtko Ursulin wrote:
>>
>> On 17/11/15 17:08, Daniel Vetter wrote:
>>> On Tue, Nov 17, 2015 at 04:54:50PM +, Tvrtko Ursulin wrote:
On 17/11/15 16:39, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 a
On 11/18/2015 7:00 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 06:48:37PM +0530, Maiti, Nabendu Bikash wrote:
On 11/18/2015 6:22 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 12:19:06PM +, Chris Wilson wrote:
On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
Unini
On Wed, Nov 18, 2015 at 09:56:06AM +, Chris Wilson wrote:
> Limit busywaiting only to the request currently being processed by the
> GPU. If the request is not currently being processed by the GPU, there
> is a very low likelihood of it being completed within the 2 microsecond
> spin timeout an
Em Qua, 2015-11-18 às 17:38 +0100, Daniel Vetter escreveu:
> On Wed, Nov 18, 2015 at 5:20 PM, Paulo Zanoni
> wrote:
> > 2015-11-18 13:59 GMT-02:00 Daniel Vetter :
> > > On Fri, Nov 13, 2015 at 03:12:41PM -0200, Paulo Zanoni wrote:
> > > > Hello
> > > >
> > > > I've been carrying some local IGT pa
On Wed, Nov 18, 2015 at 05:38:47PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 5:20 PM, Paulo Zanoni wrote:
> > 2015-11-18 13:59 GMT-02:00 Daniel Vetter :
> >> On Fri, Nov 13, 2015 at 03:12:41PM -0200, Paulo Zanoni wrote:
> >>> Hello
> >>>
> >>> I've been carrying some local IGT patches
On Tue, Nov 17, 2015 at 10:40:51AM +, Chris Wilson wrote:
> We have varied reports of swizzling corruption on gen4 desktop, and
> confirmation that it is triggered by uneven memory banks. The
> implication is that the swizzling various between the paired channels
> and the remainder of memory o
On ke, 2015-11-18 at 17:33 +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:32:30PM +0200, Imre Deak wrote:
> > During suspend-to-idle we need to keep the DMC firmware active and DC6
> > enabled, since otherwise we won't reach deep system power states like
> > PC9/10. The lead for this came
On Wed, Nov 18, 2015 at 5:20 PM, Paulo Zanoni wrote:
> 2015-11-18 13:59 GMT-02:00 Daniel Vetter :
>> On Fri, Nov 13, 2015 at 03:12:41PM -0200, Paulo Zanoni wrote:
>>> Hello
>>>
>>> I've been carrying some local IGT patches that reduced the size of buffers
>>> created by igt_create_fb() so they wou
On Wed, Nov 18, 2015 at 05:32:30PM +0200, Imre Deak wrote:
> During suspend-to-idle we need to keep the DMC firmware active and DC6
> enabled, since otherwise we won't reach deep system power states like
> PC9/10. The lead for this came from Nivedita who noticed that the
> kernel's turbostat tool d
2015-11-18 13:59 GMT-02:00 Daniel Vetter :
> On Fri, Nov 13, 2015 at 03:12:41PM -0200, Paulo Zanoni wrote:
>> Hello
>>
>> I've been carrying some local IGT patches that reduced the size of buffers
>> created by igt_create_fb() so they would fit the stolen memory, but when I
>> decided to test the t
Hi,
On 18 November 2015 at 15:59, Andy Lutomirski wrote:
> On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
> wrote:
>> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>>> Typing:
>>>
>>> # cat /sys/devices/pci:00/:00:02.0/rom
>>>
>>> Provokes:
>>>
>>> i915 :00:02.0: I
On ke, 2015-11-18 at 16:47 +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:11:03PM +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> > > On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> >
> > Otherwise assert_rpm_wakelock_held() also includes
On Wed, 18 Nov 2015 16:38:03 +0100,
Ville Syrjälä wrote:
>
> On Wed, Nov 18, 2015 at 04:23:06PM +0100, Takashi Iwai wrote:
> > Hi,
> >
> > currently a DDI port may register both DP and HDMI and it shares the
> > same encoder. The bug we've got a report is about this encoder type:
> > namely, a m
[adding linux-pci]
On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
wrote:
> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>> Typing:
>>
>> # cat /sys/devices/pci:00/:00:02.0/rom
>>
>> Provokes:
>>
>> i915 :00:02.0: Invalid ROM contents
>
> Hmm. So there's no PCI opti
On Fri, Nov 13, 2015 at 03:12:41PM -0200, Paulo Zanoni wrote:
> Hello
>
> I've been carrying some local IGT patches that reduced the size of buffers
> created by igt_create_fb() so they would fit the stolen memory, but when I
> decided to test the tree without them, I concluded the lack of sane si
On Fri, Nov 13, 2015 at 05:11:58PM +0200, Ander Conselvan De Oliveira wrote:
> On Fri, 2015-11-13 at 15:07 +, Tvrtko Ursulin wrote:
> > On 13/11/15 14:40, Ander Conselvan De Oliveira wrote:
> > > On Fri, 2015-11-13 at 12:31 +, Tvrtko Ursulin wrote:
> > > > On 13/11/15 12:16, Chris Wilson wr
2015-11-18 8:56 GMT-02:00 Daniel Vetter :
> On Sun, Nov 08, 2015 at 12:31:36AM +, Damien Lespiau wrote:
>> Hi all,
>>
>> I've added a feature to sort the patches sent to intel-gfx into 3
>> buckets: i915, intel-gpu-tools and libdrm. This sorting relies on
>> tagging patches, using the subject p
On Wed, 2015-11-18 at 17:28 +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2015 at 05:19:30PM +0200, Ander Conselvan de Oliveira wrote:
> > Their logic is exactly the same: check if the digital port is connected
> > and then call intel_dp_detect_dpcd(). So just put that logic in their
> > only calle
On Mon, Nov 16, 2015 at 12:17:15PM +0200, Ander Conselvan de Oliveira wrote:
> 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_APP
On Fri, Nov 06, 2015 at 04:42:10PM +0200, Mika Kuoppala wrote:
> Add Skylake Intel Graphics GT4 PCI IDs.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: Damien Lespiau
--
Damien
> ---
> lib/intel_chipset.h | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/
On Wed, Nov 18, 2015 at 05:19:30PM +0200, Ander Conselvan de Oliveira wrote:
> Their logic is exactly the same: check if the digital port is connected
> and then call intel_dp_detect_dpcd(). So just put that logic in their
> only caller: intel_dp_detect().
>
> Signed-off-by: Ander Conselvan de Oli
On Wed, Nov 18, 2015 at 05:11:03PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> > On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> > > On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > > > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
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
Given that we have all that in piglit already the commit message is a bit
thin on justification. Why do we need this in igt too? How does
On Wed, Nov 18, 2015 at 04:23:06PM +0100, Takashi Iwai wrote:
> Hi,
>
> currently a DDI port may register both DP and HDMI and it shares the
> same encoder. The bug we've got a report is about this encoder type:
> namely, a machine using DDI port D for HDMI is screwed up because the
> encoder is
On Wed, Nov 18, 2015 at 04:23:06PM +0100, Takashi Iwai wrote:
> Hi,
>
> currently a DDI port may register both DP and HDMI and it shares the
> same encoder. The bug we've got a report is about this encoder type:
> namely, a machine using DDI port D for HDMI is screwed up because the
> encoder is
During suspend-to-idle we need to keep the DMC firmware active and DC6
enabled, since otherwise we won't reach deep system power states like
PC9/10. The lead for this came from Nivedita who noticed that the
kernel's turbostat tool didn't report any PC9/10 residency change
across an 'echo freeze > /
On Wed, Nov 18, 2015 at 05:19:29PM +0200, Ander Conselvan de Oliveira wrote:
> That call was moved to intel_dp_detect() in
>
> commit d410b56d74bc706f414158cb0149e2a149ee1650
> Author: Chris Wilson
> Date: Tue Sep 2 20:03:59 2014 +0100
>
> drm/i915/dp: Refactor common eDP lid detection
>
Hi,
currently a DDI port may register both DP and HDMI and it shares the
same encoder. The bug we've got a report is about this encoder type:
namely, a machine using DDI port D for HDMI is screwed up because the
encoder is switched to DP suddently. The details are found in:
http://bugzilla.ope
That call was moved to intel_dp_detect() in
commit d410b56d74bc706f414158cb0149e2a149ee1650
Author: Chris Wilson
Date: Tue Sep 2 20:03:59 2014 +0100
drm/i915/dp: Refactor common eDP lid detection
but it seem to have been resurrected in the following commit, probably
due to a wrong merge c
There was a silent conflict between
commit 0a878716265e9af9f697264dc2e858fcc060d833
Author: Daniel Vetter
Date: Thu Oct 15 14:23:01 2015 +0200
drm/i915: restore ggtt double-bind avoidance
and
commit 5bab6f60cb4d1417ad7c599166bcfec87529c1a2
Author: Chris Wilson
Date: Fri Oct 23 18:43:3
Their logic is exactly the same: check if the digital port is connected
and then call intel_dp_detect_dpcd(). So just put that logic in their
only caller: intel_dp_detect().
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp.c | 33 +
1
On ke, 2015-11-18 at 16:01 +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
On Wed, Nov 18, 2015 at 04:58:46PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> > On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > > > Atm, we assert that the device is not suspended after t
On ke, 2015-11-18 at 16:44 +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> > On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > > Atm, we assert that the device is not suspended after the point
> > > when the
> > > HW is truly put to a suspended state.
On Mon, Nov 16, 2015 at 04:00:35PM +, Rodrigo Vivi wrote:
> Hi Daniel,
>
> All 4 patches in this series are reviewed and ready to merge,
> could you please merge them?
All merged to dinq, thanks for patches&review.
-Daniel
>
> Thanks,
> Rodrigo.
>
> On Fri, Nov 13, 2015 at 10:42 AM Vivi, R
On Mon, Nov 16, 2015 at 03:59:15PM +, Rodrigo Vivi wrote:
> Hi Daniel,
>
> could you please ignore patch 5 in this series and merge the 4 first
> patches.
I merged an earlier instance of the first 4 patches. Has anything changed?
Please double-check the right versions landed in dinq.
Thanks,
On Tue, Nov 10, 2015 at 07:37:54AM -0800, Vinay Belgaumkar wrote:
> v1: These tests exercise the userptr ioctl to create shared buffers
> between CPU and GPU. They contain error and normal usage scenarios.
> They also contain a couple of stress tests which copy buffers between
> CPU and GPU. These
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, November 18, 2015 2:12 PM
> To: Gore, Tim
> Cc: Daniel Vetter; intel-gfx@lis
On ke, 2015-11-18 at 15:37 +0100, Daniel Vetter wrote:
> On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> > Atm, we assert that the device is not suspended after the point
> > when the
> > HW is truly put to a suspended state. This is fine, but we can
> > catch
> > more problems if we c
On Wed, Nov 18, 2015 at 03:57:25PM +0200, Imre Deak wrote:
> MISSING_CASE() would have been useful to track down a recent problem in
> intel_display_port_aux_power_domain(), so add it there and a few related
> helpers. This was also suggested by Ville in his review of the latest
> DMC/DC changes, w
On Mon, Nov 09, 2015 at 09:13:45PM +0200, Imre Deak wrote:
> Atm, we assert that the device is not suspended after the point when the
> HW is truly put to a suspended state. This is fine, but we can catch
> more problems if we check the RPM refcount. After that one drops to zero
> we shouldn't acce
On Wed, Nov 18, 2015 at 03:57:25PM +0200, Imre Deak wrote:
> MISSING_CASE() would have been useful to track down a recent problem in
> intel_display_port_aux_power_domain(), so add it there and a few related
> helpers. This was also suggested by Ville in his review of the latest
> DMC/DC changes, w
On Wed, Nov 18, 2015 at 03:28:38PM +0200, Imre Deak wrote:
> On ke, 2015-11-18 at 12:56 +0200, Imre Deak wrote:
> > The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> > suspend hooks as errors, but they still show up as errors in dmesg. Tune
> > them down.
> >
> > One pro
On Wed, Nov 18, 2015 at 12:15:11PM +, Gore, Tim wrote:
>
>
> Tim Gore
> Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Wednesda
On Wed, Nov 18, 2015 at 01:51:57PM +, Vlad, Marius C wrote:
>
>
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, November 18, 2015 2:59 PM
> To: Vlad, Marius C
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t
MISSING_CASE() would have been useful to track down a recent problem in
intel_display_port_aux_power_domain(), so add it there and a few related
helpers. This was also suggested by Ville in his review of the latest
DMC/DC changes, we forgot to address that.
Signed-off-by: Imre Deak
---
drivers/g
Due to the current sharing of the DDI encoder between DP and HDMI
connectors we can run the DP detection after the HDMI detection has
already set the shared encoder's type. For now solve this keeping the
current behavior and running the detection in this case too. For a proper
solution Ville sugges
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, November 18, 2015 2:59 PM
To: Vlad, Marius C
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH i-g-t] overlay/intel-gpu-overlay
On Wed, Nov 18, 2015 at 02:40:29PM +0200, marius.c.
On Wed, Nov 04, 2015 at 11:19:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Another round of stuff for the type safe register access. Some of these
> were already posted during the first round, but a lot of it is new
> (LRI stuff, cmd parser, lrc setup etc., vgpu, etc
On Wed, Nov 18, 2015 at 5:59 AM, Ville Syrjälä
wrote:
> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>> Typing:
>>
>> # cat /sys/devices/pci:00/:00:02.0/rom
>>
>> Provokes:
>>
>> i915 :00:02.0: Invalid ROM contents
>
> Hmm. So there's no PCI option ROM there. I wond
On Wed, Nov 18, 2015 at 06:48:37PM +0530, Maiti, Nabendu Bikash wrote:
>
>
>
> On 11/18/2015 6:22 PM, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 12:19:06PM +, Chris Wilson wrote:
> >> On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
> >>> Uninitialized variables (width, H
On ke, 2015-11-18 at 12:56 +0200, Imre Deak wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down.
>
> One problem caused by this was noticed by Daniel: the i915 driver
> returns EA
On Wed, Nov 18, 2015 at 06:37:17PM +0530, Maiti, Nabendu Bikash wrote:
>
>
> On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
> >> On older platforms scalers/cliping used to provide destination size an
> >> exact multiple of src size.
On 11/18/2015 6:22 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 12:19:06PM +, Chris Wilson wrote:
On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
Uninitialized variables (width, Height) in intel_check_sprite_plane
leads to compilererror in O1 level. Initialize all decl
On Wed, 18 Nov 2015, Emil Renner Berthing wrote:
> On 18 November 2015 at 13:31, Gabriel Feceoru
> wrote:
>>
>>
>> On 16.11.2015 17:53, Jani Nikula wrote:
>>>
>>> On Mon, 16 Nov 2015, Maarten Lankhorst
>>> wrote:
When diagnosing a unrelated bug for someone on irc, it would seem the
>>
On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
On older platforms scalers/cliping used to provide destination size an
exact multiple of src size.
Gen-9 and above support fractional ratio of dst/src so that source is
not manipulated to
On Wed, Nov 18, 2015 at 02:54:20PM +0200, Joonas Lahtinen wrote:
> On ke, 2015-11-18 at 12:28 +, Chris Wilson wrote:
> > On Wed, Nov 18, 2015 at 02:18:52PM +0200, Joonas Lahtinen wrote:
> > > CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE
> > > clock
> > > used for timing execu
On Wed, Nov 18, 2015 at 02:40:29PM +0200, marius.c.v...@intel.com wrote:
> From: Marius Vlad
>
> Use sigaction() instead of signal() and add SIGINT, SIGTERM to close
> the overlay window. With this change the overlay window will be
> destroyed.
>
> Signed-off-by: Marius Vlad
> ---
> overlay/ov
Hi,
Just applying this patch is enough to make gem_ringfill --r render work
on my SKL 2+2 DT GT2 system I have at Espoo. I do not need the second
patch which seems to be required for Arun's SKL.
Also working with just that patch on one SKL Y system here at Egham
office. It's some months older tha
On Wed, Nov 18, 2015 at 12:50:10PM +, Vlad, Marius C wrote:
> Just trying to figure out what we have currently. I can redo with with -1, if
> that's
> OK with you.
Already pushed.
> Out of curiosity noticed that I915_PERF_ENERGY is not available on my
> machine,
> is that related to i915
On ke, 2015-11-18 at 12:28 +, Chris Wilson wrote:
> On Wed, Nov 18, 2015 at 02:18:52PM +0200, Joonas Lahtinen wrote:
> > CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE
> > clock
> > used for timing execution of tests.
> >
> > When fetching either the starting or ending time of
1 - 100 of 160 matches
Mail list logo
