devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Kumar Gala <galak@codeaurora.org>,
	Grant Likely <grant.likely@linaro.org>,
	Courtney Cavin <courtney.cavin@sonymobile.com>,
	Josh Cartwright <joshc@codeaurora.org>
Subject: Re: [RFC PATCH v2 1/5] mfd: qpnp: add support for Qualcomm QPNP PMICs
Date: Fri, 11 Jul 2014 10:07:18 +0100	[thread overview]
Message-ID: <20140711090718.GA30519@lee--X1> (raw)
In-Reply-To: <53BEB1DB.6010301@mm-sol.com>

On Thu, 10 Jul 2014, Stanimir Varbanov wrote:
> >>>> The Qualcomm QPNP PMIC chips are components used with the
> >>>> Snapdragon 800 series SoC family.  This driver exists
> >>>> largely as a glue mfd component, it exists to be an owner
> >>>> of an SPMI regmap for children devices described in
> >>>> device tree.
> >>>>
> >>>> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> >>>> Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
> >>>> ---
> >>>>  drivers/mfd/Kconfig     |   15 ++++++
> >>>>  drivers/mfd/Makefile    |    1 +
> >>>>  drivers/mfd/qpnp-spmi.c |  129 +++++++++++++++++++++++++++++++++++++++++++++++
> >>>>  3 files changed, 145 insertions(+), 0 deletions(-)
> >>>>  create mode 100644 drivers/mfd/qpnp-spmi.c
> >>>>
> >>>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >>>> index ee8204c..258b733 100644
> >>>> --- a/drivers/mfd/Kconfig
> >>>> +++ b/drivers/mfd/Kconfig
> >>>> @@ -524,6 +524,21 @@ config MFD_PM8921_CORE
> >>>>  	  Say M here if you want to include support for PM8921 chip as a module.
> >>>>  	  This will build a module called "pm8921-core".
> >>>>  
> >>>> +config MFD_QPNP_SPMI
> >>>> +	tristate "Qualcomm QPNP SPMI PMIC"
> >>>> +	depends on ARCH_QCOM || COMPILE_TEST
> >>>> +	depends on OF
> >>>> +	select MFD_CORE
> >>>> +	select REGMAP_SPMI
> >>>> +	help
> >>>> +	  This enables support for the Qualcomm QPNP SPMI PMICs.
> >>>> +	  These PMICs are currently used with the Snapdragon 800 series of
> >>>> +	  SoCs.  Note, that this will only be useful paired with descriptions
> >>>> +	  of the independent functions as children nodes in the device tree.
> >>>
> 
> <snip>
> 
> >>>
> >>>> + * This program is distributed in the hope that it will be useful,
> >>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >>>> + * GNU General Public License for more details.
> >>>> + */
> >>>> +#include <linux/kernel.h>
> >>>> +#include <linux/module.h>
> >>>> +#include <linux/spmi.h>
> >>>> +#include <linux/regmap.h>
> >>>> +#include <linux/of_address.h>
> >>>> +#include <linux/slab.h>
> >>>> +#include <linux/mfd/core.h>
> >>>> +
> >>>> +#define QPNP_RESOURCE_SIZE	256
> >>>> +
> >>>> +static const struct regmap_config qpnp_regmap_config = {
> >>>> +	.reg_bits	= 16,
> >>>> +	.val_bits	= 8,
> >>>> +	.max_register	= 0xffff,
> >>>> +};
> >>>> +
> >>>> +static int qpnp_index_to_resource(struct device_node *np, int index,
> >>>> +				  struct resource *res)
> >>>> +{
> >>>> +	const char *name = NULL;
> >>>> +	const __be32 *addrp;
> >>>> +	u64 addr;
> >>>> +
> >>>> +	addrp = of_get_address(np, index, NULL, NULL);
> >>>> +	if (!addrp)
> >>>> +		return -EINVAL;
> >>>> +
> >>>> +	addr = of_read_number(addrp, 1);
> >>>> +	if (addr == OF_BAD_ADDR)
> >>>> +		return -EINVAL;
> >>>> +
> >>>> +	of_property_read_string_index(np, "reg-names", index, &name);
> >>>> +
> >>>> +	res->start = addr;
> >>>> +	res->end = addr + QPNP_RESOURCE_SIZE - 1;
> >>>> +	res->flags = IORESOURCE_REG;
> >>>> +	res->name = name ? name : np->name;
> >>>> +
> >>>> +	return 0;
> >>>> +}
> >>>> +
> >>>> +static int qpnp_add_device(struct spmi_device *root, struct device_node *child)
> >>>> +{
> >>>> +	struct mfd_cell cell = {};
> >>>> +	struct resource *res, *r;
> >>>> +	int num_resources = 0;
> >>>> +	const char *compat;
> >>>> +	int ret, i;
> >>>> +
> >>>> +	compat = of_get_property(child, "compatible", NULL);
> >>>> +	if (!compat)
> >>>> +		return -ENODEV;
> >>>> +
> >>>> +	while (of_get_address(child, num_resources, NULL, NULL))
> >>>> +		num_resources++;
> >>>> +
> >>>> +	if (!num_resources)
> >>>> +		return -ENODEV;
> >>>> +
> >>>> +	res = kcalloc(num_resources, sizeof(*res), GFP_KERNEL);
> >>>> +	if (!res)
> >>>> +		return -ENOMEM;
> >>>> +
> >>>> +	r = res;
> >>>> +	for (i = 0; i < num_resources; i++, r++)
> >>>> +		qpnp_index_to_resource(child, i, r);
> >>>> +
> >>>> +	cell.name = kasprintf(GFP_KERNEL, "%x.%04x.%s", root->usid,
> >>>> +			      (u16)res[0].start, child->name);
> >>>> +	cell.of_compatible = compat;
> >>>> +	cell.num_resources = num_resources;
> >>>> +	cell.resources = res;
> >>>> +
> >>>> +	ret = mfd_add_devices(&root->dev, PLATFORM_DEVID_NONE, &cell, 1,
> >>>> +			      NULL, 0, NULL);
> >>>> +
> >>>> +	kfree(res);
> >>>> +	kfree(cell.name);
> >>>> +
> >>>> +	return ret;
> >>>> +}
> >>>> +
> >>>> +static int qpnp_probe(struct spmi_device *sdev)
> >>>> +{
> >>>> +	struct device_node *root = sdev->dev.of_node;
> >>>> +	struct device_node *child;
> >>>> +	struct regmap *regmap;
> >>>> +
> >>>> +	regmap = devm_regmap_init_spmi_ext(sdev, &qpnp_regmap_config);
> >>>> +	if (IS_ERR(regmap))
> >>>> +		return PTR_ERR(regmap);
> >>>> +
> >>>> +	for_each_available_child_of_node(root, child)
> >>>> +		qpnp_add_device(sdev, child);
> >>>
> >>> This entire driver looks like a re-write of of_platform_populate().
> >>>
> >>> Why?
> >>
> >> of_platform_populate is not used because the PMIC function resources are
> >> non-translatable. You can see that the resources are of type
> >> IORESOURCE_REG (qpnp_index_to_resource()) not IORESOURCE_MEM or _IO.
> >>
> >> The whole point of this mfd driver is to parse devicetree to prepare
> >> resources for every child and create platform device for it through
> >> mfd_add_devices(). Then the PMIC function driver got its resources and
> >> use them as register addresses passed to regmap. These register accesses
> >> hits the SPMI controller which is the physical interface between PMIC's
> >> and SoC.
> > 
> > I can't help but think that if this is required, it should be part of
> > the core OF code, rather than doing your own thing which looks
> > frighteningly like existing framework functionality.
> 
> does it make sense to have a common of_mfd code for devicetree parsing?
> Is that discussed already? I mean presently the mfd_cell resources and
> number of resources are passed by the mfd_add_devices users. Is it
> possible to have common code which parses devicetree sub-nodes of the
> parent device_node and fill resources/create platform devices for them.

I'm not sure it does.  Normally users _either_ represent devices in
MFD cells from within the driver _or_ populate using existing DT
interfaces i.e. of_platform_populate().  This is the first time I've
seen someone attempt to parse the entire MFD node structure from
within a driver.

After searching for some documentation to try and figure this out, I
noticed that you've also missed a patch from your set:

  mfd: qpnp-spmi: document DT bindings for Qualcomm QPNP PMICs

... which might help enlighten the DT guys.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2014-07-11  9:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-03 13:13 [RFC PATCH v2 0/5] Support for Qualcomm QPNP PMIC's Stanimir Varbanov
2014-07-03 13:13 ` [RFC PATCH v2 1/5] mfd: qpnp: add support for Qualcomm QPNP PMICs Stanimir Varbanov
     [not found]   ` <1404393243-7324-2-git-send-email-svarbanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-07-09 14:34     ` Lee Jones
2014-07-09 15:24       ` Stanimir Varbanov
2014-07-10  8:36         ` Lee Jones
2014-07-10 15:31           ` Stanimir Varbanov
2014-07-11  9:07             ` Lee Jones [this message]
2014-07-14 13:43               ` Stanimir Varbanov
2014-07-14 14:03                 ` Lee Jones
2014-07-15  9:27                   ` Stanimir Varbanov
     [not found] ` <1404393243-7324-1-git-send-email-svarbanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-07-03 13:14   ` [RFC PATCH v2 2/5] dt: qcom: msm8974: add qpnp-spmi device nodes Stanimir Varbanov
     [not found]     ` <1404393243-7324-3-git-send-email-svarbanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-07-09 14:10       ` Lee Jones
2014-07-09 15:28         ` Stanimir Varbanov
2014-07-03 13:14 ` [RFC PATCH v2 3/5] rtc: add qpnp rtc driver Stanimir Varbanov
2014-07-09 18:07   ` Stephen Boyd
2014-07-10  7:38     ` Stanimir Varbanov
2014-07-10 13:08   ` Bjorn Andersson
2014-07-10 15:43     ` Stanimir Varbanov
2014-07-15  9:51       ` Stanimir Varbanov
2014-07-03 13:14 ` [RFC PATCH v2 4/5] dt: msm8974: add qpnp rtc device node Stanimir Varbanov
2014-07-03 13:14 ` [RFC PATCH v2 5/5] dt: rtc: add binding document for qpnp rtc Stanimir Varbanov

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=20140711090718.GA30519@lee--X1 \
    --to=lee.jones@linaro.org \
    --cc=courtney.cavin@sonymobile.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=joshc@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=svarbanov@mm-sol.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).