[PATCH v2 02/10] test: pinmux: Add test for pin muxing

Simon Glass sjg at chromium.org
Wed Jun 17 16:07:28 CEST 2020


Hi Sean,

On Tue, 16 Jun 2020 at 21:18, Sean Anderson <seanga2 at 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 at 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 at 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


More information about the U-Boot mailing list