[PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Marco Crivellari]

Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistency cannot be addressed without refactoring the API.

This patch continues the effort to refactor worqueue APIs, which has begun
with the change introducing new workqueues:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")

system_dfl_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.

The old system_unbound_wq will be kept for a few release cycles.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
index b7d278b3889f..da6a725e4fbe 100644
--- a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
+++ b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
@@ -1735,7 +1735,7 @@ static void process_signal_change(struct snps_hdmirx_dev *hdmirx_dev)
 			   FIFO_UNDERFLOW_INT_EN |
 			   HDMIRX_AXI_ERROR_INT_EN, 0);
 	hdmirx_reset_dma(hdmirx_dev);
-	queue_delayed_work(system_unbound_wq,
+	queue_delayed_work(system_dfl_wq,
 			   &hdmirx_dev->delayed_work_res_change,
 			   msecs_to_jiffies(50));
 }
@@ -2190,7 +2190,7 @@ static void hdmirx_delayed_work_res_change(struct work_struct *work)
 
 		if (hdmirx_wait_signal_lock(hdmirx_dev)) {
 			hdmirx_plugout(hdmirx_dev);
-			queue_delayed_work(system_unbound_wq,
+			queue_delayed_work(system_dfl_wq,
 					   &hdmirx_dev->delayed_work_hotplug,
 					   msecs_to_jiffies(200));
 		} else {
@@ -2209,7 +2209,7 @@ static irqreturn_t hdmirx_5v_det_irq_handler(int irq, void *dev_id)
 	val = gpiod_get_value(hdmirx_dev->detect_5v_gpio);
 	v4l2_dbg(3, debug, &hdmirx_dev->v4l2_dev, "%s: 5v:%d\n", __func__, val);
 
-	queue_delayed_work(system_unbound_wq,
+	queue_delayed_work(system_dfl_wq,
 			   &hdmirx_dev->delayed_work_hotplug,
 			   msecs_to_jiffies(10));
 
@@ -2441,7 +2441,7 @@ static void hdmirx_enable_irq(struct device *dev)
 	enable_irq(hdmirx_dev->dma_irq);
 	enable_irq(hdmirx_dev->det_irq);
 
-	queue_delayed_work(system_unbound_wq,
+	queue_delayed_work(system_dfl_wq,
 			   &hdmirx_dev->delayed_work_hotplug,
 			   msecs_to_jiffies(110));
 }
-- 
2.51.1

Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Dmitry Osipenko]

Hi,

On 11/4/25 13:20, Marco Crivellari wrote:
> Currently if a user enqueue a work item using schedule_delayed_work() the
> used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
> WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
> schedule_work() that is using system_wq and queue_work(), that makes use
> again of WORK_CPU_UNBOUND.
> 
> This lack of consistency cannot be addressed without refactoring the API.
> 
> This patch continues the effort to refactor worqueue APIs, which has begun
> with the change introducing new workqueues:
> 
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
> 
> system_dfl_wq should be the default workqueue so as not to enforce
> locality constraints for random work whenever it's not required.
> 
> The old system_unbound_wq will be kept for a few release cycles.
> 
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
>  drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> index b7d278b3889f..da6a725e4fbe 100644
> --- a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> +++ b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> @@ -1735,7 +1735,7 @@ static void process_signal_change(struct snps_hdmirx_dev *hdmirx_dev)
>  			   FIFO_UNDERFLOW_INT_EN |
>  			   HDMIRX_AXI_ERROR_INT_EN, 0);
>  	hdmirx_reset_dma(hdmirx_dev);
> -	queue_delayed_work(system_unbound_wq,
> +	queue_delayed_work(system_dfl_wq,

Took me a minute to find what "dfl" stands for. Would be great if the
name was self-explanatory as system_default_wq. Even then, not clear to
me what's the point of this remaining, the system_dfl_wq naming feels
very obscure compared to the explicit system_unbound_wq.

Could you please explain the logic behind the new naming? Doesn't it
create more confusion than remove?

AFAICS, right now system_dfl_wq duplicates system_unbound_wq. Suppose,
instead, the default wq could alias the system_unbound_wq.

-- 
Best regards,
Dmitry

Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Marco Crivellari]

Hi,

On Tue, Nov 4, 2025 at 1:46 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> Hi,
>[...]
> Took me a minute to find what "dfl" stands for. Would be great if the
> name was self-explanatory as system_default_wq. Even then, not clear to
> me what's the point of this remaining, the system_dfl_wq naming feels
> very obscure compared to the explicit system_unbound_wq.
>
> Could you please explain the logic behind the new naming? Doesn't it
> create more confusion than remove?

Yes, dfl it is just the abbreviation of default.

The reason is to suggest the use of the unbound workqueue
instead of the per-cpu, unless this is really needed, of course.

There are parts of the code who just used system_wq thinking it was the
unbound workqueue (the "general" wq to use), so to make explicit the
"default" is the unbound (system_dfl_wq) I think it is appropriate.

I saw this myself also in this conversion round: there are maintainers
who are asking
to change the wq they were using from system_wq to system_dfl_wq.

Let me share also where the API change (and other stuff) have been discussed:

https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/

On Tue, Nov 4, 2025 at 1:46 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
> AFAICS, right now system_dfl_wq duplicates system_unbound_wq. Suppose,
> instead, the default wq could alias the system_unbound_wq.

The idea was just give 1 choice, so remove system_unbound_wq (and
system_wq) in future.
Personally I don't have a strong opinion, but I think it's easier to
have just 1 unbound wq, and 1
per-cpu wq.

But if Tejun has other suggestions, based on your observation, I'm fine with it!

Thanks!

--

Marco Crivellari

L3 Support Engineer, Technology & Product

Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Marco Crivellari]

On Tue, Nov 4, 2025 at 11:23 AM Marco Crivellari
<marco.crivellari@suse.com> wrote:
> [...]
>  drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Gentle ping.

Thanks!

-- 

Marco Crivellari

L3 Support Engineer

Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Dmitry Osipenko]

