Introduce scmi-pinctrl driver support by oleksiimoisieiev · Pull Request #3 · renesas-rcar/linux-bsp

oleksiimoisieiev · 2021-11-29T18:55:30Z

This merge request was marked as Draft because SCMI protocol is still under the discussion. We proposed pinctrl as separate SCMI protocol to Arm, because it is also the system management function, it's currently under review.

The main idea of the feature is to separate HW configuration from the OS level and move it to AT-F. This gives a big advantages for virtualized systems, when different set of pins should be assigned to the different OS. In this case, actual sets of pins could be passed to different OS, which has registered scmi-pinctrl clients and requests AT-F to do any HW changes.

This is the implementation of the scmi-pinctrl driver for linux-bsp, which is SCMI client, using SCMI protocol to pass through pin control subsystem commands to AT-F which performs all operations with HW.

scmi-pinctrl driver configuration is done in the device-tree. In terms of the current MR, the configuration examples were provided for Renesas H3ULCB platform on r8a77951. All additional information about the configuration can be get from Documentation/devicetree/bindings/pinctrl/renesas-scmi,pfc.yaml.

This can be tested using the follwoing scenario:

Build AT-F, which implements pinctrl feature from Introduce the Renesas H3ULCB r8a77951 pinctrl driver with SCMI interface arm-trusted-firmware#19
using the following command:

make -j17
ARCH=aarch64
CROSS_COMPILE=aarch64-linux-gnu-
CC=aarch64-linux-gnu-gcc
PLAT=rcar
MBEDTLS_COMMON_MK=1
LSI=H3
LOG_LEVEL=40
RCAR_DRAM_SPLIT=1
RCAR_GEN3_ULCB=1
PMIC_LEVEL_MODE=0
RCAR_DRAM_LPDDR4_MEMCONF=1
RCAR_LOSSY_ENABLE=1
RCAR_BL33_EXECUTION_EL=1
RCAR_RPC_HYPERFLASH_LOCKED=0
DEBUG=1
SPD=opteed
RCAR_SCMI_PLATFORM=1
bl2 bl31 rcar

Build linux-bsp kernel using command:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j $(nproc) O=../test-build

set CONFIG_PINCTRL_SCMI=y in your .config

Update device-tree using the following mappings:

Documentation/devicetree/bindings/pinctrl/renesas-scmi,pfc.yaml
move pins configuration from pinctrl to pinctrl-scmi driver node.

Upload bl2.bin and bl31.bin to the board and boot using linux-bsp kernel and the device-tree from the previous steps.
This setup will redirect the pin control subsystem requests from the kernel to AT-F.
Check if the devices works properly.

Implementation of the SCMI client driver, which implements PINCTRL_PROTOCOL. This protocol has id 18 and described in DEN0056C document. This protocol is the part of the feature that was designed to separate pinctrl subsystem to SCP firmware. The idea is to separate communication of the pin control subsystemd with the HW to SCP firmware (or similar system, such as ATF), which provides interface to give OS ability to control HW through SCMI protocol. This is generic driver, which implements SCMI protocol, independent from the platform type. DEN0056C document: https://developer.arm.com/documentation/den0056/latest Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>

scmi-pinctrl driver implements pinctrl driver interface and using SCMI protocol to redirect messages from pinctrl subsystem SDK to SCP firmware, which does the changes in HW. This setup expects SCP firmware (or similar system, such as ATF) to be installed on the platform, which implements pinctrl driver for the specific platform. SCMI-Pinctrl driver should be configured from the device-tree. The following binding shows the configuration for Renesas H3ULCB for r8a77951 as an example: Documentation/devicetree/bindings/renesas-scmi,pfc.yaml Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>

