Re: [PATCH] ARM: dts: add dtsi for palmas

[Stephen Warren]

On 06/10/2013 03:29 AM, Benoit Cousson wrote:
> Hi Keerthy,
> 
> On 06/10/2013 06:03 AM, J, KEERTHY wrote:
>> Hi Stephen,
>>
>> Thanks for the review comments.
>>
>> ________________________________________
>> From: Stephen Warren [swarren@xxxxxxxxxxxxx]
>> Sent: Saturday, June 08, 2013 1:26 AM
>> To: J, KEERTHY
>> Cc: Cousson, Benoit; devicetree-discuss@xxxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; ldewangan@xxxxxxxxxx; grant.likely@xxxxxxxxxxxx; swarren@xxxxxxxxxx; sameo@xxxxxxxxxxxxxxx; gg@xxxxxxxxxxxxxxx; lee.jones@xxxxxxxxxx
>> Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
>>
>> On 06/07/2013 05:28 AM, J Keerthy wrote:
>>> Adds palmas mfd and palmas regulator nodes. This is
>>> based on the patch series:
>>>
>>> http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg89957.html
>>>
>>> The device tree nodes are based on:
>>> https://lkml.org/lkml/2013/6/6/25
>>
>>> diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
>>
>>> +&palmas {
>>
>> Hmmm. That (i.e. requiring the board file to declare the node, then
>> setting up all the content by later including this file) is an
>> interesting approach. I guess it's reasonable. The one issue is that it
>> makes it a little harder for the board file to override any of the
>> properties in this file., although it certainly is possible by including
>> those overrides after the include.
>>
>> Irrespective of that, some comments on this:
>>
>>> +     palmas_pmic {
>>
>>> +             ti,ldo6-vibrator;
>>
>> For example, what if the board doesn't want to have the property set?
>>
>>> +
>>> +             regulators {
>>> +                     smps123_reg: smps123 {
>>> +                             regulator-name = "smps123";
>>> +                             regulator-min-microvolt = < 600000>;
>>> +                             regulator-max-microvolt = <1500000>;
>>
>> Or what if the board wants to limit the voltage range of this regulator
>> due to what it's used for on the board.
>>
>>> +                             regulator-always-on;
>>> +                             regulator-boot-on;
>>
>> And those two properties are almost certainly board-specific policy.
>>
>> Totally agree to all the above concerns. So can we have a custom .dtsi file
>> for a board+pmic combination? Or have only the required properties over ridden
>> in the board file?
> 
> Yes, you can do that potentially if most OMAP5 boards will reuse the
> same kind of settings. Kevin has just done that for OMAP3 + twl4030.
> 
> In this case, since we do have only one board, I'm not sure it worth the
> effort.

IIUC, various Tegra boards use this PMIC, so there's more than one board
in question here.

Or were you talking about e.g.:

palmas.dtsi          - base Palmas DT node for everything
omapXXXX-palmas.dtsi - common Palmas settings for all OMAP boards

... where the latter file would only be used by one board? If so, then
yes, creating the latter file might not make sense yet.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/