All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Jonker <jbx6244@gmail.com>
To: Heiko Stuebner <heiko@sntech.de>, John Keeping <john@metanate.com>
Cc: dri-devel@lists.freedesktop.org, Sandy Huang <hjc@rock-chips.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org
Subject: Re: [BUG] [PATCH] drm/rockchip: use generic fbdev setup
Date: Mon, 17 Oct 2022 20:30:23 +0200	[thread overview]
Message-ID: <c4bf7723-b3b8-0955-5ba3-e4d05bdc835a@gmail.com> (raw)
In-Reply-To: <2220890.jZfb76A358@phil>



On 10/17/22 13:29, Heiko Stuebner wrote:
> Am Montag, 17. Oktober 2022, 12:05:16 CEST schrieb John Keeping:
>> Hi Johan,
>>
>> On Mon, Oct 17, 2022 at 10:11:32AM +0200, Johan Jonker wrote:
>>> Your patch contribution causes a kernel panic on MK808 with Rockchip rk3066a SoC.
>>> Would you like to contribute to fix this issue?
>>> The assumtion that drm_fbdev_generic_setup() does what rockchip_drm_fbdev_init did is not true!
>>> A revert makes it work again.
>>

>> It looks like there are 3 different ways to end up with -ENOMEM here,
>> can you track down whether you're hitting one of the cases in
>> rockchip_gem_prime_vmap() or if it's the iosys_map_is_null case in
>> drm_gem_vmap()?

It looks like it comes from rockchip_gem_prime_vmap() second return (2).

====



int rockchip_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
{
	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);

	if (rk_obj->pages) {
		void *vaddr = vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
				  pgprot_writecombine(PAGE_KERNEL));
		if (!vaddr) {
			printk("FBDEV rockchip_gem_prime_vmap 1");
			return -ENOMEM;
		}
		iosys_map_set_vaddr(map, vaddr);
		return 0;
	}

	if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING) {

////////////////

		printk("FBDEV rockchip_gem_prime_vmap 2");

////////////////
		return -ENOMEM;
	}
	iosys_map_set_vaddr(map, rk_obj->kvaddr);

	return 0;
}

====

[    7.678392] [drm:drm_client_modeset_probe] connector 39 enabled? yes
[    7.678435] [drm:drm_client_modeset_probe] Not using firmware configuration
[    7.678465] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 39
[    7.678494] [drm:drm_client_modeset_probe] looking for preferred mode on connector 39 0
[    7.678521] [drm:drm_client_modeset_probe] found mode 1920x1080
[    7.678545] [drm:drm_client_modeset_probe] picking CRTCs for 1920x1080 config
[    7.678585] [drm:drm_client_modeset_probe] desired mode 1920x1080 set on crtc 35 (0,0)
[    7.801673] Console: switching to colour frame buffer device 240x67


[    7.811047] FBDEV rockchip_gem_prime_vmap 2