…adlock This patch fixes deadlock warning in removing/rescanning through sysfs when CONFIG_PROVE_LOCKING is enabled. The issue can be reproduced by these steps: 1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig 2. Insert Ethernet card into PCIe CH0 and start up. After kernel starting up, execute the following command. echo 1 > /sys/class/pci_bus/0000\:00/device/0000\:00\:00.0/remove 3. Rescan PCI device by this command echo 1 > /sys/class/pci_bus/0000\:00/bus_rescan The deadlock warnings will occur. ============================================ WARNING: possible recursive locking detected 4.14.70-ltsi-yocto-standard #27 Not tainted -------------------------------------------- sh/3402 is trying to acquire lock: (kn->count#78){++++}, at: kernfs_remove_by_name_ns+0x50/0xa8 but task is already holding lock: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(kn->count#78); lock(kn->count#78); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by sh/3402: #0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0 #1: (&of->mutex){+.+.}, at: kernfs_fop_write+0x108/0x210 #2: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 #3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28 stack backtrace: CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27 Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES3.0+ with 8GiB (4 x 2 GiB) (DT) Call trace: dump_backtrace+0x0/0x3d8 show_stack+0x14/0x20 dump_stack+0xbc/0xf4 __lock_acquire+0x930/0x18a8 lock_acquire+0x48/0x68 __kernfs_remove+0x280/0x2f8 kernfs_remove_by_name_ns+0x50/0xa8 remove_files.isra.0+0x38/0x78 sysfs_remove_group+0x4c/0xa0 sysfs_remove_groups+0x38/0x60 device_remove_attrs+0x54/0x78 device_del+0x1ac/0x308 pci_remove_bus_device+0x78/0xf8 pci_remove_bus_device+0x34/0xf8 pci_stop_and_remove_bus_device_locked+0x24/0x38 remove_store+0x6c/0x78 dev_attr_store+0x18/0x28 sysfs_kf_write+0x4c/0x78 kernfs_fop_write+0x138/0x210 __vfs_write+0x18/0x118 vfs_write+0xa4/0x1b0 SyS_write+0x48/0xb0 This warning occurs due to a self-deletion attribute using in the sysfs PCI device directory. This kind of attribute is really tricky, it does not allow pci framework drop this attribute until all active .show() and .store() callbacks have finished unless sysfs_break_active_protection() is called. Hence this patch avoids writing into this attribute triggers a deadlock. Referrence commit 5b55b24 ("scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock") of scsi driver Signed-off-by: Tho Vu <tho.vu.wh@renesas.com> Signed-off-by: Hoang Vo <hoang.vo.eb@renesas.com>

The thread of R-Car OP-TEE driver waits for RPC debug log command from OP-TEE, with wait_event (i.e. in TASK_UNINTERRUPTIBLE state). In case OP-TEE does't output the debug log for a long time, a hung task warning occurs when CONFIG_DETECT_HUNG_TASK is set: INFO: task optee_debug_log:1855 blocked for more than 120 seconds. Tainted: G O 4.14.75-ltsi-yocto-standard #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. optee_debug_log D 0 1855 2 0x00000020 Call trace: [<ffff000008085cf4>] __switch_to+0x94/0xd8 [<ffff000008b247c4>] __schedule+0x1c4/0x710 [<ffff000008b24d48>] schedule+0x38/0xa0 [<ffff0000089cfcfc>] debug_log_kthread+0xc4/0x130 [<ffff0000080eef2c>] kthread+0x12c/0x130 [<ffff000008084ed8>] ret_from_fork+0x10/0x18 This patch changes to wait in TASK_INTERRUPTIBLE state to solve a hung task warning. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Nguyen Bao Nguyen <nguyen.nguyen.yj@renesas.com>

