• Stephen Boyd's avatar
    drm/msm/dpu: Convert to a chained irq chip · 070e64dc
    Stephen Boyd authored
    Devices that make up DPU, i.e. graphics card, request their interrupts
    from this "virtual" interrupt chip. The interrupt chip builds upon a GIC
    SPI interrupt that raises high when any of the interrupts in the DPU's
    irq status register are triggered. From the kernel's perspective this is
    a chained irq chip, so requesting a flow handler for the GIC SPI and
    then calling generic IRQ handling code from that irq handler is not
    completely proper. It's better to convert this to a chained irq so that
    the GIC SPI irq doesn't appear in /proc/interrupts, can't have CPU
    affinity changed, and won't be accounted for with irq stats. Doing this
    also silences a recursive lockdep warning because we can specify a
    different lock class for the chained interrupts, silencing a warning
    that is easy to see with 'threadirqs' on the kernel commandline.
    
     WARNING: inconsistent lock state
     4.19.10 #76 Tainted: G        W
     --------------------------------
     inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
     irq/40-dpu_mdss/203 [HC0[0]:SC0[2]:HE1:SE0] takes:
     0000000053ea9021 (&irq_desc_lock_class){?.-.}, at: handle_level_irq+0x34/0x26c
     {IN-HARDIRQ-W} state was registered at:
       lock_acquire+0x244/0x360
       _raw_spin_lock+0x64/0xa0
       handle_fasteoi_irq+0x54/0x2ec
       generic_handle_irq+0x44/0x5c
       __handle_domain_irq+0x9c/0x11c
       gic_handle_irq+0x208/0x260
       el1_irq+0xb4/0x130
       arch_cpu_idle+0x178/0x3cc
       default_idle_call+0x3c/0x54
       do_idle+0x1a8/0x3dc
       cpu_startup_entry+0x24/0x28
       rest_init+0x240/0x270
       start_kernel+0x5a8/0x6bc
     irq event stamp: 18
     hardirqs last  enabled at (17): [<ffffff9042385e80>] _raw_spin_unlock_irq+0x40/0xc0
     hardirqs last disabled at (16): [<ffffff904237a1f4>] __schedule+0x20c/0x1bbc
     softirqs last  enabled at (0): [<ffffff9040f318d0>] copy_process+0xb50/0x3964
     softirqs last disabled at (18): [<ffffff9041036364>] local_bh_disable+0x8/0x20
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(&irq_desc_lock_class);
       <Interrupt>
         lock(&irq_desc_lock_class);
    
      *** DEADLOCK ***
    
     no locks held by irq/40-dpu_mdss/203.
    
     stack backtrace:
     CPU: 0 PID: 203 Comm: irq/40-dpu_mdss Tainted: G        W         4.19.10 #76
     Call trace:
      dump_backtrace+0x0/0x2f8
      show_stack+0x20/0x2c
      __dump_stack+0x20/0x28
      dump_stack+0xcc/0x10c
      mark_lock+0xbe0/0xe24
      __lock_acquire+0x4cc/0x2708
      lock_acquire+0x244/0x360
      _raw_spin_lock+0x64/0xa0
      handle_level_irq+0x34/0x26c
      generic_handle_irq+0x44/0x5c
      dpu_mdss_irq+0x64/0xec
      irq_forced_thread_fn+0x58/0x9c
      irq_thread+0x120/0x1dc
      kthread+0x248/0x260
      ret_from_fork+0x10/0x18
     ------------[ cut here ]------------
     irq 169 handler irq_default_primary_handler+0x0/0x18 enabled interrupts
    
    Cc: Sean Paul <seanpaul@chromium.org>
    Cc: Jordan Crouse <jcrouse@codeaurora.org>
    Cc: Jayant Shekhar <jshekhar@codeaurora.org>
    Cc: Rajesh Yadav <ryadav@codeaurora.org>
    Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
    Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
    Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
    070e64dc
dpu_mdss.c 6.04 KB