Refine dma-buf metadata setting to support framebuffer compression
Change-Id: Ia0ab9224d789c4b620e33a6f1c28483025a136ce
Signed-off-by: Richard Liu <xuegang.liu@nxp.com>
While investigating MLK-18894 ran a large number of suspend iterations
on imx6qp-sdb with rc2 kernel. After ~6 hours it hung while suspending
devices and sysrq-T showed the following trace for rtcwake:
The gckHARDWARE_SetPowerManagementState function seems hung waiting for
gckHARDWARE_QueryIdle. Inside the gckHARDWARE_QueryIdle there is a check
which looks like this:
rtcwake D 0 7090 561 0x00000001
[<809d5fc8>] (__schedule) from [<809d6380>] (schedule+0x48/0xb0)
[<809d6380>] (schedule) from [<809d9d3c>] (schedule_hrtimeout_range_clock+0xc8/0x13c)
[<809d9d3c>] (schedule_hrtimeout_range_clock) from [<809d9df0>] (schedule_hrtimeout+0x20/0x28)
[<809d9df0>] (schedule_hrtimeout) from [<807168c4>] (gckOS_Delay.part.3+0x64/0x6c)
[<807168c4>] (gckOS_Delay.part.3) from [<8071813c>] (gckOS_Delay+0x18/0x20)
[<8071813c>] (gckOS_Delay) from [<8073f08c>] (gckHARDWARE_SetPowerManagementState+0x838/0xb70)
[<8073f08c>] (gckHARDWARE_SetPowerManagementState) from [<8071df18>] (gpu_suspend+0x74/0xe4)
[<8071df18>] (gpu_suspend) from [<804fb9e8>] (dpm_run_callback+0x3c/0xdc)
/* Test if address is inside the last WAIT/LINK sequence. */
if ((address >= Hardware->lastWaitLink)
&& (address <= Hardware->lastWaitLink + 16)
Stepping through using the debugger (screenshot attached) this function
seems to return non-idle with both address lastWaitLink and being equal
to 0xFFFFFFF0. As far as I can tell the intention seems to be that the
check should pass but 0xFFFFFFF0 + 16 overflows back to zero so the
second part of the check fails because 0xFFFFFFF0 is not less than or
equal to 0.
Adding some prints to GPU code it seems that it's normal for these
values to be >0xFFFFe000. When they (randomly) hit 0xFFFFFFF0 exactly
the idle check will incorrectly fail and suspend will hang.
Actually, it is wrong when address reach to Hardware->lastWaitLink + 16,
because the address shall be either Hardware->lastWaitLink(wait command)
or Hardware->lastWaitLink + 8 (link command).
Fix the end address offset with 8 or 16 (extra 8 bytes for L2 flush).
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
version upgrade from 6.2.4.p1.150331 to 6.2.4.p2.163672
fixed gpu kernel panic for CONFIG_ARM64_SW_TTBR0_PAN,
support frequency query for gpu shader and core.
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
Adapted from 7a3d1096aa0cc77e258. This brings back the ability for
gputop to read HW counter values.
Signed-off-by: Marius Vlad <marius-cristian.vlad@nxp.com>
Some 2D APIs were not compatible with 64bit, resulting in some memory
address not accessible, Refine them as internal usage.
Date: 19th Jun, 2018
Signed-off-by: Ella Feng <ella.feng@nxp.com>
Update GPU database, add some new features, gcvFEATURE_PE_TILE_CACHE_FLUSH_FIX ans so on.
Fix imx8mscale escts dEQP-GLES3.functional.fbo.* randomly fail. When gcvFEATURE_PE_TILE_CACHE_FLUSH_FIX is
not enabled, need to flush tile cache with blt.
Signed-off-by: Ella Feng <ella.feng@nxp.com>
Reviewed-by: Xianzhon Li <xianzhong.li@nxp.com>
there are 2 test failed on 8QXP FB. CL151757 fixed bug #20196,
for image objects using host ptr, set the cacheable flag correctly.
merged CL151774 fix build error cause by CL151757.
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
When pm is running power ON to OFF (not broadcast), gckCOMMAND_Stall is called for synchronization.
But it does not blocks more events.
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
When power ON to other mode with broadcast (SUSPEND_BROADCAST,
IDLE_BROADCAST, OFF_BROADCAST), command->powerSemaphore is acquired after check idle.
code sequence:
check commit atom
check idle
>>> at this point, other thread may have new commits at this
>>> point.
Acquire command->powerSemaphore
... do clock off
This can cause unexpected interrupts after clock OFF or power
OFF.
To fix: try to acquire powerSemaphore before check commit atom,
abort when failure, because command commit is in progress.
fix bug #19216, #19230.
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
When pm (SetPowerManagementState) is running power ON to
SUSPEND_BROADCAST, it only checks wait-link FE, but not Async FE. Clock
can be off when read AsyncFE Acknowledge register and other.
pm thread:
...
check commit atom ok
>> check idle OK
(former stopIsr before cl144673 is here)
set GPU clock off
...
isr:
gcmkONERROR(ReadRegister(AQ_INTR_ACKNOWLEDGE_Address));
gckEVENT_Interrupt
>>> here, at this point, all interrupt comes, check idle in
>>> pm thread can pass.
gcmkONERROR(ReadRegister(AQ_INTR_ACKNOWLEDGE_EX_Address));
gckFE_UpdateAvaiable -> ReadRegister(GCREG_FE_ASYNC_STATUS_Address)
If gcmkONERROR(ReadRegister(AQ_INTR_ACKNOWLEDGE_EX_Address))
fail of clock off, then gckHARDWARE_Interrupt fails. In isrRoutine, it
won't wake up threadRoutine. Then it's stuck!
ReadRegister(GCREG_FE_ASYNC_STATUS_Address) failure can cause
unexpected behavior, too.
Former stopIsr (free_irq, before cl144673) can remove isr before
GPU clock off. So the issue is hidden.
To fix:
1. We should return success when either FE or AsyncFE reports
correct interrupts, so that isr can wake up threadRoutine for either FE.
That means, only need return ERROR when both FEs reports ERROR.
2. Add check for status of
ReadRegister(GCREG_FE_ASYNC_STATUS_Address).
Fix bug #19216, #19230.
merged BUG#19216 BUG#19230 CL152073 add missing part for CL151955
Signed-off-by: Xianzhong <xianzhong.li@nxp.com>
Dump the error info only when there is an error. If the gcdALLOC_ON_FAULT is not enabled, still need to check
the HW status to decide whether to dump the exception info or not
Signed-off-by: Ella Feng <ella.feng@nxp.com>
Reviewed-by: Xianzhong Li <xianzhong.li@nxp.com>
