[PATCH] mailbox: pcc: support polling mode when there is no platform IRQ

[PATCH] mailbox: pcc: support polling mode when there is no platform IRQ

[Andrea Tomassetti]

The goal is to allow clients to submit a message in both irq and polling
mode of the pcc mailbox. The ACPI specification does not require a
platform irq for pcc channels. Let's implement the case where it is not
available.

peek_data is mapped to pcc_mbox_error_check_and_clear, so that it
returns true if no error occurred while the platform processed last
message, and therefore clients can fetch response data provided by the
platform.

Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
---
 drivers/acpi/acpi_pcc.c | 77 ++++++++++++++++++++++++++++-------------
 drivers/mailbox/pcc.c   | 12 ++++++-
 2 files changed, 63 insertions(+), 26 deletions(-)

diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c
index 97064e943768..ef5d7eae150b 100644
--- a/drivers/acpi/acpi_pcc.c
+++ b/drivers/acpi/acpi_pcc.c
@@ -51,7 +51,6 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 {
 	struct pcc_data *data;
 	struct acpi_pcc_info *ctx = handler_context;
-	struct pcc_mbox_chan *pcc_chan;
 	static acpi_status ret;

 	data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -59,7 +58,7 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 		return AE_NO_MEMORY;

 	data->cl.rx_callback = pcc_rx_callback;
-	data->cl.knows_txdone = true;
+	data->cl.knows_txdone = false;
 	data->ctx.length = ctx->length;
 	data->ctx.subspace_id = ctx->subspace_id;
 	data->ctx.internal_buffer = ctx->internal_buffer;
@@ -73,61 +72,89 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 		goto err_free_data;
 	}

-	pcc_chan = data->pcc_chan;
-	if (!pcc_chan->mchan->mbox->txdone_irq) {
-		pr_err("This channel-%d does not support interrupt.\n",
-		       ctx->subspace_id);
-		ret = AE_SUPPORT;
-		goto err_free_channel;
-	}
-
 	*region_context = data;
 	return AE_OK;

-err_free_channel:
-	pcc_mbox_free_channel(data->pcc_chan);
 err_free_data:
 	kfree(data);

 	return ret;
 }

+static acpi_status
+acpi_pcc_send_msg_polling(struct pcc_data *data)
+{
+	int ret;
+
+	ret = mbox_send_message(data->pcc_chan->mchan, data->pcc_chan->shmem);
+	if (ret == -ETIME) {
+		pr_err("PCC command executed timeout!\n");
+		return AE_TIME;
+	}
+
+	if (ret < 0)
+		return AE_ERROR;
+
+	if (!mbox_client_peek_data(data->pcc_chan->mchan))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
+static acpi_status
+acpi_pcc_send_msg_irq(struct pcc_data *data)
+{
+	int ret;
+
+	ret = mbox_send_message(data->pcc_chan->mchan, NULL);
+	if (ret < 0)
+		return AE_ERROR;
+
+	ret = wait_for_completion_timeout(&data->done,
+					  usecs_to_jiffies(data->cl.tx_tout * USEC_PER_MSEC));
+	if (ret == 0) {
+		pr_err("PCC command executed timeout!\n");
+		return AE_TIME;
+	}
+
+	mbox_chan_txdone(data->pcc_chan->mchan, ret);
+
+	return AE_OK;
+}
+
 static acpi_status
 acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr,
 			       u32 bits, acpi_integer *value,
 			       void *handler_context, void *region_context)
 {
-	int ret;
+	acpi_status ret;
 	struct pcc_data *data = region_context;
 	u64 usecs_lat;
+	bool use_polling = data->pcc_chan->mchan->mbox->txdone_poll;

 	reinit_completion(&data->done);

 	/* Write to Shared Memory */
 	memcpy_toio(data->pcc_chan->shmem, (void *)value, data->ctx.length);

-	ret = mbox_send_message(data->pcc_chan->mchan, NULL);
-	if (ret < 0)
-		return AE_ERROR;
-
 	/*
 	 * pcc_chan->latency is just a Nominal value. In reality the remote
 	 * processor could be much slower to reply. So add an arbitrary
 	 * amount of wait on top of Nominal.
 	 */
 	usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency;
-	ret = wait_for_completion_timeout(&data->done,
-						usecs_to_jiffies(usecs_lat));
-	if (ret == 0) {
-		pr_err("PCC command executed timeout!\n");
-		return AE_TIME;
-	}

-	mbox_chan_txdone(data->pcc_chan->mchan, ret);
+	data->cl.tx_block = use_polling;
+	data->cl.tx_tout = usecs_lat / USEC_PER_MSEC;
+
+	if (use_polling)
+		ret = acpi_pcc_send_msg_polling(data);
+	else
+		ret = acpi_pcc_send_msg_irq(data);

 	memcpy_fromio(value, data->pcc_chan->shmem, data->ctx.length);

-	return AE_OK;
+	return ret;
 }

 void __init acpi_init_pcc(void)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 0a00719b2482..e4e744669f81 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -579,11 +579,17 @@ static void pcc_shutdown(struct mbox_chan *chan)
 		devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
 }

