[U-Boot,V2,4/4] test: Add basic tests for remoteproc

Use the sandbox environment for the basic tests.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
New patch.

 test/dm/Makefile     |  1 +
 test/dm/remoteproc.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 68 insertions(+)
 create mode 100644 test/dm/remoteproc.c

On 27 August 2015 at 22:07, Nishanth Menon <nm@ti.com> wrote:
> Use the sandbox environment for the basic tests.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> New patch.
>
>  test/dm/Makefile     |  1 +
>  test/dm/remoteproc.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 68 insertions(+)
>  create mode 100644 test/dm/remoteproc.c

Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

Nit below.

>
> diff --git a/test/dm/Makefile b/test/dm/Makefile
> index eda964318593..7b3626cb3294 100644
> --- a/test/dm/Makefile
> +++ b/test/dm/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_DM_MMC) += mmc.o
>  obj-$(CONFIG_DM_PCI) += pci.o
>  obj-$(CONFIG_RAM) += ram.o
>  obj-y += regmap.o
> +obj-$(CONFIG_REMOTEPROC) += remoteproc.o
>  obj-$(CONFIG_RESET) += reset.o
>  obj-$(CONFIG_DM_RTC) += rtc.o
>  obj-$(CONFIG_DM_SPI_FLASH) += sf.o
> diff --git a/test/dm/remoteproc.c b/test/dm/remoteproc.c
> new file mode 100644
> index 000000000000..924eae854078
> --- /dev/null
> +++ b/test/dm/remoteproc.c
> @@ -0,0 +1,67 @@
> +/*
> + * (C) Copyright 2015
> + * Texas Instruments Incorporated - http://www.ti.com/
> + * SPDX-License-Identifier:    GPL-2.0+
> + */
> +#include <common.h>
> +#include <dm.h>
> +#include <errno.h>
> +#include <remoteproc.h>
> +#include <dm/test.h>
> +#include <test/ut.h>
> +/**
> + * dm_test_remoteproc_base() - test the operations after initializations
> + * @uts:       unit test state
> + *
> + * Return:     0 if test passed, else error
> + */
> +static int dm_test_remoteproc_base(struct unit_test_state *uts)
> +{
> +       if (!rproc_is_initialized())
> +               ut_assertok(rproc_init());
> +
> +       /* Ensure we are initialized */
> +       ut_asserteq(true, rproc_is_initialized());
> +
> +
> +       /* platform data device 1 */
> +       ut_assertok(rproc_stop(0));
> +       ut_assertok(rproc_reset(0));
> +       /* -> invalid attempt tests.. */
> +       ut_asserteq(-EINVAL, rproc_start(0));
> +       ut_asserteq(-EINVAL, rproc_ping(0));
> +       /* Valid tests.. */
> +       ut_assertok(rproc_load(0, 1, 0));
> +       ut_assertok(rproc_start(0));
> +       ut_assertok(rproc_is_running(0));
> +       ut_assertok(rproc_ping(0));
> +       ut_assertok(rproc_reset(0));
> +       ut_assertok(rproc_stop(0));
> +
> +       /* dt device device 1 */
> +       ut_assertok(rproc_stop(1));
> +       ut_assertok(rproc_reset(1));
> +       ut_assertok(rproc_load(1, 1, 0));
> +       ut_assertok(rproc_start(1));
> +       ut_assertok(rproc_is_running(1));
> +       ut_assertok(rproc_ping(1));
> +       ut_assertok(rproc_reset(1));
> +       ut_assertok(rproc_stop(1));
> +
> +       /* dt device device 2 */
> +       ut_assertok(rproc_stop(0));
> +       ut_assertok(rproc_reset(0));
> +       /* -> invalid attempt tests.. */
> +       ut_asserteq(-EINVAL, rproc_start(0));
> +       ut_asserteq(-EINVAL, rproc_ping(0));
> +       /* Valid tests.. */

You don't need a period at the end of these comments\

> +       ut_assertok(rproc_load(2, 1, 0));
> +       ut_assertok(rproc_start(2));
> +       ut_assertok(rproc_is_running(2));
> +       ut_assertok(rproc_ping(2));
> +       ut_assertok(rproc_reset(2));
> +       ut_assertok(rproc_stop(2));

Would it be worth having a test that goes through things in the wrong
sequence? It's up to you.

BTW you don't have to put all your tests in one function, e.g. if some
have a different purpose you can put them in a separate function.

> +
> +       return 0;
> +}
> +DM_TEST(dm_test_remoteproc_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
> --
> 2.1.4
>

Regards,
Simon

On 21:46-20150901, Simon Glass wrote:
> On 27 August 2015 at 22:07, Nishanth Menon <nm@ti.com> wrote:
> > Use the sandbox environment for the basic tests.
> >
> > Signed-off-by: Nishanth Menon <nm@ti.com>
> > ---
> > New patch.
> >
> >  test/dm/Makefile     |  1 +
> >  test/dm/remoteproc.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 68 insertions(+)
> >  create mode 100644 test/dm/remoteproc.c
> 
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>
> 
> Nit below.

Thanks. Will fix the same in the next rev.

[...]
> > +
> > +       /* dt device device 2 */
> > +       ut_assertok(rproc_stop(0));
> > +       ut_assertok(rproc_reset(0));
> > +       /* -> invalid attempt tests.. */
> > +       ut_asserteq(-EINVAL, rproc_start(0));
> > +       ut_asserteq(-EINVAL, rproc_ping(0));
> > +       /* Valid tests.. */
> 
> You don't need a period at the end of these comments\

Yep. Will fix.

> 
> > +       ut_assertok(rproc_load(2, 1, 0));
> > +       ut_assertok(rproc_start(2));
> > +       ut_assertok(rproc_is_running(2));
> > +       ut_assertok(rproc_ping(2));
> > +       ut_assertok(rproc_reset(2));
> > +       ut_assertok(rproc_stop(2));
> 
> Would it be worth having a test that goes through things in the wrong
> sequence? It's up to you.

The current tests does attempt to perform basic sanity tests - there
are invalid sequence attempts as well.

> 
> BTW you don't have to put all your tests in one function, e.g. if some
> have a different purpose you can put them in a separate function.

I agree and had started it that way, then as I started putting things
together, considering the tests were simple sequence based, they were
good enough to put them in the test sequence in one shot. We can
definitely evolve as folks find specific needs of improvement in the
future.