Introduce scmi-pinctrl driver support #3
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
oleksiimoisieiev
changed the base branch from
v4.14.75-ltsi/rcar-3.9.11
to
v5.10/rcar-5.0.0.rc5
oleksiimoisieiev
force-pushed
the
pinctrl_scmi_pr_github
branch
2 times, most recently
from
716b15f
to
85e3a83
Compare
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 <[email protected]>
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 <[email protected]>
oleksiimoisieiev
force-pushed
the
pinctrl_scmi_pr_github
branch
from
85e3a83
to
dcf1a44
Compare
oleksiimoisieiev
changed the base branch from
v5.10/rcar-5.0.0.rc5
to
v5.10.41/rcar-5.1.4.rc3
oleksiimoisieiev
changed the title
hoailuu
pushed a commit
that referenced
this pull request
May 24, 2022
…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 <[email protected]>
Signed-off-by: Hoang Vo <[email protected]>
NguyenBNguyen
pushed a commit
that referenced
this pull request
Dec 15, 2023
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 <[email protected]>
Signed-off-by: Nguyen Bao Nguyen <[email protected]>
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.
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:
using the following command:
set CONFIG_PINCTRL_SCMI=y in your .config
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.