linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).