[    7.811071] ------------[ cut here ]------------
[    7.811084] WARNING: CPU: 0 PID: 35 at drivers/gpu/drm/drm_fb_helper.c:471 drm_fb_helper_damage_work+0x138/0x3b4
[    7.811198] rockchip-drm display-subsystem: Damage blitter failed: ret=-12
[    7.811219] Modules linked in:
[    7.811244] CPU: 0 PID: 35 Comm: kworker/0:4 Not tainted 6.0.0-next-20221013+ #46
[    7.811281] Hardware name: Rockchip (Device Tree)
[    7.811300] Workqueue: events drm_fb_helper_damage_work
[    7.811352] Backtrace: 
[    7.811370]  dump_backtrace from show_stack+0x20/0x24
[    7.811431]  r7:000001d7 r6:00000009 r5:c0b2bc60 r4:60000013
[    7.811444]  show_stack from dump_stack_lvl+0x48/0x54
[    7.811512]  dump_stack_lvl from dump_stack+0x18/0x1c
[    7.811580]  r5:c0586064 r4:c0b6374c
[    7.811590]  dump_stack from __warn+0xdc/0x154
[    7.811677]  __warn from warn_slowpath_fmt+0xa4/0xd8
[    7.811740]  r7:000001d7 r6:c0b6374c r5:c1004ec8 r4:c0b639e8
[    7.811750]  warn_slowpath_fmt from drm_fb_helper_damage_work+0x138/0x3b4
[    7.811821]  r9:ef7cf105 r8:c15dfc00 r7:fffffff4 r6:c200b490 r5:c1004ec8 r4:c200b494
[    7.811833]  drm_fb_helper_damage_work from process_one_work+0x230/0x518
[    7.811912]  r10:c110d140 r9:ef7cf105 r8:00000000 r7:ef7cf100 r6:ef7cbf00 r5:c200e300
[    7.811927]  r4:c200b494
[    7.811936]  process_one_work from worker_thread+0x54/0x554
[    7.811991]  r10:ef7cbf00 r9:00000008 r8:c1003d40 r7:ef7cbf1c r6:c200e318 r5:ef7cbf00
[    7.812006]  r4:c200e300
[    7.812015]  worker_thread from kthread+0xe8/0x104
[    7.812100]  r10:f0929e84 r9:c200da00 r8:c169aa80 r7:c200e300 r6:c01419e4 r5:00000000
[    7.812114]  r4:c200d780
[    7.812124]  kthread from ret_from_fork+0x14/0x2c
[    7.812178] Exception stack(0xf092dfb0 to 0xf092dff8)
[    7.812205] dfa0:                                     00000000 00000000 00000000 00000000
[    7.812232] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.812255] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    7.812282]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c01491a8
[    7.812299]  r4:c200d780 r3:00000001
[    7.812309] ---[ end trace 0000000000000000 ]---
[    7.812336] FBDEV rockchip_gem_prime_vmap 2
[    7.889795] FBDEV rockchip_gem_prime_vmap 2
[    7.890418] FBDEV rockchip_gem_prime_vmap 2
[    7.899447] FBDEV rockchip_gem_prime_vmap 2
[    7.905252] FBDEV rockchip_gem_prime_vmap 2

>>
>> I guess the memory usage increases slightly using the generic code and
>> RK3066 has less memory available.
> 
> also rk3066 and rk3188 do not have an iommu, so rely
> on cma allocations.
> 
> 
> Heiko
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Johan Jonker <jbx6244@gmail.com>
To: Heiko Stuebner <heiko@sntech.de>, John Keeping <john@metanate.com>
Cc: dri-devel@lists.freedesktop.org, Sandy Huang <hjc@rock-chips.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org
Subject: Re: [BUG] [PATCH] drm/rockchip: use generic fbdev setup
Date: Mon, 17 Oct 2022 20:30:23 +0200	[thread overview]
Message-ID: <c4bf7723-b3b8-0955-5ba3-e4d05bdc835a@gmail.com> (raw)
In-Reply-To: <2220890.jZfb76A358@phil>



On 10/17/22 13:29, Heiko Stuebner wrote:
> Am Montag, 17. Oktober 2022, 12:05:16 CEST schrieb John Keeping:
>> Hi Johan,
>>
>> On Mon, Oct 17, 2022 at 10:11:32AM +0200, Johan Jonker wrote:
>>> Your patch contribution causes a kernel panic on MK808 with Rockchip rk3066a SoC.
>>> Would you like to contribute to fix this issue?
>>> The assumtion that drm_fbdev_generic_setup() does what rockchip_drm_fbdev_init did is not true!
>>> A revert makes it work again.
>>

>> It looks like there are 3 different ways to end up with -ENOMEM here,
>> can you track down whether you're hitting one of the cases in
>> rockchip_gem_prime_vmap() or if it's the iosys_map_is_null case in
>> drm_gem_vmap()?

It looks like it comes from rockchip_gem_prime_vmap() second return (2).

====



