From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Anderson Date: Wed, 24 Jun 2020 16:32:34 -0400 Subject: [PATCH v2 02/10] test: pinmux: Add test for pin muxing In-Reply-To: References: <20200608012651.1525906-1-seanga2@gmail.com> <20200608012651.1525906-3-seanga2@gmail.com> <6ff48fa8-1291-52cd-a197-278f277deae4@gmail.com> <342b6c61-4580-74d8-644c-5d455b82f2b2@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 6/24/20 9:45 AM, Simon Glass wrote: > Hi Sean, > > On Wed, 24 Jun 2020 at 02:01, Sean Anderson wrote: >> >> On 6/17/20 10:07 AM, Simon Glass wrote: >>> Hi Sean, >>> >>> On Tue, 16 Jun 2020 at 21:18, Sean Anderson wrote: >>>> >>>> On 6/16/20 11:11 PM, Simon Glass wrote: >>>>> Hi Sean, >>>>> >>>>> On Sun, 7 Jun 2020 at 19:27, Sean Anderson 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 >>>>>> --- >>>>>> >>>>>> 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