27 May, 2020
2 commits
-
Add below features support for both TJA1100 and TJA1101 cards:
- Add MII and RMII mode support.
- Add refclk in/out support for RMII.Reviewed-by: Richard Zhu
Signed-off-by: Fugang Duan -
The crtc_states could be got concurrently if multiple atomic checks
happen simultaneously, so ERR_PTR(-EDEADLK) could be returned from
drm_atomic_get_crtc_state(). In such normal cases, we just rollback
all added drm objects and userspace could try the same atomic check
or commit again, so it's unnecessary to warn.Signed-off-by: Liu Ying
Reviewed-by: Sandor Yu
(cherry picked from commit e72359e9308b1bbb30f604ed6118c9216f9c43fd)
26 May, 2020
1 commit
-
There are two more DONE0_CONFIG/DONE1_CONFIG registers on i.mx8m family.
Add them to save/restore register list during systerm level suspend/
resume to restore them after resume back, otherwise, PDM case maybe failed
in suspend/resume case.Signed-off-by: Robin Gong
Reviewed-by: Shengjiu Wang
(cherry picked from commit 2c213d8ac495065f5ec4182335c151d32d0eb482)
22 May, 2020
2 commits
-
Apparently, in order to enable the MIPI block, the reset signals must
be in asserted mode, in order to proper de-assert and initialize the
MIPI block. So, before the enable process, assert all the MIPI resets.Signed-off-by: Robert Chiras
-
In VDOA_MODE, _get_vdoa_ipu_res() would lock ipu_ch_tbl.lock mutex first,
then lock vdoa_lock mutex and finally unlock ipu_ch_tbl.lock mutex.
The vdoa_lock mutex is unlocked until put_vdoa_ipu_res(). Since the two
mutexes are not unlocked in a reversed order as they are locked, AB-BA
deadlock issue may happen as the below warning shows, which can be detected
with the debug option CONFIG_PROVE_LOCKING enabled.[ 52.398770] ======================================================
[ 52.404957] WARNING: possible circular locking dependency detected
[ 52.411145] 5.4.24 #1477 Not tainted
[ 52.414728] ------------------------------------------------------
[ 52.420915] ipu1_task/92 is trying to acquire lock:
[ 52.425800] 81f02274 (&ipu_ch_tbl.lock){+.+.}, at: get_res_do_task+0x144/0x77c
[ 52.433050]
[ 52.433050] but task is already holding lock:
[ 52.438888] 8183189c (vdoa_lock){+.+.}, at: vdoa_get_handle+0x64/0x158
[ 52.445434]
[ 52.445434] which lock already depends on the new lock.
[ 52.445434]
[ 52.453615]
[ 52.453615] the existing dependency chain (in reverse order) is:
[ 52.461101]
[ 52.461101] -> #1 (vdoa_lock){+.+.}:
[ 52.466175] __mutex_lock+0xb8/0xaa8
[ 52.470283] mutex_lock_nested+0x2c/0x34
[ 52.474735] vdoa_get_handle+0x64/0x158
[ 52.479100] _get_vdoa_ipu_res+0x2b4/0x338
[ 52.483726] get_res_do_task+0x34/0x77c
[ 52.488092] ipu_task_thread+0x148/0xeb0
[ 52.492551] kthread+0x168/0x170
[ 52.496310] ret_from_fork+0x14/0x20
[ 52.500414] 0x0
[ 52.502779]
[ 52.502779] -> #0 (&ipu_ch_tbl.lock){+.+.}:
[ 52.508457] __lock_acquire+0x15d0/0x2588
[ 52.512995] lock_acquire+0xdc/0x280
[ 52.517103] __mutex_lock+0xb8/0xaa8
[ 52.521210] mutex_lock_nested+0x2c/0x34
[ 52.525662] get_res_do_task+0x144/0x77c
[ 52.530113] ipu_task_thread+0x148/0xeb0
[ 52.534566] kthread+0x168/0x170
[ 52.538322] ret_from_fork+0x14/0x20
[ 52.542425] 0x0
[ 52.544790]
[ 52.544790] other info that might help us debug this:
[ 52.544790]
[ 52.552797] Possible unsafe locking scenario:
[ 52.552797]
[ 52.558721] CPU0 CPU1
[ 52.563256] ---- ----
[ 52.567790] lock(vdoa_lock);
[ 52.570853] lock(&ipu_ch_tbl.lock);
[ 52.577040] lock(vdoa_lock);
[ 52.582619] lock(&ipu_ch_tbl.lock);
[ 52.586289]
[ 52.586289] *** DEADLOCK ***
[ 52.586289]
[ 52.592215] 1 lock held by ipu1_task/92:
[ 52.596142] #0: 8183189c (vdoa_lock){+.+.}, at: vdoa_get_handle+0x64/0x158
[ 52.603123]
[ 52.603123] stack backtrace:
[ 52.607493] CPU: 0 PID: 92 Comm: ipu1_task Not tainted 5.4.24 #1477
[ 52.613765] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 52.620298] Backtrace:
[ 52.622764] [] (dump_backtrace) from [] (show_stack+0x20/0x24)
[ 52.630345] r7:818641a8 r6:00000000 r5:600f0193 r4:818641a8
[ 52.636026] [] (show_stack) from [] (dump_stack+0xbc/0xe8)
[ 52.643261] [] (dump_stack) from [] (print_circular_bug+0x1c4/0x214)
[ 52.651361] r10:a8330000 r9:ffffffff r8:a8330000 r7:a8330550 r6:81d13b1c r5:81d13ac0
[ 52.659197] r4:81d13ac0 r3:46e9f8d1
[ 52.662783] [] (print_circular_bug) from [] (check_noncircular+0x204/0x21c)
[ 52.671492] r9:00000001 r8:81708f50 r7:00000000 r6:a8423a98 r5:a8330530 r4:a8330550
[ 52.679245] [] (check_noncircular) from [] (__lock_acquire+0x15d0/0x2588)
[ 52.687778] r8:81708f50 r7:81d13ac0 r6:00000001 r5:81e93d7c r4:a8330530
[ 52.694491] [] (__lock_acquire) from [] (lock_acquire+0xdc/0x280)
[ 52.702334] r10:00000000 r9:00000000 r8:00000000 r7:81f02274 r6:600f0113 r5:81708724
[ 52.710169] r4:00000000
[ 52.712717] [] (lock_acquire) from [] (__mutex_lock+0xb8/0xaa8)
[ 52.720384] r10:81e93d7c r9:0000f6d0 r8:81f022e8 r7:00008f50 r6:00000000 r5:ffffe000
[ 52.728219] r4:81f02240
[ 52.730765] [] (__mutex_lock) from [] (mutex_lock_nested+0x2c/0x34)
[ 52.738778] r10:00000000 r9:a8423ccc r8:81f022e8 r7:000002d0 r6:8188b6f8 r5:81f02234
[ 52.746613] r4:a4540400
[ 52.749162] [] (mutex_lock_nested) from [] (get_res_do_task+0x144/0x77c)
[ 52.757612] [] (get_res_do_task) from [] (ipu_task_thread+0x148/0xeb0)
[ 52.765886] r10:a8139bd0 r9:a8423ccc r8:81f022e8 r7:a4540400 r6:81831604 r5:a454053c
[ 52.773721] r4:600f0013
[ 52.776269] [] (ipu_task_thread) from [] (kthread+0x168/0x170)
[ 52.783849] r10:a8139bd0 r9:80b8d558 r8:81f022e8 r7:a8422000 r6:00000000 r5:a840cd00
[ 52.791684] r4:a83cc080
[ 52.794231] [] (kthread) from [] (ret_from_fork+0x14/0x20)
[ 52.801460] Exception stack(0xa8423fb0 to 0xa8423ff8)
[ 52.806521] 3fa0: 00000000 00000000 00000000 00000000
[ 52.814711] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 52.822898] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 52.829521] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:80168360
[ 52.837356] r4:a840cd00This patch corrects the locking/unlocking sequence for the two mutexes
to fix the deadlock issue.Reviewed-by: Sandor Yu
Signed-off-by: Liu Ying
(cherry picked from commit c18ff376db6529818037a66b2cafaa3f512577d8)
21 May, 2020
2 commits
-
Add copyright
Signed-off-by: Shengjiu Wang
Reviewed-by: Daniel Baluta -
Add copyright
Signed-off-by: Shengjiu Wang
Reviewed-by: Daniel Baluta
20 May, 2020
2 commits
-
According to Mixel MIPI CSI PHY spec, the minimum value for RXHS_SETTLE
is 85ns + 6*UI and the maximum value for RXHS_SETTLE is 145ns + 10*UI,
so get average value of maximum and minimum as RXHS_SETTLE typical value.Signed-off-by: Guoniu.zhou
Reviewed-by: Sandor Yu
(cherry picked from commit af684872dceece899b439b6167343b1e7655a251) -
The legacy terminate_worker may terminate the next transfer if it comes
before all jobs done in terminated_worker, or refuse to setup next transfer
since sdmac->desc may not be NULL in sdma_issue_pending(). That case could
be easily caught in Audio play in case underrun happen at ALSA level which
means dma channel will be terminated and start again very frequently.
So move the logic part of 'sdmac->desc' into sdma_disable_channel_async but
leave the desc free in the work to kill the above case.Signed-off-by: Robin Gong
Reviewed-by: Shengjiu Wang
(cherry picked from commit acf2a79f1f73b1cf59b2e3dc096ff4340cfe7687)
19 May, 2020
1 commit
-
During the unbind() procedure, drm_encoder_cleanup() will
detach the downstream DSI bridge if exists. And the DSI
bridge's detach() will detach itself from the DSI host.
So DSI host should be unregistered later than DSI device
detach. Otherwise, below kernel panic happens:[ 2.437740] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000007
[ 2.446534] Mem abort info:
[ 2.449327] ESR = 0x96000004
[ 2.452401] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.457717] SET = 0, FnV = 0
[ 2.460777] EA = 0, S1PTW = 0
[ 2.463921] Data abort info:
[ 2.466808] ISV = 0, ISS = 0x00000004
[ 2.470649] CM = 0, WnR = 0
[ 2.473617] [0000000000000007] user address but active_mm is swapper
[ 2.479978] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 2.485550] Modules linked in:
[ 2.488609] CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 5.4.24-04902-g14319eb2bae3 #1683
[ 2.496871] Hardware name: NXP i.MX8MPlus EVK board (DT)
[ 2.502188] Workqueue: events deferred_probe_work_func
[ 2.507328] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 2.512121] pc : mipi_dsi_detach+0x10/0x38
[ 2.516219] lr : adv7533_detach_dsi+0x18/0x30
[ 2.520574] sp : ffff80001242b6e0
[ 2.523885] x29: ffff80001242b6e0 x28: ffff8000119d6000
[ 2.529196] x27: 0000000000000000 x26: 00000000fffffdfb
[ 2.534507] x25: 0000000000000001 x24: ffff8000115159f0
[ 2.539819] x23: ffff000176652120 x22: ffff800011b94000
[ 2.545132] x21: ffff000177882000 x20: ffff0001778766e8
[ 2.550444] x19: ffff000177876880 x18: 0000000000000000
[ 2.555756] x17: ffff800011e0d000 x16: 0000000000000000
[ 2.561068] x15: 0000000000000004 x14: ffffffffffffffff
[ 2.566381] x13: 0000000000000000 x12: ffff0001745765c8
[ 2.571694] x11: ffff000174576480 x10: 0000000000000040
[ 2.577006] x9 : ffff000176020e98 x8 : ffff000176020e90
[ 2.582318] x7 : 0000000000000001 x6 : 0000000000000001
[ 2.587630] x5 : 0000000000000000 x4 : 0000000000000000
[ 2.592943] x3 : ffff800011a398b0 x2 : ffffffffffffffff
[ 2.598255] x1 : ffff0001778d5c00 x0 : ffff0001778d6400
[ 2.603569] Call trace:
[ 2.606018] mipi_dsi_detach+0x10/0x38
[ 2.609769] adv7511_bridge_detach+0x6c/0x80
[ 2.614041] drm_bridge_detach+0x2c/0x50
[ 2.617964] drm_encoder_cleanup+0x2c/0xa0
[ 2.622063] imx_sec_dsim_unbind+0x50/0x68
[ 2.626159] component_unbind.isra.0+0x2c/0x50
[ 2.630601] component_bind_all+0x1e0/0x228
[ 2.634784] imx_drm_bind+0xb8/0x150
[ 2.638357] try_to_bring_up_master+0x164/0x1c0
[ 2.642887] __component_add+0xa0/0x168
[ 2.646721] component_add+0x10/0x18
[ 2.650297] lcdifv3_crtc_probe+0x4c/0x78
[ 2.654309] platform_drv_probe+0x50/0xa0
[ 2.658317] really_probe+0xd4/0x318
[ 2.661891] driver_probe_device+0x54/0xe8
[ 2.665991] __device_attach_driver+0x80/0xb8
[ 2.670348] bus_for_each_drv+0x74/0xc0
[ 2.674183] __device_attach+0xdc/0x138
[ 2.678020] device_initial_probe+0x10/0x18
[ 2.682204] bus_probe_device+0x90/0x98
[ 2.686042] device_add+0x378/0x648
[ 2.689531] platform_device_add+0xfc/0x228
[ 2.693718] imx_lcdifv3_probe+0x2b0/0x388
[ 2.697814] platform_drv_probe+0x50/0xa0
[ 2.701825] really_probe+0xd4/0x318
[ 2.705403] driver_probe_device+0x54/0xe8
[ 2.709502] __device_attach_driver+0x80/0xb8
[ 2.713859] bus_for_each_drv+0x74/0xc0
[ 2.717696] __device_attach+0xdc/0x138
[ 2.721535] device_initial_probe+0x10/0x18
[ 2.725721] bus_probe_device+0x90/0x98
[ 2.729555] deferred_probe_work_func+0x64/0x98
[ 2.734089] process_one_work+0x198/0x320
[ 2.738100] worker_thread+0x1f0/0x420
[ 2.741850] kthread+0xf0/0x120
[ 2.744993] ret_from_fork+0x10/0x18
[ 2.748573] Code: aa0003e1 f9400000 f9400402 b4000102 (f9400442)
[ 2.754667] ---[ end trace 756e3cdcc6c5557e ]---Signed-off-by: Fancy Fang
(cherry picked from commit ac040846d4c80c03e7ccb96a3b8553f84b743d39)
18 May, 2020
2 commits
-
Coverity report: CID = 4327643
incompatible_cast: Pointer &irqchip_data->irqstat points to an object whose
effective type is unsigned int (32 bits, unsigned) but is dereferenced as a
wider unsigned long (64 bits, unsigned). This may lead to memory corruption.Reviewed-by: Fugang Duan
Signed-off-by: Joakim Zhang -
GENMASK(h, l) is creating a contiguous bitmask starting at bit
position @l and ending at position @h.Reviewed-by: Peter Chen
Reviewed-by: Peng Fan
Signed-off-by: Li Jun
16 May, 2020
2 commits
-
Add USB PHY parameters tuning for USB certifications.
Reviewed-by: Peter Chen
Signed-off-by: Li Jun -
put clk_prepare and clk_prepare into set_power function
Signed-off-by: Minjie Zhuang
15 May, 2020
11 commits
-
The YUV formats were removed from graphics plane and RGB ones were removed from
video planes. That's because, in general, one will use a window manager and the
UI will always reside on the graphics plane, while video playback will go to
the overlay planes.However, this move affects users using custom applications that would like to
use 2 graphics planes and one video plane. Or 3 graphics planes.DCSS is perfectly capable of scanning out RGB/YUV linear formats on all 3
pipes. Only tiled and tiled-compressed formats need special treatment:
tiled-compressed graphics has to always go to pipe 1 (since DEC400D is needed
for uncompressing the graphics format) whilst tiled-uncompressed and
tiled-compressed VPU formats need to always go to pipes 2 and 3 (DTRC will
handle de-tiling and decompression).Signed-off-by: Laurentiu Palcu
Reviewed-by: Robert Chiras -
Move the controller enablement from atomic plane update to
the CRTC's atomic enable, since some bridge(e.g. IT6263)
requires data stream from CRTC to be ready for its config.But this controller enablement change won't cause any side
effect, since the CRTC enable and plane update can be done
in one frame interval and to next frame all configurations
can take effect, which has the same behavior as before.Signed-off-by: Fancy Fang
Reviewed-by: Liu Ying
(cherry picked from commit ea4f7e2d01e9dde69a34a3e2f0a4d194f60080d2) -
After the atomic plane update, the shadow load should be
enabled to make sure its update can take effect on next
frame in any cases. And this enable is better to be done
in CRTC's atomic_flush() which is called after plane's
atomic_update() is called.Besides, the shadow load enable in controller enable is
unnecessary, so remove it.Signed-off-by: Fancy Fang
Reviewed-by: Liu Ying
(cherry picked from commit bfa7236c8477e8993f074a3068ddc64c1614db06) -
When firmware exception, send error event instead of eos event,
avoid doubt or might send eos event twice(exception + parsed eos data).Signed-off-by: Shijie Qin
Reviewed-by: ming_qian
(cherry picked from commit 2f97227dd635efa0c6ea965ab2d9f7fc9bafe9fb) -
fix clk use-after-free issue
Signed-off-by: Zhou Peng
(cherry picked from commit 0d1b3814c976cb2148958f48c4c4f4701ced6b4e) -
release clk to avoid memory leak
Signed-off-by: Zhou Peng
(cherry picked from commit 420a357a1b43c57383c74a548a9a3714b6da7de2) -
release clk to avoid memory leak
Signed-off-by: Zhou Peng
(cherry picked from commit 76d95bf26376a7f774f2939052e3595b8d2aefdb) -
change module device table name to fix build error as module
rename the c source name to avoid conflict with h1
release clk avoid memory leak
fix typo error in core indexSigned-off-by: Zhou Peng
(cherry picked from commit 099a3ae272672978b7720257f012dcf38e537dc0) -
Combine pvi and pai power up/down functions to pavi_powerup/down
function. Move clock enable/disable function to power function.Signed-off-by: Sandor Yu
-
remove the redundant pm_runtime_get_sync introduced in last code rebase
Signed-off-by: Han Xu
(cherry picked from commit 529d3dc133ad98f56f97a1f95880959943ff6084) -
To get better performance, current gpmi driver collected and chained all
small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and
wait for complete at the end.But some random DMA timeout found in this new driver, with the help of
ftrace, we found the root cause is as follows:Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6
DMA transfers and the DMA chain triggered at the end. It waits for bch
completion and check jiffies if it's timeout. The typical function graph
shown below,63.216351 | 1) | gpmi_ecc_read_page() {
63.216352 | 1) 0.750 us | gpmi_bch_layout_std();
63.216354 | 1) | gpmi_nfc_exec_op() {
63.216355 | 1) | gpmi_chain_command() {
63.216356 | 1) | mxs_dma_prep_slave_sg() {
63.216357 | 1) | /* mxs chan ccw idx: 0 */
63.216358 | 1) 1.750 us | }
63.216359 | 1) | mxs_dma_prep_slave_sg() {
63.216360 | 1) | /* mxs chan ccw idx: 1 */
63.216361 | 1) 2.000 us | }
63.216361 | 1) 6.500 us | }
63.216362 | 1) | gpmi_chain_command() {
63.216363 | 1) | mxs_dma_prep_slave_sg() {
63.216364 | 1) | /* mxs chan ccw idx: 2 */
63.216365 | 1) 1.750 us | }
63.216366 | 1) | mxs_dma_prep_slave_sg() {
63.216367 | 1) | /* mxs chan ccw idx: 3 */
63.216367 | 1) 1.750 us | }
63.216368 | 1) 5.875 us | }
63.216369 | 1) | /* gpmi_chain_wait_ready */
63.216370 | 1) | mxs_dma_prep_slave_sg() {
63.216372 | 1) | /* mxs chan ccw idx: 4 */
63.216373 | 1) 3.000 us | }
63.216374 | 1) | /* gpmi_chain_data_read */
63.216376 | 1) | mxs_dma_prep_slave_sg() {
63.216377 | 1) | /* mxs chan ccw idx: 5 */
63.216378 | 1) 2.000 us | }
63.216379 | 1) 1.125 us | mxs_dma_tx_submit();
63.216381 | 1) 1.000 us | mxs_dma_enable_chan();
63.216712 | 0) 2.625 us | mxs_dma_int_handler();
63.216717 | 0) 4.250 us | bch_irq();
63.216723 | 0) 1.250 us | mxs_dma_tasklet();
63.216723 | 1) | /* jiffies left 250 */
63.216725 | 1) ! 372.000 us | }
63.216726 | 1) 2.625 us | gpmi_count_bitflips();
63.216730 | 1) ! 379.125 us | }but it's not gurantee that bch irq handled always after dma irq handled,
sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore,
another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ
handled, this messed up the next DMA chain and causes DMA timeout. Check
the trace log when issue happened.63.218923 | 1) | gpmi_ecc_read_page() {
63.218924 | 1) 0.625 us | gpmi_bch_layout_std();
63.218926 | 1) | gpmi_nfc_exec_op() {
63.218927 | 1) | gpmi_chain_command() {
63.218928 | 1) | mxs_dma_prep_slave_sg() {
63.218929 | 1) | /* mxs chan ccw idx: 0 */
63.218929 | 1) 1.625 us | }
63.218931 | 1) | mxs_dma_prep_slave_sg() {
63.218931 | 1) | /* mxs chan ccw idx: 1 */
63.218932 | 1) 1.750 us | }
63.218933 | 1) 5.875 us | }
63.218934 | 1) | gpmi_chain_command() {
63.218934 | 1) | mxs_dma_prep_slave_sg() {
63.218935 | 1) | /* mxs chan ccw idx: 2 */
63.218936 | 1) 1.875 us | }
63.218937 | 1) | mxs_dma_prep_slave_sg() {
63.218938 | 1) | /* mxs chan ccw idx: 3 */
63.218939 | 1) 1.625 us | }
63.218939 | 1) 5.875 us | }
63.218940 | 1) | /* gpmi_chain_wait_ready */
63.218941 | 1) | mxs_dma_prep_slave_sg() {
63.218942 | 1) | /* mxs chan ccw idx: 4 */
63.218942 | 1) 1.625 us | }
63.218943 | 1) | /* gpmi_chain_data_read */
63.218944 | 1) | mxs_dma_prep_slave_sg() {
63.218945 | 1) | /* mxs chan ccw idx: 5 */
63.218947 | 1) 2.375 us | }
63.218948 | 1) 0.625 us | mxs_dma_tx_submit();
63.218949 | 1) 1.000 us | mxs_dma_enable_chan();
63.219276 | 0) 5.125 us | bch_irq();
(cherry picked from commit 5dde5bcfd7fab7a6cb9974b79f7d36cbf64b85fb)
14 May, 2020
1 commit
-
- Don't limit to only PCIe GEN1 when do the compliance tests.
- Configure the TX drive level of iMX865 PHY, adjust the peak output
voltage to pass the PCIe GEN1 compliance tests.Signed-off-by: Richard Zhu
Reviewed-by: Frank Li
(cherry picked from commit af235be4424b003b2adc53c39f57f8ed00b0e342)
13 May, 2020
1 commit
-
Fix below build warning:
warning: format ‘%li’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
"Exceed max msg size (%li) on TX, got: %i\n",Reviewed-by: Ye Li
Signed-off-by: Peng Fan
(cherry picked from commit 6566c7b54aef56d7a4bf83f75615c7c4d39f98ad)
12 May, 2020
10 commits
-
When the nvmem subsystem is not initialised at boot, the probe
will fail and an error message will be displayed.
In this case the message should not be printed as the driver will
be probed later.This patch checks the error code from nvmem before printing the
message.It also fixes the cleaning path as the driver was not exiting
properly.Signed-off-by: Franck LENORMAND
Reviewed-by: Iuliana Prodan -
It is better to re-init request list for EP0 when the EP0 begins to
uses.Reviewed-by: Jun Li
Signed-off-by: Peter Chen -
The new usb_gadget_disconnect API includes both calling class
driver's disconnect and calling .pullup at udc driver, so we
could simply your udc driver handling.Reviewed-by: Jun Li
Signed-off-by: Peter Chen -
We do not want to handle any interrupts after usb_gadget_disconnect
is called.Reviewed-by: Jun Li
Signed-off-by: Peter Chen -
Below is the recommendation from Cadence designer:
Using this bit to be sure that PHY clock is keeping up in active
state. It's good to keep Fast Access bit enabled as long as there
is any access to USB register.It is used to fix the potential ARM core hang when visit controller
register after DEVDS is set.Reviewed-by: Jun Li
Signed-off-by: Peter Chen -
And there are no multiple TRBs on EP0 and WA1 workaround,
so it doesn't need to change TRB for EP0. It fixes below oops.configfs-gadget gadget: high-speed config #1: b
android_work: sent uevent USB_STATE=CONFIGURED
Unable to handle kernel read from unreadable memory at virtual address 0000000000000008
Mem abort info:
android_work: sent uevent USB_STATE=DISCONNECTED
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b5bb7000
[0000000000000008] pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 430 Comm: HwBinder:401_1 Not tainted 5.4.24-06071-g6fa8921409c1-dirty #77
Hardware name: Freescale i.MX8QXP MEK (DT)
pstate: 60400085 (nZCv daIf +PAN -UAO)
pc : cdns3_gadget_ep_dequeue+0x1d4/0x270
lr : cdns3_gadget_ep_dequeue+0x48/0x270
sp : ffff800012763ba0
x29: ffff800012763ba0 x28: ffff00082c653c00
x27: 0000000000000000 x26: ffff000068fa7b00
x25: ffff0000699b2000 x24: ffff00082c6ac000
x23: ffff000834f0a480 x22: ffff000834e87b9c
x21: 0000000000000000 x20: ffff000834e87800
x19: ffff000069eddc00 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 0000000000000000
x13: 0000000000000000 x12: 0000000000000001
x11: ffff80001180fbe8 x10: 0000000000000001
x9 : ffff800012101558 x8 : 0000000000000001
x7 : 0000000000000006 x6 : ffff000835d9c668
x5 : ffff000834f0a4c8 x4 : 0000000096000000
x3 : 0000000000001810 x2 : 0000000000000000
x1 : ffff800024bd001c x0 : 0000000000000001
Call trace:
cdns3_gadget_ep_dequeue+0x1d4/0x270
usb_ep_dequeue+0x34/0xf8
composite_dev_cleanup+0x154/0x170
configfs_composite_unbind+0x6c/0xa8
usb_gadget_remove_driver+0x44/0x70
usb_gadget_unregister_driver+0x74/0xe0
unregister_gadget+0x28/0x58
gadget_dev_desc_UDC_store+0x80/0x110
configfs_write_file+0x1e0/0x2a0
__vfs_write+0x48/0x90
vfs_write+0xe4/0x1c8
ksys_write+0x78/0x100
__arm64_sys_write+0x24/0x30
el0_svc_common.constprop.0+0x74/0x168
el0_svc_handler+0x34/0xa0
el0_svc+0x8/0xc
Code: 52830203 b9407660 f94042e4 11000400 (b9400841)
---[ end trace 1574516e4c1772ca ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0002,20002008
Memory Limit: none
Rebooting in 5 seconds..Fixes: f616c3bda47e ("usb: cdns3: Fix dequeue implementation")
Cc: stable
Reviewed-by: Jun Li
Signed-off-by: Peter Chen -
Assign interrupt number to USB gadget structure.
Reviewed-by: Jun Li
Signed-off-by: Peter Chen -
The threaded interrupt handler may still be called after the
usb_gadget_disconnect is called, it causes the structures used
at interrupt handler was freed before it uses, eg the
usb_request. This issue usually occurs we remove the udc function
during the transfer. Below is the example when doing stress
test for android switch function, the EP0's request is freed
by .unbind (configfs_composite_unbind -> composite_dev_cleanup),
but the threaded handler accesses this request during handling
setup packet request.In fact, there is no protection between unbind the udc
and udc interrupt handling, so we have to avoid the interrupt
handler is occurred or scheduled during the .unbind flow.init: Sending signal 9 to service 'adbd' (pid 18077) process group...
android_work: did not send uevent (0 0 000000007bec2039)
libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 6ms
init: Service 'adbd' (pid 18077) received signal 9
init: Sending signal 9 to service 'adbd' (pid 18077) process group...
libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 0ms
init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:14)
init: Received control message 'start' for 'adbd' from pid: 399 (/vendor/bin/hw/android.hardware.usb@1.init: starting service 'adbd'...
read descriptors
read strings
Unable to handle kernel read from unreadable memory at virtual address 000000000000002a
android_work: sent uevent USB_STATE=CONNECTED
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e97f1000
using random self ethernet address
[000000000000002a] pgd=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 232 Comm: irq/68-5b110000 Not tainted 5.4.24-06075-g94a6b52b5815 #92
Hardware name: Freescale i.MX8QXP MEK (DT)
pstate: 00400085 (nzcv daIf +PAN -UAO)
using random host ethernet address
pc : composite_setup+0x5c/0x1730
lr : android_setup+0xc0/0x148
sp : ffff80001349bba0
x29: ffff80001349bba0 x28: ffff00083a50da00
x27: ffff8000124e6000 x26: ffff800010177950
x25: 0000000000000040 x24: ffff000834e18010
x23: 0000000000000000 x22: 0000000000000000
x21: ffff00083a50da00 x20: ffff00082e75ec40
x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 0000000000000000
x13: 0000000000000000 x12: 0000000000000001
x11: ffff80001180fb58 x10: 0000000000000040
x9 : ffff8000120fc980 x8 : 0000000000000000
x7 : ffff00083f98df50 x6 : 0000000000000100
x5 : 00000307e8978431 x4 : ffff800011386788
x3 : 0000000000000000 x2 : ffff800012342000
x1 : 0000000000000000 x0 : ffff800010c6d3a0
Call trace:
composite_setup+0x5c/0x1730
android_setup+0xc0/0x148
cdns3_ep0_delegate_req+0x64/0x90
cdns3_check_ep0_interrupt_proceed+0x384/0x738
cdns3_device_thread_irq_handler+0x124/0x6e0
cdns3_thread_irq+0x94/0xa0
irq_thread_fn+0x30/0xa0
irq_thread+0x150/0x248
kthread+0xfc/0x128
ret_from_fork+0x10/0x18
Code: 910e8000 f9400693 12001ed7 79400f79 (3940aa61)
---[ end trace c685db37f8773fba ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0002,20002008
Memory Limit: none
Rebooting in 5 seconds..Reviewed-by: Jun Li
Signed-off-by: Peter Chen -
As we use internal MPLL clocks instead of alternate clocks, so
disable alternate clock to save the PHY power when SS PHY at P3.Reviewed-by: Peter Chen
Signed-off-by: Li Jun
(cherry picked from commit ab62dd1d99480ef0a1266e213a95bb3afe4ded46) -
EP command will use suspend_clk(32K) if the SS PHY is at P3,
this slow clock makes EP command need more time to complete,
1000 times register read is not enough in this case, will
generate timeout like below:dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401]
params 00001000 00000500 00000000 --> status: Timed OutSuccess case takes about 400us to complete, see below trace
(44.286278 - 44.285897 = 0.000381s):configfs_acm.sh-822 [000] d..1 44.285896: dwc3_writel:
addr 000000006d59aae1 value 00000401
configfs_acm.sh-822 [000] d..1 44.285897: dwc3_readl:
addr 000000006d59aae1 value 00000401
... ...
configfs_acm.sh-822 [000] d..1 44.286278: dwc3_readl:
addr 000000006d59aae1 value 00000001
configfs_acm.sh-822 [000] d..1 44.286279: dwc3_gadget_ep_cmd:
ep0out: cmd 'Set Endpoint Configuration' [401]
params 00001000 00000500 00000000 --> status: SuccessfulReviewed-by: Peter Chen
Signed-off-by: Li Jun
(cherry picked from commit ed138303c1fcd87a30e0b37336b0d8993f4e5e38)
11 May, 2020
2 commits
-
Add SAI PLL frequencies.
Signed-off-by: Viorel Suman
(cherry picked from commit c9d58f88c800cd10e69dc605c20e83364f734f4d) -
IPC MU has no power domain assigned and there could be IPC
during noirq suspend phase, so IRQF_NO_SUSPEND flag is needed
for IPC MU. However, for other MUs, they have power domain
assigned and their power will be turned off during noirq suspend
phase, but their interrupts are NOT disabled even after their
power turned off, it will cause system crash when mailbox driver
trys to handle pending interrupts but the MU power is accidently
turned off.So, IRQF_NO_SUSPEND flag should ONLY be added to IPC MU which
has power domain managed by SCU, then all other MUs' pending
interrupts after noirq suspend phase will be handled after
system resume.Signed-off-by: Anson Huang
Reviewed-by: Peng Fan
(cherry picked from commit 02c7cf674c77d0ff60c123c5c98880d27d6b2c53)
09 May, 2020
1 commit
-
To ARM64, the alloc/free path is not aligned. So the free path
is not correct currently. It was designed for X86.This patch is not a mature fix, just a temp workaround to avoid
ARM64 dom0 panic.Acked-by: Alice Guo
Signed-off-by: Peng Fan
(cherry picked from commit bf7843fbbb4ea0f8590f00d255e16c0d05c57873)