From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH 3/7] drivers: irqchip: add PDC irqdomain for wakeup capable GPIOs
Date: Fri, 11 Jan 2019 14:55:51 -0800
Message-ID: <154724735183.169631.5181161977573120432@swboyd.mtv.corp.google.com>
References: <20181219221105.3004-1-ilina@codeaurora.org> <20181219221105.3004-4-ilina@codeaurora.org> <154533717951.79149.1309452983166815703@swboyd.mtv.corp.google.com> <20190107184836.GG14960@codeaurora.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20190107184836.GG14960@codeaurora.org>
Sender: linux-kernel-owner@vger.kernel.org
To: Lina Iyer <ilina@codeaurora.org>
Cc: evgreen@chromium.org, marc.zyngier@arm.com, linux-kernel@vger.kernel.org, rplsssn@codeaurora.org, linux-arm-msm@vger.kernel.org, thierry.reding@gmail.com, bjorn.andersson@linaro.org
List-Id: linux-arm-msm@vger.kernel.org

Quoting Lina Iyer (2019-01-07 10:48:36)
> On Thu, Dec 20 2018 at 13:19 -0700, Stephen Boyd wrote:
> >Quoting Lina Iyer (2018-12-19 14:11:01)
>=20
> >> +static const struct pdc_gpio_pin_data sdm845_gpio_data =3D {
> >> +       .size =3D ARRAY_SIZE(sdm845_gpio_pdc_map),
> >> +       .map =3D sdm845_gpio_pdc_map,
> >> +};
> >> +
> >> +const struct of_device_id pdc_gpio_match_table[] =3D {
> >> +       { .compatible =3D "qcom,845-pdc", .data =3D &sdm845_gpio_data =
},
> >
> >Why not qcom,sdm845-pdc?
> >
> The compatible matches the compatible specified in the PDC driver. Not
> sure why the 'sdm' was left out at that time.

Are you going to add sdm?

>=20
> >> +       { },
> >> +};
> >
> >I wonder why we wouldn't just put this all into the qcom-pdc.c file at
> >the bottom and then have that IRQCHIP_DECLARE() macros call small
> >functions that pass the pdc to gpio mapping table to qcom_pdc_init()
> >that takes a third argument?
> >
> We could. I feel we would be adding tables like this and it just
> clutters up the driver file. May be in the future we could move to
> target specific data file like the gpios, but that could be excessive
> too. Thought this might be a compromise. I am open to change.

Ok. The benefit to my approach is that we don't do the string match
twice. We do it once and sacrifice a little code space to jump to the
real init function with the data we want. We can then put those chip
tables inside some #ifdef to save space and allow configurations to turn
off everything in EXPERT mode but leave everything default enabled
otherwise.

>=20
> >I really hope that in the future all the gpios can be wakeup capable so
> >that we don't need to have the table at all!
> >
> I doubt there are plans to support that in hardware. We should plan for
> supporting tables like this for other chipsets based on the PDC
> architecture.
>=20

Uh oh. That's sad.