On Wed, Jun 28, 2017 at 05:54:56PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add support to async updates of cursors by using the new atomic
> interface for that. Basically what this commit does is do what
> intel_legacy_cursor_update() did but through atomic.
>
> v3:
> - s
On Wed, Jun 28, 2017 at 05:54:55PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thu
On Fri, Jun 30, 2017 at 09:30:50AM +0200, Daniel Vetter wrote:
> On Wed, Jun 28, 2017 at 05:54:55PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays. The cur
On Thu, Jun 29, 2017 at 01:41:16PM -0700, Manasi Navare wrote:
> Thanks for the review comments. Please find my responses below:
>
> On Thu, Jun 29, 2017 at 11:24:48PM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 28, 2017 at 05:14:31PM -0700, Manasi Navare wrote:
> > > This patch fixes the DP AUX C
On Thu, Jun 29, 2017 at 02:10:38PM -0700, Manasi Navare wrote:
> This patch fixes the DP AUX CH timeouts observed during CI IGT
> tests thus fixing the CI failures. This is done by adding a
> quirk for a particular PCI device that requires the panel power
> cycle delay (T12) to be set to 800ms whic
On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote:
> There's quite a number of machines on the market, mainly Lenovo
> ThinkPads, that make the horrible mistake in their firmware of reusing
> the PCIBAR space reserved for the SMBus for things that are completely
> unrelated to the SMBus control
On Fri, 2017-06-30 at 11:33 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/29/2017 5:38 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To support ycbcr HDMI output, we need a pipe CSC block to
> > > do the RGB->YCBCR c
On Thu, Jun 22, 2017 at 01:39:47PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:39)
> > From: Ville Syrjälä
> >
> > We have a lot of different ways of clearing the PIPESTAT registers.
> > Let's unify it all into one function. There's no magic in PIPESTAT
>
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To get a YCBCR420 output from intel platforms, we need one
> > > scaler to scale do
On Thu, Jun 15, 2017 at 09:25:08AM +0100, Chris Wilson wrote:
> Actually transferring from shmemfs to the physically contiguous set of
> pages should be wholly guarded by its obj->mm.lock!
>
> v2: Remember to free the old pages.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> ---
> drive
On Thu, 29 Jun 2017, Zhenyu Wang wrote:
> Hi, this is current gvt fixes after 4.13 stuff got pulled in
> drm-intel-next. Mostly two race fixes and several virtual display
> fixes on BDW.
Pulled to drm-intel-next-fixes, thanks.
BR,
Jani.
>
> Thanks.
> --
> The following changes since commit e274
Quoting Ville Syrjälä (2017-06-30 12:34:15)
> On Thu, Jun 22, 2017 at 01:39:47PM +0100, Chris Wilson wrote:
> > Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:39)
> > > From: Ville Syrjälä
> > >
> > > We have a lot of different ways of clearing the PIPESTAT registers.
> > > Let's unify i
On Fri, Jun 30, 2017 at 10:52:54AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/27/2017 5:25 PM, Ville Syrjälä wrote:
> > On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote:
> >> CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
> >> This block conta
On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to
On Fri, Jun 30, 2017 at 10:47:48AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/27/2017 5:22 PM, Ville Syrjälä wrote:
> > On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
> >> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> >> CEA-861-F adds two
Regards
Shashank
On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
To get a YCBCR420 outpu
On Fri, Jun 30, 2017 at 12:41:53PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2017-06-30 12:34:15)
> > On Thu, Jun 22, 2017 at 01:39:47PM +0100, Chris Wilson wrote:
> > > Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:39)
> > > > From: Ville Syrjälä
> > > >
> > > > We have a lot
Regards
Shashank
On 6/30/2017 5:16 PM, Ville Syrjälä wrote:
On Fri, Jun 30, 2017 at 10:52:54AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:25 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote:
CEA-861-F adds ycbcr capability map b
GEN9+ Interlace fetch mode doesn't support pipe/plane scaling,
This patch adds check to fail the flip if pipe/plane scaling is
requested in Interlace fetch mode.
Changes since V1:
- move check to skl_update_scaler (ville)
- mode to adjusted_mode (ville)
- combine pipe/plane scaling check
Change
Gen9+ Interlace fetch mode doesn't support few plane configurations & pipe
scaling.
- Y-tile
- 90/270 rotation
- pipe/plane scaling
- 420 planar formats
Changes since V2:
- Address review comments from ville
Mahesh Kumar (2):
drm/i915/skl+: Check for supported plane configuration in Inter
In Gen9 platform Interlaced fetch mode doesn't support following plane
configuration:
- Y/Yf tiling
- 90/270 rotation
- YUV420 hybrid planar source pixel formats.
This patch adds check to fail the flip if any of the above configuration
is requested.
Changes since V1:
- handle checks in intel_
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> This patch sets the is_hdmi2_src identifier in drm connector
> for GLK platform. GLK contains a native HDMI 2.0 controller.
> This identifier will help the EDID handling functions to save
> lot of work which is specific to HDMI 2.0 sources
Regards
Shashank
On 6/30/2017 5:28 PM, Ville Syrjälä wrote:
On Fri, Jun 30, 2017 at 10:47:48AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:22 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR4
On Wed, 2017-06-28 at 17:41 +0200, Michał Winiarski wrote:
> Testing LNCFCMOCS values on non-render engines is tricky. The values
> in
> those registers are lost on RC6, which means that if users of non-
> render
> engines want to see the proper values, they need to obtain a
> forcewake
> and execu
Regards
Shashank
On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID hand
On Fri, Jun 30, 2017 at 05:40:59PM +0530, Mahesh Kumar wrote:
> In Gen9 platform Interlaced fetch mode doesn't support following plane
> configuration:
> - Y/Yf tiling
> - 90/270 rotation
The rotation check seems to be missing from the code?
> - YUV420 hybrid planar source pixel formats.
>
>
On Thu, Jun 29, 2017 at 01:06:01PM -0700, Rodrigo Vivi wrote:
> This patch makes sense and seems the right thing to do...
>
> However removing the sanitize with I915_WRITE(*, val & ~mask);
> doesn't give me very comfortable...
>
> I've seem many power well timeouts on cnl due the lack of that san
On Thu, Jun 29, 2017 at 05:17:39PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 04:57:25PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> > > Signed-off-by: Maarten Lankhorst
> > > ---
> > > drivers/gpu/drm/drm_framebuffer.c | 1 +
> >
On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
With a real commit message (just explain why it's needed):
Reviewed-by: Daniel Vetter
Also needs
Fixes: db8f6403e88a ("drm: Convert drm_framebuffer_remove to atomic, v4.")
Cc: sta...@vger.ker
== Series Details ==
Series: Handle unsupported configuration with IF-ID (rev3)
URL : https://patchwork.freedesktop.org/series/26546/
State : failure
== Summary ==
Series 26546v3 Handle unsupported configuration with IF-ID
https://patchwork.freedesktop.org/api/1.0/series/26546/revisions/3/mbox
On Thu, Jun 29, 2017 at 04:49:44PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Pull the code to reallocate the state->connectors[] array into a
> helper function. We'll have another use for this later.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomi
On Fri, 30 Jun 2017, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 02:10:38PM -0700, Manasi Navare wrote:
>> This patch fixes the DP AUX CH timeouts observed during CI IGT
>> tests thus fixing the CI failures. This is done by adding a
>> quirk for a particular PCI device that requires the panel p
On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Introduce an rw_semaphore to protect the display commits. All normal
> commits use down_read() and hence can proceed in parallel, but GPU reset
> will use down_write() making sure no other com
On Fri, 2017-06-30 at 17:47 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > This patch sets the is_hdmi2_src identifier in drm connector
> > > for GLK platform
On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote:
> On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Introduce an rw_semaphore to protect the display commits. All normal
> > commits use down_read() and hence can proceed in
On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> > > From: Ville Syrjälä
> > >
> > > Introduce an rw_semaphore to protect the display commits. All normal
On Wed, Jun 28, 2017 at 03:28:12PM +0200, Maarten Lankhorst wrote:
> Without waiting for hw_done, previous atomic updates may dereference
> the wrong state and cause a lot of confusion. The real fix is fixing
> all obj->state to use the accessor macros, but for now wait
> indefinitely and interrupt
Hi Daniel,
Any chance on getting this patch upstream?
Thanks a lot!
-
Lionel
On 29/06/17 10:35, Lionel Landwerlin wrote:
Cc: drm-intel-fi...@lists.freedesktop.org
Fixes: d79651522e89c ("drm/i915: Enable i915 perf stream for Haswell
OA unit")
On 27/06/17 18:39, Sagar Arun Kamble wrote:
OA
On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote:
> On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> > > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> > > > From: Ville Syrjälä
> > > >
>
On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver. All drivers have changes to deal with the
> clean up. In order to allo
Oh! nevermind, please fully ignore my last email!
Fixes: 04416108ccea ("drm/i915/cnl: Add registers related to voltage
swing sequences.")
Reviewed-by: Rodrigo Vivi
On Thu, Jun 29, 2017 at 9:13 PM, Rodrigo Vivi wrote:
> the patch that introduces this error didn't land yet
>
> so, could we sq
On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
> > On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> > > Regards
> > >
> > > Shashank
> > >
> > >
> > > On 6/27/2017 5:46 PM, Ander Cons
From: Ville Syrjälä
To make sure intel_atomic_wait_for_vblanks() really waits for at least
one vblank let's switch to using drm_crtc_vblank_get_accurate().
Also toss in a FIXME that we should really be sampling the vblank
counter when we did the plane/wm update instead of resampling it
potential
From: Ville Syrjälä
Add drm_crtc_vblank_get_accurate() which is the same as
drm_crtc_vblank_get() except that it will forcefully update the
the current vblank counter/timestamp value even if the interrupt
is already enabled.
And we'll switch drm_wait_one_vblank() over to using it to make sure it
From: Ville Syrjälä
Make sure that we have an up to date vblank counter value for sending
out the completion event. On gen2/3 the vblank irq fires at frame start
rather than at start of vblank, so if we perform an update between
vblank start and frame start we would potentially sample a stale vbl
Regards
Shashank
On 6/30/2017 7:45 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
Regards
Shashank
On
== Series Details ==
Series: series starting with [1/3] drm/vblank: Introduce
drm_crtc_vblank_get_accurate()
URL : https://patchwork.freedesktop.org/series/26633/
State : success
== Summary ==
Series 26633v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26633/re
From: Ville Syrjälä
Currently the panning tests actually stop panning when they hit the
right edge fo the framebuffer. Let's make them ping-pong across the
fb to make it clear that they are indeed trying to pan around all the
time.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 5 -
1
Patch merged to dinq.
With the proper "Fixes:".
Thanks,
Rodrigo.
On Fri, 2017-06-30 at 07:15 -0700, Rodrigo Vivi wrote:
> Oh! nevermind, please fully ignore my last email!
>
> Fixes: 04416108ccea ("drm/i915/cnl: Add registers related to voltage
> swing sequences.")
> Reviewed-by: Rodrigo Vivi
On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add drm_crtc_vblank_get_accurate() which is the same as
> drm_crtc_vblank_get() except that it will forcefully update the
> the current vblank counter/timestamp value even if the interrupt
> i
On Fri, Jun 30, 2017 at 04:53:19PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> > > > Quoting ville.syrj...@linux.
series pushed to i-g-t. Thanks for the review.
On Thu, Jun 29, 2017 at 2:37 PM, Clint Taylor
wrote:
> Matches i915 support PCI device IDs
>
> Reviewed-by: Clinton Taylor
>
> -Clint
>
>
>
> On 06/29/2017 02:18 PM, Rodrigo Vivi wrote:
>>
>> By the Spec all CNL Y skus are 2+2, i.e. GT2.
>>
>> This
series pushed to libdrm. Thanks for the review.
On Thu, Jun 29, 2017 at 3:16 PM, Clint Taylor
wrote:
> Reviewed-by: Clinton Taylor
>
> -Clint
>
>
>
>
> On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:
>>
>> By the Spec all CNL Y skus are 2+2, i.e. GT2.
>>
>> This is a copy of merged i915's
>> commit
Hi,
I hit an Oops with the latest Linus tree (4.12-rc7+) on a HSW machine
like the following at boot:
BUG: unable to handle kernel NULL pointer dereference at 00b0
IP: intel_fbdev_invalidate.isra.3+0xc/0x40 [i915]
Oops: [#1] PREEMPT SMP
CPU: 2 PID: 833 Comm: X Not tainted 4.1
Quoting Daniel Vetter (2017-06-30 16:30:59)
> On Fri, Jun 30, 2017 at 04:53:19PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chri
Quoting Takashi Iwai (2017-06-30 16:38:46)
> Hi,
>
> I hit an Oops with the latest Linus tree (4.12-rc7+) on a HSW machine
> like the following at boot:
>
> BUG: unable to handle kernel NULL pointer dereference at 00b0
> IP: intel_fbdev_invalidate.isra.3+0xc/0x40 [i915]
> Oops: 000
On Fri, Jun 30, 2017 at 03:30:33PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Introduce an rw_semaphore to protect the di
This patch fixes the DP AUX CH timeouts observed during CI IGT
tests thus fixing the CI failures. This is done by adding a
quirk for a particular PCI device that requires the panel power
cycle delay (T12) to be set to 800ms which is 300msecs more than
the minimum value specified in the eDP spec. So
== Series Details ==
Series: drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
(rev3)
URL : https://patchwork.freedesktop.org/series/26518/
State : success
== Summary ==
Series 26518v3 drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH
timeouts
https://patchwork.fre
Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
if no output is connected at framebuffer setup time, we get a default
1024x768 mode that is going to be used when we first connect a monitor.
After the commit, on first connection after deferred setup, we probe
the monitor and
On Fri, 30 Jun 2017 17:40:43 +0200,
Chris Wilson wrote:
>
> Quoting Takashi Iwai (2017-06-30 16:38:46)
> > Hi,
> >
> > I hit an Oops with the latest Linus tree (4.12-rc7+) on a HSW machine
> > like the following at boot:
> >
> > BUG: unable to handle kernel NULL pointer dereference at 0
asm-generic/io.h defines few helpers which would be useful in the drivers,
such as writesb() and readsb().
Include it to the asm/io.h in architectural folder.
Acked-by: Wolfram Sang
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/io.h | 3 +++
1 file changed, 3 insertions(+)
diff --gi
The series brings a bit of order to arch/x86/include/asm/io.h by re-using
definitions in the generic header.
The series has been tested on Intel Broxton hardware in 32- and 64-bit modes.
Since v2:
- add cleanup patches in accordance to re-use what's defined in generic header
- split to few patche
Generic header defines memset_io, memcpy_fromio(). and memcpy_toio().
Reuse them from generic header and remove in x86 code.
Move the descriptions to the generic header as well.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/io.h | 45 -
incl
Despite the commit 93093d099e5d
x86: provide readq()/writeq() on 32-bit too, complete
says
...Also, map all the APIs to the strongest ordering variant. It's way
too easy to mess such details up in drivers and the difference between
"memory" and "" constrained asm()
As a preparatory to use generic IO accessor helpers we need to define
architecture dependent functions via preprocessor to let world know we
have them.
Acked-by: Wolfram Sang
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/io.h | 41 +
1 file chan
Generic header defines xlate_dev_kmem_ptr().
Reuse it from generic header and remove in x86 code.
Move a description to the generic header as well.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/io.h | 5 -
include/asm-generic/io.h | 3 +++
2 files changed, 3 insertions(+), 5 dele
== Series Details ==
Series: x86/io: Rely on asm-generic/io.h
URL : https://patchwork.freedesktop.org/series/26649/
State : success
== Summary ==
Series 26649v1 x86/io: Rely on asm-generic/io.h
https://patchwork.freedesktop.org/api/1.0/series/26649/revisions/1/mbox/
Test kms_pipe_crc_basic:
The driver reloads the GuC firmware after full gpu reset or
suspend/resume, but it never disables the GuC beforehand.
This leads us to hit the assert inside i915_ggtt_enable_guc added
by commit 04f7b24eccdf ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions").
As a work
== Series Details ==
Series: drm/i915/guc: Prevent ggtt->invalidate assert during GuC reload
URL : https://patchwork.freedesktop.org/series/26651/
State : success
== Summary ==
Series 26651v1 drm/i915/guc: Prevent ggtt->invalidate assert during GuC reload
https://patchwork.freedesktop.org/api/
From: Gustavo Padovan
Hi,
Follow up after Daniel's comments. Here I move the common async code to
drm_atomic_helper.c. i915 and msm now have to call the
drm_atomic_helper_async_check() themselves.
Please review! Thanks.
Gustavo
Gustavo Padovan (6):
drm/atomic: initial support for asynchron
From: Gustavo Padovan
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
v4:
- call drm_atomic_helper_async_check() from the check hook
v3:
- set corr
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
Tested-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++--
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 1 insertion(+), 12
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
v5: call drm_atomic_helper_async_check() from the check hook
v4: add missing atomic asyn
From: Gustavo Padovan
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)
v4: add drm_atomic_helper_async() commi
On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau wrote:
> Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> if no output is connected at framebuffer setup time, we get a default
> 1024x768 mode that is going to be used when we first connect a monitor.
> After the commit, on fir
On Fri, Jun 30, 2017 at 5:26 PM, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> Add drm_crtc_vblank_get_accurate() which is the same as
>> drm_crtc_vblank_get() except that it will forcefully update the
>> the cur
On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
wrote:
>> And if the GEM folks insist the old behavior can't be restored, then we
>> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere
>> in i915_sw_fence. Force-completing all render requests atomic updates
>> depend upon is i
== Series Details ==
Series: drm: add asynchrounous plane update (rev5)
URL : https://patchwork.freedesktop.org/series/25814/
State : failure
== Summary ==
Series 25814v5 drm: add asynchrounous plane update
https://patchwork.freedesktop.org/api/1.0/series/25814/revisions/5/mbox/
Test gem_exec
On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> wrote:
> >> And if the GEM folks insist the old behavior can't be restored, then we
> >> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere
> >> in i915_sw_fence
Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate. Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow t
These patches, along with an upcoming series for IGT, enable our
PSR IGT tests to run reliably once again on HSW, BDW, and SKL.
The first change enables us to run the PSR tests on some RVP platforms
whose panels have too slow of a setup time when running in their
preferred mode. The second fixes a
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were
5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP lin
On SKL+ there is a bit in SRD_CTL that software is not supposed to
modify, but we currently clobber that bit when we enable PSR. In
order to preserve the value of that bit, go ahead and read SRD_CTL and
do a field-wise setting of the various bits that we need to initialize
before writing the regis
According to the eDP spec, when the count field in TEST_SINK_MISC
increments then the six bytes of sink CRC information in the DPCD
should be valid. Unfortunately, this doesn't seem to be the case
on some panels, and as a result we get some incorrect and inconsistent
values from the sink CRC DPCD
Make assert_or_manual() a macro so that we get accurate line number
information when this assertion fails.
v2: Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_psr_sink_crc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/km
These patches, along with the kernel series at
https://patchwork.freedesktop.org/series/24049/ allow our PSR
IGT tests to run more predictably on HSW, BDW, and SKL. These
patches depend on the kernel series in order to run properly. On
the systems I have available the following sets of tests run
v2: * Minor functional tweaks and bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_frontbuffer_tracking.c | 119 +++
1 file changed, 19 insertions(+), 100 deletions(-)
diff --git a/tests/kms_frontbuffer_trackin
v2: * Minor functional tweaks and bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_fbcon_fbt.c | 54 +--
1 file changed, 18 insertions(+), 36 deletions(-)
diff --git a/tests/kms_fbcon_fbt.c b/tests/
Factor out some code that was replicated in three test utilities into
some new IGT library functions so that we are checking PSR status in
a consistent fashion across all of our PSR tests.
v2: * Add sink CRC helper function
* Misc. bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Si
The multidraw subtest was not taking whether or not the GEM buffer had
ever been in write-combining mode when checking for PSR state, so fix
that.
Signed-off-by: Jim Bride
---
tests/kms_frontbuffer_tracking.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/kms_frontbu
v2: * Minor functional tweaks & bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_psr_sink_crc.c | 134 +++
1 file changed, 66 insertions(+), 68 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests
== Series Details ==
Series: Kernel PSR Fix-ups (rev2)
URL : https://patchwork.freedesktop.org/series/24049/
State : failure
== Summary ==
Series 24049v2 Kernel PSR Fix-ups
https://patchwork.freedesktop.org/api/1.0/series/24049/revisions/2/mbox/
Test core_auth:
Subgroup basic-auth:
Reviewed-by: Rodrigo Vivi
On Fri, Jun 30, 2017 at 12:08 PM, Jim Bride wrote:
> On SKL+ there is a bit in SRD_CTL that software is not supposed to
> modify, but we currently clobber that bit when we enable PSR. In
> order to preserve the value of that bit, go ahead and read SRD_CTL and
> do a fi
my only bikeshed here is the subject since this is not the psr feature itself...
anyways, I don't mind much since sink crc is only used to test psr...
Also yes, based on what I saw on sink crc behaviour I know that this
doesn't fix things for real because I remember reading hundreds or
thousand i
oh! at least one good reason why igt is full of macros! :(
Reviewed-by: Rodrigo Vivi
On Fri, Jun 30, 2017 at 12:12 PM, Jim Bride wrote:
> Make assert_or_manual() a macro so that we get accurate line number
> information when this assertion fails.
>
> v2: Rebase
>
> Cc: Rodrigo Vivi
> Cc: Paul
On Fri, Jun 30, 2017 at 12:12 PM, Jim Bride wrote:
> Factor out some code that was replicated in three test utilities into
> some new IGT library functions so that we are checking PSR status in
> a consistent fashion across all of our PSR tests.
>
> v2: * Add sink CRC helper function
> * Misc.
I believe it would be better to create the psr lib with only one
function at time and on every patch that adds the new function already
removes that from here and from frontbuffer tracking test as well...
easier to review and to make sure that we are not changing the behaviour.
also...
On Fri, J
1 - 100 of 113 matches
Mail list logo
