Hi Sean, On Tue, 16 Jun 2020 at 21:18, Sean Anderson <sean...@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 <sean...@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 <sean...@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. Regards, Simon