On 2/4/26 14:49, Marco Crivellari wrote:
> On Tue, Nov 4, 2025 at 11:23 AM Marco Crivellari
> <marco.crivellari@suse.com> wrote:
>> [...]
>>  drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> Gentle ping.
> 
> Thanks!
> 

Would be good to have a reply from Tejun as I feel confused by the two
"identical" unbound workqueues. What happens if one part of kernel
queues work items to old unbound wq and other queues to new system_dfl
at the same time such that all workers are busy?

-- 
Best regards,
Dmitry

Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Dmitry Osipenko]

On 2/9/26 23:46, Dmitry Osipenko wrote:
> On 2/4/26 14:49, Marco Crivellari wrote:
>> On Tue, Nov 4, 2025 at 11:23 AM Marco Crivellari
>> <marco.crivellari@suse.com> wrote:
>>> [...]
>>>  drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c | 8 ++++----
>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> Gentle ping.
>>
>> Thanks!
>>
> 
> Would be good to have a reply from Tejun as I feel confused by the two
> "identical" unbound workqueues. What happens if one part of kernel
> queues work items to old unbound wq and other queues to new system_dfl
> at the same time such that all workers are busy?

Alright, looking further at the code, apparently there is nothing
special RE the two unbound work queues. See some parts of kernel already
moved to system_dfl. Would be great is this all was clarified in the
commit message.

Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>

-- 
Best regards,
Dmitry

Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Marco Crivellari]

On Mon, Feb 9, 2026 at 10:18 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
> Alright, looking further at the code, apparently there is nothing
> special RE the two unbound work queues. See some parts of kernel already
> moved to system_dfl. Would be great is this all was clarified in the
> commit message.
>
> Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>

Hi,

If you want I can send a new version with the improved commit log:

---

This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:

   commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
   commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.

Before that to happen, workqueue users must be converted to the better named
new workqueues with no intended behaviour changes:

   system_wq -> system_percpu_wq
   system_unbound_wq -> system_dfl_wq

This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.

Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/

---

Let me know what's best.

Thanks!

-- 

Marco Crivellari

L3 Support Engineer

Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl_wq

[Dmitry Osipenko]

On 2/10/26 17:36, Marco Crivellari wrote:
> On Mon, Feb 9, 2026 at 10:18 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>> Alright, looking further at the code, apparently there is nothing
>> special RE the two unbound work queues. See some parts of kernel already
>> moved to system_dfl. Would be great is this all was clarified in the
>> commit message.
>>
>> Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> 
> Hi,
> 
> If you want I can send a new version with the improved commit log:
> 
> ---
> 
> This patch continues the effort to refactor workqueue APIs, which has begun
> with the changes introducing new workqueues and a new alloc_workqueue flag:
> 
>    commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
>    commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
> 
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.
> 
> Before that to happen, workqueue users must be converted to the better named
> new workqueues with no intended behaviour changes:
> 
>    system_wq -> system_percpu_wq
>    system_unbound_wq -> system_dfl_wq
> 
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
> 
> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
> 
> ---
> 
> Let me know what's best.

That's better, feel free to send the v2. Thanks!

-- 
Best regards,
Dmitry