All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lina Iyer <ilina@codeaurora.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Boyd <swboyd@chromium.org>,
	Evan Green <evgreen@chromium.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	rplsssn@codeaurora.org, linux-arm-msm@vger.kernel.org,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Doug Anderson <dianders@chromium.org>
Subject: Re: [PATCH v2 0/8] qcom: support wakeup capable GPIOs
Date: Wed, 30 Jan 2019 10:03:13 -0700	[thread overview]
Message-ID: <20190130170313.GA6069@codeaurora.org> (raw)
In-Reply-To: <CACRpkdZVrwviuXo_3epzDTacrYRnyTAWOLKSpNG7j_0Fv8CkEg@mail.gmail.com>

On Mon, Jan 28 2019 at 07:19 -0700, Linus Walleij wrote:
>On Thu, Jan 24, 2019 at 9:22 PM Lina Iyer <ilina@codeaurora.org> wrote:
>
>> This is a bug fix submission of the v1 posted here [1]. The discussion on how
>> to represent the wakeup-parent interrupt controller is on-going [2] here. The
>> reiew comments in [1], from Doug and Stephen are addressed in this patch.
>>
>> The series attempts to add GPIO chip in hierarchy with PDC interrupt controller
>> that can detect and wakeup the GPIOs routed to it, when the system is
>> suspend/deep sleep mode.
>
>I kind of start to get the hang of this now. This is starting to
>look finished. Some words on the hierarchical GPIO IRQs:
>
>I have started to look into hierarchical GPIO+irqchip since
>the usage of such is spreading.
>
>I have been on to Thierry patches trying to make him implement
>more generic helpers in the gpiolib irqchip library functions.
>
>In short I see the following:
>
>- Hierarchical gpiochips all have .alloc() and .translate() functions
>  that look more or less the same.
>
Yes.

>- They all fall down to remapping either tuples or entire ranges
>  of IRQs from parent to child with a linear look-up table on
>  allocation.
>
I would think this would be the generic case, unless its QCOM, where we
would want to push the tuples up hierarchy :(

>So my idea would be to add support for this into the gpiolib
>hierarchical irqchip helper: by supplying a parent irqdomain
>and a list of translation tuples, we should be able to handle
>pretty much any hierarchical GPIO irqdomain (famous last
>words).
>
We would read the tuples from DT? Also please consider Rob's idea of
specifying hierarchy from [2].

>Right now I am converting the IXP4xx platform to hierarchical
>IRQ from the ground up (it is not even using device tree
>so it is a bit of a challenge) but it seems to be working.
>
>So I will try to post this in some hopefully working form, and
>on top of those changes or before them introduce some
>helpers in the core for hierarchical irqs. Or I fail.
>
Thanks, please copy me on the thread. I would not want to miss this.

>Anyways, I do not think my ambitions for refactoring the
>helpers can stand in the way of support for these use cases
>and new hardware, so maybe we need to merge a few
>more hierarchical drivers just bypassing the gpiolib
>helpers. I don't want to block development, and I suspect
>Thierry might be getting annoyed at me at this point, so
>we should maybe just pile up a few more hierarchical
>chips so I can refactor them later.
>
>What do you think?
>
I attempted refactoring the .alloc and .translate and for a generic case
and it seemed like it would fit the bill very well. Will await your
patches.

Thanks,
Lina

      reply	other threads:[~2019-01-30 17:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 20:21 [PATCH v2 0/8] qcom: support wakeup capable GPIOs Lina Iyer
2019-01-24 20:21 ` [PATCH v2 1/8] gpio: Add support for hierarchical IRQ domains Lina Iyer
2019-01-24 20:21 ` [PATCH v2 2/8] irqdomain: add bus token DOMAIN_BUS_WAKEUP Lina Iyer
2019-02-15 21:18   ` Stephen Boyd
2019-02-15 21:18     ` Stephen Boyd
2019-01-24 20:22 ` [PATCH v2 3/8] drivers: irqchip: add PDC irqdomain for wakeup capable GPIOs Lina Iyer
2019-01-24 20:22 ` [PATCH v2 4/8] dt-bindings: sdm845-pinctrl: add wakeup interrupt parent for GPIO Lina Iyer
2019-01-24 20:22 ` [PATCH v2 5/8] drivers: pinctrl: msm: setup GPIO irqchip hierarchy Lina Iyer
2019-01-30 22:45   ` Stephen Boyd
2019-01-30 22:45     ` Stephen Boyd
2019-01-31 16:34     ` Lina Iyer
2019-01-24 20:22 ` [PATCH v2 6/8] arm64: dts: qcom: add PDC interrupt controller for SDM845 Lina Iyer
2019-01-24 20:22 ` [PATCH v2 7/8] arm64: dts: qcom: setup PDC as wakeup parent for GPIOs " Lina Iyer
2019-01-24 20:22 ` [PATCH v2 8/8] arm64: defconfig: enable PDC interrupt controller for Qualcomm SDM845 Lina Iyer
2019-01-28 14:17 ` [PATCH v2 0/8] qcom: support wakeup capable GPIOs Linus Walleij
2019-01-30 17:03   ` Lina Iyer [this message]

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=20190130170313.GA6069@codeaurora.org \
    --to=ilina@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=evgreen@chromium.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=rplsssn@codeaurora.org \
    --cc=swboyd@chromium.org \
    --cc=thierry.reding@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.