On 25/11/16 12:04, Laxman Dewangan wrote: > Thanks Thierry for review. > > On Friday 25 November 2016 03:27 PM, Thierry Reding wrote: >> * PGP Signed by an unknown key >> >> On Thu, Nov 24, 2016 at 02:08:54PM +0530, Laxman Dewangan wrote: >>> + NVIDIA Tegra124/210 SoC has IO pads which supports multi-voltage >>> + level of interfacing and deep power down mode of IO pads. The >>> + voltage of IO pads are SW configurable based on IO rail of that >>> + pads on T210. This driver provides the interface to change IO pad >>> + voltage and power state via pincontrol interface. >> This has a lot of chip-specific text. Will all of that have to be >> updated if support for new chips is added? > > Then saying that Tegra124 and later.. > Hoping, people know our chip releasing sequence as numbering are not in > sequence. > >> >>> +#include <linux/regulator/consumer.h> >>> +#include <soc/tegra/pmc.h> >> Have you considered moving this code into the PMC driver? It seems a >> little over the top to go through all of the platform device creation >> and driver registration dance only to call into a public API later on. > > Yes, we had discussion on this and suggestion came to use the pinctrl > framework. > If we do in the pmc driver then we will need lots of DT processing for > getting information from DT which we can directly get from the pinctrl > core framework. > Also client driver may need to have the control dynamically and get the > IO pads from DT. So implementing all in pmc will be huge duplication > over already existing framework. I don't follow. We already did something similar for the Tegra DPAUX driver [0]. Cheers Jon [0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/tegra/dpaux.c?id=0751bb5c44fe1aa9494ce259d974c3d249b73a84 -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