int rockchip_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
{
	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);

	if (rk_obj->pages) {
		void *vaddr = vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
				  pgprot_writecombine(PAGE_KERNEL));
		if (!vaddr) {
			printk("FBDEV rockchip_gem_prime_vmap 1");
			return -ENOMEM;
		}
		iosys_map_set_vaddr(map, vaddr);
		return 0;
	}

	if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING) {

////////////////

		printk("FBDEV rockchip_gem_prime_vmap 2");

////////////////
		return -ENOMEM;
	}
	iosys_map_set_vaddr(map, rk_obj->kvaddr);

	return 0;
}

====

[    7.678392] [drm:drm_client_modeset_probe] connector 39 enabled? yes
[    7.678435] [drm:drm_client_modeset_probe] Not using firmware configuration
[    7.678465] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 39
[    7.678494] [drm:drm_client_modeset_probe] looking for preferred mode on connector 39 0
[    7.678521] [drm:drm_client_modeset_probe] found mode 1920x1080
[    7.678545] [drm:drm_client_modeset_probe] picking CRTCs for 1920x1080 config
[    7.678585] [drm:drm_client_modeset_probe] desired mode 1920x1080 set on crtc 35 (0,0)
[    7.801673] Console: switching to colour frame buffer device 240x67


[    7.811047] FBDEV rockchip_gem_prime_vmap 2


[    7.811071] ------------[ cut here ]------------
[    7.811084] WARNING: CPU: 0 PID: 35 at drivers/gpu/drm/drm_fb_helper.c:471 drm_fb_helper_damage_work+0x138/0x3b4
[    7.811198] rockchip-drm display-subsystem: Damage blitter failed: ret=-12
[    7.811219] Modules linked in:
[    7.811244] CPU: 0 PID: 35 Comm: kworker/0:4 Not tainted 6.0.0-next-20221013+ #46
[    7.811281] Hardware name: Rockchip (Device Tree)
[    7.811300] Workqueue: events drm_fb_helper_damage_work
[    7.811352] Backtrace: 
[    7.811370]  dump_backtrace from show_stack+0x20/0x24
[    7.811431]  r7:000001d7 r6:00000009 r5:c0b2bc60 r4:60000013
[    7.811444]  show_stack from dump_stack_lvl+0x48/0x54
[    7.811512]  dump_stack_lvl from dump_stack+0x18/0x1c
[    7.811580]  r5:c0586064 r4:c0b6374c
[    7.811590]  dump_stack from __warn+0xdc/0x154
[    7.811677]  __warn from warn_slowpath_fmt+0xa4/0xd8
[    7.811740]  r7:000001d7 r6:c0b6374c r5:c1004ec8 r4:c0b639e8
[    7.811750]  warn_slowpath_fmt from drm_fb_helper_damage_work+0x138/0x3b4
[    7.811821]  r9:ef7cf105 r8:c15dfc00 r7:fffffff4 r6:c200b490 r5:c1004ec8 r4:c200b494
[    7.811833]  drm_fb_helper_damage_work from process_one_work+0x230/0x518
[    7.811912]  r10:c110d140 r9:ef7cf105 r8:00000000 r7:ef7cf100 r6:ef7cbf00 r5:c200e300
[    7.811927]  r4:c200b494
[    7.811936]  process_one_work from worker_thread+0x54/0x554
[    7.811991]  r10:ef7cbf00 r9:00000008 r8:c1003d40 r7:ef7cbf1c r6:c200e318 r5:ef7cbf00
[    7.812006]  r4:c200e300
[    7.812015]  worker_thread from kthread+0xe8/0x104
[    7.812100]  r10:f0929e84 r9:c200da00 r8:c169aa80 r7:c200e300 r6:c01419e4 r5:00000000
[    7.812114]  r4:c200d780
[    7.812124]  kthread from ret_from_fork+0x14/0x2c
[    7.812178] Exception stack(0xf092dfb0 to 0xf092dff8)
[    7.812205] dfa0:                                     00000000 00000000 00000000 00000000
[    7.812232] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.812255] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    7.812282]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c01491a8
[    7.812299]  r4:c200d780 r3:00000001
[    7.812309] ---[ end trace 0000000000000000 ]---
[    7.812336] FBDEV rockchip_gem_prime_vmap 2
[    7.889795] FBDEV rockchip_gem_prime_vmap 2
[    7.890418] FBDEV rockchip_gem_prime_vmap 2
[    7.899447] FBDEV rockchip_gem_prime_vmap 2
[    7.905252] FBDEV rockchip_gem_prime_vmap 2

