linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: "lihuisong (C)" <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: Fri, 10 Mar 2023 20:14:53 +0000	[thread overview]
Message-ID: <20230310201453.5fd3wv4ydarq5yin@bogus> (raw)
In-Reply-To: <718da090-bc58-0762-c901-cbbfc3b78d5f@huawei.com>

On Sat, Mar 04, 2023 at 05:47:28PM +0800, lihuisong (C) wrote:
> 
> 在 2023/3/3 19:14, Sudeep Holla 写道:
> > On Fri, Mar 03, 2023 at 02:33:49PM +0800, lihuisong (C) wrote:
> > > Sorry for my resend. Because I found that my last reply email is not in the
> > > thread of this patch. I guess it may be send failed.
> > > 
> > > 在 2023/3/2 22:02, Sudeep Holla 写道:
> > > > No. I meant a comment saying it is not need since only one transfer can occur
> > > > at a time and mailbox takes care of locking. So chan_in_use can be accessed
> > > > without a lock.
> > > Got it. Agreed.
> > Thanks
> already modify this comment as below.
> > 
> > > > > For types no need this flag, it is always hard to understand and redundant
> > > > > design.
> > > > But does it matter ? You can even support shared interrupt for type 1&2.
> > > BTW, type 1 subspaces do not support a level triggered platform interrupt as
> > > no method is provided to clear the interrupt.
> > Agreed but there is no harm using the flag, you can add a comment that it is
> > useful only if shared interrupts are supported. That will imply it is dummy
> > for type 1. I am avoiding too many type unnecessary checks especially in IRQ
> > handler.
> 
> Understood.
> 
> > 
> > > > They support level interrupt, so we can add them too. I understand you can
> > > > test only type 3, but this driver caters for all and the code must be generic
> > > > as much as possible. I don't see any point in check for type 3 only. Only
> > > I understand what you do.
> > > But type 2 also supports the communication flow from OSPM to Platfrom.
> > > In this case, this flag will get in the way of type 2.
> > > 
> > How ?
> It should be ok if all types except for type 3 do not check this flag in
> interrupt handle.
> Namely, these types consider it as dummy, and do not use it, anywhere,
> Right?
> > 
> > > Whether the interrupt belongs to a type2 channel is only determined by
> > > the status field in Generic Communications Channel Shared Memory Region,
> > > which is done in rx_callback of PCC client.
> > Agreed, but do you see any issue using the flag even if it acts as dummy ?
> 
> I think it can work well if these types completely ignore this flag, like below.
> what do you think?
> 
> -->8
> 
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index ecd54f049de3..14405e99193d 100755
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -92,6 +92,13 @@ 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: this flag is used just to check if the interrupt needs
> + *             handling when it is shared. Since only one transfer can
> occur
> + *             at a time and mailbox takes care of locking, this flag can
> be
> + *             accessed without a lock. Note: the type only support the
> + *             communication from OSPM to Platform, like type3, use it, and
> + *             other types completely ignore it.
>   */
>  struct pcc_chan_info {
>         struct pcc_mbox_chan chan;
> @@ -102,6 +109,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 +234,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 +292,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)

I would have avoided the type check above but I understand your concern
so let us keep it like this for now.

Please submit non-RFC patch as some maintainers may not look at RFC.

-- 
Regards,
Sudeep

  reply	other threads:[~2023-03-10 20:15 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
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 [this message]
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=20230310201453.5fd3wv4ydarq5yin@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).