On 6/24/20 9:45 AM, Simon Glass wrote:
Hi Sean,
On Wed, 24 Jun 2020 at 02:01, Sean Anderson seanga2@gmail.com wrote:
On 6/17/20 10:07 AM, Simon Glass wrote:
Hi Sean,
On Tue, 16 Jun 2020 at 21:18, Sean Anderson seanga2@gmail.com wrote:
On 6/16/20 11:11 PM, Simon Glass wrote:
Hi Sean,
On Sun, 7 Jun 2020 at 19:27, Sean Anderson seanga2@gmail.com wrote:
This extends the pinctrl-sandbox driver to support pin muxing, and adds a test for that behaviour. The test is done in C and not python (like the existing tests for the pinctrl uclass) because it needs to call pinctrl_select_state. Another option could be to add a command that invokes pinctrl_select_state and then test everything in test/py/tests/test_pinmux.py.
The pinctrl-sandbox driver now mimics the way that many pinmux devices work. There are two groups of pins which are muxed together, as well as four pins which are muxed individually. I have tried to test all normal paths. However, very few error cases are explicitly checked for.
Signed-off-by: Sean Anderson seanga2@gmail.com
Changes in v2:
- New
arch/sandbox/dts/test.dts | 45 +++++++-- drivers/pinctrl/pinctrl-sandbox.c | 155 +++++++++++++++++++++++------- test/dm/Makefile | 3 + test/py/tests/test_pinmux.py | 36 +++---- 4 files changed, 178 insertions(+), 61 deletions(-)
[..]
diff --git a/test/dm/Makefile b/test/dm/Makefile index 0d1c66fa1e..9e273ee02d 100644 --- a/test/dm/Makefile +++ b/test/dm/Makefile @@ -76,4 +76,7 @@ obj-$(CONFIG_DM_RNG) += rng.o obj-$(CONFIG_CLK_K210_SET_RATE) += k210_pll.o obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o obj-$(CONFIG_RESET_SYSCON) += syscon-reset.o +ifneq ($(CONFIG_PINMUX),) +obj-$(CONFIG_PINCONF) += pinmux.o
I don't see this file in your patch.
Whoops, will add it next revision.
+endif endif diff --git a/test/py/tests/test_pinmux.py b/test/py/tests/test_pinmux.py index 4e6df992a4..0cbbae000c 100644 --- a/test/py/tests/test_pinmux.py +++ b/test/py/tests/test_pinmux.py @@ -28,15 +28,15 @@ def test_pinmux_status_all(u_boot_console):
Feel free to convert this to C also if you like. It is faster, although perhaps not much faster since it only runs a few commands?
Ok, I can have a look.
Should C be preferred for new tests?
+Stephen Warren
For sandbox tests, yes. If there is a lot of interaction, Python is extremely slow.
But with Python we can run a test on real hardware without compiling the test into U-Boot. So there are benefits on both sides.
Ok, I looked into it, and the python test uses the assert 'somestring' in output idiom a lot. From what I can tell, there's not an easy way to replicate this behavior on the C side of things. Adding a function to do this would probably call for its own patch. I could also use the existing functionality to test for lines, but I think that would be much more brittle when compared to the python version.
Well you could add assert_nextline_contains() for example?
Yes, but I would also have to skip a specific number of lines, e.g.
console_record_reset(); run_command("pinmux", 0); ut_assert_nextline_contains(""); ut_assert_nextline_contains(""); ut_assert_nextline_contains("Usage:");
console_record_reset(); /* ... */
That's ok, but still fairly brittle in how it tests the output.
Oh well, perhaps I'll add something like that next revision...
--Sean