AnsweredAssumed Answered

imx6q bsp driver(ipu_common.c)

Question asked by datoudatou datoudatou on Apr 18, 2014
Latest reply on Jan 7, 2018 by xiaojun ye

hi all,

     because i'm encounterd some question with ldb display ,it will indiciate that some error as follow sometimes.

<3>mxc_sdc_fb mxc_sdc_fb.0: timeout when waiting for flip irq

<3>mxc_sdc_fb mxc_sdc_fb.0: MXCFB_WAIT_FOR_VSYNC: timeout 0

<3>mxc_sdc_fb mxc_sdc_fb.0: MXCFB_WAIT_FOR_VSYNC: timeout 0

.....

.....

    

     or

E/FslHwcomposer( 2370): FBIO_WAITFORVSYNC error: Timer expired

mxc_sdc_fb mxc_sdc_fb.0: MXCFB_WAIT_FOR_VSYNC: timeout 0

E/FslHwcomposer( 2370): FBIO_WAITFORVSYNC error: Timer expired

mxc_sdc_fb mxc_sdc_fb.0: MXCFB_WAIT_FOR_VSYNC: timeout 0

 

     and then the screen can't display anything.

 

 

     so i check the source code with relative driver.the kernel wll pop these msgs because that something is not "completed",why? because the correspond handler isn't be invoked? the sync irq of per-IPU will invoke all handler if they require, so in ipu-common.c:

     in function ipu_sync_irq_handler() and ipu_err_irq_handler(), all of them will attempt to acquire the same spin_lock, i have a question about this.

     if the CPU0(assume) enter the sync irq isr, it obtain the spin_lock, and then some errors of IPU block happen(the sync irq ise not release the spin lock yet), the system maybe select CPU0 to hanlde this irq, now the ipu_err_irq_handler want to acquire the same spin_lock that ipu_sync_irq_handler holded, is this possible?(if possible(CPU0 unuseful?), use spin_lock_irqsave / spin_lock_irqresotre instead of spin_lock/spin_unlock will avoid this issue, right?)

 

 

     thank you for your reply!!!!

Outcomes