public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: "Maulik Shah (mkshah)" <quic_mkshah@quicinc.com>
Cc: <linux-kernel@vger.kernel.org>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	<linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH 2/5] irqchip/qcom-pdc: Kill non-wakeup irqdomain
Date: Mon, 28 Feb 2022 20:00:55 +0000	[thread overview]
Message-ID: <87y21u69s8.wl-maz@kernel.org> (raw)
In-Reply-To: <22ac147c-fb47-fc8c-8e10-8e67db94fbf8@quicinc.com>

On Mon, 28 Feb 2022 19:29:41 +0000,
"Maulik Shah (mkshah)" <quic_mkshah@quicinc.com> wrote:
> 
> Hi,
> 
> On 2/24/2022 3:42 PM, Marc Zyngier wrote:
> > A careful look at the way the PDC driver works shows that:
> > 
> > - all interrupts are in the same space
> > - all interrupts are treated the same
> > 
> > And yet the driver creates two domains based on whether
> > the interrupt gets mapped directly or from the pinctrl code,
> > which is obviously a waste of resources.
> The GPIO is kept under separate domain to handle extra configuration
> for wake GPIO handling.

Which extra configuration? The irq_chip structure is the same, the
translation is the same, the GIC mapping is the same, and the select
method only serves to select between two irq domains that do the same
thing.

So please point me to what the difference is.

> 
> On targets like SM8150/SM8250 each wake up capable GPIO (if totan n)
> line has dedicated parent PDC irq (if total m, n = m) associated with
> it.
> However on targets like sdx55 PDC has muxes where each wake GPIO (if
> total n) line goes through each PDC muxes (if total m, n > m) and
> any of these muxes can be used to route any one GPIO to PDC (and
> parent GIC) but unlike other targets it doesn't have one to one
> mapping for GPIO to GIC interrupt.
> So this will need to be kept as is to support sdx55 target.

As far as I can tell, the current code doesn't have any support for
this. And if there is a mux involved in the interrupt routing, this
should be something entierly separate, as the current code is strictly
hierarchical.

What am I missing?

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-02-28 20:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-24 10:12 [PATCH 0/5] irqchip/qcom-pdc: Assorted cleanups and fixes Marc Zyngier
2022-02-24 10:12 ` [PATCH 1/5] irqchip/qcom-pdc: Kill PDC_NO_PARENT_IRQ Marc Zyngier
2022-02-28 17:40   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-28 19:23   ` [PATCH 1/5] " Maulik Shah (mkshah)
2022-03-01 10:11   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-24 10:12 ` [PATCH 2/5] irqchip/qcom-pdc: Kill non-wakeup irqdomain Marc Zyngier
2022-02-28 17:40   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-28 19:29   ` [PATCH 2/5] " Maulik Shah (mkshah)
2022-02-28 20:00     ` Marc Zyngier [this message]
2022-03-01 10:11   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-24 10:12 ` [PATCH 3/5] irqchip/qcom-pdc: Kill qcom_pdc_translate helper Marc Zyngier
2022-02-28 17:40   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-28 19:30   ` [PATCH 3/5] " Maulik Shah (mkshah)
2022-03-01 10:11   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-24 10:12 ` [PATCH 4/5] irqchip/qcom-pdc: Fix broken locking Marc Zyngier
2022-02-28 17:40   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-28 19:30   ` [PATCH 4/5] " Maulik Shah (mkshah)
2022-03-01 10:11   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-24 10:12 ` [PATCH 5/5] irqchip/qcom-pdc: Drop open coded version of __assign_bit() Marc Zyngier
2022-02-28 17:40   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier
2022-02-28 19:31   ` [PATCH 5/5] " Maulik Shah (mkshah)
2022-03-01 10:11   ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier

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=87y21u69s8.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_mkshah@quicinc.com \
    --cc=tglx@linutronix.de \
    /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