Re: [Intel-gfx] [PATCH 53/59] drm/arc: Move to drm/tiny
Hi Daniel, I've got pretty strange results so I need some time to investigate it and probably retest. I'll send you update in a few days. --- Eugeniy Paltsev From: Daniel Vetter Sent: Friday, June 5, 2020 22:55 To: Eugeniy Paltsev Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Sam Ravnborg; Alexey Brodkin; snps-...@lists.infradead.org Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny Hi Eugeniy, Thanks for testing. I looked at the second one (I hoped it would just magically disappear) and I still don't understand what's going on there. My patch series isn't touching that area at all, so really confused. I squashed in the bugfix from the previous round into the right patches, and pushed a branch with just the arcpgu changes here: https://urldefense.com/v3/__https://cgit.freedesktop.org/*danvet/drm/log/?h=for-eugeniy__;fg!!A4F2R9G_pg!IJ1o4XiXVdStPu--Q-SCTUpRbsbqrjX255R34nuD7L7ptPywOy4SKr21dwSpfOkXIVqH5pM$ Maybe it's something in my pile of not-so-tested stuff :-) Can you pls test this? And if it still fails, try to bisect where it breaks? Thanks, Daniel On Thu, Jun 4, 2020 at 9:00 PM Eugeniy Paltsev wrote: > > I've tested your change and one issue gone. > > However I still see kernel crash (due to invalid read in kernel mode by 0x0 > address) on weston stop: > --->8--- > Oops > Path: (null) > CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted > 5.7.0-rc6-01594-g4ceda91a4176-dirty #6 > Workqueue: events drm_mode_rmfb_work_fn > Invalid Read @ 0x by insn @ drm_gem_fb_destroy+0x32/0x130 > ECR: 0x00050100 EFA: 0x ERET: 0x813b9a76 > STAT32: 0x80080602 [IE K ] BTA: 0x813b9a72 > BLK: drm_gem_fb_destroy+0xc0/0x130 > SP: 0x9f055ea4 FP: 0x > LPS: 0x813560ec LPE: 0x813560f0 LPC: 0x > r00: 0x r01: 0x9f6a6100 r02: 0x0001 > r03: 0x9fd5dde8 r04: 0x810f5de8 r05: 0x > r06: 0x r07: 0x r08: 0x00e1 > r09: 0x r10: 0x r11: 0x00e1 > r12: 0x813b9b04 > > Stack Trace: > drm_gem_fb_destroy+0x32/0x130 > drm_framebuffer_remove+0x1d2/0x358 > drm_mode_rmfb_work_fn+0x28/0x38 > process_one_work+0x19a/0x358 > worker_thread+0x2c4/0x494 > kthread+0xec/0x100 > ret_from_fork+0x18/0x1c > --->8--- > > > The stack traces may vary but always end in drm_gem_fb_destroy: > --->8--- > Stack Trace: > drm_gem_fb_destroy+0x32/0x130 > drm_mode_rmfb+0x10e/0x148 > drm_ioctl_kernel+0x70/0xa0 > drm_ioctl+0x284/0x410 > ksys_ioctl+0xea/0xa3c > EV_Trap+0xcc/0xd0 > --->8--- > Stack Trace: > drm_gem_fb_destroy+0x32/0x130 > drm_fb_release+0x66/0xb0 > drm_file_free.part.11+0x112/0x1bc > drm_release+0x80/0x120 > __fput+0x98/0x1bc > task_work_run+0x6e/0xa8 > do_exit+0x2b4/0x7fc > do_group_exit+0x2a/0x8c > get_signal+0x9a/0x5f0 > do_signal+0x86/0x23c > resume_user_mode_begin+0x88/0xd0 > --->8------- > > > --- > Eugeniy Paltsev > > > > From: Daniel Vetter > Sent: Thursday, June 4, 2020 14:19 > To: Eugeniy Paltsev > Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Sam Ravnborg; > Alexey Brodkin > Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny > > Hi Eugeniy, > > Apologies, somehow I missed your mail. I looked at the code again, and I > think I fumbled something. Does the below diff help to prevent the issues? > > Thanks, Daniel > > > diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c > index 857812f25bec..33d812a5ad7f 100644 > --- a/drivers/gpu/drm/tiny/arcpgu.c > +++ b/drivers/gpu/drm/tiny/arcpgu.c > @@ -228,6 +228,9 @@ static void arc_pgu_update(struct drm_simple_display_pipe > *pipe, > struct arcpgu_drm_private *arcpgu; > struct drm_gem_cma_object *gem; > > + if (!pipe->plane.state->fb) > + return; > + > arcpgu = pipe_to_arcpgu_priv(pipe); > gem = drm_fb_cma_get_gem_obj(pipe->plane.state->fb, 0); > arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr); > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - > https://urldefense.com/v3/__http://blog.ffwll.ch__;!!A4F2R9G_pg!P0EvyJfMuDwqbeZmHZM5S9po30QWr4KgGrggRirNfgo7wrRXfnUO-8iq0AA4fQCW2WGPlDc$ -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - https://urldefense.com/v3/__http://blog.ffwll.ch__;!!A4F2R9G_pg!IJ1o4XiXVdStPu--Q-SCTUpRbsbqrjX255R34nuD7L7ptPywOy4SKr21dwSpfOkXpn86Q20$ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 53/59] drm/arc: Move to drm/tiny
I've tested your change and one issue gone. However I still see kernel crash (due to invalid read in kernel mode by 0x0 address) on weston stop: --->8--- Oops Path: (null) CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.7.0-rc6-01594-g4ceda91a4176-dirty #6 Workqueue: events drm_mode_rmfb_work_fn Invalid Read @ 0x by insn @ drm_gem_fb_destroy+0x32/0x130 ECR: 0x00050100 EFA: 0x ERET: 0x813b9a76 STAT32: 0x80080602 [IE K ] BTA: 0x813b9a72 BLK: drm_gem_fb_destroy+0xc0/0x130 SP: 0x9f055ea4 FP: 0x LPS: 0x813560ec LPE: 0x813560f0 LPC: 0x r00: 0x r01: 0x9f6a6100 r02: 0x0001 r03: 0x9fd5dde8 r04: 0x810f5de8 r05: 0x r06: 0x r07: 0x r08: 0x00e1 r09: 0x r10: 0x r11: 0x00e1 r12: 0x813b9b04 Stack Trace: drm_gem_fb_destroy+0x32/0x130 drm_framebuffer_remove+0x1d2/0x358 drm_mode_rmfb_work_fn+0x28/0x38 process_one_work+0x19a/0x358 worker_thread+0x2c4/0x494 kthread+0xec/0x100 ret_from_fork+0x18/0x1c --->8--- The stack traces may vary but always end in drm_gem_fb_destroy: --->8--- Stack Trace: drm_gem_fb_destroy+0x32/0x130 drm_mode_rmfb+0x10e/0x148 drm_ioctl_kernel+0x70/0xa0 drm_ioctl+0x284/0x410 ksys_ioctl+0xea/0xa3c EV_Trap+0xcc/0xd0 --->8--- Stack Trace: drm_gem_fb_destroy+0x32/0x130 drm_fb_release+0x66/0xb0 drm_file_free.part.11+0x112/0x1bc drm_release+0x80/0x120 __fput+0x98/0x1bc task_work_run+0x6e/0xa8 do_exit+0x2b4/0x7fc do_group_exit+0x2a/0x8c get_signal+0x9a/0x5f0 do_signal+0x86/0x23c resume_user_mode_begin+0x88/0xd0 --->8--- --- Eugeniy Paltsev From: Daniel Vetter Sent: Thursday, June 4, 2020 14:19 To: Eugeniy Paltsev Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Sam Ravnborg; Alexey Brodkin Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny Hi Eugeniy, Apologies, somehow I missed your mail. I looked at the code again, and I think I fumbled something. Does the below diff help to prevent the issues? Thanks, Daniel diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c index 857812f25bec..33d812a5ad7f 100644 --- a/drivers/gpu/drm/tiny/arcpgu.c +++ b/drivers/gpu/drm/tiny/arcpgu.c @@ -228,6 +228,9 @@ static void arc_pgu_update(struct drm_simple_display_pipe *pipe, struct arcpgu_drm_private *arcpgu; struct drm_gem_cma_object *gem; + if (!pipe->plane.state->fb) + return; + arcpgu = pipe_to_arcpgu_priv(pipe); gem = drm_fb_cma_get_gem_obj(pipe->plane.state->fb, 0); arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr); -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - https://urldefense.com/v3/__http://blog.ffwll.ch__;!!A4F2R9G_pg!P0EvyJfMuDwqbeZmHZM5S9po30QWr4KgGrggRirNfgo7wrRXfnUO-8iq0AA4fQCW2WGPlDc$ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 53/59] drm/arc: Move to drm/tiny
Hi Daniel, I've already tested it (and found several issues), so please check my reply here: https://www.mail-archive.com/linux-snps-arc@lists.infradead.org/msg07403.html Not sure why you didn't receive my reply (probably the reason is because it was sent to your @ffwll.ch mail instead of @intel.com one). From: Daniel Vetter Sent: Thursday, June 4, 2020 11:05 To: Alexey Brodkin Cc: Intel Graphics Development; DRI Development; Daniel Vetter; Eugeniy Paltsev; Sam Ravnborg Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny On Fri, May 08, 2020 at 08:07:41PM +0200, Daniel Vetter wrote: > On Fri, May 8, 2020 at 3:56 PM Alexey Brodkin > wrote: > > > > Hi Daniel, > > > > > > Looking at this patch series, feels a bit like hand-rolling of bridge > > > > code, badly. We should get away from that. > > > > > > > > Once you have that I think the end result is tiny enough that it can > > > > stay, bridges intergrate quite well into simple display pipe drivers. > > > > > > > > > BTW should I pull that series in my tree and send you a pull-request > > > > > or that kind of change needs to go through another tree? > > > > > > > > > > Also I'd like to test the change we discuss here to make sure stuff > > > > > still works. Once we do that I'll send an update. Any hint on > > > > > when that change needs to be acked/nacked? > > > > > > > > Simplest is if this can all land through drm-misc, is arc not > > > > maintained in there? And there's plenty of time for testing, I'm just > > > > slowly crawling through the tree to get everything polished and > > > > cleaned up in this area. > > > > > > Any updates on testing this pile here? First patch landed now, and I've > > > started to push driver patches. So would be good to get this sorted out > > > too. > > > > Sorry we're in the middle of 2 long weekends so missed this one. > > I guess we'll be able to test it in a week or two from now. > > > > Is that OK? > > This aren't high-priority, so totally ok. As long as you don't land a > driver rewrite and I have to rebase everything :-) Ping for a bit of testing on this stuff ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation https://urldefense.com/v3/__http://blog.ffwll.ch__;!!A4F2R9G_pg!Ncpf9M5g5wUEicELHfzz8syA0c0KogYc2E0tdnXGHGmUwGbROv-vwMDISCh7u6w58Dgs-ws$ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
