On Friday 25 November 2016 10:59 PM, Jon Hunter wrote:
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
In the above dpaux driver, you used the pinctrl framework and its core
functionality for the device tree interfacing and client interfacing.
The same thing I am saying here, we should not avoid the pinctrl
framework. The client driver will use the pinctrl framework for the IO
pad configurations, not direct PMC APIs.
--
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
