On 07/26/2013 03:50 PM, Andrew Chew wrote: >>>> How does this interact with the pinctrl driver that Laxman just sent >>>> for Palmas? >>>> >>>> https://lkml.org/lkml/2013/7/26/141 >>>> [PATCH 0/2] pinctrl: palmas: add pincontrol driver >>> >>> Thanks for pointing this out. Given this: >>> >>> +Optional properties: >>> +- ti,palams-enable-dvfs1: Enable DVFS1. Configure pins for DVFS1 mode. >>> +- ti,palams-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode. >>> >>> I think his work already encompasses what my patch is supposed to do. >>> >>> Abandoning this patch. >> >> OK, that's simple! >> >> Are the existing ti,mux-pad1/ti,mux-pad2 properties already in the binding >> redundant with Laxman's pinctrl driver? > > In linux-next (where I based my work), yes, those two properties already exist, > and as far as I understand it, are redundant with Laxman's pinctrl driver. > I expect those properties will go away with Laxman's pinctrl driver. Except those properties have been there for many kernel revisions and are an ABI and hence can't be removed, although I noticed that they got renamed recently, and of course we aren't technically being strict about this quite yet... Re: the complete pinctrl driver: is anything outside the Palmas going to need to reprogram the Palmas pinctrl HW at run-time? Are the functions that can be routed to the pins just static configuration for PMIC features, or might other generic (non-Palmas) drivers use those pins for something? If not, perhaps it's be simpler to just add your ti,mux-pad3 property and be done. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
