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
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
