media: imx8: mipi-csi: mxc-capture: merge in fix from NXP for wrong … #49
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…uffer sometimes being used on CSI restart which resulted in screen tearing Signed-off-by: Pat Kusbel <pat@kusbel.com>
|
Hi, |
|
it was on the NXP forum, have to see if we cvann find the link there |
gibsson
pushed a commit
that referenced
this pull request
May 1, 2020
…LAG_DETACH is set commit 8305f72 upstream. During system resume from suspend, this can be observed on ASM1062 PMP controller: ata10.01: SATA link down (SStatus 0 SControl 330) ata10.02: hard resetting link ata10.02: SATA link down (SStatus 0 SControl 330) ata10.00: configured for UDMA/133 Kernel panic - not syncing: stack-protector: Kernel in: sata_pmp_eh_recover+0xa2b/0xa40 CPU: 2 PID: 230 Comm: scsi_eh_9 Tainted: P OE #49-Ubuntu Hardware name: System manufacturer System Product 1001 12/10/2017 Call Trace: dump_stack+0x63/0x8b panic+0xe4/0x244 ? sata_pmp_eh_recover+0xa2b/0xa40 __stack_chk_fail+0x19/0x20 sata_pmp_eh_recover+0xa2b/0xa40 ? ahci_do_softreset+0x260/0x260 [libahci] ? ahci_do_hardreset+0x140/0x140 [libahci] ? ata_phys_link_offline+0x60/0x60 ? ahci_stop_engine+0xc0/0xc0 [libahci] sata_pmp_error_handler+0x22/0x30 ahci_error_handler+0x45/0x80 [libahci] ata_scsi_port_error_handler+0x29b/0x770 ? ata_scsi_cmd_error_handler+0x101/0x140 ata_scsi_error+0x95/0xd0 ? scsi_try_target_reset+0x90/0x90 scsi_error_handler+0xd0/0x5b0 kthread+0x121/0x140 ? scsi_eh_get_sense+0x200/0x200 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x40 Kernel Offset: 0xcc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Since sata_pmp_eh_recover_pmp() doens't set rc when ATA_DFLAG_DETACH is set, sata_pmp_eh_recover() continues to run. During retry it triggers the stack protector. Set correct rc in sata_pmp_eh_recover_pmp() to let sata_pmp_eh_recover() jump to pmp_fail directly. BugLink: https://bugs.launchpad.net/bugs/1821434 Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tkisky
pushed a commit
that referenced
this pull request
Feb 21, 2022
When FSPI running in octal ddr mode, it won't access the odd start address A, but to access the previous 2 byte aligned start address A-1, when access the nor chip via IPS. The code change fix the issue and tested with mt35xu512aba, which is 128K erase size and easy to trigger the issue when running UBIFS test. After enabled the OCTAL DDR mode for i.MX8DXL, found kernel dump during UBIFS bonnie++ test, at the step of mounting. the error logs are as followings: Volume ID 0, size 508 LEBs (66519552 bytes, 63.4 MiB), LEB size 130944 bytes (127.8 KiB), dynamic, name "test", alignment 1 [ 168.170373] UBIFS (ubi0:0): default file-system created [ 168.181626] UBIFS (ubi0:0): Mounting in unauthenticated mode [ 168.189532] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 387 [ 168.244961] UBIFS error (ubi0:0 pid 386): check_lpt_type.constprop.22: invalid type (4) in LPT node type 2 [ 168.254733] CPU: 0 PID: 386 Comm: mount Not tainted 5.10.72-01963-g6f6d787f2e3-dirty #49 [ 168.262826] Hardware name: Freescale i.MX8DXL EVK (DT) [ 168.267970] Call trace: [ 168.270427] dump_backtrace+0x0/0x1c0 [ 168.274097] show_stack+0x18/0x68 [ 168.277414] dump_stack+0xd8/0x134 [ 168.280822] check_lpt_type.constprop.22+0x58/0x60 [ 168.285614] ubifs_lpt_init+0x37c/0x558 [ 168.289456] ubifs_mount+0xee8/0x13b8 [ 168.293123] legacy_get_tree+0x30/0x60 [ 168.296874] vfs_get_tree+0x2c/0x118 [ 168.300455] path_mount+0x744/0x9b0 [ 168.303944] do_mount+0x9c/0xb8 [ 168.307090] __arm64_sys_mount+0x12c/0x2a0 [ 168.311194] el0_svc_common.constprop.4+0x68/0x188 [ 168.315987] do_el0_svc+0x24/0x90 [ 168.319307] el0_svc+0x14/0x20 [ 168.322364] el0_sync_handler+0x90/0xb8 [ 168.326203] el0_sync+0x160/0x180 [ 168.330403] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops mount: /home/root/tmp: wrong fs type, bad option, bad superblock on ubi0:test, missing codepage or helper program, or other er. After debugging the UBIFS lpt code, found it accesses the nor chip from an odd address, such as address A, but FSPI controller force to read from 2 byte aligned address A-1, so it can't read the correct data and causes UBIFS mount failed. This should be a common issue but not found on i.MX8ULP, becuase the ubifs_info pnode_sz is an even number due to the chip mounted on i.MX8ULP is a 64K erase size macronix nor chip, the 128K erase size micron nor chip on i.MX8DXL can easily trigger the issue. The code change can fix the read on odd address issue but it's still a workaround. There are some cases can NOT be fixed, theoretically. For instance, read CR register in OCTAL DTR mode with odd address. Since the nor chip can only outputs the same bytes repeatedly when continuously read, so there is no SW workaround, but we haven't seen any real cases till now. Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
tkisky
pushed a commit
that referenced
this pull request
Mar 18, 2022
When FSPI running in octal ddr mode, it won't access the odd start address A, but to access the previous 2 byte aligned start address A-1, when access the nor chip via IPS. The code change fix the issue and tested with mt35xu512aba, which is 128K erase size and easy to trigger the issue when running UBIFS test. After enabled the OCTAL DDR mode for i.MX8DXL, found kernel dump during UBIFS bonnie++ test, at the step of mounting. the error logs are as followings: Volume ID 0, size 508 LEBs (66519552 bytes, 63.4 MiB), LEB size 130944 bytes (127.8 KiB), dynamic, name "test", alignment 1 [ 168.170373] UBIFS (ubi0:0): default file-system created [ 168.181626] UBIFS (ubi0:0): Mounting in unauthenticated mode [ 168.189532] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 387 [ 168.244961] UBIFS error (ubi0:0 pid 386): check_lpt_type.constprop.22: invalid type (4) in LPT node type 2 [ 168.254733] CPU: 0 PID: 386 Comm: mount Not tainted 5.10.72-01963-g6f6d787f2e3-dirty #49 [ 168.262826] Hardware name: Freescale i.MX8DXL EVK (DT) [ 168.267970] Call trace: [ 168.270427] dump_backtrace+0x0/0x1c0 [ 168.274097] show_stack+0x18/0x68 [ 168.277414] dump_stack+0xd8/0x134 [ 168.280822] check_lpt_type.constprop.22+0x58/0x60 [ 168.285614] ubifs_lpt_init+0x37c/0x558 [ 168.289456] ubifs_mount+0xee8/0x13b8 [ 168.293123] legacy_get_tree+0x30/0x60 [ 168.296874] vfs_get_tree+0x2c/0x118 [ 168.300455] path_mount+0x744/0x9b0 [ 168.303944] do_mount+0x9c/0xb8 [ 168.307090] __arm64_sys_mount+0x12c/0x2a0 [ 168.311194] el0_svc_common.constprop.4+0x68/0x188 [ 168.315987] do_el0_svc+0x24/0x90 [ 168.319307] el0_svc+0x14/0x20 [ 168.322364] el0_sync_handler+0x90/0xb8 [ 168.326203] el0_sync+0x160/0x180 [ 168.330403] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops mount: /home/root/tmp: wrong fs type, bad option, bad superblock on ubi0:test, missing codepage or helper program, or other er. After debugging the UBIFS lpt code, found it accesses the nor chip from an odd address, such as address A, but FSPI controller force to read from 2 byte aligned address A-1, so it can't read the correct data and causes UBIFS mount failed. This should be a common issue but not found on i.MX8ULP, becuase the ubifs_info pnode_sz is an even number due to the chip mounted on i.MX8ULP is a 64K erase size macronix nor chip, the 128K erase size micron nor chip on i.MX8DXL can easily trigger the issue. The code change can fix the read on odd address issue but it's still a workaround. There are some cases can NOT be fixed, theoretically. For instance, read CR register in OCTAL DTR mode with odd address. Since the nor chip can only outputs the same bytes repeatedly when continuously read, so there is no SW workaround, but we haven't seen any real cases till now. Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes issue where screen tearing occurs and the video buffer is misaligned with the screen resulting in the image wrapping around. Caused by wrong buffer being used when csi restarted such as when resolution was changed.
Signed-off-by: Pat Kusbel pat@kusbel.com