Hi Paul,
On 30 September 2016 at 12:12, Paul Burton paul.burton@imgtec.com wrote:
On Monday, 26 September 2016 18:35:25 BST Simon Glass wrote:
Hi Paul,
On 26 September 2016 at 12:29, Paul Burton paul.burton@imgtec.com wrote:
Allow for drivers to make use of driver model GPIOs when they're enabled
& available without needing to #ifdef on CONFIG_DM_GPIO by providing
dummy functions covering GPIO requests. Each will simply return -ENODEV
or -EINVAL, depending upon which the real implementation returns when a
GPIO isn't found. Only the driver model versions of the GPIO request
functions are covered & dm_gpio_request is excluded since it's
documented as only being of use for debugging, so drivers shouldn't be
calling it anyway.
Also provide a dummy dm_gpio_is_valid, with the idea that all other GPIO
functions called would be within an if (dm_gpio_is_valid(...)) statement
and have been optimised out in cases where that returns a compile-time
constant false.
This parallels the clock API, keeping the #ifdefs & checks in a single
location allowing drivers or other code to use GPIOs without needing to
perform such checks themselves.
Signed-off-by: Paul Burton paul.burton@imgtec.com
include/asm-generic/gpio.h | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
Ick - why not just define DM_GPIO? I don't think we want to provide
special support for legacy things. It is just confusing.
- Simon
Hi Simon,
For the MIPS Boston system I already enable DM_GPIO, I went with this approach so that it wouldn't necessarily need to be enabled for the Crown Bay x86 system which is the other user of the pch_gbe driver.
Would having pch_gbe depend on CONFIG_DM_GPIO be ok with you Bin? I see crownbay_defconfig enables CONFIG_CMD_GPIO but couldn't find any GPIO-using code at a glance. So hopefully it would just work without needing to change any existing crownbay code?
It seems OK to me, but in any case, DM_GPIO should be enabled for x86.
Regards, Simon