[PATCH v2 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs

2024-04-24 Thread Beleswar Padhi
shutting down before core1 has been shut down from sysfs. Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 23 +-- 1 file changed, 21 insertions(+), 2

[PATCH v2 1/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1

2024-04-24 Thread Beleswar Padhi
From: Apurva Nandan PSC controller has a limitation that it can only power-up the second core when the first core is in ON state. Power-state for core0 should be equal to or higher than core1, else the kernel is seen hanging during rproc loading. Make the powering up of cores sequential, by

[PATCH v2 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1

2024-04-24 Thread Beleswar Padhi
/all/20230906124756.3480579-1-a-nan...@ti.com/ Apurva Nandan (1): remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi (1): remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs drivers/remoteproc/ti_k3_r5_remoteproc.c | 51

[PATCH v3 0/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1

2024-04-30 Thread Beleswar Padhi
): remoteproc: k3-r5: Wait for core0 power-up before powering up core1 Beleswar Padhi (1): remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs drivers/remoteproc/ti_k3_r5_remoteproc.c | 56 +++- 1 file changed, 54 insertions(+), 2 deletions

[PATCH v3 1/2] remoteproc: k3-r5: Wait for core0 power-up before powering up core1

2024-04-30 Thread Beleswar Padhi
: Add a remoteproc driver for R5F subsystem") Signed-off-by: Apurva Nandan [added comments and fixed code style] Signed-off-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 33 1 file changed, 33 insertions(+) diff --git a/drivers/

[PATCH v3 2/2] remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs

2024-04-30 Thread Beleswar Padhi
shutting down before core1 has been shut down from sysfs. Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 23 +-- 1 file changed, 21 insertions(+), 2

[PATCH] remoteproc: k3-r5: Jump to error handling labels in start/stop errors

2024-05-06 Thread Beleswar Padhi
to return with required -EPERM error code during the core stop operation from sysfs. Fixes: 3c8a9066d584 ("remoteproc: k3-r5: Do not allow core1 to power up before core0 via sysfs") Signed-off-by: Beleswar Padhi --- As stated in the bug-report[0], Smatch complains that: drivers/

[PATCH 0/3] Defer TI's Remoteproc's Probe until Mailbox is Probed

2024-05-30 Thread Beleswar Padhi
. This makes our k3_rproc_attach() & k3_rproc_detach() functions NOP. Also, use the devm_rproc_alloc() helper to automatically free created rprocs incase of a probe defer. Beleswar Padhi (3): remoteproc: k3-r5: Use devm_rproc_alloc() helper remoteproc: k3-r5: Acquire mailbox handle during p

[PATCH 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe

2024-05-30 Thread Beleswar Padhi
-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 66 1 file changed, 21 insertions(+), 45 deletions(-) diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c index 26362a509ae3..157e8fd57665 100644 --- a/drivers

[PATCH 3/3] remoteproc: k3-dsp: Acquire mailbox handle during probe routine

2024-05-30 Thread Beleswar Padhi
-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_dsp_remoteproc.c | 67 +++ 1 file changed, 21 insertions(+), 46 deletions(-) diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c index 3555b535b168..88cda609a5eb 100644 --- a/drivers

[PATCH 1/3] remoteproc: k3-r5: Use devm_rproc_alloc() helper

2024-05-30 Thread Beleswar Padhi
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 6 ++ 1 file changed, 2 insertions(+), 4

[PATCH v2 2/3] remoteproc: k3-r5: Acquire mailbox handle during probe

2024-06-03 Thread Beleswar Padhi
-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 74 +--- 1 file changed, 26 insertions(+), 48 deletions(-) diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c index 26362a509ae3c..7e02e3472ce25 100644 --- a/drivers

[PATCH v2 3/3] remoteproc: k3-dsp: Acquire mailbox handle during probe routine

2024-06-03 Thread Beleswar Padhi
-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_dsp_remoteproc.c | 76 --- 1 file changed, 26 insertions(+), 50 deletions(-) diff --git a/drivers/remoteproc/ti_k3_dsp_remoteproc.c b/drivers/remoteproc/ti_k3_dsp_remoteproc.c index 3555b535b1683..edaa5e91aebe9 100644 --- a/drivers

[PATCH v2 0/3] Defer TI's Remoteproc's Probe until Mailbox is Probed

2024-06-03 Thread Beleswar Padhi
ew's comments in v1 regarding some cleanup (Using dev_err_probe, removing unused labels, adding matching mbox_free_channel call during device removal). Link to v1: https://lore.kernel.org/all/20240530090737.655054-1-b-pa...@ti.com/ Beleswar Padhi (3): remoteproc: k3-r5: Use devm_rproc_alloc() he

[PATCH v2 1/3] remoteproc: k3-r5: Use devm_rproc_alloc() helper

2024-06-03 Thread Beleswar Padhi
Use the device lifecycle managed allocation function. This helps prevent mistakes like freeing out of order in cleanup functions and forgetting to free on error paths. Signed-off-by: Beleswar Padhi --- drivers/remoteproc/ti_k3_r5_remoteproc.c | 6 ++ 1 file changed, 2 insertions(+), 4