[PATCH v6 7/9] v4l: vsp1: Adapt entities to configure into a body

2018-02-28 Thread Kieran Bingham
Currently the entities store their configurations into a display list.
Adapt this such that the code can be configured into a body directly,
allowing greater flexibility and control of the content.

All users of vsp1_dl_list_write() are removed in this process, thus it
too is removed.

A helper, vsp1_dl_list_get_body0() is provided to access the internal body0
from the display list.

Signed-off-by: Kieran Bingham 

---

v4:
 - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0()
   The similarities between vsp1_dl_list_get_body and
   vsp1_dl_list_body_get() were too close

 - body0 could be removed later when the default body is no longer
   needed.

v5:
 - Support DRM/UIF changes

v6:
 - Remove DRM/UIF changes

 drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
 drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c| 22 +++-
 drivers/media/platform/vsp1/vsp1_entity.c | 16 -
 drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
 drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
 drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
 drivers/media/platform/vsp1/vsp1_lif.c| 15 
 drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
 drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
 drivers/media/platform/vsp1/vsp1_sru.c| 14 
 drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
 drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
 drivers/media/platform/vsp1/vsp1_video.c  | 11 --
 drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
 20 files changed, 174 insertions(+), 157 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index b9ff96f76b3e..60d449d7b135 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -30,10 +30,10 @@
  * Device Access
  */
 
-static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list 
*dl,
- u32 reg, u32 data)
+static inline void vsp1_bru_write(struct vsp1_bru *bru,
+ struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, bru->base + reg, data);
+   vsp1_dl_body_write(dlb, bru->base + reg, data);
 }
 
 /* 
-
@@ -287,7 +287,7 @@ static const struct v4l2_subdev_ops bru_ops = {
 
 static void bru_prepare(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
-   struct vsp1_dl_list *dl)
+   struct vsp1_dl_body *dlb)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
@@ -309,7 +309,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * format at the pipeline output is premultiplied.
 */
flags = pipe->output ? pipe->output->format.flags : 0;
-   vsp1_bru_write(bru, dl, VI6_BRU_INCTRL,
+   vsp1_bru_write(bru, dlb, VI6_BRU_INCTRL,
   flags & V4L2_PIX_FMT_FLAG_PREMUL_ALPHA ?
   0 : VI6_BRU_INCTRL_NRM);
 
@@ -317,12 +317,12 @@ static void bru_prepare(struct vsp1_entity *entity,
 * Set the background position to cover the whole output image and
 * configure its color.
 */
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_SIZE,
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_SIZE,
   (format->width << VI6_BRU_VIRRPF_SIZE_HSIZE_SHIFT) |
   (format->height << VI6_BRU_VIRRPF_SIZE_VSIZE_SHIFT));
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_LOC, 0);
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_LOC, 0);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_COL, bru->bgcolor |
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_COL, bru->bgcolor |
   (0xff << VI6_BRU_VIRRPF_COL_A_SHIFT));
 
/*
@@ -332,7 +332,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * unit.
 */
