All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Chris Zhong <zyw@rock-chips.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	sameo@linux.intel.com, lgirdwood@gmail.com, broonie@kernel.org,
	a.zummo@towertech.it, mturquette@linaro.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	rtc-linux@googlegroups.com, grant.likely@linaro.org,
	hl@rock-chips.com, huangtao@rock-chips.com, cf@rock-chips.com,
	zhangqing@rock-chips.com, xxx@rock-chips.com,
	dianders@chromium.org, heiko@sntech.de, olof@lixom.net,
	sonnyrao@chromium.org, dtor@chromium.org,
	javier.martinez@collabora.co.uk, kever.yang@rock-chips.com
Subject: Re: [PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808
Date: Tue, 26 Aug 2014 12:20:13 +0100	[thread overview]
Message-ID: <20140826112013.GK9574@lee--X1> (raw)
In-Reply-To: <53FC63EE.6060104@rock-chips.com>

On Tue, 26 Aug 2014, Chris Zhong wrote:
> On 08/26/2014 06:20 PM, Lee Jones wrote:
> >On Tue, 26 Aug 2014, Chris Zhong wrote:
> >>On 08/26/2014 05:22 PM, Lee Jones wrote:
> >>>On Mon, 25 Aug 2014, Chris Zhong wrote:
> >>>>On 08/20/2014 05:21 PM, Lee Jones wrote:
> >>>>>On Wed, 20 Aug 2014, Chris Zhong wrote:
> >>>>>
> >>>>>>The RK808 chip is a power management IC for multimedia and handheld
> >>>>>>devices. It contains the following components:
> >>>>>>
> >>>>>>- Regulators
> >>>>>>- RTC
> >>>>>>
> >>>>>>The rk808 core driver is registered as a platform driver and provides
> >>>>>>communication through I2C with the host device for the different
> >>>>>>components.
> >>>>>>
> >>>>>>Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> >>>>>>---
> >>>[...]
> >>>
> >>>>>>+	rk808->pdata = pdata;
> >>>>>Remove pdata from 'struct rk808'.  You can obtain it from dev.
> >>>>Can I keep this pdata in rk808, because it is used in the regulator driver.
> >>>>The one obtain from dev maybe empty.
> >>>If the one in dev is empty, you should populate that instead.
> >>So, should I malloc a pada, and assign it to client->dev?
> >If client->dev.pdata is NULL, yes.
> >
> >But actually, I have more important questions that need to be answered
> >first.  Ones which I would normally be able to answer myself if the
> >patch-set had been sent as one (i.e. threaded) instead of as
> >individual patches:
> >
> >- What are you using pdata for?
> 
> For save some properties,
> 
> like "rockchip,system-power-controller" in MFD
> and some regulator properties in regulator/rk808...
> 
> >- Where is pdata populated?
> 
> It is populated in probe in mfd/rk808.c
> 
> actually, I copy it from tps65910.c
> 
> 
> >- Where is pdata used?
> 
> pdata is used in mfd and regulator

I'm still a little confused.  I see it being populated in the MFD
driver, then I only see the attributes populated in the MFD driver
used in the MFD driver and nowhere else?  I do see other attributes
used in the regulator driver i.e. .of_node[], but these are then used
only in the regulator driver, thus they shouldn't really be pdata.

Let me put it another way:

struct rk808_board {
+       int irq;
+       int irq_base;
+       int wakeup;
+       bool pm_off;
+       struct regulator_init_data *rk808_init_data[rk808_NUM_REGULATORS];
+       struct device_node *of_node[rk808_NUM_REGULATORS];
+       int pmic_sleep_gpio;
+       unsigned int dcdc_slp_voltage[3]; /* buckx_voltage in uV */
+       unsigned int ldo_slp_voltage[7];
+};

For each of the above:

- Can it be passed from platform data i.e. arch/<arch>/{plat,mach}-*?
- Can it use local (not passed from driver to driver) variable instead?

If the answer to the first question is 'no' and/or if the answer to
the second question is 'yes', then it shouldn't be platform data.

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

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Chris Zhong <zyw-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org,
	mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	hl-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	cf-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	xxx-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org,
	olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
	sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	dtor-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org,
	kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org
Subject: Re: [PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808
Date: Tue, 26 Aug 2014 12:20:13 +0100	[thread overview]
Message-ID: <20140826112013.GK9574@lee--X1> (raw)
In-Reply-To: <53FC63EE.6060104-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Tue, 26 Aug 2014, Chris Zhong wrote:
> On 08/26/2014 06:20 PM, Lee Jones wrote:
> >On Tue, 26 Aug 2014, Chris Zhong wrote:
> >>On 08/26/2014 05:22 PM, Lee Jones wrote:
> >>>On Mon, 25 Aug 2014, Chris Zhong wrote:
> >>>>On 08/20/2014 05:21 PM, Lee Jones wrote:
> >>>>>On Wed, 20 Aug 2014, Chris Zhong wrote:
> >>>>>
> >>>>>>The RK808 chip is a power management IC for multimedia and handheld
> >>>>>>devices. It contains the following components:
> >>>>>>
> >>>>>>- Regulators
> >>>>>>- RTC
> >>>>>>
> >>>>>>The rk808 core driver is registered as a platform driver and provides
> >>>>>>communication through I2C with the host device for the different
> >>>>>>components.
> >>>>>>
> >>>>>>Signed-off-by: Chris Zhong <zyw-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >>>>>>---
> >>>[...]
> >>>
> >>>>>>+	rk808->pdata = pdata;
> >>>>>Remove pdata from 'struct rk808'.  You can obtain it from dev.
> >>>>Can I keep this pdata in rk808, because it is used in the regulator driver.
> >>>>The one obtain from dev maybe empty.
> >>>If the one in dev is empty, you should populate that instead.
> >>So, should I malloc a pada, and assign it to client->dev?
> >If client->dev.pdata is NULL, yes.
> >
> >But actually, I have more important questions that need to be answered
> >first.  Ones which I would normally be able to answer myself if the
> >patch-set had been sent as one (i.e. threaded) instead of as
> >individual patches:
> >
> >- What are you using pdata for?
> 
> For save some properties,
> 
> like "rockchip,system-power-controller" in MFD
> and some regulator properties in regulator/rk808...
> 
> >- Where is pdata populated?
> 
> It is populated in probe in mfd/rk808.c
> 
> actually, I copy it from tps65910.c
> 
> 
> >- Where is pdata used?
> 
> pdata is used in mfd and regulator

I'm still a little confused.  I see it being populated in the MFD
driver, then I only see the attributes populated in the MFD driver
used in the MFD driver and nowhere else?  I do see other attributes
used in the regulator driver i.e. .of_node[], but these are then used
only in the regulator driver, thus they shouldn't really be pdata.

Let me put it another way:

struct rk808_board {
+       int irq;
+       int irq_base;
+       int wakeup;
+       bool pm_off;
+       struct regulator_init_data *rk808_init_data[rk808_NUM_REGULATORS];
+       struct device_node *of_node[rk808_NUM_REGULATORS];
+       int pmic_sleep_gpio;
+       unsigned int dcdc_slp_voltage[3]; /* buckx_voltage in uV */
+       unsigned int ldo_slp_voltage[7];
+};

For each of the above:

- Can it be passed from platform data i.e. arch/<arch>/{plat,mach}-*?
- Can it use local (not passed from driver to driver) variable instead?

If the answer to the first question is 'no' and/or if the answer to
the second question is 'yes', then it shouldn't be platform data.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-08-26 11:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-20  3:31 [PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808 Chris Zhong
2014-08-20  3:31 ` Chris Zhong
2014-08-20  9:21 ` Lee Jones
2014-08-20  9:21   ` Lee Jones
2014-08-25  2:19   ` Chris Zhong
2014-08-25  2:19     ` Chris Zhong
2014-08-26  9:22     ` Lee Jones
2014-08-26  9:22       ` Lee Jones
2014-08-26 10:05       ` Chris Zhong
2014-08-26 10:20         ` Lee Jones
2014-08-26 10:20           ` Lee Jones
2014-08-26 10:39           ` Chris Zhong
2014-08-26 10:39             ` Chris Zhong
2014-08-26 11:20             ` Lee Jones [this message]
2014-08-26 11:20               ` Lee Jones
2014-08-26 12:05               ` Chris Zhong
2014-08-26 12:23                 ` Lee Jones
2014-08-26 12:37                   ` Chris Zhong
2014-08-26 12:37                     ` Chris Zhong
2014-08-26 16:20                     ` Lee Jones
2014-08-26 16:20                       ` Lee Jones
2014-08-26 16:28       ` Dmitry Torokhov
2014-08-26 17:19         ` Doug Anderson
2014-08-26 17:19           ` Doug Anderson
2014-08-27 11:27         ` Lee Jones
2014-08-27 11:27           ` Lee Jones
2014-08-20 21:59 ` Doug Anderson
2014-08-20 21:59   ` Doug Anderson

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=20140826112013.GK9574@lee--X1 \
    --to=lee.jones@linaro.org \
    --cc=a.zummo@towertech.it \
    --cc=broonie@kernel.org \
    --cc=cf@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dtor@chromium.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=heiko@sntech.de \
    --cc=hl@rock-chips.com \
    --cc=huangtao@rock-chips.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=javier.martinez@collabora.co.uk \
    --cc=kever.yang@rock-chips.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@linaro.org \
    --cc=olof@lixom.net \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=sameo@linux.intel.com \
    --cc=sonnyrao@chromium.org \
    --cc=xxx@rock-chips.com \
    --cc=zhangqing@rock-chips.com \
    --cc=zyw@rock-chips.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.