Op 2021-02-10 om 04:11 schreef Stephen Rothwell:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/v3d/v3d_sched.c:263:1: error: return type is an incomplete
> type
> 263 | v3d_gpu_reset_for_timeout(struct v3d_de
rk. We need explicit annotations.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> v3: Kerneldoc.
>
> v4: Some spelling fixes from Mika
>
> v5: Amend commit message to explain in det
..@vger.kernel.org
>> Cc: amd-...@lists.freedesktop.org
>> Cc: intel-...@lists.freedesktop.org
>> Cc: Chris Wilson
>> Cc: Maarten Lankhorst
>> Cc: Christian König
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/dma-buf/dma-fence.c | 3 +++
>&g
nt. Therefore these annotations
> cannot be sprinkled over the code entirely mindless to avoid false
> positives.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> Cc: linux-me...@vger.kernel.org
Op 25-09-2019 om 10:32 schreef sandy.huang:
>
> 在 2019/9/25 下午4:17, Maarten Lankhorst 写道:
>> Op 25-09-2019 om 10:06 schreef Sandy Huang:
>>> These new format is supported by some rockchip socs:
>>>
>>> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
&g
FBCON_LOGO_CANSHOW = -1, /* the logo can be shown */
> FBCON_LOGO_DRAW = -2, /* draw the logo to a console */
I did a casual review, so for whole series with the small nitpicks I had, and
any feedback by others, kbuild and the arm mess being fixed up:
Reviewed-by:
^Typo in subject.
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> For some reasons the pm_vt_switch_unregister call was missing from the
> direct unregister_framebuffer path. Fix this.
>
> v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
> called already. I botched that in v1
Op 13-01-2019 om 21:23 schreef Rodrigo Siqueira:
> Hi,
>
> I resend this patch for CI via “intel-...@lists.freedesktop.org” as
> Daniel suggested, and I got a feedback that reported an issue as can be
> seen here:
>
>https://patchwork.freedesktop.org/series/51147/
>
> After a careful analysis o
ially since you selected EXPERT.
Oh well, apply this with git am --scissors?
-8<
When configuring the kernel without PCI we can still enable VGA switcheroo,
which is not possible because VGA_ARB cannot be selected.
Remove this by depending on PCI for !S390.
Reported-by: Paul Menzel
Op 30-12-2018 om 07:21 schreef syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 903b77c63167 Merge tag 'linux-kselftest-4.21-rc1' of git:/..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12d0f55340
> kernel config: https://s
Op 27-06-18 om 23:25 schreef Enric Balletbo i Serra:
> From: Gustavo Padovan
>
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and update for the same plane
Op 18-05-18 om 17:17 schreef Liviu Dudau:
> Due to the fact that writeback connectors behave in a special way
> in DRM (they always report being disconnected) we might confuse some
> userspace. Add a client capability for writeback connectors that will
> filter them out for clients that don't under
Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li
> ---
> drivers/gp
Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li
> ---
> drivers/gp
Op 08-05-18 om 12:34 schreef Lowry Li:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Add a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related su
Op 19-04-18 om 13:05 schreef Fengguang Wu:
> Hi Maarten,
>
>> What extra dmesg output do you get when you boot with drm.debug=0x1f ?
>
> Attached is the dmesg with drm.debug=0x1f.
>
> Thanks,
> Fengguang
Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768:
kern :debug : [
Hey,
Op 19-04-18 om 04:52 schreef Fengguang Wu:
> Hello,
>
> FYI this happens in mainline kernel and at least dates back to v4.13 .
>
> [ 75.245840]
> [ 75.247783] /opt/deb/gawk_1%3a4.1.4+dfsg-1_amd64.deb
> [ 75.247785]
> [ 75.248145] [ cut here ]
> [ 75.248446] C
Op 04-04-18 om 14:26 schreef Daniel Vetter:
> On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark wrote:
>> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst
>> wrote:
>>> Op 04-04-18 om 13:37 schreef Rob Clark:
>>>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
>
Op 04-04-18 om 14:05 schreef Rob Clark:
> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst
> wrote:
>> Op 04-04-18 om 13:37 schreef Rob Clark:
>>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
>>> wrote:
>>>> Op 04-04-18 om 12:21 schreef Daniel V
Op 04-04-18 om 13:37 schreef Rob Clark:
> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst
> wrote:
>> Op 04-04-18 om 12:21 schreef Daniel Vetter:
>>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>>>> On Tue, Apr 03, 2018 at 06:42:23PM -04
Op 04-04-18 om 12:21 schreef Daniel Vetter:
> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
>> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
>>> Add an atomic helper to implement dirtyfb support. This is needed to
>>> support DSI command-mode panels with x11 userspace
Op 15-03-18 om 14:30 schreef Ville Syrjälä:
> On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
>> drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
>> arguments that can be removed by creating separate functins.
>>
>> Create specific functions for these calls to reduc
Op 13-03-18 om 23:02 schreef Joe Perches:
> drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> arguments that can be removed by creating separate functins.
>
> Create specific functions for these calls to reduce x86/64 defconfig
> size by ~20k.
>
> Modify the existing macros to
Hey,
Op 21-02-18 om 15:37 schreef Rob Clark:
> Follow the same pattern of locking as with other state objects. This
> avoids boilerplate in the driver.
I'm afraid this will prohibit any uses of this on i915, since it still uses
legacy lock_all().
Oh well, afaict nothing in i915 uses private obj
Op 21-02-18 om 00:56 schreef Daniel Vetter:
> On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:
>> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:
>>> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
Op 18-12-17 om 08:08 schreef Daniel Vetter:
> Hm, the bisect looks funny. Only way I can explain that is that my
> patch fixed a pre-existing lockdep splat, and uncovered the issue in
> the ww-mutex self tests. That one is uncovered by the new
> cross-release lockdep checks in 4.15.
>
> Anyway I th
Op 14-12-17 om 16:54 schreef Rafael J. Wysocki:
> On Thursday, December 14, 2017 4:52:22 PM CET Thomas Gleixner wrote:
>> On Thu, 14 Dec 2017, Rafael J. Wysocki wrote:
>>> The problem here is that pci_pm_thaw_noirq() calls pci_restore_state() which
>>> in fact requires the device to be in D0, so th
Op 11-12-17 om 12:06 schreef Thomas Gleixner:
> On Mon, 11 Dec 2017, Thomas Gleixner wrote:
>
>> On Mon, 11 Dec 2017, Daniel Vetter wrote:
>>> Anything else we can do to move this? I just had to resolve a small
>>> conflict when moving forward to -rc3. Carrying a revert for the entire
>>> apic pull
Op 06-12-17 om 15:15 schreef Thomas Gleixner:
> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>> Op 06-12-17 om 13:46 schreef Thomas Gleixner:
>>> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>>>> Op 06-12-17 om 13:15 schreef Michal Hocko:
>>>>> &
Op 06-12-17 om 13:46 schreef Thomas Gleixner:
> On Wed, 6 Dec 2017, Maarten Lankhorst wrote:
>> Op 06-12-17 om 13:15 schreef Michal Hocko:
>>> "No irq handler" part looks a bit scary (maybe related to lost affinity
>>> messages?) but the following messages look
Op 06-12-17 om 13:15 schreef Michal Hocko:
> On Mon 04-12-17 14:36:20, Linus Torvalds wrote:
>> On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki wrote:
>>> So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the
>>> systems I have tested, so it is probably safe to assume it to be
>>>
Hey,
Op 30-11-17 om 23:47 schreef Thomas Gleixner:
> On Thu, 30 Nov 2017, Maarten Lankhorst wrote:
>> Op 30-11-17 om 10:18 schreef Thomas Gleixner:
>> # cat /sys/kernel/debug/irq/irqs/28
>> handler: handle_edge_irq
>> device: :00:02.0
>> status: 0
Op 30-11-17 om 14:15 schreef Fengguang Wu:
> Hello,
>
> This happens in mainline kernel v4.15-rc1 on LENOVO IdeaPad U410.
> It at least dates back to v4.11 .
>
> It occurs in 72 out of 72 boots.
Can I get a boot log with drm.debug=0x1f? I don't have enough information to
see what's going on. :)
~
Op 30-11-17 om 10:18 schreef Thomas Gleixner:
> Maarten,
>
> On Wed, 29 Nov 2017, Maarten Lankhorst wrote:
>> The changes to interrupts bring down our CI during hibernate, see:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=103712
>>
>> I created a bu
Op 28-11-17 om 16:13 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Daniel Vetter wrote:
>
>> On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
>>> Some drivers like i915 start with crtc's enabled, but with deferred
>>> fbcon setup they were
Hey,
Op 13-11-17 om 13:05 schreef Thomas Gleixner:
> Linus,
>
> please pull the latest x86-apic-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-apic-for-linus
>
> This update provides a major overhaul of the APIC initialization and vector
> allocati
rwise once during initial fbdev setup.
Signed-off-by: Maarten Lankhorst
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
Cc: # v4.14+
Reported-by: Thomas Voegtle
---
drivers/gpu/drm/drm_fb_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/dr
Op 28-11-17 om 10:30 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Maarten Lankhorst wrote:
>
>> Op 27-11-17 om 19:09 schreef Thomas Voegtle:
>>>
>>> Hello,
>>>
>>> with v4.14 I recognized that my file server (headless haswell system)
>>&g
Op 27-11-17 om 19:09 schreef Thomas Voegtle:
>
> Hello,
>
> with v4.14 I recognized that my file server (headless haswell system)
> doesn't enter packages pc3 anymore and only enters pc2 according to
> powertop.
> In v4.13 the system used pc2 and pc3.
>
> So I bisected that down to:
>
> ca91a2758fc
mic_helper.c
> @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev,
> drm_modeset_backoff(&ctx);
> }
>
> + drm_atomic_state_put(state);
> drm_modeset_drop_locks(&ctx);
> drm_modeset_acquire_fini(&ctx);
>
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.
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
r.pl | wc -l
39
~/linux$ git show | scripts/get_maintainer.pl | wc -l
37
~/linux$ git show | scripts/get_maintainer.pl | wc -l
38
Any idea why this happens?
The commit I used for testing is pasted below.
Kind regards,
Maarten Lankhorst
--8<--
commit 94273dc6f6e3ab77948dddc6e0572ca7ea890520
Aut
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.
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
Op 30-06-17 om 15:56 schreef Daniel Vetter:
> 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 dri
Op 30-06-17 om 15:56 schreef Daniel Vetter:
> 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 dri
: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
drivers/gpu/drm/drm_atomic_helper.c | 18
tel-...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c |
Op 27-06-17 om 17:01 schreef Daniel Vetter:
> On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote:
>> Op 27-06-17 om 09:37 schreef Daniel Vetter:
>>> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>>>> On 2017-06-20 01:57 PM, Andrey G
Op 27-06-17 om 09:37 schreef Daniel Vetter:
> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
>>> Problem : While running IGT kms_atomic_transition test suite i encountered
>>> a hang in drmHandleEvent immediately following an ato
Op 09-06-17 om 23:30 schreef Andrey Grodzovsky:
> Problem:
> While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immidietly follwoing an atomic_commit.
> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the
;)
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dc69175255b1..3999dffcd9ef 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,7 +24,6 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_
Op 05-06-17 om 12:08 schreef Archit Taneja:
>
>
> On 06/03/2017 01:55 AM, Eric Anholt wrote:
>> Many DRM drivers have common code to make a stub connector
>> implementation that wraps a drm_panel. By wrapping the panel in a DRM
>> bridge, all of the connector code (including calls during encoder
>
Op 16-12-16 om 14:17 schreef Nicolai Hähnle:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
>> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>>
>>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state,
>>> unsigned int subclass,
>>> struct mutex_waiter wait
Op 30-11-16 om 01:35 schreef Chris Wilson:
> Signed-off-by: Chris Wilson
> Cc: Peter Zijlstra
> Cc: Maarten Lankhorst
> Cc: Nicolai Hähnle
> ---
> kernel/locking/test-ww_mutex.c | 134
> +
> 1 file changed, 134 insertions(+)
Op 28-11-16 om 13:20 schreef Nicolai Hähnle:
> From: Nicolai Hähnle
>
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Nicolai Hähnle
> ---
> driv
w'. So thread #0 gets stuck waiting for ww' to be released.
>>>>
>>>> This patch fixes the deadlock by waking up all waiters in the slow path
>>>> of ww_mutex_unlock.
>>>>
>>>> We have an internal test case for amdgpu which con
Op 17-10-16 om 08:05 schreef Daniel Vetter:
> On Thu, Oct 13, 2016 at 05:04:03PM -0300, Paulo Zanoni wrote:
>> Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu:
>>> Op 08-10-16 om 02:11 schreef Lyude:
>>>> Now that we've make skl_wm_levels make a li
r values and just use a single
> helper, skl_write_wm_level(), to convert and write the new watermarks on
> the fly.
>
> Changes since v1:
> - Fixup skl_write_wm_level()
> - Fixup skl_wm_level_from_reg_val()
> - Don't forget to copy *active to intel_crtc->wm.active.skl
>
Op 05-10-16 om 17:33 schreef Lyude:
> While it (mostly) works, the code for handling watermarks on Skylake has been
> kind of ugly for a while. As well a lot of it isn't that friendly to atomic
> transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
> full cleanup, it's a g
el, something we take advantage of in
>> the next commit to cut down on all of the copy paste code in here.
> I'd like to start my review pointing that I really like this patch. I
> agree the current form is annoying.
>
> See below for some details.
>
>
>> Signed-off-b
wn, we need to add them ourselves.
>
>Signed-off-by: Lyude
>Reviewed-by: Matt Roper
>Cc: sta...@vger.kernel.org
>Cc: Ville Syrjälä
>Cc: Daniel Vetter
>Cc: Radhakrishna Sripada
>Cc: Hans de Goede
>Signed-off-by: Maarten Lankhorst
>
top immediately when
> userspace wants to quit.
>
> Also adds the necessary error checking for fence_wait().
>
> v2: Comment by Daniel Vetter
> - Add error checking for fence_wait()
>
> v3: Rebase on top of new atomic noblocking support
>
> v4: Comment by Maarten
Op 31-08-16 om 21:07 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> There is now a new property called FENCE_FD attached to every plane
> state that receives the sync_file fd from userspace via the atomic commit
> IOCTL.
>
> The fd is then translated to a fence (that may be a fence_collectio
Op 22-08-16 om 18:50 schreef Lyude:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them
Op 17-08-16 om 21:55 schreef Lyude:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them
Op 18-08-16 om 16:05 schreef Lyude Paul:
> On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 17-08-16 om 21:55 schreef Lyude:
>>> Since the watermark calculations for Skylake are still broken, we're apt
>>> to hitti
top immediately when
> userspace wants to quit.
>
> Also adds the necessary error checking for fence_wait().
>
> v2: Comment by Daniel Vetter
> - Add error checking for fence_wait()
>
> v3: Rebase on top of new atomic noblocking support
>
> v4: Comment by Maarten
sable() from pre/post-plane updates
> Changes since v3:
> - Use time_before() to compare timeout to jiffies
> Changes since v2:
> - Really apply minor style nitpicks to patch this time
> Changes since v1:
> - Added comments about this probably being one of the requirements to
Op 11-08-16 om 20:39 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> If userspace is running an synchronously atomic commit and interrupts the
> atomic operation during fence_wait() it will hang until the timer expires,
> so here we change the wait to be interruptible so it stop immediately w
Hey,
Op 10-08-16 om 16:28 schreef Lyude:
> Now that we can hook into update_crtcs and control the order in which we
> update CRTCs at each modeset, we can finish the final step of fixing
> Skylake's watermark handling by performing DDB updates at the same time
> as plane updates and watermark upda
:
> - Really apply minor style nitpicks to patch this time
> Changes since v1:
> - Added comments about this probably being one of the requirements to
>fixing Skylake's watermark issues
> - Minor style nitpicks from Matt Roper
> - Disable these functions on Broxton, since it
Hey,
Op 08-08-16 om 23:03 schreef Lyude:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however,
Op 08-08-16 om 21:59 schreef Gustavo Padovan:
> 2016-08-08 Maarten Lankhorst :
>
>> Op 20-06-16 om 17:53 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> When creating a sync_pt the name received wasn't used anywhere.
>>> Now we add
Op 20-06-16 om 17:53 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> When creating a sync_pt the name received wasn't used anywhere.
> Now we add it to the sync info debug output to make it easier to indetify
> the userspace name of that sync pt.
>
> Signed-off-by: Gustavo Padovan
> ---
> d
use this later
>
> Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic
> 'check' (v2)")
> Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
> Signed-off-by: Matt Roper
> Signed-off-by: Lyude
> Revie
ev_priv) &&
> + hweight32(intel_state->active_crtcs) > 1)
> + skl_disable_sagv(dev_priv);
> intel_modeset_verify_disabled(dev);
> }
>
> @@ -13765,6 +13773,9 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
> intel_modeset_verify_crtc(crtc, old_crtc_state, crtc->state);
> }
>
> + if (hweight32(intel_state->active_crtcs) <= 1)
> + skl_enable_sagv(dev_priv);
Should be guarded with a if (intel_state->modeset &&
Looks ok otherwise. :-)
With that fixed:
Reviewed-by: Maarten Lankhorst
Op 01-08-16 om 13:48 schreef Ville Syrjälä:
> On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote:
>> Op 29-07-16 om 22:33 schreef Matt Roper:
>>> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
>>>> On Thu, Jul 28, 2016 at 05:0
Op 29-07-16 om 22:33 schreef Matt Roper:
> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
>> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
>>> This is completely untested (and probably horribly broken/buggy), but
>>> here's a quick mockup of the general approach I was
Op 26-07-16 om 16:50 schreef Lyude:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however, is th
use this later
>
> Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic
> 'check' (v2)")
> Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
> Signed-off-by: Matt Roper
> Signed-off-by: Lyude
> Revie
Op 21-07-16 om 21:23 schreef Lyude:
> From: Matt Roper
>
> When we write watermark values to the hardware, those values are stored
> in dev_priv->wm.skl_hw. However with recent watermark changes, the
> results structure we're copying from only contains valid watermark and
> DDB values for the pip
Op 21-07-16 om 21:23 schreef Lyude:
> Manual pipe flushes are only necessary in order to make sure that we prevent
> pipes with changed ddb allocations from overlapping from one another at
> any point in time. Additionally, forcing us to wait for the next vblank
> every time we have to update the w
Op 11-07-16 om 22:27 schreef Gustavo Padovan:
> 2016-07-10 Maarten Lankhorst :
>
>> Op 08-07-16 om 17:44 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> Signalling doesn't need to be enabled at sync_file creation, it is only
>>> requ
Op 08-07-16 om 17:44 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Signalling doesn't need to be enabled at sync_file creation, it is only
> required if userspace waiting the fence to signal through poll().
>
> Thus we delay fence_add_callback() until poll is called. It only adds the
> call
Op 30-05-16 om 12:45 schreef Chris Wilson:
> On Mon, May 30, 2016 at 12:27:46PM +0200, Peter Zijlstra wrote:
>> On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote:
>>> Patch not applied, SCHED_RR:
>> ww_mutex isn't RT aware at all; its one of the thi
Op 30-05-16 om 11:11 schreef Peter Zijlstra:
> On Mon, May 30, 2016 at 09:43:53AM +0200, Maarten Lankhorst wrote:
>> Op 26-05-16 om 22:08 schreef Chris Wilson:
>>> Recursive locking for ww_mutexes was originally conceived as an
>>> exception. However, it is hea
ever release the lock, we spin until
> kicked, whereupon the deadlock is discovered and reported.
>
> A simple solution for the now common problem is to move the recursive
> deadlock discovery to the first action when taking the ww_mutex.
>
> Testcase: igt/kms_cursor_legacy
>
Op 26-05-16 om 12:43 schreef Chris Wilson:
> On Thu, May 26, 2016 at 12:37:30PM +0200, Maarten Lankhorst wrote:
>> The check should also not be for NULL, but for use_ww_ctx.
>> This way the if check is optimized out for the ww_ctx path, where
>> ww_ctx is always non-null.
&
modesets.
>
> Testcase: igt/kms_cursor_legacy
> Signed-off-by: Chris Wilson
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Christian König
> Cc: Maarten Lankhorst
> Cc: linux-kernel@vger.kernel.org
> ---
> kernel/locking/mutex.c | 56
>
by: Gustavo Padovan
Acked-by: Maarten Lankhorst
Op 02-05-16 om 21:25 schreef robert.f...@collabora.com:
> From: Robert Foss
>
> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
> update is requested and there is an earlier update pending".
>
> Signed-off-by: Robert Foss
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++
Cc: David Airlie
>> Cc: Daniel Vetter
>> Cc: Rob Clark
>> Signed-off-by: Gustavo Padovan
> Acked-by: Rob Clark
>
Looking much better.
Acked-by: Maarten Lankhorst
Op 19-04-16 om 22:42 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> This function had copies in 3 different files. Unify them in kernel.h.
>
> Cc: Joe Perches
> Cc: Andrew Morton
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rob Clark
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gp
Op 30-03-16 om 11:08 schreef Bjørn Mork:
> commit e2c8b8701e2d moved modeset locking inside resume/suspend
> functions, but missed a code path only executed on lid close/open
> on older hardware. The result was a deadlock when closing and
> opening the lid without suspending on such hardware:
>
App
Hey,
Op 23-03-16 om 19:47 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Hi,
>
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a arra
Op 17-03-16 om 11:49 schreef William Dauchy:
> On Mon, Jan 11, 2016 at 2:35 AM, kernel test robot
> wrote:
>> FYI, we noticed the below changes on
>>
>> git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
>> commit 396e33ae204f52abebec9e578f44c749305500f4 ("drm/i915: Add two-stage
>> IL
t now with the actual value of num_fences
> in the sync_file.
>
> Also, info->sync_fence_info was converted to __u64 pointer to prevent
> 32bit compatibility issues.
For this patch and 6/6:
Reviewed-by: Maarten Lankhorst
ctl(fd, SYNC_IOC_FILE_INFO, info);
> }
>
> v2: fix fence_info memory leak
>
> v3: Comments from Emil Velikov
> - improve commit message
> - remove __u64 cast
> - remove check for output fields in file_info
> - clean up sync_fill_fence_i
Op 29-02-16 om 23:08 schreef Gustavo Padovan:
> Hi Maarten,
>
> 2016-02-29 Maarten Lankhorst :
>
>> Op 26-02-16 om 22:00 schreef Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks a
t; + __s32 fd2;
> + charname[32];
> + __s32 fence;
> };
>
> /**
For the first 3 patches:
Reviewed-by: Maarten Lankhorst
1 - 100 of 528 matches
Mail list logo
