[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53FC77F0.4030004@rock-chips.com>
Date: Tue, 26 Aug 2014 20:05:04 +0800
From: Chris Zhong <zyw@...k-chips.com>
To: Lee Jones <lee.jones@...aro.org>
CC: robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
sameo@...ux.intel.com, lgirdwood@...il.com, broonie@...nel.org,
a.zummo@...ertech.it, mturquette@...aro.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
rtc-linux@...glegroups.com, grant.likely@...aro.org,
hl@...k-chips.com, huangtao@...k-chips.com, cf@...k-chips.com,
zhangqing@...k-chips.com, xxx@...k-chips.com,
dianders@...omium.org, heiko@...ech.de, olof@...om.net,
sonnyrao@...omium.org, dtor@...omium.org,
javier.martinez@...labora.co.uk, kever.yang@...k-chips.com
Subject: Re: [PATCH v2 2/5] MFD: RK808: Add new mfd driver for RK808
On 08/26/2014 07:20 PM, Lee Jones wrote:
> 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@...k-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.
Yes, if we have no dts file, these value can pass from mach-rk***.
It can be filled with all user setting of rk808, in a struct.
the latest struct is:
struct rk808_board {
int wakeup;
bool pm_off;
struct regulator_init_data *rk808_init_data[RK808_NUM_REGULATORS];
struct device_node *of_node[RK808_NUM_REGULATORS];
unsigned int dcdc_slp_voltage[3]; /* buckx_voltage in uV */
unsigned int ldo_slp_voltage[7];
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists