Re: [U-Boot] [PATCH V3 2/4] remoteproc: Introduce a sandbox dummy driver

2015-10-03 Thread Simon Glass
Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V3 2/4] remoteproc: Introduce a sandbox dummy driver

2015-10-01 Thread Simon Glass
On Thursday, 17 September 2015, Nishanth Menon  wrote:
>
> Introduce a dummy driver for sandbox that allows us to verify basic
> functionality. This is not meant to do anything functional - but is
> more or less meant as a framework plumbing debug helper.
>
> The sandbox remoteproc driver maintains absolutey no states and is a
> simple driver which just is filled with empty hooks. Idea being to give
> an approximate idea to implement own remoteproc driver using this as a
> template.
>
> Reviewed-by: Simon Glass 
> Signed-off-by: Nishanth Menon 
> ---
>
> Changes Since V2:
> - Fixed TODO message for removal of non-DT pdata entry
> - Picked up Simon's reviewed-by from V2
>
> V2: https://patchwork.ozlabs.org/patch/511747/
> V1: https://patchwork.ozlabs.org/patch/510197/
>
>  drivers/remoteproc/Kconfig|   9 +
>  drivers/remoteproc/Makefile   |   3 +
>  drivers/remoteproc/sandbox_testproc.c | 336 
> ++
>  3 files changed, 348 insertions(+)
>  create mode 100644 drivers/remoteproc/sandbox_testproc.c


 Acked-by: Simon Glass 
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V3 2/4] remoteproc: Introduce a sandbox dummy driver

2015-09-17 Thread Nishanth Menon
Introduce a dummy driver for sandbox that allows us to verify basic
functionality. This is not meant to do anything functional - but is
more or less meant as a framework plumbing debug helper.

The sandbox remoteproc driver maintains absolutey no states and is a
simple driver which just is filled with empty hooks. Idea being to give
an approximate idea to implement own remoteproc driver using this as a
template.

Reviewed-by: Simon Glass 
Signed-off-by: Nishanth Menon 
---

Changes Since V2:
- Fixed TODO message for removal of non-DT pdata entry
- Picked up Simon's reviewed-by from V2

V2: https://patchwork.ozlabs.org/patch/511747/
V1: https://patchwork.ozlabs.org/patch/510197/

 drivers/remoteproc/Kconfig|   9 +
 drivers/remoteproc/Makefile   |   3 +
 drivers/remoteproc/sandbox_testproc.c | 336 ++
 3 files changed, 348 insertions(+)
 create mode 100644 drivers/remoteproc/sandbox_testproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 444682624ace..437224b5491f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -12,4 +12,13 @@ config REMOTEPROC
bool
depends on DM
 
+# Please keep the configuration alphabetically sorted.
+config REMOTEPROC_SANDBOX
+   bool "Support for Test processor for Sandbox"
+   select REMOTEPROC
+   depends on DM
+   depends on SANDBOX
+   help
+ Say 'y' here to add support for test processor which does dummy
+ operations for sandbox platform.
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 14c27929b63e..720aa6e64701 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -5,3 +5,6 @@
 #
 
 obj-$(CONFIG_REMOTEPROC) += rproc-uclass.o
+
+# Remote proc drivers - Please keep this list alphabetically sorted.
+obj-$(CONFIG_REMOTEPROC_SANDBOX) += sandbox_testproc.o
diff --git a/drivers/remoteproc/sandbox_testproc.c 
b/drivers/remoteproc/sandbox_testproc.c
new file mode 100644
index ..004c7792d186
--- /dev/null
+++ b/drivers/remoteproc/sandbox_testproc.c
@@ -0,0 +1,336 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated - http://www.ti.com/
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#define pr_fmt(fmt) "%s: " fmt, __func__
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * enum sandbox_state - different device states
+ * @sb_booted: Entry condition, just booted
+ * @sb_init:   Initialized (basic environment is ready)
+ * @sb_reset:  Held in reset (accessible, but not running)
+ * @sb_loaded: Loaded with image (but not running)
+ * @sb_running:Processor is running
+ */
+enum sandbox_state {
+   sb_booted,
+   sb_init,
+   sb_reset,
+   sb_loaded,
+   sb_running
+};
+
+/**
+ * struct sandbox_test_devdata - private data per device
+ * @current_state: device current state
+ */
+struct sandbox_test_devdata {
+   enum sandbox_state current_state;
+};
+
+/**
+ * sandbox_dev_move_to_state() - statemachine for our dummy device
+ * @dev:   device to switch state
+ * @next_state:next proposed state
+ *
+ * This tries to follow the following statemachine:
+ *   Entry
+ *|
+ *v
+ * +---+
+ * +---+ init  |
+ * |   |   | <-+
+ * |   +---+   |
+ * |   |
+ * |   |
+ * |   ++  |
+ * Load|   |  reset |  |
+ * |   || <--+ |
+ * |   ++| |
+ * ||Load| |
+ * ||| |
+ * |   +v+   reset   | |
+ * +-> | |(opt)  | |
+ * |  Loaded +---+ |
+ * | | |
+ * +++ |
+ *  | Start|
+ *  +---v-+(opt)   |
+ *   +->| Running |Stop|
+ * Ping  +- | ++
+ * (opt)+-+
+ *
+ * (is_running does not change state)
+ *
+ * Return: 0 when valid state transition is seen, else returns -EINVAL
+ */
+static int sandbox_dev_move_to_state(struct udevice *dev,
+enum sandbox_state next_state)
+{
+   struct sandbox_test_devdata *ddata = dev_get_priv(dev);
+
+   /* No state transition is OK */
+   if (ddata->current_state == next_state)
+   return 0;
+
+   debug("current_state=%d, next_state=%d\n", ddata->current_state,
+ next_state);
+   switch (ddata->current_state) {
+   case sb_booted:
+   if (next_state == sb_init)
+   goto ok_state;
+   break;
+
+   case sb_init:
+   if (next_state == sb_reset ||