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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