>>
>> I guess the memory usage increases slightly using the generic code and
>> RK3066 has less memory available.
> 
> also rk3066 and rk3188 do not have an iommu, so rely
> on cma allocations.
> 
> 
> Heiko
> 
> 

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Johan Jonker <jbx6244@gmail.com>
To: Heiko Stuebner <heiko@sntech.de>, John Keeping <john@metanate.com>
Cc: David Airlie <airlied@linux.ie>, Sandy Huang <hjc@rock-chips.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [BUG] [PATCH] drm/rockchip: use generic fbdev setup
Date: Mon, 17 Oct 2022 20:30:23 +0200	[thread overview]
Message-ID: <c4bf7723-b3b8-0955-5ba3-e4d05bdc835a@gmail.com> (raw)
In-Reply-To: <2220890.jZfb76A358@phil>



On 10/17/22 13:29, Heiko Stuebner wrote:
> Am Montag, 17. Oktober 2022, 12:05:16 CEST schrieb John Keeping:
>> Hi Johan,
>>
>> On Mon, Oct 17, 2022 at 10:11:32AM +0200, Johan Jonker wrote:
>>> Your patch contribution causes a kernel panic on MK808 with Rockchip rk3066a SoC.
>>> Would you like to contribute to fix this issue?
>>> The assumtion that drm_fbdev_generic_setup() does what rockchip_drm_fbdev_init did is not true!
>>> A revert makes it work again.
>>

>> It looks like there are 3 different ways to end up with -ENOMEM here,
>> can you track down whether you're hitting one of the cases in
>> rockchip_gem_prime_vmap() or if it's the iosys_map_is_null case in
>> drm_gem_vmap()?

It looks like it comes from rockchip_gem_prime_vmap() second return (2).

====



int rockchip_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
{
	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);

	if (rk_obj->pages) {
		void *vaddr = vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
				  pgprot_writecombine(PAGE_KERNEL));
		if (!vaddr) {
			printk("FBDEV rockchip_gem_prime_vmap 1");
			return -ENOMEM;
		}
		iosys_map_set_vaddr(map, vaddr);
		return 0;
	}

	if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING) {

////////////////

		printk("FBDEV rockchip_gem_prime_vmap 2");

////////////////
		return -ENOMEM;
	}
	iosys_map_set_vaddr(map, rk_obj->kvaddr);

	return 0;
}

====

[    7.678392] [drm:drm_client_modeset_probe] connector 39 enabled? yes
[    7.678435] [drm:drm_client_modeset_probe] Not using firmware configuration
[    7.678465] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 39
[    7.678494] [drm:drm_client_modeset_probe] looking for preferred mode on connector 39 0
[    7.678521] [drm:drm_client_modeset_probe] found mode 1920x1080
[    7.678545] [drm:drm_client_modeset_probe] picking CRTCs for 1920x1080 config
[    7.678585] [drm:drm_client_modeset_probe] desired mode 1920x1080 set on crtc 35 (0,0)
[    7.801673] Console: switching to colour frame buffer device 240x67


[    7.811047] FBDEV rockchip_gem_prime_vmap 2