+static bool pcc_peek_data(struct mbox_chan *chan)
+{
+	return pcc_mbox_error_check_and_clear(chan->con_priv) == 0;
+}
+
 static const struct mbox_chan_ops pcc_chan_ops = {
 	.send_data = pcc_send_data,
 	.startup = pcc_startup,
 	.shutdown = pcc_shutdown,
 	.last_tx_done = pcc_last_tx_done,
+	.peek_data = pcc_peek_data,
 };

 /**
@@ -877,8 +883,12 @@ static int pcc_mbox_probe(struct platform_device *pdev)
 		(unsigned long) pcct_tbl + sizeof(struct acpi_table_pcct));

 	acpi_pcct_tbl = (struct acpi_table_pcct *) pcct_tbl;
-	if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL)
+	if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL) {
 		pcc_mbox_ctrl->txdone_irq = true;
+	} else {
+		pcc_mbox_ctrl->txdone_poll = true;
+		pcc_mbox_ctrl->txpoll_period = 1;
+	}

 	for (i = 0; i < count; i++) {
 		struct pcc_chan_info *pchan = chan_info + i;
--
2.25.0

Re: [PATCH] mailbox: pcc: support polling mode when there is no platform IRQ

[kernel test robot]

Hi Andrea,

kernel test robot noticed the following build warnings:

[auto build test WARNING on rafael-pm/linux-next]
[also build test WARNING on rafael-pm/bleeding-edge jassibrar-mailbox/for-next linus/master v6.18-rc5 next-20251111]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Andrea-Tomassetti/mailbox-pcc-support-polling-mode-when-there-is-no-platform-IRQ/20251110-232950
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20251110150825.3548819-1-andrea.tomassetti%40sipearl.com
patch subject: [PATCH] mailbox: pcc: support polling mode when there is no platform IRQ
config: i386-randconfig-061-20251111 (https://download.01.org/0day-ci/archive/20251112/202511120243.soxAFpqQ-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251112/202511120243.soxAFpqQ-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/acpi/acpi_pcc.c:89:70: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void *mssg @@     got void [noderef] __iomem *shmem @@
   drivers/acpi/acpi_pcc.c:89:70: sparse:     expected void *mssg
   drivers/acpi/acpi_pcc.c:89:70: sparse:     got void [noderef] __iomem *shmem

vim +89 drivers/acpi/acpi_pcc.c

    83	
    84	static acpi_status
    85	acpi_pcc_send_msg_polling(struct pcc_data *data)
    86	{
    87		int ret;
    88	
  > 89		ret = mbox_send_message(data->pcc_chan->mchan, data->pcc_chan->shmem);
    90		if (ret == -ETIME) {
    91			pr_err("PCC command executed timeout!\n");
    92			return AE_TIME;
    93		}
    94	
    95		if (ret < 0)
    96			return AE_ERROR;
    97	
    98		if (!mbox_client_peek_data(data->pcc_chan->mchan))
    99			return AE_ERROR;
   100	
   101		return AE_OK;
   102	}
   103	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] mailbox: pcc: support polling mode when there is no platform IRQ

[kernel test robot]

Hi Andrea,

kernel test robot noticed the following build errors:

[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on rafael-pm/bleeding-edge jassibrar-mailbox/for-next linus/master v6.18-rc5 next-20251111]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Andrea-Tomassetti/mailbox-pcc-support-polling-mode-when-there-is-no-platform-IRQ/20251110-232950
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20251110150825.3548819-1-andrea.tomassetti%40sipearl.com
patch subject: [PATCH] mailbox: pcc: support polling mode when there is no platform IRQ
config: i386-buildonly-randconfig-004-20251111 (https://download.01.org/0day-ci/archive/20251112/202511120558.Cln7LF6M-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251112/202511120558.Cln7LF6M-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/

All errors (new ones prefixed by >>):

   ld: drivers/acpi/acpi_pcc.o: in function `acpi_pcc_address_space_handler':
>> acpi_pcc.c:(.text+0x69): undefined reference to `__udivdi3'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] mailbox: pcc: support polling mode when there is no platform IRQ

[kernel test robot]

Hi Andrea,

kernel test robot noticed the following build errors:

[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on rafael-pm/bleeding-edge jassibrar-mailbox/for-next linus/master v6.18-rc5 next-20251111]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Andrea-Tomassetti/mailbox-pcc-support-polling-mode-when-there-is-no-platform-IRQ/20251110-232950
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20251110150825.3548819-1-andrea.tomassetti%40sipearl.com
patch subject: [PATCH] mailbox: pcc: support polling mode when there is no platform IRQ
config: i386-buildonly-randconfig-002-20251112 (https://download.01.org/0day-ci/archive/20251112/202511120729.R3XQNSnx-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251112/202511120729.R3XQNSnx-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/

All errors (new ones prefixed by >>):

   ld: drivers/acpi/acpi_pcc.o: in function `acpi_pcc_address_space_handler':
>> drivers/acpi/acpi_pcc.c:148:(.text+0x7e): undefined reference to `__udivdi3'

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for OF_GPIO
   Depends on [n]: GPIOLIB [=y] && OF [=n] && HAS_IOMEM [=y]
   Selected by [y]:
   - GPIO_TB10X [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && (ARC_PLAT_TB10X || COMPILE_TEST [=y])
   WARNING: unmet direct dependencies detected for GPIO_SYSCON
   Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
   Selected by [m]:
   - GPIO_SAMA5D2_PIOBU [=m] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF_GPIO [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
   WARNING: unmet direct dependencies detected for I2C_K1
   Depends on [n]: I2C [=y] && HAS_IOMEM [=y] && (ARCH_SPACEMIT || COMPILE_TEST [=y]) && OF [=n]
   Selected by [m]:
   - MFD_SPACEMIT_P1 [=m] && HAS_IOMEM [=y] && (ARCH_SPACEMIT || COMPILE_TEST [=y]) && I2C [=y]


vim +148 drivers/acpi/acpi_pcc.c

   124	
   125	static acpi_status
   126	acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr,
   127				       u32 bits, acpi_integer *value,
   128				       void *handler_context, void *region_context)
   129	{
   130		acpi_status ret;
   131		struct pcc_data *data = region_context;
   132		u64 usecs_lat;
   133		bool use_polling = data->pcc_chan->mchan->mbox->txdone_poll;
   134	
   135		reinit_completion(&data->done);
   136	
   137		/* Write to Shared Memory */
   138		memcpy_toio(data->pcc_chan->shmem, (void *)value, data->ctx.length);
   139	
   140		/*
   141		 * pcc_chan->latency is just a Nominal value. In reality the remote
   142		 * processor could be much slower to reply. So add an arbitrary
   143		 * amount of wait on top of Nominal.
   144		 */
   145		usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency;
   146	
   147		data->cl.tx_block = use_polling;
 > 148		data->cl.tx_tout = usecs_lat / USEC_PER_MSEC;
   149	
   150		if (use_polling)
   151			ret = acpi_pcc_send_msg_polling(data);
   152		else
   153			ret = acpi_pcc_send_msg_irq(data);
   154	
   155		memcpy_fromio(value, data->pcc_chan->shmem, data->ctx.length);
   156	
   157		return ret;
   158	}
   159	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v2] mailbox: pcc: support polling mode when there is no platform IRQ