…adlock This patch fixes deadlock warning in removing/rescanning through sysfs when CONFIG_PROVE_LOCKING is enabled. The issue can be reproduced by these steps: 1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig 2. Insert Ethernet card into PCIe CH0 and start up. After kernel starting up, execute the following command. echo 1 > /sys/class/pci_bus/0000\:00/device/0000\:00\:00.0/remove 3. Rescan PCI device by this command echo 1 > /sys/class/pci_bus/0000\:00/bus_rescan The deadlock warnings will occur. ============================================ WARNING: possible recursive locking detected 4.14.70-ltsi-yocto-standard #27 Not tainted -------------------------------------------- sh/3402 is trying to acquire lock: (kn->count#78){++++}, at: kernfs_remove_by_name_ns+0x50/0xa8 but task is already holding lock: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(kn->count#78); lock(kn->count#78); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by sh/3402: #0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0 #1: (&of->mutex){+.+.}, at: kernfs_fop_write+0x108/0x210 #2: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 #3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28 stack backtrace: CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27 Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES3.0+ with 8GiB (4 x 2 GiB) (DT) Call trace: dump_backtrace+0x0/0x3d8 show_stack+0x14/0x20 dump_stack+0xbc/0xf4 __lock_acquire+0x930/0x18a8 lock_acquire+0x48/0x68 __kernfs_remove+0x280/0x2f8 kernfs_remove_by_name_ns+0x50/0xa8 remove_files.isra.0+0x38/0x78 sysfs_remove_group+0x4c/0xa0 sysfs_remove_groups+0x38/0x60 device_remove_attrs+0x54/0x78 device_del+0x1ac/0x308 pci_remove_bus_device+0x78/0xf8 pci_remove_bus_device+0x34/0xf8 pci_stop_and_remove_bus_device_locked+0x24/0x38 remove_store+0x6c/0x78 dev_attr_store+0x18/0x28 sysfs_kf_write+0x4c/0x78 kernfs_fop_write+0x138/0x210 __vfs_write+0x18/0x118 vfs_write+0xa4/0x1b0 SyS_write+0x48/0xb0 This warning occurs due to a self-deletion attribute using in the sysfs PCI device directory. This kind of attribute is really tricky, it does not allow pci framework drop this attribute until all active .show() and .store() callbacks have finished unless sysfs_break_active_protection() is called. Hence this patch avoids writing into this attribute triggers a deadlock. Referrence commit 5b55b24 ("scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock") of scsi driver Signed-off-by: Tho Vu <tho.vu.wh@renesas.com> Signed-off-by: Hoang Vo <hoang.vo.eb@renesas.com>

The thread of R-Car OP-TEE driver waits for RPC debug log command from OP-TEE, with wait_event (i.e. in TASK_UNINTERRUPTIBLE state). In case OP-TEE does't output the debug log for a long time, a hung task warning occurs when CONFIG_DETECT_HUNG_TASK is set: INFO: task optee_debug_log:1855 blocked for more than 120 seconds. Tainted: G O 4.14.75-ltsi-yocto-standard #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. optee_debug_log D 0 1855 2 0x00000020 Call trace: [<ffff000008085cf4>] __switch_to+0x94/0xd8 [<ffff000008b247c4>] __schedule+0x1c4/0x710 [<ffff000008b24d48>] schedule+0x38/0xa0 [<ffff0000089cfcfc>] debug_log_kthread+0xc4/0x130 [<ffff0000080eef2c>] kthread+0x12c/0x130 [<ffff000008084ed8>] ret_from_fork+0x10/0x18 This patch changes to wait in TASK_INTERRUPTIBLE state to solve a hung task warning. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>

…adlock This patch fixes deadlock warning in removing/rescanning through sysfs when CONFIG_PROVE_LOCKING is enabled. The issue can be reproduced by these steps: 1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig 2. Insert Ethernet card into PCIe CH0 and start up. After kernel starting up, execute the following command. echo 1 > /sys/class/pci_bus/0000\:00/device/0000\:00\:00.0/remove 3. Rescan PCI device by this command echo 1 > /sys/class/pci_bus/0000\:00/bus_rescan The deadlock warnings will occur. ============================================ WARNING: possible recursive locking detected 4.14.70-ltsi-yocto-standard #27 Not tainted -------------------------------------------- sh/3402 is trying to acquire lock: (kn->count#78){++++}, at: kernfs_remove_by_name_ns+0x50/0xa8 but task is already holding lock: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(kn->count#78); lock(kn->count#78); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by sh/3402: #0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0 #1: (&of->mutex){+.+.}, at: kernfs_fop_write+0x108/0x210 #2: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 #3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28 stack backtrace: CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27 Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES3.0+ with 8GiB (4 x 2 GiB) (DT) Call trace: dump_backtrace+0x0/0x3d8 show_stack+0x14/0x20 dump_stack+0xbc/0xf4 __lock_acquire+0x930/0x18a8 lock_acquire+0x48/0x68 __kernfs_remove+0x280/0x2f8 kernfs_remove_by_name_ns+0x50/0xa8 remove_files.isra.0+0x38/0x78 sysfs_remove_group+0x4c/0xa0 sysfs_remove_groups+0x38/0x60 device_remove_attrs+0x54/0x78 device_del+0x1ac/0x308 pci_remove_bus_device+0x78/0xf8 pci_remove_bus_device+0x34/0xf8 pci_stop_and_remove_bus_device_locked+0x24/0x38 remove_store+0x6c/0x78 dev_attr_store+0x18/0x28 sysfs_kf_write+0x4c/0x78 kernfs_fop_write+0x138/0x210 __vfs_write+0x18/0x118 vfs_write+0xa4/0x1b0 SyS_write+0x48/0xb0 This warning occurs due to a self-deletion attribute using in the sysfs PCI device directory. This kind of attribute is really tricky, it does not allow pci framework drop this attribute until all active .show() and .store() callbacks have finished unless sysfs_break_active_protection() is called. Hence this patch avoids writing into this attribute triggers a deadlock. Referrence commit 5b55b24 ("scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock") of scsi driver Signed-off-by: Tho Vu <tho.vu.wh@renesas.com> Signed-off-by: Hoang Vo <hoang.vo.eb@renesas.com>