[    7.811071] ------------[ cut here ]------------
[    7.811084] WARNING: CPU: 0 PID: 35 at drivers/gpu/drm/drm_fb_helper.c:471 drm_fb_helper_damage_work+0x138/0x3b4
[    7.811198] rockchip-drm display-subsystem: Damage blitter failed: ret=-12
[    7.811219] Modules linked in:
[    7.811244] CPU: 0 PID: 35 Comm: kworker/0:4 Not tainted 6.0.0-next-20221013+ #46
[    7.811281] Hardware name: Rockchip (Device Tree)
[    7.811300] Workqueue: events drm_fb_helper_damage_work
[    7.811352] Backtrace: 
[    7.811370]  dump_backtrace from show_stack+0x20/0x24
[    7.811431]  r7:000001d7 r6:00000009 r5:c0b2bc60 r4:60000013
[    7.811444]  show_stack from dump_stack_lvl+0x48/0x54
[    7.811512]  dump_stack_lvl from dump_stack+0x18/0x1c
[    7.811580]  r5:c0586064 r4:c0b6374c
[    7.811590]  dump_stack from __warn+0xdc/0x154
[    7.811677]  __warn from warn_slowpath_fmt+0xa4/0xd8
[    7.811740]  r7:000001d7 r6:c0b6374c r5:c1004ec8 r4:c0b639e8
[    7.811750]  warn_slowpath_fmt from drm_fb_helper_damage_work+0x138/0x3b4
[    7.811821]  r9:ef7cf105 r8:c15dfc00 r7:fffffff4 r6:c200b490 r5:c1004ec8 r4:c200b494
[    7.811833]  drm_fb_helper_damage_work from process_one_work+0x230/0x518
[    7.811912]  r10:c110d140 r9:ef7cf105 r8:00000000 r7:ef7cf100 r6:ef7cbf00 r5:c200e300
[    7.811927]  r4:c200b494
[    7.811936]  process_one_work from worker_thread+0x54/0x554
[    7.811991]  r10:ef7cbf00 r9:00000008 r8:c1003d40 r7:ef7cbf1c r6:c200e318 r5:ef7cbf00
[    7.812006]  r4:c200e300
[    7.812015]  worker_thread from kthread+0xe8/0x104
[    7.812100]  r10:f0929e84 r9:c200da00 r8:c169aa80 r7:c200e300 r6:c01419e4 r5:00000000
[    7.812114]  r4:c200d780
[    7.812124]  kthread from ret_from_fork+0x14/0x2c
[    7.812178] Exception stack(0xf092dfb0 to 0xf092dff8)
[    7.812205] dfa0:                                     00000000 00000000 00000000 00000000
[    7.812232] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.812255] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    7.812282]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c01491a8
[    7.812299]  r4:c200d780 r3:00000001
[    7.812309] ---[ end trace 0000000000000000 ]---
[    7.812336] FBDEV rockchip_gem_prime_vmap 2
[    7.889795] FBDEV rockchip_gem_prime_vmap 2
[    7.890418] FBDEV rockchip_gem_prime_vmap 2
[    7.899447] FBDEV rockchip_gem_prime_vmap 2
[    7.905252] FBDEV rockchip_gem_prime_vmap 2

>>
>> I guess the memory usage increases slightly using the generic code and
>> RK3066 has less memory available.
> 
> also rk3066 and rk3188 do not have an iommu, so rely
> on cma allocations.
> 
> 
> Heiko
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Johan Jonker <jbx6244@gmail.com>
To: Heiko Stuebner <heiko@sntech.de>, John Keeping <john@metanate.com>
Cc: dri-devel@lists.freedesktop.org, Sandy Huang <hjc@rock-chips.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org
Subject: Re: [BUG] [PATCH] drm/rockchip: use generic fbdev setup
Date: Mon, 17 Oct 2022 20:30:23 +0200	[thread overview]
Message-ID: <c4bf7723-b3b8-0955-5ba3-e4d05bdc835a@gmail.com> (raw)
In-Reply-To: <2220890.jZfb76A358@phil>



On 10/17/22 13:29, Heiko Stuebner wrote:
> Am Montag, 17. Oktober 2022, 12:05:16 CEST schrieb John Keeping:
>> Hi Johan,
>>
>> On Mon, Oct 17, 2022 at 10:11:32AM +0200, Johan Jonker wrote:
>>> Your patch contribution causes a kernel panic on MK808 with Rockchip rk3066a SoC.
>>> Would you like to contribute to fix this issue?
>>> The assumtion that drm_fbdev_generic_setup() does what rockchip_drm_fbdev_init did is not true!
>>> A revert makes it work again.
>>

