linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Huisong Li <lihuisong@huawei.com>
Cc: robbiek@xsightlabs.com, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, rafael@kernel.org,
	rafael.j.wysocki@intel.com, wanghuiqiang@huawei.com,
	zhangzekun11@huawei.com, wangxiongfeng2@huawei.com,
	tanxiaofei@huawei.com, guohanjun@huawei.com, xiexiuqi@huawei.com,
	wangkefeng.wang@huawei.com, huangdaode@huawei.com
Subject: Re: [PATCH 2/2] mailbox: pcc: Support shared interrupt for multiple subspaces
Date: Wed, 1 Mar 2023 13:36:26 +0000	[thread overview]
Message-ID: <20230301133626.gchca3fdaqijxwzq@bogus> (raw)
In-Reply-To: <20230216063653.1995-3-lihuisong@huawei.com>

On Thu, Feb 16, 2023 at 02:36:53PM +0800, Huisong Li wrote:
> If the platform acknowledge interrupt is level triggered, then it can
> be shared by multiple subspaces provided each one has a unique platform
> interrupt ack preserve and ack set masks.
> 
> If it can be shared, then we can request the irq with IRQF_SHARED and
> IRQF_ONESHOT flags. The first one indicating it can be shared and the
> latter one to keep the interrupt disabled until the hardirq handler
> finished.
> 
> Further, since there is no way to detect if the interrupt is for a given
> channel as the interrupt ack preserve and ack set masks are for clearing
> the interrupt and not for reading the status(in case Irq Ack register
> may be write-only on some platforms), we need a way to identify if the
> given channel is in use and expecting the interrupt.
> 
> PCC type0, type1 and type5 do not support shared level triggered interrupt.
> The methods of determining whether a given channel for remaining types
> should respond to an interrupt are as follows:
>  - type2: Whether the interrupt belongs to a given channel is only
>           determined by the status field in Generic Communications Channel
>           Shared Memory Region, which is done in rx_callback of PCC client.
>  - type3: This channel checks chan_in_use flag first and then checks the
>           command complete bit(value '1' indicates that the command has
>           been completed).
>  - type4: Platform ensure that the default value of the command complete
>           bit corresponding to the type4 channel is '1'. This command
>           complete bit is '0' when receive a platform notification.
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> ---
>  drivers/mailbox/pcc.c | 45 ++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 42 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index ecd54f049de3..04c2d73a0473 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -92,6 +92,10 @@ struct pcc_chan_reg {
>   * @error: PCC register bundle for the error status register
>   * @plat_irq: platform interrupt
>   * @type: PCC subspace type
> + * @plat_irq_flags: platform interrupt flags
> + * @chan_in_use: flag indicating whether the channel is in use or not when use
> + *		platform interrupt, and only use it for communication from OSPM
> + *		to Platform, like type 3.

Also add a node that since only one transfer can occur at a time and the
mailbox takes care of locking, this flag needs no locking and is used just
to check if the interrupt needs handling when it is shared.

>   */
>  struct pcc_chan_info {
>  	struct pcc_mbox_chan chan;
> @@ -102,6 +106,8 @@ struct pcc_chan_info {
>  	struct pcc_chan_reg error;
>  	int plat_irq;
>  	u8 type;
> +	unsigned int plat_irq_flags;
> +	bool chan_in_use;
>  };
>  
>  #define to_pcc_chan_info(c) container_of(c, struct pcc_chan_info, chan)
> @@ -225,6 +231,12 @@ static int pcc_map_interrupt(u32 interrupt, u32 flags)
>  	return acpi_register_gsi(NULL, interrupt, trigger, polarity);
>  }
>  
> +static bool pcc_chan_plat_irq_can_be_shared(struct pcc_chan_info *pchan)
> +{
> +	return (pchan->plat_irq_flags & ACPI_PCCT_INTERRUPT_MODE) ==
> +		ACPI_LEVEL_SENSITIVE;
> +}
> +
>  static bool pcc_chan_command_complete(struct pcc_chan_info *pchan,
>  				      u64 cmd_complete_reg_val)
>  {
> @@ -277,6 +289,9 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>  	int ret;
>  
>  	pchan = chan->con_priv;
> +	if (pchan->type == ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE &&
> +	    !pchan->chan_in_use)
> +		return IRQ_NONE;
>  
>  	ret = pcc_chan_reg_read(&pchan->cmd_complete, &val);
>  	if (ret)
> @@ -302,9 +317,13 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>  	/*
>  	 * The PCC slave subspace channel needs to set the command complete bit
>  	 * and ring doorbell after processing message.
> +	 *
> +	 * The PCC master subspace channel clears chan_in_use to free channel.
>  	 */
>  	if (pchan->type == ACPI_PCCT_TYPE_EXT_PCC_SLAVE_SUBSPACE)
>  		pcc_send_data(chan, NULL);
> +	else if (pchan->type == ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE)
> +		pchan->chan_in_use = false;

Just wondering if this has to be for type 3 only. I am trying to avoid
conditional update of this flag, can we not do it for everything except type4 ?
(I mean just in unconditional else part)

>
>  	return IRQ_HANDLED;
>  }
> @@ -353,10 +372,13 @@ pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
>  	spin_unlock_irqrestore(&chan->lock, flags);
>  
>  	if (pchan->plat_irq > 0) {
> +		unsigned long irqflags;
>  		int rc;
>  
> -		rc = devm_request_irq(dev, pchan->plat_irq, pcc_mbox_irq, 0,
> -				      MBOX_IRQ_NAME, chan);
> +		irqflags = pcc_chan_plat_irq_can_be_shared(pchan) ?
> +					IRQF_SHARED | IRQF_ONESHOT : 0;
> +		rc = devm_request_irq(dev, pchan->plat_irq, pcc_mbox_irq,
> +				      irqflags, MBOX_IRQ_NAME, chan);
>  		if (unlikely(rc)) {
>  			dev_err(dev, "failed to register PCC interrupt %d\n",
>  				pchan->plat_irq);
> @@ -418,7 +440,17 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
>  	if (ret)
>  		return ret;
>  
> -	return pcc_chan_reg_read_modify_write(&pchan->db);
> +	ret = pcc_chan_reg_read_modify_write(&pchan->db);
> +	/*
> +	 * For the master subspace channel, set chan_in_use flag to true after
> +	 * ring doorbell, and clear this flag when the reply message is
> +	 * processed.
> +	 */
> +	if (!ret && pchan->type == ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE &&
> +	    pchan->plat_irq > 0)
> +		pchan->chan_in_use = true;

Ditto here(for all type except type 4?)

-- 
Regards,
Sudeep

  reply	other threads:[~2023-03-01 13:36 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-16  3:40 [RFC] ACPI: PCC: Support shared interrupt for multiple subspaces Huisong Li
2022-10-26  6:10 ` lihuisong (C)
2022-10-27 11:10   ` Sudeep Holla
2022-10-27 12:48     ` lihuisong (C)
2022-10-27 15:53 ` Sudeep Holla
2022-10-28  7:55   ` lihuisong (C)
2022-10-31 10:40     ` Sudeep Holla
2022-11-01  2:49       ` lihuisong (C)
2022-11-04 15:04         ` Robbie King
2022-11-04 15:15           ` Sudeep Holla
2022-11-04 15:39             ` Robbie King
2022-11-07  6:24               ` lihuisong (C)
2022-11-17 18:09                 ` Robbie King
2022-11-19  7:32                   ` lihuisong (C)
2022-11-21 16:59                     ` Robbie King
2022-11-22  3:42                       ` lihuisong (C)
2022-11-22  3:30 ` [RFC V2] " Huisong Li
2022-11-22 13:46   ` Sudeep Holla
2022-11-23  3:36     ` lihuisong (C)
2022-12-03  9:51 ` [RFC-V3 0/2] mailbox: pcc: Support platform notification for type4 and shared interrupt Huisong Li
2022-12-03  9:51   ` [RFC-V3 1/2] mailbox: pcc: Add processing platform notification for slave subspaces Huisong Li
2023-02-06 15:39     ` Sudeep Holla
2023-02-07  2:27       ` lihuisong (C)
2023-02-13 21:18         ` Robbie King
2023-02-14  1:24           ` lihuisong (C)
2022-12-03  9:51   ` [RFC-V3 2/2] mailbox: pcc: Support shared interrupt for multiple subspaces Huisong Li
2022-12-14  2:57   ` [RFC-V3 0/2] mailbox: pcc: Support platform notification for type4 and shared interrupt lihuisong (C)
2022-12-30  1:07     ` lihuisong (C)
2023-01-04 11:06     ` Sudeep Holla
2023-01-05  1:14       ` lihuisong (C)
2023-01-28  1:49         ` lihuisong (C)
2023-02-16  6:36 ` [PATCH " Huisong Li
2023-02-16  6:36   ` [PATCH 1/2] mailbox: pcc: Add processing platform notification for slave subspaces Huisong Li
2023-03-01 13:24     ` Sudeep Holla
2023-03-02  1:57       ` lihuisong (C)
2023-03-02 13:52         ` Sudeep Holla
2023-03-03  1:50           ` lihuisong (C)
2023-03-03 11:07             ` Sudeep Holla
2023-03-04  9:49               ` lihuisong (C)
2023-02-16  6:36   ` [PATCH 2/2] mailbox: pcc: Support shared interrupt for multiple subspaces Huisong Li
2023-03-01 13:36     ` Sudeep Holla [this message]
2023-03-02  2:17       ` lihuisong (C)
2023-03-02 14:02         ` Sudeep Holla
     [not found]           ` <020cc964-9938-7ebe-7514-125cd041bfcb@huawei.com>
2023-03-03 11:14             ` Sudeep Holla
2023-03-04  9:47               ` lihuisong (C)
2023-03-10 20:14                 ` Sudeep Holla
2023-03-14  1:05                   ` lihuisong (C)
2023-02-27 13:09   ` [PATCH 0/2] mailbox: pcc: Support platform notification for type4 and shared interrupt lihuisong (C)
2023-03-14 11:11 ` [PATCH v2 " Huisong Li
2023-03-14 11:11   ` [PATCH v2 1/2] mailbox: pcc: Add support for platform notification handling Huisong Li
2023-03-27 11:30     ` Sudeep Holla
2023-03-27 12:25       ` lihuisong (C)
2023-03-27 13:27         ` Sudeep Holla
2023-03-14 11:11   ` [PATCH v2 2/2] mailbox: pcc: Support shared interrupt for multiple subspaces Huisong Li
2023-03-24  2:30   ` [PATCH v2 0/2] mailbox: pcc: Support platform notification for type4 and shared interrupt lihuisong (C)
2023-03-27 11:33   ` Sudeep Holla
2023-03-27 12:31     ` lihuisong (C)
2023-04-10  1:26       ` lihuisong (C)
2023-04-11 14:47         ` Robbie King
2023-04-14  1:05           ` lihuisong (C)
2023-04-14 13:48             ` Robbie King
2023-04-18  2:21               ` lihuisong (C)
2023-04-21 10:55                 ` Sudeep Holla
2023-04-23  3:58                   ` lihuisong (C)
2023-04-25 13:22                   ` lihuisong (C)
2023-04-23 11:03 ` [PATCH v3 " Huisong Li
2023-04-23 11:03   ` [PATCH v3 1/2] mailbox: pcc: Add support for platform notification handling Huisong Li
2023-04-23 11:03   ` [PATCH v3 2/2] mailbox: pcc: Support shared interrupt for multiple subspaces Huisong Li
2023-04-25 14:41   ` [PATCH v3 0/2] mailbox: pcc: Support platform notification for type4 and shared interrupt Sudeep Holla
2023-05-25 12:25     ` lihuisong (C)
2023-05-04  1:30   ` lihuisong (C)
2023-05-09  9:06   ` Sudeep Holla
2023-06-13 12:57 ` [PATCH v4 " Huisong Li
2023-06-13 12:57   ` [PATCH v4 1/2] mailbox: pcc: Add support for platform notification handling Huisong Li
2023-06-13 12:57   ` [PATCH v4 2/2] mailbox: pcc: Support shared interrupt for multiple subspaces Huisong Li
2023-06-14 15:58   ` [PATCH v4 0/2] mailbox: pcc: Support platform notification for type4 and shared interrupt Sudeep Holla
2023-07-14  6:39     ` lihuisong (C)
2023-07-21 12:31       ` lihuisong (C)
2023-06-15  1:58   ` Hanjun Guo
2023-08-01  6:38 ` [PATCH RESEND " Huisong Li
2023-08-01  6:38   ` [PATCH RESEND v4 1/2] mailbox: pcc: Add support for platform notification handling Huisong Li
2023-08-01  6:38   ` [PATCH RESEND v4 2/2] mailbox: pcc: Support shared interrupt for multiple subspaces Huisong Li
2023-08-01  9:38   ` [PATCH RESEND v4 0/2] mailbox: pcc: Support platform notification for type4 and shared interrupt Sudeep Holla
2023-08-09 11:44     ` lihuisong (C)
2023-08-17  6:50       ` lihuisong (C)
2023-08-26  2:40         ` lihuisong (C)
     [not found]           ` <AS8P193MB233566815E722D9B3B13B5EECAE2A@AS8P193MB2335.EURP193.PROD.OUTLOOK.COM>
2023-08-28  1:03             ` lihuisong (C)
2023-08-29  9:55     ` Sudeep Holla
2023-09-21 13:52   ` Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230301133626.gchca3fdaqijxwzq@bogus \
    --to=sudeep.holla@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=huangdaode@huawei.com \
    --cc=lihuisong@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=robbiek@xsightlabs.com \
    --cc=tanxiaofei@huawei.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=wangxiongfeng2@huawei.com \
    --cc=xiexiuqi@huawei.com \
    --cc=zhangzekun11@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).