Re: linux-next: build failure after merge of the drm-misc tree

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

Re: [PATCH] dma-fence: basic lockdep annotations

ndle 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 detail why cross-release isn't > the solution. > >

Re: [RFC 01/17] dma-fence: add might_sleep annotation to _wait()

er.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 +++ >>  

Re: [RFC 02/17] dma-fence: basic lockdep annotations

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 > Cc: linaro-mm-...@li

Re: [PATCH 1/3] drm: Add some new format DRM_FORMAT_NVXX_10

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

Re: [PATCH 32/33] fbcon: Document what I learned about fbcon locking

= -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: Maarten Lankhorst Howev

Re: [PATCH 19/33] fbdev: unify unlink_framebufer paths

^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

Re: [PATCH v2] drm/drm_vblank: Change EINVAL by the correct errno

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

[PATCH] drm: Require PCI for selecting VGA_ARB.

ou 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 Signed-off-by: Maarte

Re: WARNING: lock held when returning to user space in set_property_atomic

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: 

Re: [RFC PATCH] drm/atomic: add ASYNC_UPDATE flag to the Atomic IOCTL.

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

Re: [RFC PATCH] drm/atomic: add ASYNC_UPDATE flag to the Atomic IOCTL.

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

Re: [PATCH v8 3/3] drm: writeback: Add client capability for exposing writeback connectors

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

Re: [PATCH v8 3/3] drm: writeback: Add client capability for exposing writeback connectors

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

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

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

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

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 > --- >

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

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

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

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 > --- >

Re: [RFC PATCH] drm: Add per-plane pixel blend mode property

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

Re: [RFC PATCH] drm: Add per-plane pixel blend mode property

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

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

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 : [

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

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 : [

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

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]

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

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]

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

Op 04-04-18 om 14:26 schreef Daniel Vetter: > On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark <robdcl...@gmail.com> wrote: >> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst >> <maarten.lankho...@linux.intel.com> wrote: >>> Op 04-04-18 om 13:37 schreef Rob Clark:

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

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 >

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

Op 04-04-18 om 14:05 schreef Rob Clark: > On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst > <maarten.lankho...@linux.intel.com> wrote: >> Op 04-04-18 om 13:37 schreef Rob Clark: >>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst >>> <maarten.lankho...@l

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

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

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

Op 04-04-18 om 13:37 schreef Rob Clark: > On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst > <maarten.lankho...@linux.intel.com> wrote: >> Op 04-04-18 om 12:21 schreef Daniel Vetter: >>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: >>>> O

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

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

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

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

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

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

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

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

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

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

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

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

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

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

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

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

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

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

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

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:

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

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:

Re: 995d11c4c0 ("drm: rework delayed connector cleanup in .."): WARNING: possible circular locking dependency detected

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

Re: 995d11c4c0 ("drm: rework delayed connector cleanup in .."): WARNING: possible circular locking dependency detected

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

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

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

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

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

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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: >>>>> &

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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: >>>>> &

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

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

Re: [GIT pull] x86 APIC updates for 4.15

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

Re: [GIT pull] x86 APIC updates for 4.15

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

Re: WARNING: CPU: 1 PID: 185 at drivers/gpu/drm/i915/intel_display.c:14422 intel_modeset_init+0x3dc/0xf60 [i915]

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. :)

Re: WARNING: CPU: 1 PID: 185 at drivers/gpu/drm/i915/intel_display.c:14422 intel_modeset_init+0x3dc/0xf60 [i915]

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. :)

Re: [GIT pull] x86 APIC updates for 4.15

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

Re: [GIT pull] x86 APIC updates for 4.15

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

Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

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 no lo

Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

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 no lo

Re: [GIT pull] x86 APIC updates for 4.15

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 >

Re: [GIT pull] x86 APIC updates for 4.15

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 >

[PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

once during initial fbdev setup. Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup") Cc: <sta...@vger.kernel.org> # v4.14+ Reported-by: Thomas Voegtle <t...@lio96.de> --- drivers/gpu/drm/drm_

[PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

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/drm_fb_

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

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

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

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

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

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: > >

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

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: > >

Re: [PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()

helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev, > drm_modeset_backoff(); > } > > + drm_atomic_state_put(state); > drm_modeset_drop_locks(); > drm_modeset_acquire_fini();

Re: [PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()

mic_helper.c > @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev, > drm_modeset_backoff(); > } > > + drm_atomic_state_put(state); > drm_modeset_drop_locks(); > drm_modeset_acquire_fini(); > Reviewed-by: Maa

[PATCH 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

[PATCH 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

scripts/get_maintainer.pl misses maintainers sometimes

~/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 Author: Daniel Vet

scripts/get_maintainer.pl misses maintainers sometimes

~/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 Author: Daniel Vet

[PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

[PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

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

[PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

kernel.org Cc: intel-...@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

[PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

: 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

[PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.

Cc: Eric Anholt <e...@anholt.net> Cc: dri-de...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: intel-...@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: n

[PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.

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 |

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

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

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

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

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

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

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

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

Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

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

Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

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

[PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper

uot;) Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> --- 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_COMPA

[PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper

uot;) 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_

Re: [PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

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

Re: [PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

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

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

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

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

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

Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress

Op 30-11-16 om 01:35 schreef Chris Wilson: > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Maarten Lankhorst <d...@mblankhorst.nl> > Cc: Nicolai Hähnle <nhaeh...@gmail.com> > ---

Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress

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(+)

Re: [PATCH 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

Op 28-11-16 om 13:20 schreef Nicolai Hähnle: > From: Nicolai Hähnle <nicolai.haeh...@amd.com> > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: Maarten Lankhorst <d...@mblankhorst.nl> > Cc: Daniel Vetter <dan

Re: [PATCH 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

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

  1   2   3   4   5   6   7   8   9   10   >