The thread of R-Car OP-TEE driver waits for RPC debug log command from OP-TEE, with wait_event (i.e. in TASK_UNINTERRUPTIBLE state). In case OP-TEE does't output the debug log for a long time, a hung task warning occurs when CONFIG_DETECT_HUNG_TASK is set: INFO: task optee_debug_log:1855 blocked for more than 120 seconds. Tainted: G O 4.14.75-ltsi-yocto-standard #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. optee_debug_log D 0 1855 2 0x00000020 Call trace: [<ffff000008085cf4>] __switch_to+0x94/0xd8 [<ffff000008b247c4>] __schedule+0x1c4/0x710 [<ffff000008b24d48>] schedule+0x38/0xa0 [<ffff0000089cfcfc>] debug_log_kthread+0xc4/0x130 [<ffff0000080eef2c>] kthread+0x12c/0x130 [<ffff000008084ed8>] ret_from_fork+0x10/0x18 This patch changes to wait in TASK_INTERRUPTIBLE state to solve a hung task warning. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>

…adlock This patch fixes deadlock warning in removing/rescanning through sysfs when CONFIG_PROVE_LOCKING is enabled. The issue can be reproduced by these steps: 1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig 2. Insert Ethernet card into PCIe CH0 and start up. After kernel starting up, execute the following command. echo 1 > /sys/class/pci_bus/0000\:00/device/0000\:00\:00.0/remove 3. Rescan PCI device by this command echo 1 > /sys/class/pci_bus/0000\:00/bus_rescan The deadlock warnings will occur. ============================================ WARNING: possible recursive locking detected 4.14.70-ltsi-yocto-standard #27 Not tainted -------------------------------------------- sh/3402 is trying to acquire lock: (kn->count#78){++++}, at: kernfs_remove_by_name_ns+0x50/0xa8 but task is already holding lock: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(kn->count#78); lock(kn->count#78); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by sh/3402: #0: (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0 #1: (&of->mutex){+.+.}, at: kernfs_fop_write+0x108/0x210 #2: (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130 #3: (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28 stack backtrace: CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27 Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES3.0+ with 8GiB (4 x 2 GiB) (DT) Call trace: dump_backtrace+0x0/0x3d8 show_stack+0x14/0x20 dump_stack+0xbc/0xf4 __lock_acquire+0x930/0x18a8 lock_acquire+0x48/0x68 __kernfs_remove+0x280/0x2f8 kernfs_remove_by_name_ns+0x50/0xa8 remove_files.isra.0+0x38/0x78 sysfs_remove_group+0x4c/0xa0 sysfs_remove_groups+0x38/0x60 device_remove_attrs+0x54/0x78 device_del+0x1ac/0x308 pci_remove_bus_device+0x78/0xf8 pci_remove_bus_device+0x34/0xf8 pci_stop_and_remove_bus_device_locked+0x24/0x38 remove_store+0x6c/0x78 dev_attr_store+0x18/0x28 sysfs_kf_write+0x4c/0x78 kernfs_fop_write+0x138/0x210 __vfs_write+0x18/0x118 vfs_write+0xa4/0x1b0 SyS_write+0x48/0xb0 This warning occurs due to a self-deletion attribute using in the sysfs PCI device directory. This kind of attribute is really tricky, it does not allow pci framework drop this attribute until all active .show() and .store() callbacks have finished unless sysfs_break_active_protection() is called. Hence this patch avoids writing into this attribute triggers a deadlock. Referrence commit 5b55b24 ("scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock") of scsi driver Signed-off-by: Tho Vu <tho.vu.wh@renesas.com> Signed-off-by: Hoang Vo <hoang.vo.eb@renesas.com> Signed-off-by: Tin Tran <tin.tran.xk@renesas.com>

