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 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 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 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
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 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
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
[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 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
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
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
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
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
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 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 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 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
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 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
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 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 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 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 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
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
-
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
[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
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
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 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 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: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
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: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
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
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
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
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
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,
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
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
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 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 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
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 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
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 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
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
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
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
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/
> 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
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
>-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
>-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+
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
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
101 - 160 of 160 matches
Mail list logo
