Hi Benoît,
On 10/01/2013 12:50 PM, Benoît Thébaudeau wrote:
On Tuesday, October 1, 2013 6:17:06 PM, Eric Nelson wrote:
On 10/01/2013 09:10 AM, Stefano Babic wrote:
On 01/10/2013 17:56, Eric Nelson wrote:
On 10/01/2013 07:49 AM, Stefano Babic wrote:
On 01/10/2013 16:26, Eric Nelson wrote:
...
Did I miss something in this thread that does actually require that ability? It seems a pretty obscure thing in the normal case to drive an output without confidence that it will succeed.
Yes, it seems quite strange, but it helps to debug the hardware. It is not the first time we see that, even driving the output, the signal does not go to the expected value, due for example to a conflict (another peripheral driving the signal) or to a wrong pull up resistor. As U-Boot is a great tool for hardware debugging, reading the signal back let check that the output is set to the desired value.
I agree with all of that, though this only covers the case of a pin set up as a GPIO output, and that same debugging approach is often used for other functions (display data pins, clock inputs and outputs, et cetera).
You probably wouldn't just set SION on all pins, right? I suspect that there'd be some ramification in terms of power consumption if nothing else.
Right. Well, instead of adding SION to the pin definition header files, then we could just add SION where needed on a per-pin basis, e.g.:
imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | IOMUX_CONFIG_SION << MUX_MODE_SHIFT);
A helper macro could be defined in arch/arm/include/asm/imx-common/iomux-v3.h in order to simplify the writing, e.g.:
#define MUX_MODE_SION (IOMUX_CONFIG_SION << MUX_MODE_SHIFT)
imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION);
I like this approach much better since it lets the reader know there's something special about the pin.
Regards,
Eric