The thread of R-Car OP-TEE driver waits for RPC debug log command from OP-TEE, with wait_event (i.e. in TASK_UNINTERRUPTIBLE state). In case OP-TEE does't output the debug log for a long time, a hung task warning occurs when CONFIG_DETECT_HUNG_TASK is set: INFO: task optee_debug_log:1855 blocked for more than 120 seconds. Tainted: G O 4.14.75-ltsi-yocto-standard #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. optee_debug_log D 0 1855 2 0x00000020 Call trace: [<ffff000008085cf4>] __switch_to+0x94/0xd8 [<ffff000008b247c4>] __schedule+0x1c4/0x710 [<ffff000008b24d48>] schedule+0x38/0xa0 [<ffff0000089cfcfc>] debug_log_kthread+0xc4/0x130 [<ffff0000080eef2c>] kthread+0x12c/0x130 [<ffff000008084ed8>] ret_from_fork+0x10/0x18 This patch changes to wait in TASK_INTERRUPTIBLE state to solve a hung task warning. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Anh Vo <anh.vo.vx@renesas.com>

commit f02c41f87cfe61440c18bf77d1ef0a884b9ee2b5 upstream. Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access. [ 4.239592] ============================= [ 4.239595] [ BUG: Invalid wait context ] [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted [ 4.239603] ----------------------------- [ 4.239606] kworker/u8:5/76 is trying to lock: [ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.239641] other info that might help us debug this: [ 4.239643] context-{5:5} [ 4.239646] 5 locks held by kworker/u8:5/76: [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value. [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c [ 4.254109] #2: ffff00000920c8f8 [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value. [ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690 [ 4.264840] #4: [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value. [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690 [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz [ 4.304082] stack backtrace: [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 4.304097] Workqueue: async async_run_entry_fn [ 4.304106] Call trace: [ 4.304110] show_stack+0x14/0x20 (C) [ 4.304122] dump_stack_lvl+0x6c/0x90 [ 4.304131] dump_stack+0x14/0x1c [ 4.304138] __lock_acquire+0xdfc/0x1584 [ 4.426274] lock_acquire+0x1c4/0x33c [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 [ 4.444422] __irq_set_trigger+0x5c/0x178 [ 4.448435] __setup_irq+0x2e4/0x690 [ 4.452012] request_threaded_irq+0xc4/0x190 [ 4.456285] devm_request_threaded_irq+0x7c/0xf4 [ 4.459398] ata1: link resume succeeded after 1 retries [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0 [ 4.470660] mmc_start_host+0x50/0xac [ 4.474327] mmc_add_host+0x80/0xe4 [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440 [ 4.482094] renesas_sdhi_probe+0x488/0x6f4 [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78 [ 4.491509] platform_probe+0x64/0xd8 [ 4.495178] really_probe+0xb8/0x2a8 [ 4.498756] __driver_probe_device+0x74/0x118 [ 4.503116] driver_probe_device+0x3c/0x154 [ 4.507303] __device_attach_driver+0xd4/0x160 [ 4.511750] bus_for_each_drv+0x84/0xe0 [ 4.515588] __device_attach_async_helper+0xb0/0xdc [ 4.520470] async_run_entry_fn+0x30/0xd8 [ 4.524481] process_one_work+0x210/0x62c [ 4.528494] worker_thread+0x1ac/0x340 [ 4.532245] kthread+0x10c/0x110 [ 4.535476] ret_from_fork+0x10/0x20 Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250121135833.3769310-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Huy Bui <huy.bui.pz@bp.renesas.com>

The thread of R-Car OP-TEE driver waits for RPC debug log command from OP-TEE, with wait_event (i.e. in TASK_UNINTERRUPTIBLE state). In case OP-TEE does't output the debug log for a long time, a hung task warning occurs when CONFIG_DETECT_HUNG_TASK is set: INFO: task optee_debug_log:1855 blocked for more than 120 seconds. Tainted: G O 4.14.75-ltsi-yocto-standard #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. optee_debug_log D 0 1855 2 0x00000020 Call trace: [<ffff000008085cf4>] __switch_to+0x94/0xd8 [<ffff000008b247c4>] __schedule+0x1c4/0x710 [<ffff000008b24d48>] schedule+0x38/0xa0 [<ffff0000089cfcfc>] debug_log_kthread+0xc4/0x130 [<ffff0000080eef2c>] kthread+0x12c/0x130 [<ffff000008084ed8>] ret_from_fork+0x10/0x18 This patch changes to wait in TASK_INTERRUPTIBLE state to solve a hung task warning. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Nhi Nguyen <nhi.nguyen.kx@renesas.com>

The thread of R-Car OP-TEE driver waits for RPC debug log command from OP-TEE, with wait_event (i.e. in TASK_UNINTERRUPTIBLE state). In case OP-TEE does't output the debug log for a long time, a hung task warning occurs when CONFIG_DETECT_HUNG_TASK is set: INFO: task optee_debug_log:1855 blocked for more than 120 seconds. Tainted: G O 4.14.75-ltsi-yocto-standard #3 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. optee_debug_log D 0 1855 2 0x00000020 Call trace: [<ffff000008085cf4>] __switch_to+0x94/0xd8 [<ffff000008b247c4>] __schedule+0x1c4/0x710 [<ffff000008b24d48>] schedule+0x38/0xa0 [<ffff0000089cfcfc>] debug_log_kthread+0xc4/0x130 [<ffff0000080eef2c>] kthread+0x12c/0x130 [<ffff000008084ed8>] ret_from_fork+0x10/0x18 This patch changes to wait in TASK_INTERRUPTIBLE state to solve a hung task warning. Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by: Anh Vo <anh.vo.vx@renesas.com>

oleksiimoisieiev changed the base branch from v4.14.75-ltsi/rcar-3.9.11 to v5.10/rcar-5.0.0.rc5 November 29, 2021 18:57

oleksiimoisieiev force-pushed the pinctrl_scmi_pr_github branch 2 times, most recently from 716b15f to 85e3a83 Compare December 1, 2021 09:21

oleksiimoisieiev added 2 commits December 1, 2021 16:33

oleksiimoisieiev force-pushed the pinctrl_scmi_pr_github branch from 85e3a83 to dcf1a44 Compare December 1, 2021 14:34

oleksiimoisieiev changed the base branch from v5.10/rcar-5.0.0.rc5 to v5.10.41/rcar-5.1.4.rc3 December 1, 2021 14:53

oleksiimoisieiev changed the title ~~Introducing pinctrl driver via SCMI~~ Introduce scmi-pinctrl driver support Dec 1, 2021

oleksiimoisieiev marked this pull request as draft December 1, 2021 14:54

oleksiimoisieiev mentioned this pull request Dec 1, 2021

Introduce the Renesas H3ULCB r8a77951 pinctrl driver with SCMI interface renesas-rcar/arm-trusted-firmware#19

Draft

firscity referenced this pull request in firscity/linux-bsp Mar 8, 2022

porting of patch #3

b8b7382

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce scmi-pinctrl driver support#3

Introduce scmi-pinctrl driver support#3
oleksiimoisieiev wants to merge 2 commits intorenesas-rcar:v5.10.41/rcar-5.1.4.rc3from
oleksiimoisieiev:pinctrl_scmi_pr_github

oleksiimoisieiev commented Nov 29, 2021 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

oleksiimoisieiev commented Nov 29, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

oleksiimoisieiev commented Nov 29, 2021 •

edited

Loading