[Andrea Tomassetti]

The goal is to allow clients to submit a message in both irq and polling
mode of the pcc mailbox. The ACPI specification does not require a
platform irq for pcc channels. Let's implement the case where it is not
available.

peek_data is mapped to pcc_mbox_error_check_and_clear, so that it
returns true if no error occurred while the platform processed last
message, and therefore clients can fetch response data provided by the
platform.

Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
---
v2: Fix issues reported by the kernel test robot
  - sparse: incorrect type in argument 2 (different address spaces)
  - acpi_pcc.c:(.text+0x69): undefined reference to `__udivdi3'

 drivers/acpi/acpi_pcc.c | 78 ++++++++++++++++++++++++++++-------------
 drivers/mailbox/pcc.c   | 12 ++++++-
 2 files changed, 64 insertions(+), 26 deletions(-)

diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c
index 97064e943768..37f94fa4c424 100644
--- a/drivers/acpi/acpi_pcc.c
+++ b/drivers/acpi/acpi_pcc.c
@@ -51,7 +51,6 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 {
 	struct pcc_data *data;
 	struct acpi_pcc_info *ctx = handler_context;
-	struct pcc_mbox_chan *pcc_chan;
 	static acpi_status ret;
 
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -59,7 +58,7 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 		return AE_NO_MEMORY;
 
 	data->cl.rx_callback = pcc_rx_callback;
-	data->cl.knows_txdone = true;
+	data->cl.knows_txdone = false;
 	data->ctx.length = ctx->length;
 	data->ctx.subspace_id = ctx->subspace_id;
 	data->ctx.internal_buffer = ctx->internal_buffer;
@@ -73,61 +72,90 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 		goto err_free_data;
 	}
 
-	pcc_chan = data->pcc_chan;
-	if (!pcc_chan->mchan->mbox->txdone_irq) {
-		pr_err("This channel-%d does not support interrupt.\n",
-		       ctx->subspace_id);
-		ret = AE_SUPPORT;
-		goto err_free_channel;
-	}
-
 	*region_context = data;
 	return AE_OK;
 
-err_free_channel:
-	pcc_mbox_free_channel(data->pcc_chan);
 err_free_data:
 	kfree(data);
 
 	return ret;
 }
 
+static acpi_status
+acpi_pcc_send_msg_polling(struct pcc_data *data)
+{
+	int ret;
+
+	ret = mbox_send_message(data->pcc_chan->mchan,
+				(__force void *)data->pcc_chan->shmem);
+	if (ret == -ETIME) {
+		pr_err("PCC command executed timeout!\n");
+		return AE_TIME;
+	}
+
+	if (ret < 0)
+		return AE_ERROR;
+
+	if (!mbox_client_peek_data(data->pcc_chan->mchan))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
+static acpi_status
+acpi_pcc_send_msg_irq(struct pcc_data *data)
+{
+	int ret;
+
+	ret = mbox_send_message(data->pcc_chan->mchan, NULL);
+	if (ret < 0)
+		return AE_ERROR;
+
+	ret = wait_for_completion_timeout(&data->done,
+					  usecs_to_jiffies(data->cl.tx_tout * USEC_PER_MSEC));
+	if (ret == 0) {
+		pr_err("PCC command executed timeout!\n");
+		return AE_TIME;
+	}
+
+	mbox_chan_txdone(data->pcc_chan->mchan, ret);
+
+	return AE_OK;
+}
+
 static acpi_status
 acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr,
 			       u32 bits, acpi_integer *value,
 			       void *handler_context, void *region_context)
 {
-	int ret;
+	acpi_status ret;
 	struct pcc_data *data = region_context;
 	u64 usecs_lat;
+	bool use_polling = data->pcc_chan->mchan->mbox->txdone_poll;
 
 	reinit_completion(&data->done);
 
 	/* Write to Shared Memory */
 	memcpy_toio(data->pcc_chan->shmem, (void *)value, data->ctx.length);
 
-	ret = mbox_send_message(data->pcc_chan->mchan, NULL);
-	if (ret < 0)
-		return AE_ERROR;
-
 	/*
 	 * pcc_chan->latency is just a Nominal value. In reality the remote
 	 * processor could be much slower to reply. So add an arbitrary
 	 * amount of wait on top of Nominal.
 	 */
 	usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency;
-	ret = wait_for_completion_timeout(&data->done,
-						usecs_to_jiffies(usecs_lat));
-	if (ret == 0) {
-		pr_err("PCC command executed timeout!\n");
-		return AE_TIME;
-	}
 
-	mbox_chan_txdone(data->pcc_chan->mchan, ret);
+	data->cl.tx_block = use_polling;
+	data->cl.tx_tout = div_u64(usecs_lat, USEC_PER_MSEC);
+
+	if (use_polling)
+		ret = acpi_pcc_send_msg_polling(data);
+	else
+		ret = acpi_pcc_send_msg_irq(data);
 
 	memcpy_fromio(value, data->pcc_chan->shmem, data->ctx.length);
 
-	return AE_OK;
+	return ret;
 }
 
 void __init acpi_init_pcc(void)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 0a00719b2482..e4e744669f81 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -579,11 +579,17 @@ static void pcc_shutdown(struct mbox_chan *chan)
 		devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
 }
 
+static bool pcc_peek_data(struct mbox_chan *chan)
+{
+	return pcc_mbox_error_check_and_clear(chan->con_priv) == 0;
+}
+
 static const struct mbox_chan_ops pcc_chan_ops = {
 	.send_data = pcc_send_data,
 	.startup = pcc_startup,
 	.shutdown = pcc_shutdown,
 	.last_tx_done = pcc_last_tx_done,
+	.peek_data = pcc_peek_data,
 };
 
 /**
@@ -877,8 +883,12 @@ static int pcc_mbox_probe(struct platform_device *pdev)
 		(unsigned long) pcct_tbl + sizeof(struct acpi_table_pcct));
 
 	acpi_pcct_tbl = (struct acpi_table_pcct *) pcct_tbl;
-	if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL)
+	if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL) {
 		pcc_mbox_ctrl->txdone_irq = true;
+	} else {
+		pcc_mbox_ctrl->txdone_poll = true;
+		pcc_mbox_ctrl->txpoll_period = 1;
+	}
 
 	for (i = 0; i < count; i++) {
 		struct pcc_chan_info *pchan = chan_info + i;

base-commit: 8b690556d8fe074b4f9835075050fba3fb180e93
-- 
2.51.2

Re: [PATCH v2] mailbox: pcc: support polling mode when there is no platform IRQ

[Sudeep Holla]

On Wed, Nov 19, 2025 at 10:01:18AM +0100, Andrea Tomassetti wrote:
> The goal is to allow clients to submit a message in both irq and polling
> mode of the pcc mailbox. The ACPI specification does not require a
> platform irq for pcc channels. Let's implement the case where it is not
> available.
> 
> peek_data is mapped to pcc_mbox_error_check_and_clear, so that it
> returns true if no error occurred while the platform processed last
> message, and therefore clients can fetch response data provided by the
> platform.
> 
> Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
> Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
> ---
> v2: Fix issues reported by the kernel test robot
>   - sparse: incorrect type in argument 2 (different address spaces)
>   - acpi_pcc.c:(.text+0x69): undefined reference to `__udivdi3'
> 
>  drivers/acpi/acpi_pcc.c | 78 ++++++++++++++++++++++++++++-------------
>  drivers/mailbox/pcc.c   | 12 ++++++-

