From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Enric Balletbo Serra <eballetbo@gmail.com>,
Mark Brown <broonie@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Tony Lindgren <tony@atomide.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
<linux-leds@vger.kernel.org>, <linux-input@vger.kernel.org>,
Daniel Thompson <daniel.thompson@linaro.org>,
Jingoo Han <jingoohan1@gmail.com>,
Richard Purdie <rpurdie@rpsys.net>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Pavel Machek <pavel@ucw.cz>, Mark Rutland <mark.rutland@arm.com>,
Russell King <linux@armlinux.org.uk>,
Javier Martinez Canillas <javier@dowhile0.org>
Subject: Re: [PATCH 4/4] mfd: tps65217: Instantiate sub-devices from device tree
Date: Thu, 8 Jun 2017 12:11:35 -0500 [thread overview]
Message-ID: <578f348c-509f-79d3-9770-73c9fcffe19c@ti.com> (raw)
In-Reply-To: <CAFqH_53v32iODN4xhoh4ho4s6grxknEDS3Ak6CHBcTAQo6fDNw@mail.gmail.com>
On 06/08/2017 08:16 AM, Enric Balletbo Serra wrote:
> 2017-06-07 18:05 GMT+02:00 Grygorii Strashko <grygorii.strashko@ti.com>:
>>
>>
>> On 06/07/2017 05:32 AM, Enric Balletbo i Serra wrote:
>>> The driver boots only via device tree but currently all the MFD sub-devices
>>> are instatiated independently of the device tree configuration, i.e
>>> although tps65217-charger is disabled by default it's instantiated by the
>>> MFD driver.
>>>
>>> Instead of register all sub-devices, if the TPS65217 device tree node has a
>>> sub-node enabled, try to instatiate them as MFD sub-devices but not
>>> instantiate sub-nodes that are not enabled.
>>>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>> ---
>>> drivers/mfd/tps65217.c | 56 +++++++-------------------------------------
>>> include/linux/mfd/tps65217.h | 6 -----
>>> 2 files changed, 9 insertions(+), 53 deletions(-)
>>>
>>> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
>>> index f769c7d..9effdda 100644
>>> --- a/drivers/mfd/tps65217.c
>>> +++ b/drivers/mfd/tps65217.c
>>> @@ -33,14 +33,7 @@
>>> #include <linux/mfd/core.h>
>>> #include <linux/mfd/tps65217.h>
>>>
>>> -static struct resource charger_resources[] = {
>>> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_AC, "AC"),
>>> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_USB, "USB"),
>>> -};
>>> -
>>> -static struct resource pb_resources[] = {
>>> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_PB, "PB"),
>>> -};
>>
>> May be I messed smth, but how about interrupts for charger and pwrbutton?
>>
>
> I might be wrong but as this driver is DT-only these resources came
> from the DT. The driver calls platform_get_irq_byname and then
> of_irq_get_byname.
>
> i.e arch/arm/boot/dts/am335x-bone-common.dtsi
>
> &tps {
> charger {
> interrupts = <0>, <1>;
> interrupt-names = "USB", "AC";
> status = "okay";
> };
>
> pwrbutton {
> interrupts = <2>;
> status = "okay";
> };
> };
Sry, but this make no sense - those IRQ configuration is static,
so it should be defined in arch/arm/boot/dts/tps65217.dtsi at least.
But, again, it also not required, because it is strictly static for
this particular device and so defined in code.
And platform_get_irq_byname() should perfectly work with mfd_add_devices().
Also not that tps65217.dtsi included in below files, but
./arch/arm/boot/dts/am335x-bone-common.dtsi:/include/ "tps65217.dtsi"
./arch/arm/boot/dts/am335x-chilisom.dtsi:/include/ "tps65217.dtsi"
./arch/arm/boot/dts/am335x-nano.dts:#include "tps65217.dtsi"
./arch/arm/boot/dts/am335x-pepper.dts:/include/ "tps65217.dtsi"
./arch/arm/boot/dts/am335x-sl50.dts:#include "tps65217.dtsi"
but IRQs defined only in
./arch/arm/boot/dts/am335x-bone-common.dtsi: interrupt-names = "USB", "AC";
./arch/arm/boot/dts/am335x-chiliboard.dts: interrupt-names = "USB", "AC";
So how are other boards working?
>
>>> +#define TPS65217_NUM_IRQ 3
>>>
>>> static void tps65217_irq_lock(struct irq_data *data)
>>> {
>>> @@ -86,29 +79,6 @@ static struct irq_chip tps65217_irq_chip = {
>>> .irq_disable = tps65217_irq_disable,
>>> };
>>>
>>> -static struct mfd_cell tps65217s[] = {
>>> - {
>>> - .name = "tps65217-pmic",
>>> - .of_compatible = "ti,tps65217-pmic",
>>> - },
>>> - {
>>> - .name = "tps65217-bl",
>>> - .of_compatible = "ti,tps65217-bl",
>>> - },
>>> - {
>>> - .name = "tps65217-charger",
>>> - .num_resources = ARRAY_SIZE(charger_resources),
>>> - .resources = charger_resources,
>>> - .of_compatible = "ti,tps65217-charger",
>>> - },
>>> - {
>>> - .name = "tps65217-pwrbutton",
>>> - .num_resources = ARRAY_SIZE(pb_resources),
>>> - .resources = pb_resources,
>>> - .of_compatible = "ti,tps65217-pwrbutton",
>>> - },
>>> -};
>>> -
>>> static irqreturn_t tps65217_irq_thread(int irq, void *data)
>>> {
>>> struct tps65217 *tps = data;
>>> @@ -359,23 +329,8 @@ static int tps65217_probe(struct i2c_client *client,
>>> return ret;
>>> }
>>>
>>> - if (client->irq) {
>>> + if (client->irq)
>>> tps65217_irq_init(tps, client->irq);
>>> - } else {
>>> - int i;
>>> -
>>> - /* Don't tell children about IRQ resources which won't fire */
>>> - for (i = 0; i < ARRAY_SIZE(tps65217s); i++)
>>> - tps65217s[i].num_resources = 0;
>>> - }
>>> -
>>> - ret = devm_mfd_add_devices(tps->dev, -1, tps65217s,
>>> - ARRAY_SIZE(tps65217s), NULL, 0,
>>> - tps->irq_domain);
>>> - if (ret < 0) {
>>> - dev_err(tps->dev, "mfd_add_devices failed: %d\n", ret);
>>> - return ret;
>>> - }
>>
>> And as I remember there was a request to use mfd_add_devices()
>> and not of_platform_populate() for mfd sub-devices instantiation.
>>
>
> From what I know or you add the sub-devices via mfd_add_devices or
> using the DT with of_platform_populate, and the first is probably the
> preferred, but in this specific case this driver is DT-only so IMHO
> makes more sense adding via the DT, there are already some bindings
> i.e:
> arch/arm/boot/dts/tps65217.dtsi
> arch/arm/boot/dts/am335x-bone-common.dtsi
>
> Let me explain a bit more, assume that you have another AM335x with
> the TPS65217 PMIC but you don't want the charger because is not wired
> in your board. Your board DT will include the tps65217.dtsi, in this
> file you can see:
>
> &tps {
> ...
> charger {
> compatible = "ti,tps65217-charger";
> status = "disabled";
> };
> ...
> };
>
> Seems that's fine but actually not works as expected, the TPS65217 MFD
> registers all the sub-devices so the charger is enabled and running
> even you have status = "disabled" in your DT. This looks incoherent to
> me, hence I replaced the devm_mfd_add_devices() for the
> of_platform_populate which takes care of the status propriety and only
> calls the probe of the sub-devices that match and are enabled (status
> = "okay").
I can't find links on corresponding discussions, but mfd_add_devices() is
preferred for MDF devices. Below is one commit i've found. Also you can compare number of
drivers using mfd_add_devices() and of_platform_populate().
regarding your problem - I think, It might be reasonable from your side to propose change to
mfd_add_device() which will take into account 'status = "disabled";' DT property.
---
commit 4531156db726d27e593d35800d43c74be4e393b9
Author: Keerthy <j-keerthy@ti.com>
Date: Mon Sep 19 13:09:05 2016 +0530
mfd: tps65218: Use mfd_add_devices instead of of_platform_populate
mfd_add_devices enables parsing device tree nodes without compatibles
for regulators and gpio modules. Replace of_platform_populate with
mfd_add_devices. mfd_cell currently is populated with regulators,
gpio and powerbutton.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
--
regards,
-grygorii
next prev parent reply other threads:[~2017-06-08 17:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 10:32 [PATCH 1/4] dt-bindings: tps65217: Update binding documentation Enric Balletbo i Serra
2017-06-07 10:32 ` [PATCH 2/4] ARM: dts: tps65217: Add backlight and pmic device Enric Balletbo i Serra
2017-06-07 10:32 ` [PATCH 3/4] regulator: tps65217: Fix module autoload for devices registered via OF Enric Balletbo i Serra
2017-06-07 10:32 ` [PATCH 4/4] mfd: tps65217: Instantiate sub-devices from device tree Enric Balletbo i Serra
2017-06-07 16:05 ` Grygorii Strashko
2017-06-08 13:16 ` Enric Balletbo Serra
2017-06-08 17:11 ` Grygorii Strashko [this message]
2017-06-08 21:35 ` Enric Balletbo Serra
2017-06-08 22:30 ` Javier Martinez Canillas
2017-06-08 23:47 ` Grygorii Strashko
2017-06-09 0:00 ` Javier Martinez Canillas
2017-06-09 9:55 ` Enric Balletbo Serra
2017-06-09 14:03 ` [PATCH 1/4] dt-bindings: tps65217: Update binding documentation Rob Herring
2017-06-09 22:30 ` Enric Balletbo Serra
2017-06-13 14:43 ` Rob Herring
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=578f348c-509f-79d3-9770-73c9fcffe19c@ti.com \
--to=grygorii.strashko@ti.com \
--cc=broonie@kernel.org \
--cc=daniel.thompson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=eballetbo@gmail.com \
--cc=enric.balletbo@collabora.com \
--cc=jacek.anaszewski@gmail.com \
--cc=javier@dowhile0.org \
--cc=jingoohan1@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=rpurdie@rpsys.net \
--cc=tony@atomide.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).