drm/msm/dpu: Remove dynamic allocation from atomic context
We know the upper bound on # of mixers (ie. two), so lets just allocate this on the stack. Fixes: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0 INFO: lockdep is turned off. irq event stamp: 43642 hardirqs last enabled at (43641): [<ffffffe24dd276bc>] cpuidle_enter_state+0x158/0x25c hardirqs last disabled at (43642): [<ffffffe24dfff450>] enter_el1_irq_or_nmi+0x10/0x1c softirqs last enabled at (43620): [<ffffffe24d4103fc>] __do_softirq+0x1e4/0x464 softirqs last disabled at (43615): [<ffffffe24d48bd90>] __irq_exit_rcu+0x104/0x150 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.15.0-rc3-debug+ #105 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Call trace: dump_backtrace+0x0/0x18c show_stack+0x24/0x30 dump_stack_lvl+0xa0/0xd4 dump_stack+0x18/0x34 ___might_sleep+0x1e0/0x1f0 __might_sleep+0x78/0x8c slab_pre_alloc_hook.constprop.0+0x48/0x6c __kmalloc+0xc8/0x21c dpu_crtc_vblank_callback+0x158/0x1f8 dpu_encoder_vblank_callback+0x70/0xc4 dpu_encoder_phys_vid_vblank_irq+0x50/0x12c dpu_core_irq+0x1bc/0x1d0 dpu_irq+0x1c/0x28 msm_irq+0x34/0x40 __handle_irq_event_percpu+0x15c/0x308 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x54/0x98 handle_level_irq+0xa0/0xd0 handle_irq_desc+0x2c/0x44 generic_handle_domain_irq+0x28/0x34 dpu_mdss_irq+0x90/0xe8 handle_irq_desc+0x2c/0x44 handle_domain_irq+0x54/0x80 gic_handle_irq+0xd4/0x148 call_on_irq_stack+0x2c/0x54 do_interrupt_handler+0x4c/0x64 el1_interrupt+0x30/0xd0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x78/0x7c arch_local_irq_enable+0xc/0x14 cpuidle_enter+0x44/0x5c do_idle+0x248/0x268 cpu_startup_entry+0x30/0x48 rest_init+0x188/0x19c arch_call_rest_init+0x1c/0x28 start_kernel+0x704/0x744 __primary_switched+0xc0/0xc8 Fixes: 78d9b458 ("drm/msm/dpu: Add CRC support for DPU") Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20211023160016.3322052-2-robdclark@gmail.comSigned-off-by: Rob Clark <robdclark@chromium.org>
Showing
Please register or sign in to comment