Please separate the changes to the PCC OpRegion handler and the PCC mailbox
driver into individual patches. I’ve also done some cleanup work [1], which
has been tested and resolves part of the polling vs. IRQ flag initialization
issue.

I’d appreciate it if you could rebase your changes on top of those updates to
make the review process smoother and help us move forward more quickly.

-- 
Regards,
Sudeep

[1] https://lore.kernel.org/all/20251016-pcc_mb_updates-v1-0-0fba69616f69@arm.com/

[PATCH v3 1/2] mailbox: pcc: support polling mode when there is no platform IRQ

[Andrea Tomassetti]

The goal is to allow clients to submit a message in both irq and polling
mode of the pcc mailbox. The ACPI specification does not require a
platform irq for pcc channels. Let's implement the case where it is not
available.

Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
---
v3: Thank you very much for the feedback Sudeep! Here there are the changes
    implemented in this latest version:
  - separate the changes to the PCC OpRegion handler and the PCC mailbox
    driver into individual patches
  - rebased the changes on top of the ongoing cleanup work

v2: Fix issues reported by the kernel test robot
  - sparse: incorrect type in argument 2 (different address spaces)
  - acpi_pcc.c:(.text+0x69): undefined reference to `__udivdi3'

 drivers/acpi/acpi_pcc.c | 78 ++++++++++++++++++++++++++++-------------
 1 file changed, 53 insertions(+), 25 deletions(-)

diff --git a/drivers/acpi/acpi_pcc.c b/drivers/acpi/acpi_pcc.c
index 97064e943768..37f94fa4c424 100644
--- a/drivers/acpi/acpi_pcc.c
+++ b/drivers/acpi/acpi_pcc.c
@@ -51,7 +51,6 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 {
 	struct pcc_data *data;
 	struct acpi_pcc_info *ctx = handler_context;
-	struct pcc_mbox_chan *pcc_chan;
 	static acpi_status ret;
 
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
@@ -59,7 +58,7 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 		return AE_NO_MEMORY;
 
 	data->cl.rx_callback = pcc_rx_callback;
-	data->cl.knows_txdone = true;
+	data->cl.knows_txdone = false;
 	data->ctx.length = ctx->length;
 	data->ctx.subspace_id = ctx->subspace_id;
 	data->ctx.internal_buffer = ctx->internal_buffer;
@@ -73,61 +72,90 @@ acpi_pcc_address_space_setup(acpi_handle region_handle, u32 function,
 		goto err_free_data;
 	}
 
-	pcc_chan = data->pcc_chan;
-	if (!pcc_chan->mchan->mbox->txdone_irq) {
-		pr_err("This channel-%d does not support interrupt.\n",
-		       ctx->subspace_id);
-		ret = AE_SUPPORT;
-		goto err_free_channel;
-	}
-
 	*region_context = data;
 	return AE_OK;
 
-err_free_channel:
-	pcc_mbox_free_channel(data->pcc_chan);
 err_free_data:
 	kfree(data);
 
 	return ret;
 }
 
+static acpi_status
+acpi_pcc_send_msg_polling(struct pcc_data *data)
+{
+	int ret;
+
+	ret = mbox_send_message(data->pcc_chan->mchan,
+				(__force void *)data->pcc_chan->shmem);
+	if (ret == -ETIME) {
+		pr_err("PCC command executed timeout!\n");
+		return AE_TIME;
+	}
+
+	if (ret < 0)
+		return AE_ERROR;
+
+	if (!mbox_client_peek_data(data->pcc_chan->mchan))
+		return AE_ERROR;
+
+	return AE_OK;
+}
+
+static acpi_status
+acpi_pcc_send_msg_irq(struct pcc_data *data)
+{
+	int ret;
+
+	ret = mbox_send_message(data->pcc_chan->mchan, NULL);
+	if (ret < 0)
+		return AE_ERROR;
+
+	ret = wait_for_completion_timeout(&data->done,
+					  usecs_to_jiffies(data->cl.tx_tout * USEC_PER_MSEC));
+	if (ret == 0) {
+		pr_err("PCC command executed timeout!\n");
+		return AE_TIME;
+	}
+
+	mbox_chan_txdone(data->pcc_chan->mchan, ret);
+
+	return AE_OK;
+}
+
 static acpi_status
 acpi_pcc_address_space_handler(u32 function, acpi_physical_address addr,
 			       u32 bits, acpi_integer *value,
 			       void *handler_context, void *region_context)
 {
-	int ret;
+	acpi_status ret;
 	struct pcc_data *data = region_context;
 	u64 usecs_lat;
+	bool use_polling = data->pcc_chan->mchan->mbox->txdone_poll;
 
 	reinit_completion(&data->done);
 
 	/* Write to Shared Memory */
 	memcpy_toio(data->pcc_chan->shmem, (void *)value, data->ctx.length);
 
-	ret = mbox_send_message(data->pcc_chan->mchan, NULL);
-	if (ret < 0)
-		return AE_ERROR;
-
 	/*
 	 * pcc_chan->latency is just a Nominal value. In reality the remote
 	 * processor could be much slower to reply. So add an arbitrary
 	 * amount of wait on top of Nominal.
 	 */
 	usecs_lat = PCC_CMD_WAIT_RETRIES_NUM * data->pcc_chan->latency;
-	ret = wait_for_completion_timeout(&data->done,
-						usecs_to_jiffies(usecs_lat));
-	if (ret == 0) {
-		pr_err("PCC command executed timeout!\n");
-		return AE_TIME;
-	}
 
-	mbox_chan_txdone(data->pcc_chan->mchan, ret);
+	data->cl.tx_block = use_polling;
+	data->cl.tx_tout = div_u64(usecs_lat, USEC_PER_MSEC);
+
+	if (use_polling)
+		ret = acpi_pcc_send_msg_polling(data);
+	else
+		ret = acpi_pcc_send_msg_irq(data);
 
 	memcpy_fromio(value, data->pcc_chan->shmem, data->ctx.length);
 
-	return AE_OK;
+	return ret;
 }
 
 void __init acpi_init_pcc(void)
-- 
2.51.2

[PATCH v3 2/2] mailbox: pcc: add peek_data handler

[Andrea Tomassetti]

peek_data is mapped to pcc_mbox_error_check_and_clear, so that it
returns true if no error occurred while the platform processed last
message, and therefore clients can fetch response data provided by the
platform.

Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
---
 drivers/mailbox/pcc.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 418007020439..ccd50b33409b 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -502,11 +502,17 @@ static void pcc_shutdown(struct mbox_chan *chan)
 		devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
 }
 
+static bool pcc_peek_data(struct mbox_chan *chan)
+{
+	return pcc_mbox_error_check_and_clear(chan->con_priv) == 0;
+}
+
 static const struct mbox_chan_ops pcc_chan_ops = {
 	.send_data = pcc_send_data,
 	.startup = pcc_startup,
 	.shutdown = pcc_shutdown,
 	.last_tx_done = pcc_last_tx_done,
+	.peek_data = pcc_peek_data,
 };
 
 /**
-- 
2.51.2

Re: [PATCH v3 1/2] mailbox: pcc: support polling mode when there is no platform IRQ

[Sudeep Holla]

On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote:
> The goal is to allow clients to submit a message in both irq and polling
> mode of the pcc mailbox. The ACPI specification does not require a
> platform irq for pcc channels. Let's implement the case where it is not
> available.
>

Just curious if you have a real use case for this polling mode on your
platforms or ...

> Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
> Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
> Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/

You are just trying to fix these warnings. If it is latter, we don't have to
add support for polling mode especially if it can't be tested on real
platforms.

-- 
Regards,
Sudeep

Re: Re: [PATCH v3 1/2] mailbox: pcc: support polling mode when there is no platform IRQ

[Andrea Tomassetti]

On 25/12/03 10:28AM, Sudeep Holla wrote:
> On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote:
> > The goal is to allow clients to submit a message in both irq and polling
> > mode of the pcc mailbox. The ACPI specification does not require a
> > platform irq for pcc channels. Let's implement the case where it is not
> > available.
> >
> 
> Just curious if you have a real use case for this polling mode on your
> platforms or ...
> 
> > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
> > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
> > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
> > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
> 
> You are just trying to fix these warnings. If it is latter, we don't have to
> add support for polling mode especially if it can't be tested on real
> platforms.
>
In our target product, we're still investigating if PCC-based SCMI communication will
rely on interrupts or polling. When we started looking into it we realized that polling
wasn't supported and that's why we decided to work on and send this patch. We thought it
could have been beneficial to other members of the community and it brings the driver a
bit closer to the ACPI specifications.

We're using ARM Fast Models for prototyping and that's how we validated and tested this patch.

Best regards,
Andrea
> -- 
> Regards,
> Sudeep

Re: Re: [PATCH v3 1/2] mailbox: pcc: support polling mode when there is no platform IRQ

[Sudeep Holla]

On Thu, Dec 04, 2025 at 01:59:38PM +0100, Andrea Tomassetti wrote:
> On 25/12/03 10:28AM, Sudeep Holla wrote:
> > On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote:
> > > The goal is to allow clients to submit a message in both irq and polling
> > > mode of the pcc mailbox. The ACPI specification does not require a
> > > platform irq for pcc channels. Let's implement the case where it is not
> > > available.
> > >
> > 
> > Just curious if you have a real use case for this polling mode on your
> > platforms or ...
> > 
> > > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
> > > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> > > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> > > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
> > 
> > You are just trying to fix these warnings. If it is latter, we don't have to
> > add support for polling mode especially if it can't be tested on real
> > platforms.
> >
> In our target product, we're still investigating if PCC-based SCMI communication will
> rely on interrupts or polling. When we started looking into it we realized that polling
> wasn't supported and that's why we decided to work on and send this patch. We thought it
> could have been beneficial to other members of the community and it brings the driver a
> bit closer to the ACPI specifications.
> 
> We're using ARM Fast Models for prototyping and that's how we validated and tested this patch.
> 

I wouldn't consider that as real platform especially if it is not std. AEM
models that are well maintained. Many Fast models are short lived and never
maintained long term, so I don't want to push any feature based on that alone
unless you have a real platform with missing or broken interrupt that needs
this polling feature.

It is burden for long term maintenance if there is no regular way to test this
polling mode feature.

-- 
Regards,
Sudeep

Re: Re: Re: [PATCH v3 1/2] mailbox: pcc: support polling mode when there is no platform IRQ

[Andrea Tomassetti]

On 25/12/04 01:14PM, Sudeep Holla wrote:
> On Thu, Dec 04, 2025 at 01:59:38PM +0100, Andrea Tomassetti wrote:
> > On 25/12/03 10:28AM, Sudeep Holla wrote:
> > > On Tue, Dec 02, 2025 at 11:12:14AM +0100, Andrea Tomassetti wrote:
> > > > The goal is to allow clients to submit a message in both irq and polling
> > > > mode of the pcc mailbox. The ACPI specification does not require a
> > > > platform irq for pcc channels. Let's implement the case where it is not
> > > > available.
> > > >
> > > 
> > > Just curious if you have a real use case for this polling mode on your
> > > platforms or ...
> > > 
> > > > Tested-by: Thibault Cantori <thibault.cantori@sipearl.com>
> > > > Co-developed-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> > > > Signed-off-by: Olivier Dautricourt <olivier.dautricourt@sipearl.com>
> > > > Signed-off-by: Andrea Tomassetti <andrea.tomassetti@sipearl.com>
> > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120243.soxAFpqQ-lkp@intel.com/
> > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120558.Cln7LF6M-lkp@intel.com/
> > > > Closes: https://lore.kernel.org/oe-kbuild-all/202511120729.R3XQNSnx-lkp@intel.com/
> > > 
> > > You are just trying to fix these warnings. If it is latter, we don't have to
> > > add support for polling mode especially if it can't be tested on real
> > > platforms.
> > >
> > In our target product, we're still investigating if PCC-based SCMI communication will
> > rely on interrupts or polling. When we started looking into it we realized that polling
> > wasn't supported and that's why we decided to work on and send this patch. We thought it
> > could have been beneficial to other members of the community and it brings the driver a
> > bit closer to the ACPI specifications.
> > 
> > We're using ARM Fast Models for prototyping and that's how we validated and tested this patch.
> > 
> 
> I wouldn't consider that as real platform especially if it is not std. AEM
> models that are well maintained. Many Fast models are short lived and never
> maintained long term, so I don't want to push any feature based on that alone
> unless you have a real platform with missing or broken interrupt that needs
> this polling feature.
> 
> It is burden for long term maintenance if there is no regular way to test this
> polling mode feature.
> 
Fair, I totally get your point. Thank you very much for your time.

Regards,
Andrea
> -- 
> Regards,
> Sudeep

Re: Re: Re: [PATCH v3 1/2] mailbox: pcc: support polling mode when there is no platform IRQ

[Sudeep Holla]

On Tue, Dec 09, 2025 at 10:39:53AM +0000, Andrea Tomassetti wrote:
> On 25/12/04 01:14PM, Sudeep Holla wrote:
> > 
> > I wouldn't consider that as real platform especially if it is not std. AEM
> > models that are well maintained. Many Fast models are short lived and never
> > maintained long term, so I don't want to push any feature based on that alone
> > unless you have a real platform with missing or broken interrupt that needs
> > this polling feature.
> > 
> > It is burden for long term maintenance if there is no regular way to test this
> > polling mode feature.
> > 
> Fair, I totally get your point. Thank you very much for your time.
> 

Thanks for understanding. We can always revisit this if this becomes a
requirement on a real platform in the future. I am not against that just FYI.

-- 
Regards,
Sudeep