>> It looks like there are 3 different ways to end up with -ENOMEM here,
>> can you track down whether you're hitting one of the cases in
>> rockchip_gem_prime_vmap() or if it's the iosys_map_is_null case in
>> drm_gem_vmap()?

It looks like it comes from rockchip_gem_prime_vmap() second return (2).

====



int rockchip_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
{
	struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);

	if (rk_obj->pages) {
		void *vaddr = vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
				  pgprot_writecombine(PAGE_KERNEL));
		if (!vaddr) {
			printk("FBDEV rockchip_gem_prime_vmap 1");
			return -ENOMEM;
		}
		iosys_map_set_vaddr(map, vaddr);
		return 0;
	}

	if (rk_obj->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING) {

////////////////

		printk("FBDEV rockchip_gem_prime_vmap 2");

////////////////
		return -ENOMEM;
	}
	iosys_map_set_vaddr(map, rk_obj->kvaddr);

	return 0;
}

====

[    7.678392] [drm:drm_client_modeset_probe] connector 39 enabled? yes
[    7.678435] [drm:drm_client_modeset_probe] Not using firmware configuration
[    7.678465] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 39
[    7.678494] [drm:drm_client_modeset_probe] looking for preferred mode on connector 39 0
[    7.678521] [drm:drm_client_modeset_probe] found mode 1920x1080
[    7.678545] [drm:drm_client_modeset_probe] picking CRTCs for 1920x1080 config
[    7.678585] [drm:drm_client_modeset_probe] desired mode 1920x1080 set on crtc 35 (0,0)
[    7.801673] Console: switching to colour frame buffer device 240x67


[    7.811047] FBDEV rockchip_gem_prime_vmap 2


[    7.811071] ------------[ cut here ]------------
[    7.811084] WARNING: CPU: 0 PID: 35 at drivers/gpu/drm/drm_fb_helper.c:471 drm_fb_helper_damage_work+0x138/0x3b4
[    7.811198] rockchip-drm display-subsystem: Damage blitter failed: ret=-12
[    7.811219] Modules linked in:
[    7.811244] CPU: 0 PID: 35 Comm: kworker/0:4 Not tainted 6.0.0-next-20221013+ #46
[    7.811281] Hardware name: Rockchip (Device Tree)
[    7.811300] Workqueue: events drm_fb_helper_damage_work
[    7.811352] Backtrace: 
[    7.811370]  dump_backtrace from show_stack+0x20/0x24
[    7.811431]  r7:000001d7 r6:00000009 r5:c0b2bc60 r4:60000013
[    7.811444]  show_stack from dump_stack_lvl+0x48/0x54
[    7.811512]  dump_stack_lvl from dump_stack+0x18/0x1c
[    7.811580]  r5:c0586064 r4:c0b6374c
[    7.811590]  dump_stack from __warn+0xdc/0x154
[    7.811677]  __warn from warn_slowpath_fmt+0xa4/0xd8
[    7.811740]  r7:000001d7 r6:c0b6374c r5:c1004ec8 r4:c0b639e8
[    7.811750]  warn_slowpath_fmt from drm_fb_helper_damage_work+0x138/0x3b4
[    7.811821]  r9:ef7cf105 r8:c15dfc00 r7:fffffff4 r6:c200b490 r5:c1004ec8 r4:c200b494
[    7.811833]  drm_fb_helper_damage_work from process_one_work+0x230/0x518
[    7.811912]  r10:c110d140 r9:ef7cf105 r8:00000000 r7:ef7cf100 r6:ef7cbf00 r5:c200e300
[    7.811927]  r4:c200b494
[    7.811936]  process_one_work from worker_thread+0x54/0x554
[    7.811991]  r10:ef7cbf00 r9:00000008 r8:c1003d40 r7:ef7cbf1c r6:c200e318 r5:ef7cbf00
[    7.812006]  r4:c200e300
[    7.812015]  worker_thread from kthread+0xe8/0x104
[    7.812100]  r10:f0929e84 r9:c200da00 r8:c169aa80 r7:c200e300 r6:c01419e4 r5:00000000
[    7.812114]  r4:c200d780
[    7.812124]  kthread from ret_from_fork+0x14/0x2c
[    7.812178] Exception stack(0xf092dfb0 to 0xf092dff8)
[    7.812205] dfa0:                                     00000000 00000000 00000000 00000000
[    7.812232] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.812255] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    7.812282]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c01491a8
[    7.812299]  r4:c200d780 r3:00000001
[    7.812309] ---[ end trace 0000000000000000 ]---
[    7.812336] FBDEV rockchip_gem_prime_vmap 2
[    7.889795] FBDEV rockchip_gem_prime_vmap 2
[    7.890418] FBDEV rockchip_gem_prime_vmap 2
[    7.899447] FBDEV rockchip_gem_prime_vmap 2
[    7.905252] FBDEV rockchip_gem_prime_vmap 2