if (entity->type == VSP1_ENTITY_BRU)
-   vsp1_bru_write(bru, dl, VI6_BRU_ROP,
+   vsp1_bru_write(bru, dlb, VI6_BRU_ROP,
   VI6_BRU_ROP_DSTSEL_BRUIN(1) |
   VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
   VI6_BRU_ROP_AROP(VI6_ROP_NOP));
@@ -374,7 +374,7 @@ static void bru_prepare(struct vsp1_entity *entity,
if (!(entity->type == VSP1_ENTITY_BRU && i == 1))
ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_CTRL(i), 

[PATCH v6 6/9] v4l: vsp1: Refactor display list configure operations

2018-02-28 Thread Kieran Bingham
The entities provide a single .configure operation which configures the
object into the target display list, based on the vsp1_entity_params
selection.

This restricts us to a single function prototype for both static
configuration (the pre-stream INIT stage) and the dynamic runtime stages
for both each frame - and each partition therein.

Split the configure function into two parts, '.prepare()' and
'.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
.configure(). The configuration for individual partitions is handled by
passing the partition number to the configure call, and processing any
runtime stage actions on the first partition only.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_clu.c|  42 +--
 drivers/media/platform/vsp1/vsp1_dl.h |   1 +-
 drivers/media/platform/vsp1/vsp1_drm.c|  21 +--
 drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
 drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
 drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
 drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
 drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
 drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
 16 files changed, 360 insertions(+), 380 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index e8fd2ae3b3eb..b9ff96f76b3e 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -285,19 +285,15 @@ static const struct v4l2_subdev_ops bru_ops = {
  * VSP1 Entity Operations
  */
 
-static void bru_configure(struct vsp1_entity *entity,
- struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+static void bru_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
 
-   if (params != VSP1_ENTITY_PARAMS_INIT)
-   return;
-
format = vsp1_entity_get_pad_format(>entity, bru->entity.config,
bru->entity.source_pad);
 
@@ -404,7 +400,7 @@ static void bru_configure(struct vsp1_entity *entity,
 }
 
 static const struct vsp1_entity_operations bru_entity_ops = {
-   .configure = bru_configure,
+   .prepare = bru_prepare,
 };
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index b2a39a6ef7e4..be4d7e493746 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -213,37 +213,36 @@ static const struct v4l2_subdev_ops clu_ops = {
 /* 
-
  * VSP1 Entity Operations
  */
+static void clu_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   /*
+* The yuv_mode can't be changed during streaming. Cache it internally
+* for future runtime configuration calls.
+*/
+   struct v4l2_mbus_framefmt *format;
+
+   format = vsp1_entity_get_pad_format(>entity,
+   clu->entity.config,
+   CLU_PAD_SINK);
+   clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
+}
 
 static void clu_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
  struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+ unsigned int partition)
 {
struct vsp1_clu *clu = to_clu(>subdev);
struct vsp1_dl_body *dlb;
unsigned long flags;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
 
-   switch (params) {
-   case VSP1_ENTITY_PARAMS_INIT: {
-   /*
-* The format can't be changed during streaming, only verify it
-* at setup time and store the information internally for future
-* runtime configuration calls.
-*/
-   struct v4l2_mbus_framefmt *format;
-
-   

[PATCH v6 2/9] v4l: vsp1: Protect bodies against overflow

2018-02-28 Thread Kieran Bingham
The body write function relies on the code never asking it to write more
than the entries available in the list.

Currently with each list body containing 256 entries, this is fine, but
we can reduce this number greatly saving memory. In preparation of this
add a level of protection to catch any buffer overflows.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 

---

v3:
 - adapt for new 'body' terminology
 - simplify WARN_ON macro usage

 drivers/media/platform/vsp1/vsp1_dl.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 0c1bd17f9281..59fe80bf6e9d 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -50,6 +50,7 @@ struct vsp1_dl_entry {
  * @dma: DMA address of the entries
  * @size: size of the DMA memory in bytes
  * @num_entries: number of stored entries
+ * @max_entries: number of entries available
  */
 struct vsp1_dl_body {
struct list_head list;
@@ -60,6 +61,7 @@ struct vsp1_dl_body {
size_t size;
 
unsigned int num_entries;
+   unsigned int max_entries;
 };
 
 /**
@@ -139,6 +141,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
 
dlb->vsp1 = vsp1;
dlb->size = size;
+   dlb->max_entries = num_entries;
 
dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, >dma,
GFP_KERNEL);
@@ -220,6 +223,10 @@ void vsp1_dl_body_free(struct vsp1_dl_body *dlb)
  */
 void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
+   if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
+ "DLB size exceeded (max %u)", dlb->max_entries))
+   return;
+
dlb->entries[dlb->num_entries].addr = reg;
dlb->entries[dlb->num_entries].data = data;
dlb->num_entries++;
-- 
git-series 0.9.1


[PATCH v6 1/9] v4l: vsp1: Reword uses of 'fragment' as 'body'

2018-02-28 Thread Kieran Bingham
Throughout the codebase, the term 'fragment' is used to represent a
display list body. This term duplicates the 'body' which is already in
use.

The datasheet references these objects as a body, therefore replace all
mentions of a fragment with a body, along with the corresponding
pluralised terms.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_clu.c |  10 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 107 --
 drivers/media/platform/vsp1/vsp1_dl.h  |  14 +--
 drivers/media/platform/vsp1/vsp1_lut.c |   8 +-
 4 files changed, 69 insertions(+), 70 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index f2fb26e5ab4e..9621afa3658c 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -47,19 +47,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
if (!dlb)
return -ENOMEM;
 
-   vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0);
+   vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
for (i = 0; i < 17 * 17 * 17; ++i)
-   vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
+   vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_fragment_free(dlb);
+   vsp1_dl_body_free(dlb);
return 0;
 }
 
@@ -256,7 +256,7 @@ static void clu_configure(struct vsp1_entity *entity,
spin_unlock_irqrestore(>lock, flags);
 
if (dlb)
-   vsp1_dl_list_add_fragment(dl, dlb);
+   vsp1_dl_list_add_body(dl, dlb);
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 0b86ed01e85d..0c1bd17f9281 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -69,7 +69,7 @@ struct vsp1_dl_body {
  * @header: display list header, NULL for headerless lists
  * @dma: DMA address for the header
  * @body0: first display list body
- * @fragments: list of extra display list bodies
+ * @bodies: list of extra display list bodies
  * @has_chain: if true, indicates that there's a partition chain
  * @chain: entry in the display list partition chain
  */
@@ -81,7 +81,7 @@ struct vsp1_dl_list {
dma_addr_t dma;
 
struct vsp1_dl_body body0;
-   struct list_head fragments;
+   struct list_head bodies;
 
bool has_chain;
struct list_head chain;
@@ -98,13 +98,13 @@ enum vsp1_dl_mode {
  * @mode: display list operation mode (header or headerless)
  * @singleshot: execute the display list in single-shot mode
  * @vsp1: the VSP1 device
- * @lock: protects the free, active, queued, pending and gc_fragments lists
+ * @lock: protects the free, active, queued, pending and gc_bodies lists
  * @free: array of all free display lists
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
- * @gc_work: fragments garbage collector work struct
- * @gc_fragments: array of display list fragments waiting to be freed
+ * @gc_work: bodies garbage collector work struct
+ * @gc_bodies: array of display list bodies waiting to be freed
  */
 struct vsp1_dl_manager {
unsigned int index;
@@ -119,7 +119,7 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
 
struct work_struct gc_work;
-   struct list_head gc_fragments;
+   struct list_head gc_bodies;
 };
 
 /* 
-
@@ -157,17 +157,16 @@ static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
 }
 
 /**
- * vsp1_dl_fragment_alloc - Allocate a display list fragment
+ * vsp1_dl_body_alloc - Allocate a display list body
  * @vsp1: The VSP1 device
- * @num_entries: The maximum number of entries that the fragment can contain
+ * @num_entries: The maximum number of entries that the body can contain
  *
- * Allocate a display list fragment with enough memory to contain the requested
+ * Allocate a display list body with enough memory to contain the requested
  * number of entries.
  *
- * Return a pointer to a fragment on success or NULL if memory can't be
- * allocated.
+ * Return a pointer to a body on success or NULL if memory can't be allocated.
  */
-struct vsp1_dl_body *vsp1_dl_fragment_alloc(struct vsp1_device *vsp1,
+struct vsp1_dl_body *vsp1_dl_body_alloc(struct vsp1_device *vsp1,
unsigned int num_entries)
 {

[PATCH v6 8/9] v4l: vsp1: Move video configuration to a cached dlb

2018-02-28 Thread Kieran Bingham
We are now able to configure a pipeline directly into a local display
list body. Take advantage of this fact, and create a cacheable body to
store the configuration of the pipeline in the video object.

vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
Convert this function to use the cached video->config body and obtain a
local display list reference.

Attach the video->config body to the display list when needed before
committing to hardware.

The pipe object is marked as un-configured when resuming from a suspend.
This ensures that when the hardware is reset - our cached configuration
will be re-attached to the next committed DL.

Signed-off-by: Kieran Bingham 
---

v3:
 - 's/fragment/body/', 's/fragments/bodies/'
 - video dlb cache allocation increased from 2 to 3 dlbs

Our video DL usage now looks like the below output:

dl->body0 contains our disposable runtime configuration. Max 41.
dl_child->body0 is our partition specific configuration. Max 12.
dl->bodies shows our constant configuration and LUTs.

  These two are LUT/CLU:
 * dl->bodies[x]->num_entries 256 / max 256
 * dl->bodies[x]->num_entries 4914 / max 4914

Which shows that our 'constant' configuration cache is currently
utilised to a maximum of 64 entries.

trace-cmd report | \
grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;

  dl->body0->num_entries 13 / max 128
  dl->body0->num_entries 14 / max 128
  dl->body0->num_entries 16 / max 128
  dl->body0->num_entries 20 / max 128
  dl->body0->num_entries 27 / max 128
  dl->body0->num_entries 34 / max 128
  dl->body0->num_entries 41 / max 128
  dl_child->body0->num_entries 10 / max 128
  dl_child->body0->num_entries 12 / max 128
  dl->bodies[x]->num_entries 15 / max 128
  dl->bodies[x]->num_entries 16 / max 128
  dl->bodies[x]->num_entries 17 / max 128
  dl->bodies[x]->num_entries 18 / max 128
  dl->bodies[x]->num_entries 20 / max 128
  dl->bodies[x]->num_entries 21 / max 128
  dl->bodies[x]->num_entries 256 / max 256
  dl->bodies[x]->num_entries 31 / max 128
  dl->bodies[x]->num_entries 32 / max 128
  dl->bodies[x]->num_entries 39 / max 128
  dl->bodies[x]->num_entries 40 / max 128
  dl->bodies[x]->num_entries 47 / max 128
  dl->bodies[x]->num_entries 48 / max 128
  dl->bodies[x]->num_entries 4914 / max 4914
  dl->bodies[x]->num_entries 55 / max 128
  dl->bodies[x]->num_entries 56 / max 128
  dl->bodies[x]->num_entries 63 / max 128
  dl->bodies[x]->num_entries 64 / max 128

v4:
 - Adjust pipe configured flag to be reset on resume rather than suspend
 - rename dl_child, dl_next

 drivers/media/platform/vsp1/vsp1_pipe.c  |  7 +++-
 drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 67 -
 drivers/media/platform/vsp1/vsp1_video.h |  2 +-
 4 files changed, 54 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 5012643583b6..fa445b1a2e38 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
   VI6_CMD_STRCMD);
pipe->state = VSP1_PIPELINE_RUNNING;
+   pipe->configured = true;
}
 
pipe->buffers_ready = 0;
@@ -470,6 +471,12 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1)
continue;
 
spin_lock_irqsave(>irqlock, flags);
+   /*
+* The hardware may have been reset during a suspend and will
+* need a full reconfiguration
+*/
+   pipe->configured = false;
+
if (vsp1_pipeline_ready(pipe))
vsp1_pipeline_run(pipe);
spin_unlock_irqrestore(>irqlock, flags);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 90d29492b9b9..e7ad6211b4d0 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -90,6 +90,7 @@ struct vsp1_partition {
  * @irqlock: protects the pipeline state
  * @state: current state
  * @wq: wait queue to wait for state change completion
+ * @configured: flag determining if the hardware has run since reset
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
  * @kref: pipeline reference count
@@ -117,6 +118,7 @@ struct vsp1_pipeline {
spinlock_t irqlock;
enum vsp1_pipeline_state state;
wait_queue_head_t wq;
+   bool configured;
 
void (*frame_end)(struct vsp1_pipeline *pipe, bool completed);
 
@@ -143,8 +145,6 @@ struct vsp1_pipeline {
 */
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int partitions;
struct 

[PATCH v6 5/9] v4l: vsp1: Use reference counting for bodies

2018-02-28 Thread Kieran Bingham
Extend the display list body with a reference count, allowing bodies to
be kept as long as a reference is maintained. This provides the ability
to keep a cached copy of bodies which will not change, so that they can
be re-applied to multiple display lists.

Signed-off-by: Kieran Bingham 

---
This could be squashed into the body update code, but it's not a
straightforward squash as the refcounts will affect both:
  v4l: vsp1: Provide a body pool
and
  v4l: vsp1: Convert display lists to use new body pool
therefore, I have kept this separate to prevent breaking bisectability
of the vsp-tests.

v3:
 - 's/fragment/body/'

v4:
 - Fix up reference handling comments.

 drivers/media/platform/vsp1/vsp1_clu.c |  7 ++-
 drivers/media/platform/vsp1/vsp1_dl.c  | 15 ++-
 drivers/media/platform/vsp1/vsp1_lut.c |  7 ++-
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 2018144470c5..b2a39a6ef7e4 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -257,8 +257,13 @@ static void clu_configure(struct vsp1_entity *entity,
clu->clu = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index a069c845..0f87e0bb21c1 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -58,6 +59,8 @@ struct vsp1_dl_body {
struct list_head list;
struct list_head free;
 
+   refcount_t refcnt;
+
struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
@@ -259,6 +262,7 @@ struct vsp1_dl_body *vsp1_dl_body_get(struct 
vsp1_dl_body_pool *pool)
if (!list_empty(>free)) {
dlb = list_first_entry(>free, struct vsp1_dl_body, free);
list_del(>free);
+   refcount_set(>refcnt, 1);
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -279,6 +283,9 @@ void vsp1_dl_body_put(struct vsp1_dl_body *dlb)
if (!dlb)
return;
 
+   if (!refcount_dec_and_test(>refcnt))
+   return;
+
dlb->num_entries = 0;
 
spin_lock_irqsave(>pool->lock, flags);
@@ -465,7 +472,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32 reg, 
u32 data)
  * in the order in which bodies are added.
  *
  * Adding a body to a display list passes ownership of the body to the list. 
The
- * caller must not touch the body after this call.
+ * caller retains its reference to the fragment when adding it to the display
+ * list, but is not allowed to add new entries to the body.
+ *
+ * The reference must be explicitly released by a call to vsp1_dl_body_put()
+ * when the body isn't needed anymore.
  *
  * Additional bodies are only usable for display lists in header mode.
  * Attempting to add a body to a header-less display list will return an error.
@@ -477,6 +488,8 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl,
if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
return -EINVAL;
 
+   refcount_inc(>refcnt);
+
list_add_tail(>list, >bodies);
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 262cb72139d6..77cf7137a0f2 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -213,8 +213,13 @@ static void lut_configure(struct vsp1_entity *entity,
lut->lut = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_body(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_body_put(dlb);
+   }
+
break;
}
 }
-- 
git-series 0.9.1


[PATCH v6 3/9] v4l: vsp1: Provide a body pool

2018-02-28 Thread Kieran Bingham
Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the TLB, and a large number of display list
allocations adds pressure to this resource.

Reduce TLB pressure on the IPMMUs by allocating multiple display list
bodies in a single allocation, and providing these to the display list
through a 'body pool'. A pool can be allocated by the display list
manager or entities which require their own body allocations.

Signed-off-by: Kieran Bingham 

---
v4:
 - Provide comment explaining extra allocation on body pool
   highlighting area for optimisation later.

v3:
 - s/fragment/body/, s/fragments/bodies/
 - qty -> num_bodies
 - indentation fix
 - s/vsp1_dl_body_pool_{alloc,free}/vsp1_dl_body_pool_{create,destroy}/'
 - Add kerneldoc to non-static functions

v2:
 - assign dlb->dma correctly

 drivers/media/platform/vsp1/vsp1_dl.c | 163 +++-
 drivers/media/platform/vsp1/vsp1_dl.h |   8 +-
 2 files changed, 171 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 59fe80bf6e9d..87bc4acf8c9e 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -45,6 +45,8 @@ struct vsp1_dl_entry {
 /**
  * struct vsp1_dl_body - Display list body
  * @list: entry in the display list list of bodies
+ * @free: entry in the pool free body list
+ * @pool: pool to which this body belongs
  * @vsp1: the VSP1 device
  * @entries: array of entries
  * @dma: DMA address of the entries
@@ -54,6 +56,9 @@ struct vsp1_dl_entry {
  */
 struct vsp1_dl_body {
struct list_head list;
+   struct list_head free;
+
+   struct vsp1_dl_body_pool *pool;
struct vsp1_device *vsp1;
 
struct vsp1_dl_entry *entries;
@@ -65,6 +70,30 @@ struct vsp1_dl_body {
 };
 
 /**
+ * struct vsp1_dl_body_pool - display list body pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_body_pool {
+   /* DMA allocation */
+   dma_addr_t dma;
+   size_t size;
+   void *mem;
+
+   /* Body management */
+   struct vsp1_dl_body *bodies;
+   struct list_head free;
+   spinlock_t lock;
+
+   struct vsp1_device *vsp1;
+};
+
+/**
  * struct vsp1_dl_list - Display list
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
@@ -105,6 +134,7 @@ enum vsp1_dl_mode {
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
+ * @pool: body pool for the display list bodies
  * @gc_work: bodies garbage collector work struct
  * @gc_bodies: array of display list bodies waiting to be freed
  */
@@ -120,6 +150,8 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *queued;
struct vsp1_dl_list *pending;
 
+   struct vsp1_dl_body_pool *pool;
+
struct work_struct gc_work;
struct list_head gc_bodies;
 };
@@ -128,6 +160,137 @@ struct vsp1_dl_manager {
  * Display List Body Management
  */
 
+/**
+ * vsp1_dl_body_pool_create - Create a pool of bodies from a single allocation
+ * @vsp1: The VSP1 device
+ * @num_bodies: The quantity of bodies to allocate
+ * @num_entries: The maximum number of entries that the body can contain
+ * @extra_size: Extra allocation provided for the bodies
+ *
+ * Allocate a pool of display list bodies each with enough memory to contain 
the
+ * requested number of entries.
+ *
+ * Return a pointer to a pool on success or NULL if memory can't be allocated.
+ */
+struct vsp1_dl_body_pool *
+vsp1_dl_body_pool_create(struct vsp1_device *vsp1, unsigned int num_bodies,
+unsigned int num_entries, size_t extra_size)
+{
+   struct vsp1_dl_body_pool *pool;
+   size_t dlb_size;
+   unsigned int i;
+
+   pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+   if (!pool)
+   return NULL;
+
+   pool->vsp1 = vsp1;
+
+   /*
+* Todo: 'extra_size' is only used by vsp1_dlm_create(), to allocate
+* extra memory for the display list header. We need only one header per
+* display list, not per display list body, thus this allocation is
+* extraneous and should be reworked in the future.
+*/
+   dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;
+   pool->size = dlb_size * num_bodies;
+
+   pool->bodies = kcalloc(num_bodies, sizeof(*pool->bodies), GFP_KERNEL);
+   if (!pool->bodies) {
+   kfree(pool);
+   return NULL;
+   }
+
+   pool->mem = 

[PATCH v6 4/9] v4l: vsp1: Convert display lists to use new body pool

2018-02-28 Thread Kieran Bingham
Adapt the dl->body0 object to use an object from the body pool. This
greatly reduces the pressure on the TLB for IPMMU use cases, as all of
the lists use a single allocation for the main body.

The CLU and LUT objects pre-allocate a pool containing three bodies,
allowing a userspace update before the hardware has committed a previous
set of tables.

Bodies are no longer 'freed' in interrupt context, but instead released
back to their respective pools. This allows us to remove the garbage
collector in the DLM.

Signed-off-by: Kieran Bingham 

---
v3:
 - 's/fragment/body', 's/fragments/bodies/'
 - CLU/LUT now allocate 3 bodies
 - vsp1_dl_list_fragments_free -> vsp1_dl_list_bodies_put

v2:
 - Use dl->body0->max_entries to determine header offset, instead of the
   global constant VSP1_DL_NUM_ENTRIES which is incorrect.
 - squash updates for LUT, CLU, and fragment cleanup into single patch.
   (Not fully bisectable when separated)

 drivers/media/platform/vsp1/vsp1_clu.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 223 ++
 drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  27 ++-
 drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
 6 files changed, 101 insertions(+), 181 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 9621afa3658c..2018144470c5 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -23,6 +23,8 @@
 #define CLU_MIN_SIZE   4U
 #define CLU_MAX_SIZE   8190U
 
+#define CLU_SIZE   (17 * 17 * 17)
+
 /* 
-
  * Device Access
  */
@@ -47,19 +49,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_body_get(clu->pool);
if (!dlb)
return -ENOMEM;
 
vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
-   for (i = 0; i < 17 * 17 * 17; ++i)
+   for (i = 0; i < CLU_SIZE; ++i)
vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_body_free(dlb);
+   vsp1_dl_body_put(dlb);
return 0;
 }
 
@@ -261,8 +263,16 @@ static void clu_configure(struct vsp1_entity *entity,
}
 }
 
+static void clu_destroy(struct vsp1_entity *entity)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   vsp1_dl_body_pool_destroy(clu->pool);
+}
+
 static const struct vsp1_entity_operations clu_entity_ops = {
.configure = clu_configure,
+   .destroy = clu_destroy,
 };
 
 /* 
-
@@ -288,6 +298,17 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1)
if (ret < 0)
return ERR_PTR(ret);
 
+   /*
+* Pre-allocate a body pool, with 3 bodies allowing a userspace update
+* before the hardware has committed a previous set of tables, handling
+* both the queued and pending dl entries. One extra entry is added to
+* the CLU_SIZE to allow for the VI6_CLU_ADDR header.
+*/
+   clu->pool = vsp1_dl_body_pool_create(clu->entity.vsp1, 3, CLU_SIZE + 1,
+0);
+   if (!clu->pool)
+   return ERR_PTR(-ENOMEM);
+
/* Initialize the control handler. */
v4l2_ctrl_handler_init(>ctrls, 2);
v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.h 
b/drivers/media/platform/vsp1/vsp1_clu.h
index 036e0a2f1a42..fa3fe856725b 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.h
+++ b/drivers/media/platform/vsp1/vsp1_clu.h
@@ -36,6 +36,7 @@ struct vsp1_clu {
spinlock_t lock;
unsigned int mode;
struct vsp1_dl_body *clu;
+   struct vsp1_dl_body_pool *pool;
 };
 
 static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 87bc4acf8c9e..a069c845 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -111,7 +111,7 @@ struct vsp1_dl_list {
struct vsp1_dl_header *header;
dma_addr_t dma;
 
-   struct vsp1_dl_body body0;
+   struct vsp1_dl_body *body0;
struct list_head bodies;
 
bool has_chain;
@@ -135,8 +135,6 @@ enum vsp1_dl_mode {
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
  * @pool: body pool for the display list bodies
- * 

[PATCH v6 0/9] vsp1: TLB optimisation and DL caching

2018-02-28 Thread Kieran Bingham
Each display list currently allocates an area of DMA memory to store register
settings for the VSP1 to process. Each of these allocations adds pressure to
the IPMMU TLB entries.

We can reduce the pressure by pre-allocating larger areas and dividing the area
across multiple bodies represented as a pool.

With this reconfiguration of bodies, we can adapt the configuration code to
separate out constant hardware configuration and cache it for re-use.

The patches provided in this series can be found at:
  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git  
tags/vsp1/tlb-optimise/v6

Changelog:
--

v6:
 - Rebased on to linux-media/master (v4.16-rc1)
 - Removed DRM/UIF (DISCOM/ColorKey) updates

v5:
 - Rebased on to renesas-drivers-2018-01-09-v4.15-rc7 to fix conflicts
   with DRM and UIF updates on VSP1 driver

v4:
 - Rebased to v4.14
 * v4l: vsp1: Use reference counting for bodies
   - Fix up reference handling comments

 * v4l: vsp1: Provide a body pool
   - Provide comment explaining extra allocation on body pool
 highlighting area for optimisation later.

 * v4l: vsp1: Refactor display list configure operations
   - Fix up comment to describe yuv_mode caching rather than format

 * vsp1: Adapt entities to configure into a body
   - Rename vsp1_dl_list_get_body() to vsp1_dl_list_get_body0()

 * v4l: vsp1: Move video configuration to a cached dlb
   - Adjust pipe configured flag to be reset on resume rather than suspend
   - rename dl_child, dl_next

Testing:

The VSP unit tests have been run on this patch set with the following results:

--- Test loop 1 ---
- vsp-unit-test-.sh
Test Conditions:
  Platform  Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+
  Kernel release4.16.0-rc1-arm64-renesas-00166-ge0ad4e839fff
  convert   /usr/bin/convert
  compare   /usr/bin/compare
  killall   /usr/bin/killall
  raw2rgbpnm/usr/bin/raw2rgbpnm
  stress/usr/bin/stress
  yavta /usr/bin/yavta
- vsp-unit-test-0001.sh
Testing WPF packing in RGB332: pass
Testing WPF packing in ARGB555: pass
Testing WPF packing in XRGB555: pass
Testing WPF packing in RGB565: pass
Testing WPF packing in BGR24: pass
Testing WPF packing in RGB24: pass
Testing WPF packing in ABGR32: pass
Testing WPF packing in ARGB32: pass
Testing WPF packing in XBGR32: pass
Testing WPF packing in XRGB32: pass
- vsp-unit-test-0002.sh
Testing WPF packing in NV12M: pass
Testing WPF packing in NV16M: pass
Testing WPF packing in NV21M: pass
Testing WPF packing in NV61M: pass
Testing WPF packing in UYVY: pass
Testing WPF packing in VYUY: skip
Testing WPF packing in YUV420M: pass
Testing WPF packing in YUV422M: pass
Testing WPF packing in YUV444M: pass
Testing WPF packing in YVU420M: pass
Testing WPF packing in YVU422M: pass
Testing WPF packing in YVU444M: pass
Testing WPF packing in YUYV: pass
Testing WPF packing in YVYU: pass
- vsp-unit-test-0003.sh
Testing scaling from 640x640 to 640x480 in RGB24: pass
Testing scaling from 1024x768 to 640x480 in RGB24: pass
Testing scaling from 640x480 to 1024x768 in RGB24: pass
Testing scaling from 640x640 to 640x480 in YUV444M: pass
Testing scaling from 1024x768 to 640x480 in YUV444M: pass
Testing scaling from 640x480 to 1024x768 in YUV444M: pass
- vsp-unit-test-0004.sh
Testing histogram in RGB24: pass
Testing histogram in YUV444M: pass
- vsp-unit-test-0005.sh
Testing RPF.0: pass
Testing RPF.1: pass
Testing RPF.2: pass
Testing RPF.3: pass
Testing RPF.4: pass
- vsp-unit-test-0006.sh
Testing invalid pipeline with no RPF: pass
Testing invalid pipeline with no WPF: pass
- vsp-unit-test-0007.sh
Testing BRU in RGB24 with 1 inputs: pass
Testing BRU in RGB24 with 2 inputs: pass
Testing BRU in RGB24 with 3 inputs: pass
Testing BRU in RGB24 with 4 inputs: pass
Testing BRU in RGB24 with 5 inputs: pass
Testing BRU in YUV444M with 1 inputs: pass
Testing BRU in YUV444M with 2 inputs: pass
Testing BRU in YUV444M with 3 inputs: pass
Testing BRU in YUV444M with 4 inputs: pass
Testing BRU in YUV444M with 5 inputs: pass
- vsp-unit-test-0008.sh
Test requires unavailable feature set `bru rpf.0 uds wpf.0': skipped
- vsp-unit-test-0009.sh
Test requires unavailable feature set `rpf.0 wpf.0 wpf.1': skipped
- vsp-unit-test-0010.sh
Testing CLU in RGB24 with zero configuration: pass
Testing CLU in RGB24 with identity configuration: pass
Testing CLU in RGB24 with wave configuration: pass
Testing CLU in YUV444M with zero configuration: pass
Testing CLU in YUV444M with identity configuration: pass
Testing CLU in YUV444M with wave configuration: pass
Testing LUT in RGB24 with zero configuration: pass
Testing LUT in RGB24 with identity configuration: pass
Testing LUT in RGB24 with gamma configuration: pass
Testing LUT in YUV444M with zero configuration: pass
Testing LUT in YUV444M with identity configuration: pass
Testing LUT in YUV444M with gamma configuration: pass
- vsp-unit-test-0011.sh
Testing  hflip=0 vflip=0 rotate=0: pass
Testing  hflip=1 

[PATCH v6 9/9] v4l: vsp1: Reduce display list body size

2018-02-28 Thread Kieran Bingham
The display list originally allocated a body of 256 entries to store all
of the register lists required for each frame.

This has now been separated into fragments for constant stream setup, and
runtime updates.

Empirical testing shows that the body0 now uses a maximum of 41
registers for each frame, for both DRM and Video API pipelines thus a
rounded 64 entries provides a suitable allocation.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index a762e840d147..6b5743a431a2 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -21,7 +21,7 @@
 #include "vsp1.h"
 #include "vsp1_dl.h"
 
-#define VSP1_DL_NUM_ENTRIES256
+#define VSP1_DL_NUM_ENTRIES64
 
 #define VSP1_DLH_INT_ENABLE(1 << 1)
 #define VSP1_DLH_AUTO_START(1 << 0)
-- 
git-series 0.9.1


Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

2018-02-28 Thread Laurent Pinchart
Hi Kieran,

On Wednesday, 28 February 2018 18:41:31 EET Kieran Bingham wrote:
> Hi Laurent,
> 
> This series has a pending question below:
> 
> On 17/11/17 15:07, Kieran Bingham wrote:
> > Hi Laurent,
> > 
> > Just a query on your bikeshedding here.
> > 
> > Choose your colours wisely :)
> > 
> > On 12/09/17 20:19, Laurent Pinchart wrote:
> >> On Tuesday, 12 September 2017 00:16:50 EEST Kieran Bingham wrote:
> >>> On 17/08/17 19:13, Laurent Pinchart wrote:
>  On Monday 14 Aug 2017 16:13:28 Kieran Bingham wrote:
> > The entities provide a single .configure operation which configures
> > the object into the target display list, based on the
> > vsp1_entity_params selection.
> > 
> > This restricts us to a single function prototype for both static
> > configuration (the pre-stream INIT stage) and the dynamic runtime
> > stages for both each frame - and each partition therein.
> > 
> > Split the configure function into two parts, '.prepare()' and
> > '.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
> > VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
> > .configure(). The configuration for individual partitions is handled
> > by passing the partition number to the configure call, and processing
> > any runtime stage actions on the first partition only.
> > 
> > Signed-off-by: Kieran Bingham
> > 
> > ---
> > 
> >  drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
> >  drivers/media/platform/vsp1/vsp1_clu.c|  43 +--
> >  drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
> >  drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
> >  drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
> >  drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
> >  drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
> >  drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
> >  drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
> >  drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
> >  drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
> >  drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
> >  drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
> >  drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
> >  drivers/media/platform/vsp1/vsp1_wpf.c| 297 +++--
> >  15 files changed, 359 insertions(+), 371 deletions(-)
>  
>  [snip]
>  
> > diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
> > b/drivers/media/platform/vsp1/vsp1_clu.c index
> > 175717018e11..5f65ce3ad97f
> > 100644
> > --- a/drivers/media/platform/vsp1/vsp1_clu.c
> > +++ b/drivers/media/platform/vsp1/vsp1_clu.c
> > @@ -213,37 +213,37 @@ static const struct v4l2_subdev_ops clu_ops = {
> >  /* --
> >   * VSP1 Entity Operations
> >   */
> > +static void clu_prepare(struct vsp1_entity *entity,
> > +   struct vsp1_pipeline *pipe,
> > +   struct vsp1_dl_list *dl)
> > +{
> > +   struct vsp1_clu *clu = to_clu(>subdev);
> > +
> > +   /*
> > +* The format can't be changed during streaming, only verify it
> > +* at setup time and store the information internally for future
> > +* runtime configuration calls.
> > +*/
>  
>  I know you're just moving the comment around, but let's fix it at the
>  same time. There's no verification here (and no "setup time" either).
>  I'd write it as
>  
>   /*
>    * The format can't be changed during streaming. Cache it internally
>    * for future runtime configuration calls.
>    */
> >>> 
> >>> I think I'm ok with that and I've updated the patch - but I'm not sure
> >>> we are really caching the 'format' here, as much as the yuv_mode ...
> >> 
> >> Yes, it's the YUV mode we're caching, feel free to update the comment.
> > 
> > Done.
> > 
> >>> I'll ponder ...
> >>> 
> > +   struct v4l2_mbus_framefmt *format;
> > +
> > +   format = vsp1_entity_get_pad_format(>entity,
> > +   clu->entity.config,
> > +   CLU_PAD_SINK);
> > +   clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
> > +}
>  
>  [snip]
>  
> > diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
> > b/drivers/media/platform/vsp1/vsp1_entity.h index
> > 408602ebeb97..2f33e343ccc6 100644
> > --- a/drivers/media/platform/vsp1/vsp1_entity.h
> > +++ b/drivers/media/platform/vsp1/vsp1_entity.h
>  
>  [snip]
>  
> > @@ -80,8 +68,10 @@ struct vsp1_route {
> >  /**
> >   * struct vsp1_entity_operations - Entity operations
> >   * @destroy:   Destroy the entity.
> > - * @configure: Setup 

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

2018-02-28 Thread Alex Deucher
On Tue, Feb 27, 2018 at 7:56 AM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
>
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
>
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes(). For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().
>
> Cc: Keith Packard 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> Cc: Shashank Sharma 
> Cc: Stefan Agner 
> Cc: Thierry Reding 
> Cc: Boris Brezillon 
> Cc: Philipp Zabel 
> Cc: Laurent Pinchart 
> Cc: Manfred Schlaegl 
> Cc: Marek Vasut 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Alison Wang 
> Cc: Eric Anholt 
> Cc: Linus Walleij 
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: Maxime Ripard 
> Signed-off-by: Ville Syrjälä 

Acked-by: Alex Deucher 


Re: [PATCH v5 12/26] watchdog: renesas_wdt: Add R-Car Gen2 support

2018-02-28 Thread Geert Uytterhoeven
Hi Fabrizio,

On Mon, Feb 12, 2018 at 6:44 PM, Fabrizio Castro
 wrote:
> Due to commits:
> * "ARM: shmobile: Add watchdog support",
> * "ARM: shmobile: rcar-gen2: Add watchdog support", and
> * "soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2",
> we now have everything we needed for the watchdog to work on Gen2 and
> RZ/G1.
>
> This commit adds "renesas,rcar-gen2-wdt" as compatible string for R-Car
> Gen2 and RZ/G1, and since on those platforms the rwdt clock needs to be
> always ON, when suspending to RAM we need to explicitly disable the
> counting by clearing TME from RWTCSRA.
>
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Ramesh Shanmugasundaram 
> 

Thanks for your patch!

I verified this works on R-Car Gen2, so
Reviewed-and-Tested-by: Geert Uytterhoeven 

Still, more comments below...

> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -203,13 +203,29 @@ static int rwdt_remove(struct platform_device *pdev)
> return 0;
>  }
>
> -/*
> - * This driver does also fit for R-Car Gen2 (r8a779[0-4]) WDT. However, for 
> SMP
> - * to work there, one also needs a RESET (RST) driver which does not exist 
> yet
> - * due to HW issues. This needs to be solved before adding compatibles here.
> - */
> +static int __maybe_unused rwdt_suspend(struct device *dev)
> +{
> +   struct rwdt_priv *priv = dev_get_drvdata(dev);
> +
> +   if (watchdog_active(>wdev))
> +   rwdt_write(priv, priv->cks, RWTCSRA);
> +   return 0;
> +}
> +
> +static int __maybe_unused rwdt_resume(struct device *dev)
> +{
> +   struct rwdt_priv *priv = dev_get_drvdata(dev);
> +
> +   if (watchdog_active(>wdev))
> +   rwdt_write(priv, priv->cks | RWTCSRA_TME, RWTCSRA);

Writing to this register is not sufficient on R-Car Gen3, where PSCI
suspend powers down the whole SoC.  Hence all WDT register content is lost,
causing the watchdog timeout never to trigger.
Note that this issue is pre-existing, and not caused by your patch.

This can be fixed by replacing the RWTCSRA register writes in the
suspend/resume handlers by calls to rwdt_stop() resp. rwdt_start(), like is
done in the BSP in commit e406980763f18f38 ("watchdog: renesas-wdt: Support
the suspend/resume"). Note that this would cause a small change in behavior
on R-Car Gen2, where the timeout would be reset on resume, instead of
continuing where stopped before. I don't think that hurts, though.

Since I was always a bit uncomfortable with this patch doing two things at
once (1. suspend/resume, 2. "renesas,rcar-gen2-wdt" matching), I think it
would be better to take the patch from the BSP first, and add support for
"renesas,rcar-gen2-wdt" in a subsequent patch.

Does the above make sense?
Do you agree?

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


RCar-H3-ES2.0: v4.16-rc1 (media tree) __handle_irq_event_percpu page fault

2018-02-28 Thread Kieran Bingham
Hi Linux-ARM / Linux-Renesas-SoC

I had this page fault occur once, during testing of my current series.

It occurred once, and hasn't happened since, so perhaps just the direction the
wind was blowing. Posting to see if there is a known regression - or if anyone
else has hit similar, or so that it will come up in a google search if someone
else does :D


Has anyone else had a back trace similar to this on v4.16-rc1 ?


HW: RCar-H3 ES-2.0 platform.
SW: Linux media master branch + my development branch:

   git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git
   tags/vsp1/tlb-optimise/v6

Don't be confused by the tag name 'tlb-optimise' - I'm not playing around with
any TLB code here - just reducing the number of allocations by creating a single
larger dma buffer in a media driver.

===


Welcome to Ubuntu 16.04 LTS (GNU/Linux
4.16.0-rc1-arm64-renesas-00166-ge0ad4e839fff aarch64)

root@Ubuntu-ARM64:~# [ 3894.054525] Unable to handle kernel paging request at
virtual address 08ee7070
[ 3894.062527] Mem abort info:
[ 3894.065334]   ESR = 0x9607
[ 3894.068403]   Exception class = DABT (current EL), IL = 32 bits
[ 3894.074348]   SET = 0, FnV = 0
[ 3894.077416]   EA = 0, S1PTW = 0
[ 3894.080573] Data abort info:
[ 3894.083469]   ISV = 0, ISS = 0x0007
[ 3894.087323]   CM = 0, WnR = 0
[ 3894.090306] swapper pgtable: 4k pages, 48-bit VAs, pgd = 3440d0b1
[ 3894.097123] [08ee7070] *pgd=00073fffe003, *pud=00073fffd003,
*pmd=00073fffa003, *pte=
[ 3894.108469] Internal error: Oops: 9607 [#1] PREEMPT SMP
[ 3894.114070] Modules linked in:
[ 3894.117143] CPU: 0 PID: 15500 Comm: stress Tainted: GW
4.16.0-rc1-arm64-renesas-00166-ge0ad4e839fff #240
[ 3894.127957] Hardware name: Renesas Salvator-X 2nd version board based on
r8a7795 ES2.0+ (DT)
[ 3894.136420] pstate: 6085 (nZCv daIf -PAN -UAO)
[ 3894.141243] pc : __handle_irq_event_percpu+0x3e0/0x468
[ 3894.146403] lr : __handle_irq_event_percpu+0x3e0/0x468
[ 3894.151557] sp : 08003e60
[ 3894.154880] x29: 08003e60 x28: 0001
[ 3894.160213] x27: 8006fa99ac00 x26: 09015000
[ 3894.165545] x25: 08ee7010 x24: 08003efc
[ 3894.170877] x23: 08ee7010 x22: 
[ 3894.176210] x21: 08f0fac0 x20: 0085
[ 3894.181543] x19: 8006f93e6e00 x18: 0a03
[ 3894.186876] x17: 97c65e58 x16: d6f3ef00
[ 3894.192209] x15: 97e5f000 x14: 03f3
[ 3894.197540] x13:  x12: 03f3
[ 3894.202872] x11: 0018 x10: 
[ 3894.208206] x9 : 09bfc000 x8 : 08fb
[ 3894.213539] x7 : 087058d4 x6 : cbbdd6ed
[ 3894.218870] x5 : 8006f9976d68 x4 : 8006ffef0a80
[ 3894.224204] x3 :  x2 : 0001
[ 3894.229536] x1 :  x0 : 0001
[ 3894.234871] Process stress (pid: 15500, stack limit = 0xbee2ce9d)
[ 3894.241680] Call trace:
[ 3894.244143]  __handle_irq_event_percpu+0x3e0/0x468
[ 3894.248950]  handle_irq_event_percpu+0x28/0x60
[ 3894.253407]  handle_irq_event+0x50/0x80
[ 3894.257257]  handle_fasteoi_irq+0xa8/0x188
[ 3894.261369]  generic_handle_irq+0x34/0x50
[ 3894.265393]  __handle_domain_irq+0x68/0xc0
[ 3894.269505]  gic_handle_irq+0x60/0xb8
[ 3894.273181]  el0_irq_naked+0x50/0x5c
[ 3894.276771] Code: 97fff84d 174d f90033a1 94003205 (f94033a1)
[ 3894.282906] ---[ end trace 05f4c46a627d8e19 ]---
[ 3894.287540] Kernel panic - not syncing: Fatal exception in interrupt
[ 3894.293923] SMP: stopping secondary CPUs
[ 3894.297864] Kernel Offset: disabled
[ 3894.301364] CPU features: 0x1802000
[ 3894.304861] Memory Limit: none
[ 3894.307939] ---[ end Kernel panic - not syncing: Fatal exception in interrupt



[PATCH] media: renesas-ceu: mark PM functions as __maybe_unused

2018-02-28 Thread Arnd Bergmann
The PM runtime operations are unused when CONFIG_PM is disabled,
leading to a harmless warning:

drivers/media/platform/renesas-ceu.c:1003:12: error: 'ceu_runtime_suspend' 
defined but not used [-Werror=unused-function]
 static int ceu_runtime_suspend(struct device *dev)
^~~
drivers/media/platform/renesas-ceu.c:987:12: error: 'ceu_runtime_resume' 
defined but not used [-Werror=unused-function]
 static int ceu_runtime_resume(struct device *dev)
^~

This adds a __maybe_unused annotation to shut up the warning.

Fixes: 32e5a70dc8f4 ("media: platform: Add Renesas CEU driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/platform/renesas-ceu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/renesas-ceu.c 
b/drivers/media/platform/renesas-ceu.c
index 22330c0c2f6a..eccd60a7ebec 100644
--- a/drivers/media/platform/renesas-ceu.c
+++ b/drivers/media/platform/renesas-ceu.c
@@ -984,7 +984,7 @@ static int ceu_init_mbus_fmt(struct ceu_device *ceudev)
 /*
  * ceu_runtime_resume() - soft-reset the interface and turn sensor power on.
  */
-static int ceu_runtime_resume(struct device *dev)
+static int __maybe_unused ceu_runtime_resume(struct device *dev)
 {
struct ceu_device *ceudev = dev_get_drvdata(dev);
struct v4l2_subdev *v4l2_sd = ceudev->sd->v4l2_sd;
@@ -1000,7 +1000,7 @@ static int ceu_runtime_resume(struct device *dev)
  * ceu_runtime_suspend() - disable capture and interrupts and soft-reset.
  *Turn sensor power off.
  */
-static int ceu_runtime_suspend(struct device *dev)
+static int __maybe_unused ceu_runtime_suspend(struct device *dev)
 {
struct ceu_device *ceudev = dev_get_drvdata(dev);
struct v4l2_subdev *v4l2_sd = ceudev->sd->v4l2_sd;
-- 
2.9.0



RE: [PATCH] dmaengine: rcar-dmac: Check the done lists in rcar_dmac_chan_get_residue()

2018-02-28 Thread Yoshihiro Shimoda
Hi Vinod,

Would you review this patch?
Or, should I rebase this on the latest your repo?

Best regards,
Yoshihiro Shimoda

> -Original Message-
> From: Yoshihiro Shimoda
> Sent: Friday, February 2, 2018 7:05 PM
> To: vinod.k...@intel.com
> Cc: dmaeng...@vger.kernel.org; linux-renesas-soc@vger.kernel.org; Yoshihiro 
> Shimoda 
> Subject: [PATCH] dmaengine: rcar-dmac: Check the done lists in 
> rcar_dmac_chan_get_residue()
> 
> This patch fixes an issue that a race condition happens between a client
> driver and the rcar-dmac driver:
> 
> - The rcar_dmac_isr_transfer_end() is called.
>  - The done list appears, and desc.running is the next active list.
> - rcar_dmac_chan_get_residue() is called by a client driver before
>   rcar_dmac_isr_channel_thread() is called.
>  - The rcar_dmac_chan_get_residue() will not find any descriptors.
>  - And, the following WARNING happens:
>   WARN(1, "No descriptor for cookie!");
> 
> The sh-sci driver with HSCIF (921,600bps) on R-Car H3 can cause this
> situation.
> So, this patch checks the done lists in rcar_dmac_chan_get_residue()
> and returns zero if the done lists has the argument cookie.
> 
> Tested-by: Nguyen Viet Dung 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/dma/sh/rcar-dmac.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 2b2c7db..f748be6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1264,8 +1264,17 @@ static unsigned int rcar_dmac_chan_get_residue(struct 
> rcar_dmac_chan *chan,
>* If the cookie doesn't correspond to the currently running transfer
>* then the descriptor hasn't been processed yet, and the residue is
>* equal to the full descriptor size.
> +  * Also, a client driver is possible to call this function before
> +  * rcar_dmac_isr_channel_thread() runs. In this case, the "desc.running"
> +  * will be the next descriptor, and the done list will appear. So, if
> +  * the argument cookie matches the done list's cookie, we can assume
> +  * the residue is zero.
>*/
>   if (cookie != desc->async_tx.cookie) {
> + list_for_each_entry(desc, >desc.done, node) {
> + if (cookie == desc->async_tx.cookie)
> + return 0;
> + }
>   list_for_each_entry(desc, >desc.pending, node) {
>   if (cookie == desc->async_tx.cookie)
>   return desc->size;
> --
> 1.9.1



Re: [GIT PULL FOR renesas-drivers] d3/i2c-conflict/drm

2018-02-28 Thread Geert Uytterhoeven
Hi Kieran,

On Thu, Feb 15, 2018 at 7:35 PM, Kieran Bingham  wrote:
> Please consider including this branch in renesas-drivers.
>
> --
> Regards
>
> Kieran
>
> The following changes since commit 94fc27ac487a80daf42f97b1a0503d029f3c1325:
>
>   Merge tag 'drm-intel-next-fixes-2018-02-07' of 
> git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-02-08 
> 08:21:37 +1000)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
> d3/i2c-conflict/drm
>
> for you to fetch changes up to 21dc5df16073e4ec91b478ac95913daaa088c81b:
>
>   drm: adv7511: Add support for i2c_new_secondary_device (2018-02-15 17:30:23 
> +)

Thank you, merges cleanly into today's linux-next.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [GIT PULL FOR renesas-drivers] d3/i2c-conflict/media

2018-02-28 Thread Geert Uytterhoeven
Hi Kieran,

On Thu, Feb 15, 2018 at 7:35 PM, Kieran Bingham  wrote:
> Please consider including this branch in renesas-drivers.
>
> --
> Regards
>
> Kieran
>
> The following changes since commit 29422737017b866d4a51014cc7522fa3a99e8852:
>
>   media: rc: get start time just before calling driver tx (2018-02-14 
> 14:17:21 -0500)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
> d3/i2c-conflict/media
>
> for you to fetch changes up to a22cefa41188bdda128b76d6a067e55b40ce5c22:
>
>   media: adv7604: Add support for i2c_new_secondary_device (2018-02-15 
> 17:31:26 +)

Thank you, merges cleanly into today's linux-next.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

2018-02-28 Thread Simon Horman
On Tue, Feb 27, 2018 at 11:23:39PM +0300, Sergei Shtylyov wrote:
> On 02/27/2018 11:06 PM, Sergei Shtylyov wrote:
> 
> > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
> > 'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 
> > FCPVD/VSPD/
> > DU/LVDS device nodes and then describing the HDMI encoder connected to the 
> > LVDS
> > output (we're omitting the LVDS decoder for now). These patches depend on
> > the recent R8A77970 DU/LVDS rework patches by Laurent in order to work...   
> 
>Need to mention that the DU driver silently fails to probe now. I do
>hope that this is not due to my updates. :-)

Please test that theory.


Re: [PATCH v5 01/26] ARM: shmobile: Add watchdog support

2018-02-28 Thread Geert Uytterhoeven
Hi Fabrizio,

On Mon, Feb 12, 2018 at 6:44 PM, Fabrizio Castro
 wrote:
> On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non
> boot CPUs run a routine designed to bring up SMP and deal with hot plug.
> The value contained in the SBAR registers is not initialized by a WDT
> triggered reset, which means that after a WDT triggered reset we jump
> to the SMP bring up routine, preventing the system from executing the
> bootrom code.
>
> The purpose of this patch is to jump to the bootrom code in case of a
> WDT triggered reset, and keep the SMP functionality untouched.
> In order to tell if the code had been called due to the WDT overflowing
> we are testing WOVF from register RWTCSRA.
>
> The new function shmobile_boot_vector_gen2 isn't replacing
> shmobile_boot_vector for backward compatibility reasons. The kernel
> will install the best option (either shmobile_boot_vector or
> shmobile_boot_vector_gen2) to ICRAM1 after parsing the device tree,
> according to the amount of memory available.
>
> Since shmobile_boot_vector has become bigger, "reg" property of nodes
> compatible with "renesas,smp-sram" now need to be set to a value
> greater or equal to "<0 0x60>".
>
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Ramesh Shanmugasundaram 
> 

> --- a/arch/arm/mach-shmobile/common.h
> +++ b/arch/arm/mach-shmobile/common.h
> @@ -7,6 +7,12 @@ extern void shmobile_init_delay(void);
>  extern void shmobile_boot_vector(void);
>  extern unsigned long shmobile_boot_fn;
>  extern unsigned long shmobile_boot_size;
> +#ifdef CONFIG_ARCH_RCAR_GEN2

I think this #ifdef can be removed.

> +extern void shmobile_boot_vector_gen2(void);
> +extern unsigned long shmobile_boot_fn_gen2;
> +extern unsigned long shmobile_boot_cpu_gen2;
> +extern unsigned long shmobile_boot_size_gen2;
> +#endif /* CONFIG_ARCH_RCAR_GEN2 */
>  extern void shmobile_smp_boot(void);
>  extern void shmobile_smp_sleep(void);
>  extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn,

Apart from that:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

2018-02-28 Thread Sharma, Shashank

for I915: Acked-by: Shashank Sharma 

Regards
Shashank
On 2/27/2018 6:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.

The static part will consist of subpixel_order, panel_orientation,
and bus_formats.

Actually I'm not sure where bus_formats & co. fit in all this. For some
drivers those seem to be static, even though they might fill them out
from .get_modes(). For other drivers this stuff even gets frobbed at
runtime, making it more some kind of a bastard encoder/connector state.
I'll just stick it into the static side so that the behaviour doesn't
change when I start clear out the entire dynamic state with memset().

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Hans de Goede 
Cc: Shashank Sharma 
Cc: Stefan Agner 
Cc: Thierry Reding 
Cc: Boris Brezillon 
Cc: Philipp Zabel 
Cc: Laurent Pinchart 
Cc: Manfred Schlaegl 
Cc: Marek Vasut 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Alison Wang 
Cc: Eric Anholt 
Cc: Linus Walleij 
Cc: linux-renesas-soc@vger.kernel.org
Cc: Maxime Ripard 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |   2 +-
  drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |   2 +-
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   2 +-
  drivers/gpu/drm/bridge/sii902x.c   |   2 +-
  drivers/gpu/drm/bridge/tc358767.c  |   2 +-
  drivers/gpu/drm/drm_connector.c|  12 +-
  drivers/gpu/drm/drm_fb_helper.c|   2 +-
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   2 +-
  drivers/gpu/drm/gma500/cdv_intel_hdmi.c|   2 +-
  drivers/gpu/drm/gma500/cdv_intel_lvds.c|   2 +-
  drivers/gpu/drm/gma500/mdfld_dsi_output.c  |   2 +-
  drivers/gpu/drm/gma500/oaktrail_hdmi.c |   2 +-
  drivers/gpu/drm/gma500/oaktrail_lvds.c |   2 +-
  drivers/gpu/drm/gma500/psb_intel_lvds.c|   2 +-
  drivers/gpu/drm/gma500/psb_intel_sdvo.c|   2 +-
  drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
  drivers/gpu/drm/i915/intel_dsi.c   |   4 +-
  drivers/gpu/drm/i915/intel_dvo.c   |   2 +-
  drivers/gpu/drm/i915/intel_lvds.c  |   2 +-
  drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
  drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
  drivers/gpu/drm/imx/parallel-display.c |   2 +-
  drivers/gpu/drm/mxsfb/mxsfb_crtc.c |   6 +-
  drivers/gpu/drm/panel/panel-arm-versatile.c|   2 +-
  drivers/gpu/drm/panel/panel-ilitek-ili9322.c   |   8 +-
  drivers/gpu/drm/panel/panel-lvds.c |   4 +-
  .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  |   2 +-
  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|   4 +-
  drivers/gpu/drm/panel/panel-simple.c   |   4 +-
  drivers/gpu/drm/pl111/pl111_display.c  |   4 +-
  drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
  drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |   2 +-
  drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
  drivers/gpu/drm/tve200/tve200_display.c|   2 +-
  drivers/gpu/drm/vc4/vc4_dpi.c  |   4 +-
  include/drm/drm_connector.h| 123 -
  36 files changed, 125 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 74d2efaec52f..1ba72dc2a85b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1927,7 +1927,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
  
-	connector->display_info.subpixel_order = subpixel_order;

+   connector->static_display_info.subpixel_order = subpixel_order;
drm_connector_register(connector);
  
  	if (has_aux)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c 
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index 120dd3b26fc2..7e9f7f1ab1b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -639,7 +639,7 @@ static int 

[PATCH] ARM: shmobile: rcar-gen2: Fix error check in regulator quirk

2018-02-28 Thread Geert Uytterhoeven
On systems with two regulators, a bogus error message is printed on
success:

i2c 6-0058: i2c error 2

While adding support for Stout, the number of messages to send was
made variable, but the corresponding return value check of
i2c_transfer() wasn't updated.

Fixes: ff938cd14d67a704 ("ARM: shmobile: stout: enable R-Car Gen2 regulator 
quirk")
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c 
b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
index 27fb3a5ec73e6dda..93f628acfd944fd5 100644
--- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
@@ -98,7 +98,7 @@ static int regulator_quirk_notify(struct notifier_block *nb,
 
dev_info(>dev, "clearing da9063/da9210 interrupts\n");
ret = i2c_transfer(client->adapter, da9xxx_msgs, len);
-   if (ret != ARRAY_SIZE(da9xxx_msgs))
+   if (ret != len)
dev_err(>dev, "i2c error %d\n", ret);
}
 
-- 
2.7.4



Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

2018-02-28 Thread Stefan Agner
On 27.02.2018 13:56, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
> 
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
> 
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes(). For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().

Back when I introduced bus flags it was meant to be a static
information.

So for the general idea/drm_connector.h:

Reviewed-by: Stefan Agner 

[...] 

>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   2 +-

For fsl-dcu:

Acked-by: Stefan Agner 

--
Stefan

>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c|   2 +-
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c|   2 +-
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c  |   2 +-
>  drivers/gpu/drm/gma500/oaktrail_hdmi.c |   2 +-
>  drivers/gpu/drm/gma500/oaktrail_lvds.c |   2 +-
>  drivers/gpu/drm/gma500/psb_intel_lvds.c|   2 +-
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c|   2 +-
>  drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
>  drivers/gpu/drm/i915/intel_dsi.c   |   4 +-
>  drivers/gpu/drm/i915/intel_dvo.c   |   2 +-
>  drivers/gpu/drm/i915/intel_lvds.c  |   2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
>  drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
>  drivers/gpu/drm/imx/parallel-display.c |   2 +-
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c |   6 +-
>  drivers/gpu/drm/panel/panel-arm-versatile.c|   2 +-
>  drivers/gpu/drm/panel/panel-ilitek-ili9322.c   |   8 +-
>  drivers/gpu/drm/panel/panel-lvds.c |   4 +-
>  .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  |   2 +-
>  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|   4 +-
>  drivers/gpu/drm/panel/panel-simple.c   |   4 +-
>  drivers/gpu/drm/pl111/pl111_display.c  |   4 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |   2 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
>  drivers/gpu/drm/tve200/tve200_display.c|   2 +-
>  drivers/gpu/drm/vc4/vc4_dpi.c  |   4 +-
>  include/drm/drm_connector.h| 123 
> -
>  36 files changed, 125 insertions(+), 106 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 74d2efaec52f..1ba72dc2a85b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -1927,7 +1927,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
>   } else
>   connector->polled = DRM_CONNECTOR_POLL_HPD;
>  
> - connector->display_info.subpixel_order = subpixel_order;
> + connector->static_display_info.subpixel_order = subpixel_order;
>   drm_connector_register(connector);
>  
>   if (has_aux)
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> index 120dd3b26fc2..7e9f7f1ab1b1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
> @@ -639,7 +639,7 @@ static int
> dce_virtual_connector_encoder_init(struct amdgpu_device *adev,
>   drm_connector_init(adev->ddev, connector, _virtual_connector_funcs,
>  DRM_MODE_CONNECTOR_VIRTUAL);
>   drm_connector_helper_add(connector, 
> _virtual_connector_helper_funcs);
> - connector->display_info.subpixel_order = SubPixelHorizontalRGB;
> + connector->static_display_info.subpixel_order = SubPixelHorizontalRGB;
>   connector->interlace_allowed = false;
>   connector->doublescan_allowed = false;
>   drm_connector_register(connector);
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index d73281095fac..2d18c8ef22a0 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -238,7 +238,7 @@ static int
> atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
>   crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
>  
>   for_each_new_connector_in_state(state->state, 

Re: [RFC][PATCH] ARM: shmobile: Rework the PMIC IRQ line quirk

2018-02-28 Thread Geert Uytterhoeven
Hi Marek,

On Mon, Feb 26, 2018 at 11:17 AM, Marek Vasut  wrote:
> Rather than hard-coding the quirk topology, which stopped scaling,
> parse the information from DT. The code looks for all compatible
> PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
> to the same pin. If so, the code sends a matching sequence to the
> PMIC to deassert the IRQ.

Note that not all R-Car Gen2 boards have all regulators described in DT yet.
E.g. gose lacks da9210. So that has to be fixed first.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH 2/4] dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers

2018-02-28 Thread Geert Uytterhoeven
Hi Sergei,

On Wed, Feb 28, 2018 at 8:38 AM, Sergei Shtylyov
 wrote:
> On 2/28/2018 9:49 AM, Simon Horman wrote:
>> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
>> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
>> @@ -120,9 +120,9 @@ Boards:
>>   compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
>> - Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD)
>>   compatible = "renesas,stout", "renesas,r8a7790"
>> -  - V3MSK
>> +  - V3MSK (Y-ASK-RCAR-V3M-WS10)
>
>https://elinux.org/R-Car/Boards/V3MSK (now that I'm reminded of this
> site) says the V3MSK's model # is RTP0RC77970SEB0010S.

Nope, that's Eagle :-(
Check the picture on https://elinux.org/R-Car/Boards/Eagle

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


renesas-drivers-2018-02-28-v4.16-rc3

2018-02-28 Thread Geert Uytterhoeven
I have pushed renesas-drivers-2018-02-28-v4.16-rc3 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20180227-v4.16-rc3.

Included branches with driver code:
  - clk-renesas
  - sh-pfc
  - topic/rcar-genpd-wakeup-v4
  - topic/r8a77970-eagle-i2c-v1
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/ipmmu-driver-v6
  - git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
  - git://linuxtv.org/pinchartl/media.git#tags/vsp1-discom-v1-20171215
  - git://linuxtv.org/pinchartl/media.git#tags/drm-next-colorkey-v1-20171215
  - git://git.ragnatech.se/linux#for-renesas-drivers
  - topic/vsp1/tlb-optimise/v5-rebased1
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#vsp1/vga-performance-fix
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#d3/i2c-conflict/drm
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#d3/i2c-conflict/media
  - topic/rcar-gen2-wdt-v5+

Included fixes:
  - ARM: shmobile: rcar-gen2: Fix error check in regulator quirk
  - arm_pmu: Use disable_irq_nosync when disabling SPI in CPU teardown hook
  - [LOCAL] arm64: defconfig: Update renesas_defconfig

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

2018-02-28 Thread Kieran Bingham
Hi Laurent,

This series has a pending question below:

On 17/11/17 15:07, Kieran Bingham wrote:
> Hi Laurent,
> 
> Just a query on your bikeshedding here.
> 
> Choose your colours wisely :)
> 
> --
> Kieran
> 
> On 12/09/17 20:19, Laurent Pinchart wrote:
>> Hi Kieran,
>>
>> On Tuesday, 12 September 2017 00:16:50 EEST Kieran Bingham wrote:
>>> On 17/08/17 19:13, Laurent Pinchart wrote:
 On Monday 14 Aug 2017 16:13:28 Kieran Bingham wrote:
> The entities provide a single .configure operation which configures the
> object into the target display list, based on the vsp1_entity_params
> selection.
>
> This restricts us to a single function prototype for both static
> configuration (the pre-stream INIT stage) and the dynamic runtime stages
> for both each frame - and each partition therein.
>
> Split the configure function into two parts, '.prepare()' and
> '.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
> VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
> .configure(). The configuration for individual partitions is handled by
> passing the partition number to the configure call, and processing any
> runtime stage actions on the first partition only.
>
> Signed-off-by: Kieran Bingham 
> ---
>
>  drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_clu.c|  43 +--
>  drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
>  drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
>  drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
>  drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
>  drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
>  drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
>  drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
>  drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
>  drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
>  drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
>  15 files changed, 359 insertions(+), 371 deletions(-)

 [snip]

> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
> b/drivers/media/platform/vsp1/vsp1_clu.c index 175717018e11..5f65ce3ad97f
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_clu.c
> +++ b/drivers/media/platform/vsp1/vsp1_clu.c
> @@ -213,37 +213,37 @@ static const struct v4l2_subdev_ops clu_ops = {
>
>  /*
>  ---
>  -
>  
>   * VSP1 Entity Operations
>   */
>
> +static void clu_prepare(struct vsp1_entity *entity,
> + struct vsp1_pipeline *pipe,
> + struct vsp1_dl_list *dl)
> +{
> + struct vsp1_clu *clu = to_clu(>subdev);
> +
> + /*
> +  * The format can't be changed during streaming, only verify it
> +  * at setup time and store the information internally for future
> +  * runtime configuration calls.
> +  */

 I know you're just moving the comment around, but let's fix it at the same
 time. There's no verification here (and no "setup time" either). I'd write
 it as

/*

 * The format can't be changed during streaming. Cache it internally
 * for future runtime configuration calls.
 */
>>>
>>> I think I'm ok with that and I've updated the patch - but I'm not sure we
>>> are really caching the 'format' here, as much as the yuv_mode ...
>>
>> Yes, it's the YUV mode we're caching, feel free to update the comment.
> 
> Done.
> 
>>
>>> I'll ponder ...
>>>
> + struct v4l2_mbus_framefmt *format;
> +
> + format = vsp1_entity_get_pad_format(>entity,
> + clu->entity.config,
> + CLU_PAD_SINK);
> + clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
> +}

 [snip]

> diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
> b/drivers/media/platform/vsp1/vsp1_entity.h index
> 408602ebeb97..2f33e343ccc6 100644
> --- a/drivers/media/platform/vsp1/vsp1_entity.h
> +++ b/drivers/media/platform/vsp1/vsp1_entity.h

 [snip]

> @@ -80,8 +68,10 @@ struct vsp1_route {
>
>  /**
>  
>   * struct vsp1_entity_operations - Entity operations
>   * @destroy: Destroy the entity.
>
> - * @configure:   Setup the hardware based on the entity state
> (pipeline, formats,
> - *   selection rectangles, ...)
> + * @prepare: Setup the initial hardware parameters for the stream
> (pipeline,
> + *   formats)
> + * @configure:   Configure the runtime 

RE: [PATCH v5 01/26] ARM: shmobile: Add watchdog support

2018-02-28 Thread Fabrizio Castro
Hi Geert,

thank you for your feedback!

> Subject: Re: [PATCH v5 01/26] ARM: shmobile: Add watchdog support
>
> Hi Fabrizio,
>
> On Mon, Feb 12, 2018 at 6:44 PM, Fabrizio Castro
>  wrote:
> > On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non
> > boot CPUs run a routine designed to bring up SMP and deal with hot plug.
> > The value contained in the SBAR registers is not initialized by a WDT
> > triggered reset, which means that after a WDT triggered reset we jump
> > to the SMP bring up routine, preventing the system from executing the
> > bootrom code.
> >
> > The purpose of this patch is to jump to the bootrom code in case of a
> > WDT triggered reset, and keep the SMP functionality untouched.
> > In order to tell if the code had been called due to the WDT overflowing
> > we are testing WOVF from register RWTCSRA.
> >
> > The new function shmobile_boot_vector_gen2 isn't replacing
> > shmobile_boot_vector for backward compatibility reasons. The kernel
> > will install the best option (either shmobile_boot_vector or
> > shmobile_boot_vector_gen2) to ICRAM1 after parsing the device tree,
> > according to the amount of memory available.
> >
> > Since shmobile_boot_vector has become bigger, "reg" property of nodes
> > compatible with "renesas,smp-sram" now need to be set to a value
> > greater or equal to "<0 0x60>".
> >
> > Signed-off-by: Fabrizio Castro 
> > Signed-off-by: Ramesh Shanmugasundaram 
> > 
>
> > --- a/arch/arm/mach-shmobile/common.h
> > +++ b/arch/arm/mach-shmobile/common.h
> > @@ -7,6 +7,12 @@ extern void shmobile_init_delay(void);
> >  extern void shmobile_boot_vector(void);
> >  extern unsigned long shmobile_boot_fn;
> >  extern unsigned long shmobile_boot_size;
> > +#ifdef CONFIG_ARCH_RCAR_GEN2
>
> I think this #ifdef can be removed.

I'll send a new version of this patch without ifdefs.

Thanks,
Fab

>
> > +extern void shmobile_boot_vector_gen2(void);
> > +extern unsigned long shmobile_boot_fn_gen2;
> > +extern unsigned long shmobile_boot_cpu_gen2;
> > +extern unsigned long shmobile_boot_size_gen2;
> > +#endif /* CONFIG_ARCH_RCAR_GEN2 */
> >  extern void shmobile_smp_boot(void);
> >  extern void shmobile_smp_sleep(void);
> >  extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn,
>
> Apart from that:
> Reviewed-by: Geert Uytterhoeven 
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.


[PATCH v6 01/26] ARM: shmobile: Add watchdog support

2018-02-28 Thread Fabrizio Castro
On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non
boot CPUs run a routine designed to bring up SMP and deal with hot plug.
The value contained in the SBAR registers is not initialized by a WDT
triggered reset, which means that after a WDT triggered reset we jump
to the SMP bring up routine, preventing the system from executing the
bootrom code.

The purpose of this patch is to jump to the bootrom code in case of a
WDT triggered reset, and keep the SMP functionality untouched.
In order to tell if the code had been called due to the WDT overflowing
we are testing WOVF from register RWTCSRA.

The new function shmobile_boot_vector_gen2 isn't replacing
shmobile_boot_vector for backward compatibility reasons. The kernel
will install the best option (either shmobile_boot_vector or
shmobile_boot_vector_gen2) to ICRAM1 after parsing the device tree,
according to the amount of memory available.

Since shmobile_boot_vector has become bigger, "reg" property of nodes
compatible with "renesas,smp-sram" now need to be set to a value
greater or equal to "<0 0x60>".

Signed-off-by: Fabrizio Castro 
Signed-off-by: Ramesh Shanmugasundaram 
Reviewed-by: Geert Uytterhoeven 
---
v5->v6:
* taken ifdefs out as per Geert's suggestion.

 arch/arm/mach-shmobile/common.h  |  4 +++
 arch/arm/mach-shmobile/headsmp.S | 53 
 2 files changed, 57 insertions(+)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index a8fa4f7..43c1ac69 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -7,6 +7,10 @@ extern void shmobile_init_delay(void);
 extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
 extern unsigned long shmobile_boot_size;
+extern void shmobile_boot_vector_gen2(void);
+extern unsigned long shmobile_boot_fn_gen2;
+extern unsigned long shmobile_boot_cpu_gen2;
+extern unsigned long shmobile_boot_size_gen2;
 extern void shmobile_smp_boot(void);
 extern void shmobile_smp_sleep(void);
 extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn,
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 32e0bf6..2ece67c 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -16,6 +16,11 @@
 #include 
 #include 
 
+#define SCTLR_MMU  0x01
+#define BOOTROM_ADDRESS0xE634
+#define RWTCSRA_ADDRESS 0xE6020004
+#define RWTCSRA_WOVF   0x10
+
 /*
  * Reset vector for secondary CPUs.
  * This will be mapped at address 0 by SBAR register.
@@ -38,6 +43,54 @@ shmobile_boot_size:
.long   . - shmobile_boot_vector
 
 /*
+ * Reset vector for R-Car Gen2 and RZ/G1 secondary CPUs.
+ * This will be mapped at address 0 by SBAR register.
+ */
+ENTRY(shmobile_boot_vector_gen2)
+   mrc p15, 0, r0, c0, c0, 5   @ r0 = MPIDR
+   ldr r1, shmobile_boot_cpu_gen2
+   cmp r0, r1
+   bne shmobile_smp_continue_gen2
+
+   mrc p15, 0, r1, c1, c0, 0   @ r1 = SCTLR
+   and r0, r1, #SCTLR_MMU
+   cmp r0, #SCTLR_MMU
+   beq shmobile_smp_continue_gen2
+
+   ldr r0, rwtcsra
+   mov r1, #0
+   ldrbr1, [r0]
+   and r0, r1, #RWTCSRA_WOVF
+   cmp r0, #RWTCSRA_WOVF
+   bne shmobile_smp_continue_gen2
+
+   ldr r0, bootrom
+   bx  r0
+
+shmobile_smp_continue_gen2:
+   ldr r1, shmobile_boot_fn_gen2
+   bx  r1
+
+ENDPROC(shmobile_boot_vector_gen2)
+
+   .align  4
+rwtcsra:
+   .word   RWTCSRA_ADDRESS
+bootrom:
+   .word   BOOTROM_ADDRESS
+   .globl  shmobile_boot_cpu_gen2
+shmobile_boot_cpu_gen2:
+   .word   0x
+
+   .align  2
+   .globl  shmobile_boot_fn_gen2
+shmobile_boot_fn_gen2:
+   .space  4
+   .globl  shmobile_boot_size_gen2
+shmobile_boot_size_gen2:
+   .long   . - shmobile_boot_vector_gen2
+
+/*
  * Per-CPU SMP boot function/argument selection code based on MPIDR
  */
 
-- 
2.7.4



RE: [PATCH] watchdog: renesas_wdt: Blacklist early R-Car Gen2 SoCs

2018-02-28 Thread Fabrizio Castro
> Subject: [PATCH] watchdog: renesas_wdt: Blacklist early R-Car Gen2 SoCs
>
> On early revisions of some R-Car Gen2 SoCs, and depending on SMP
> configuration, the system may fail to restart on watchdog time-out, and
> lock up instead.
>
> Specifically:
>   - On R-Car H2 ES1.0 and M2-W ES1.0, watchdog restart fails unless
> only the first CPU core is in use (using e.g. the "maxcpus=1" kernel
> commandline option).
>   - On R-Car V2H ES1.1, watchdog restart fails unless SMP is disabled
> completely (using CONFIG_SMP=n during build configuration, or using
> the "nosmp" or "maxcpus=0" kernel commandline options).
>
> Prevent using the watchdog in impacted cases by blacklisting the
> affected SoCs, using the minimum known working revisions (ES2.0 on R-Car
> H2, and ES3.0 on M2-W), and taking the actual SMP software configuration
> into account.
>
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Fabrizio Castro 

> ---
> To be folded into Fabrizio Castro's "watchdog: renesas_wdt: Add R-Car
> Gen2 support".
>
> Note that I cannot use IS_ENABLED(CONFIG_SMP), as setup_max_cpus does
> not exist for CONFIG_SMP=n.
>
> Any reports on R-Car M2-W ES2.0 and V2H ES2.0+ are welcomed!
>
> As the failure is due to an integration issue, and the watchdog itself
> is working fine, an alternative solution would be to move the check to
> the code that installs the reset trigger ("soc: renesas: rcar-rst:
> Enable watchdog as reset trigger for Gen2").
> However, doing so would mean that:
>   1. The user could enable and seemingly use the watchdog, but watchdog
>  timeout would not restart the system,
>   2. The same check should be done before installing the new reset
>  vector ("ARM: shmobile: rcar-gen2: Add watchdog support"), too,
>  else onlining CPU0 would fail once the watchdog has timed out.
> ---
>  drivers/watchdog/renesas_wdt.c | 43 
> ++
>  1 file changed, 43 insertions(+)
>
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 0f88614797c36022..4c8e8d2600a922a5 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -16,6 +16,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>
>  #define RWTCNT0
> @@ -131,6 +133,44 @@ static const struct watchdog_ops rwdt_ops = {
>  .restart = rwdt_restart,
>  };
>
> +#if defined(CONFIG_ARCH_RCAR_GEN2) && defined(CONFIG_SMP)
> +/*
> + * Watchdog-reset integration is broken on early revisions of R-Car Gen2 SoCs
> + */
> +static const struct soc_device_attribute rwdt_quirks_match[] = {
> +{
> +.soc_id = "r8a7790",
> +.revision = "ES1.*",
> +.data = (void *)1,/* needs single CPU */
> +}, {
> +.soc_id = "r8a7791",
> +.revision = "ES[12].*",
> +.data = (void *)1,/* needs single CPU */
> +}, {
> +.soc_id = "r8a7792",
> +.revision = "*",
> +.data = (void *)0,/* needs SMP disabled */
> +},
> +{ /* sentinel */ }
> +};
> +
> +static bool rwdt_blacklisted(struct device *dev)
> +{
> +const struct soc_device_attribute *attr;
> +
> +attr = soc_device_match(rwdt_quirks_match);
> +if (attr && setup_max_cpus > (uintptr_t)attr->data) {
> +dev_info(dev, "Watchdog blacklisted on %s %s\n", attr->soc_id,
> + attr->revision);
> +return true;
> +}
> +
> +return false;
> +}
> +#else /* !CONFIG_ARCH_RCAR_GEN2 || !CONFIG_SMP */
> +static inline bool rwdt_blacklisted(struct device *dev) { return false; }
> +#endif /* !CONFIG_ARCH_RCAR_GEN2 || !CONFIG_SMP */
> +
>  static int rwdt_probe(struct platform_device *pdev)
>  {
>  struct rwdt_priv *priv;
> @@ -139,6 +179,9 @@ static int rwdt_probe(struct platform_device *pdev)
>  unsigned long clks_per_sec;
>  int ret, i;
>
> +if (rwdt_blacklisted(>dev))
> +return -ENODEV;
> +
>  priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
>  if (!priv)
>  return -ENOMEM;
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.


Re: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

2018-02-28 Thread Sergei Shtylyov
On 02/28/2018 04:27 PM, Simon Horman wrote:

>>> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
>>> 'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 
>>> FCPVD/VSPD/
>>> DU/LVDS device nodes and then describing the HDMI encoder connected to the 
>>> LVDS
>>> output (we're omitting the LVDS decoder for now). These patches depend on
>>> the recent R8A77970 DU/LVDS rework patches by Laurent in order to work...   
>>
>>Need to mention that the DU driver silently fails to probe now. I do
>>hope that this is not due to my updates. :-)
> 
> Please test that theory.

   Yeah, after sucking in the recent versions of the DU/LVDS patches and 
uncommenting
and fixing rejects in a couple patches here, the graphical console works again. 
:-)

MBR, Sergei