[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <577F39F1.3000203@ti.com>
Date: Fri, 8 Jul 2016 10:58:17 +0530
From: Keerthy <a0393675@...com>
To: Laxman Dewangan <ldewangan@...dia.com>, Nishanth Menon <nm@...com>,
Mark Brown <broonie@...nel.org>
CC: Tony Lindgren <tony@...mide.com>, <linux-kernel@...r.kernel.org>,
<linux-omap@...r.kernel.org>, Liam Girdwood <lgirdwood@...il.com>,
Keerthy <j-keerthy@...com>, Stephen Warren <swarren@...dia.com>,
Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH 0/4] regulator: tps65917/palmas: Cleanups and bugfixes
On Friday 20 May 2016 11:46 AM, Laxman Dewangan wrote:
>
> On Friday 20 May 2016 10:01 AM, Keerthy wrote:
>> + Lee Jones
>>
>> On Saturday 07 May 2016 12:31 AM, Nishanth Menon wrote:
>>> On 05/06/2016 12:14 PM, Mark Brown wrote:
>>>> On Fri, May 06, 2016 at 12:44:23PM +0530, Laxman Dewangan wrote:
>>>>
>>>>> When you are here, can you implement the dt parsing with the new
>>>>> method from
>>>>> regulator framework.
>>>>> Regulator FW calls callback to parse customized DT property, just
>>>>> need to
>>>>> pass the node and pointer when registering.
>>>>
>>>>> This will helps lots in cleanups and readability.
>>>>
>>>> Yes, please.
>>>>
>>> yeah, the driver has started showing it's age, it will be good to do a
>>> refactor.
>>
>> Laxman,
>>
>> I got the dt parsing with new method from regulator framework part, But
>> by new method do you also want to remove the dt compatible of
>> regulators and let only the mfd compatible stay?
>>
>> replace of_platform_populate with mfd_add_devices so that linux
>> handles the drivers split up and not the device tree?
>>
>
> The DT binding of child devices of the palmas are like that each sub
> node has compatible.
> So I dont think we can change this to avoid regression.
>
> However, if we make the child devices independent of the parent devices
> then it will be very useful to use across different PMIC if they have
> same IP.
> Currently, child devices are very much tightly coupled with parent
> devices for the register access and global structure member accces.
>
> This is exactly what we did for the max77686 RTC driver which is used by
> max77686, max77802 and max77620.
>
> There is two mfd core driver, max77686 and max77620 and uses same RTC
> driver rtc-max77686.c
Laxman,
Sorry for responding late on this thread. The new way of the dt parsing
with the new method expects the driver to populate vsel_reg, vsel_mask,
enable_reg, enable_mask.
The inherent difference in palmas regulator driver w.r.t handling
regulators is that this driver treats smps and ldo differently. It has
separate read/write functions for both and goes by separate base
addresses for spmp and ldo. Now to get all this unified under one
regulator_desc array a lot of code churn would be needed in both header
and C files. Not sure if that is okay.
Regards,
Keerthy
>
>
Powered by blists - more mailing lists