>>
>> I guess the memory usage increases slightly using the generic code and
>> RK3066 has less memory available.
> 
> also rk3066 and rk3188 do not have an iommu, so rely
> on cma allocations.
> 
> 
> Heiko
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-10-17 18:30 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 11:50 [PATCH] drm/rockchip: use generic fbdev setup John Keeping
2021-10-29 11:50 ` John Keeping
2021-10-29 11:50 ` John Keeping
2021-10-29 19:00 ` Thomas Zimmermann
2021-10-29 19:00   ` Thomas Zimmermann
2021-10-29 19:00   ` Thomas Zimmermann
2021-10-30 12:05   ` John Keeping
2021-10-30 12:05     ` John Keeping
2021-10-30 12:05     ` John Keeping
2021-10-31 18:09     ` Thomas Zimmermann
2021-10-31 18:09       ` Thomas Zimmermann
2021-10-31 18:09       ` Thomas Zimmermann
2021-11-01 11:34       ` John Keeping
2021-11-01 11:34         ` John Keeping
2021-11-01 11:34         ` John Keeping
2021-11-01 11:34         ` John Keeping
2021-12-07 11:54         ` John Keeping
2021-12-07 11:54           ` John Keeping
2021-12-07 11:54           ` John Keeping
2021-12-07 11:54           ` John Keeping
2021-12-07 13:00           ` Thomas Zimmermann
2021-12-07 13:00             ` Thomas Zimmermann
2021-12-07 13:00             ` Thomas Zimmermann
2022-10-17  8:11 ` [BUG] " Johan Jonker
2022-10-17  8:11   ` Johan Jonker
2022-10-17  8:11   ` Johan Jonker
2022-10-17  8:11   ` Johan Jonker
2022-10-17 10:05   ` John Keeping
2022-10-17 10:05     ` John Keeping
2022-10-17 10:05     ` John Keeping
2022-10-17 10:05     ` John Keeping
2022-10-17 11:29     ` Heiko Stuebner
2022-10-17 11:29       ` Heiko Stuebner
2022-10-17 11:29       ` Heiko Stuebner
2022-10-17 11:29       ` Heiko Stuebner
2022-10-17 18:30       ` Johan Jonker [this message]
2022-10-17 18:30         ` Johan Jonker
2022-10-17 18:30         ` Johan Jonker
2022-10-17 18:30         ` Johan Jonker
2022-10-17 19:00         ` John Keeping
2022-10-17 19:00           ` John Keeping
2022-10-17 19:00           ` John Keeping
2022-10-17 19:00           ` John Keeping
2022-10-17 19:16           ` Johan Jonker
2022-10-17 19:16             ` Johan Jonker
2022-10-17 19:16             ` Johan Jonker
2022-10-17 19:16             ` Johan Jonker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4bf7723-b3b8-0955-5ba3-e4d05bdc835a@gmail.com \
    --to=jbx6244@gmail.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=john@metanate.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.