[renesas-drivers:topic/renesas-overlays 2/85] drivers/of/configfs.c:48:2: error: implicit declaration of function 'of_fdt_unflatten_tree'

2016-09-13 Thread kbuild test robot
tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
topic/renesas-overlays
head:   c62872358e9767f9b0d00fa4b023484d59e4ba65
commit: 3cc2e4a7426c6f0d2e4de08283737840ed495779 [2/85] OF: DT-Overlay configfs 
interface (v7)
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3cc2e4a7426c6f0d2e4de08283737840ed495779
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/of/configfs.c: In function 'create_overlay':
>> drivers/of/configfs.c:48:2: error: implicit declaration of function 
>> 'of_fdt_unflatten_tree' [-Werror=implicit-function-declaration]
 of_fdt_unflatten_tree(blob, NULL, >overlay);
 ^
   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/node.h:17,
from include/linux/cpu.h:16,
from drivers/of/configfs.c:12:
   drivers/of/configfs.c: In function 'cfs_overlay_item_dtbo_read':
   drivers/of/configfs.c:153:11: warning: format '%u' expects argument of type 
'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' 
[-Wformat=]
 pr_debug("%s: buf=%p max_count=%u\n", __func__,
  ^
   include/linux/printk.h:260:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^
   include/linux/printk.h:326:2: note: in expansion of macro 'dynamic_pr_debug'
 dynamic_pr_debug(fmt, ##__VA_ARGS__)
 ^
   drivers/of/configfs.c:153:2: note: in expansion of macro 'pr_debug'
 pr_debug("%s: buf=%p max_count=%u\n", __func__,
 ^
   cc1: some warnings being treated as errors

vim +/of_fdt_unflatten_tree +48 drivers/of/configfs.c

42  
43  static int create_overlay(struct cfs_overlay_item *overlay, void *blob)
44  {
45  int err;
46  
47  /* unflatten the tree */
  > 48  of_fdt_unflatten_tree(blob, NULL, >overlay);
49  if (overlay->overlay == NULL) {
50  pr_err("%s: failed to unflatten tree\n", __func__);
51  err = -EINVAL;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH] cpufreq: dt: Add support for r8a7792

2016-09-13 Thread Rafael J. Wysocki
On Wednesday, September 07, 2016 10:32:59 AM Viresh Kumar wrote:
> On 06-09-16, 14:18, Geert Uytterhoeven wrote:
> > Add the compatible string for supporting the generic cpufreq driver on
> > the Renesas R-Car V2H (r8a7792) SoC.
> > 
> > Signed-off-by: Geert Uytterhoeven 
> > ---
> > Untested due to lack of hardware.
> > ---
> >  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index 285ed3e6494e9d22..276378a43321a4e0 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -52,6 +52,7 @@ static const struct of_device_id machines[] __initconst = 
> > {
> > { .compatible = "renesas,r8a7779", },
> > { .compatible = "renesas,r8a7790", },
> > { .compatible = "renesas,r8a7791", },
> > +   { .compatible = "renesas,r8a7792", },
> > { .compatible = "renesas,r8a7793", },
> > { .compatible = "renesas,r8a7794", },
> > { .compatible = "renesas,sh73a0", },
> 
> Acked-by: Viresh Kumar 

Applied.

Thanks,
Rafael



[PATCH 14/13] v4l: vsp1: Fix spinlock in mixed IRQ context function

2016-09-13 Thread Laurent Pinchart
The wpf_configure() function can be called both from IRQ and non-IRQ
contexts, use spin_lock_irqsave().

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_wpf.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index b4ecffbaa3e3..c483fead3e98 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -251,11 +251,12 @@ static void wpf_configure(struct vsp1_entity *entity,
if (params == VSP1_ENTITY_PARAMS_RUNTIME) {
const unsigned int mask = BIT(WPF_CTRL_VFLIP)
| BIT(WPF_CTRL_HFLIP);
+   unsigned long flags;
 
-   spin_lock(>flip.lock);
+   spin_lock_irqsave(>flip.lock, flags);
wpf->flip.active = (wpf->flip.active & ~mask)
 | (wpf->flip.pending & mask);
-   spin_unlock(>flip.lock);
+   spin_unlock_irqrestore(>flip.lock, flags);
 
outfmt = (wpf->alpha << VI6_WPF_OUTFMT_PDV_SHIFT) | wpf->outfmt;
 
-- 
Regards,

Laurent Pinchart



[PATCH 05/13] v4l: vsp1: Use DFE instead of FRE for frame end

2016-09-13 Thread Laurent Pinchart
From: Kieran Bingham 

The DFE and FRE interrupts are both fired at frame completion, as each
display list processes a single frame. This won't be true anymore when
using image partitioning, switch to DFE in preparation.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drv.c | 2 +-
 drivers/media/platform/vsp1/vsp1_wpf.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 92418fc09511..57c713a4e1df 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -60,7 +60,7 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data)
status = vsp1_read(vsp1, VI6_WPF_IRQ_STA(i));
vsp1_write(vsp1, VI6_WPF_IRQ_STA(i), ~status & mask);
 
-   if (status & VI6_WFP_IRQ_STA_FRE) {
+   if (status & VI6_WFP_IRQ_STA_DFE) {
vsp1_pipeline_frame_end(wpf->pipe);
ret = IRQ_HANDLED;
}
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 31983169c24a..748f5af90b7e 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -318,7 +318,7 @@ static void wpf_configure(struct vsp1_entity *entity,
/* Enable interrupts */
vsp1_dl_list_write(dl, VI6_WPF_IRQ_STA(wpf->entity.index), 0);
vsp1_dl_list_write(dl, VI6_WPF_IRQ_ENB(wpf->entity.index),
-  VI6_WFP_IRQ_ENB_FREE);
+  VI6_WFP_IRQ_ENB_DFEE);
 }
 
 static const struct vsp1_entity_operations wpf_entity_ops = {
-- 
Regards,

Laurent Pinchart



[PATCH 04/13] v4l: vsp1: Repair race between frame end and qbuf handler

2016-09-13 Thread Laurent Pinchart
From: Kieran Bingham 

The frame-end function releases and completes the buffers on the input
and output entities of the pipe before marking the pipe->state as
'STOPPED'. This introduces a race whereby with the pipe->state still
'RUNNING', a QBUF handler can commence processing a frame before the
frame_end function has completed.

In the event that this happens, a frame queued by QBUF hangs due to the
incorrect pipe->state setting which prevents vsp1_pipeline_run from
issuing a CMD_STRCMD.

By locking the entire function we prevent this from occurring, but we
also change the locking state of the buffer release code. This has been
analysed visually as acceptable, but it must be considered that this now
causes the video->irqlock to be taken under the pipe->irqlock context.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_video.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index ed9759e8a6fc..cd7d215ed455 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -234,18 +234,13 @@ static void vsp1_video_frame_end(struct vsp1_pipeline 
*pipe,
 {
struct vsp1_video *video = rwpf->video;
struct vsp1_vb2_buffer *buf;
-   unsigned long flags;
 
buf = vsp1_video_complete_buffer(video);
if (buf == NULL)
return;
 
-   spin_lock_irqsave(>irqlock, flags);
-
video->rwpf->mem = buf->mem;
pipe->buffers_ready |= 1 << video->pipe_index;
-
-   spin_unlock_irqrestore(>irqlock, flags);
 }
 
 static void vsp1_video_pipeline_run(struct vsp1_pipeline *pipe)
@@ -285,6 +280,8 @@ static void vsp1_video_pipeline_frame_end(struct 
vsp1_pipeline *pipe)
unsigned long flags;
unsigned int i;
 
+   spin_lock_irqsave(>irqlock, flags);
+
/* Complete buffers on all video nodes. */
for (i = 0; i < vsp1->info->rpf_count; ++i) {
if (!pipe->inputs[i])
@@ -295,8 +292,6 @@ static void vsp1_video_pipeline_frame_end(struct 
vsp1_pipeline *pipe)
 
vsp1_video_frame_end(pipe, pipe->output);
 
-   spin_lock_irqsave(>irqlock, flags);
-
state = pipe->state;
pipe->state = VSP1_PIPELINE_STOPPED;
 
-- 
Regards,

Laurent Pinchart



[PATCH 12/13] v4l: vsp1: Support multiple partitions per frame

2016-09-13 Thread Laurent Pinchart
From: Kieran Bingham 

Adapt vsp1_video_pipeline_run() such that it can iterate each partition
required for constructing this frame's display list chain in the event
that multiple display lists are required to process in hardware.

The first display list is held as the head list object, whilst any
following parition display lists are linked to the head by means of
vsp1_dl_list_add_chain().

Linking the chained display list headers to process using the auto start
mechanism of the hardware is performed during the vsp1_dl_list_commit().

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_pipe.h  |   3 +
 drivers/media/platform/vsp1/vsp1_rpf.c   |  46 +---
 drivers/media/platform/vsp1/vsp1_uds.c   |  15 +++-
 drivers/media/platform/vsp1/vsp1_video.c | 121 ++-
 drivers/media/platform/vsp1/vsp1_wpf.c   |  30 +++-
 5 files changed, 195 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index af4cd23d399b..f15b697ad999 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -79,6 +79,7 @@ enum vsp1_pipeline_state {
  * @dl: display list associated with the pipeline
  * @div_size: The maximum allowed partition size for the pipeline
  * @partitions: The number of partitions used to process one frame
+ * @current_partition: The partition number currently being configured
  */
 struct vsp1_pipeline {
struct media_pipeline pipe;
@@ -109,6 +110,8 @@ struct vsp1_pipeline {
 
unsigned int div_size;
unsigned int partitions;
+   struct v4l2_rect partition;
+   unsigned int current_partition;
 };
 
 void vsp1_pipeline_reset(struct vsp1_pipeline *pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index de5ef76c5004..e6236ff2f74a 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -72,8 +72,8 @@ static void rpf_configure(struct vsp1_entity *entity,
}
 
if (params == VSP1_ENTITY_PARAMS_PARTITION) {
-   const struct v4l2_rect *crop;
unsigned int offsets[2];
+   struct v4l2_rect crop;
 
/* Source size and crop offsets.
 *
@@ -82,21 +82,47 @@ static void rpf_configure(struct vsp1_entity *entity,
 * offsets are needed, as planes 2 and 3 always have identical
 * strides.
 */
-   crop = vsp1_rwpf_get_crop(rpf, rpf->entity.config);
+   crop = *vsp1_rwpf_get_crop(rpf, rpf->entity.config);
+
+   /* Partition Algorithm Control
+*
+* The partition algorithm can split this frame into multiple
+* slices. We must scale our partition window based on the pipe
+* configuration to match the destination partition window.
+* To achieve this, we adjust our crop to provide a 'sub-crop'
+* matching the expected partition window. Only 'left' and
+* 'width' need to be adjusted.
+*/
+   if (pipe->partitions > 1) {
+   const struct v4l2_mbus_framefmt *output;
+   struct vsp1_entity *wpf = >output->entity;
+   unsigned int input_width = crop.width;
+
+   /* Scale the partition window based on the configuration
+* of the pipeline.
+*/
+   output = vsp1_entity_get_pad_format(wpf, wpf->config,
+   RWPF_PAD_SOURCE);
+
+   crop.width = pipe->partition.width * input_width
+  / output->width;
+   crop.left += pipe->partition.left * input_width
+  / output->width;
+   }
 
vsp1_rpf_write(rpf, dl, VI6_RPF_SRC_BSIZE,
-  (crop->width << VI6_RPF_SRC_BSIZE_BHSIZE_SHIFT) |
-  (crop->height << 
VI6_RPF_SRC_BSIZE_BVSIZE_SHIFT));
+  (crop.width << VI6_RPF_SRC_BSIZE_BHSIZE_SHIFT) |
+  (crop.height << VI6_RPF_SRC_BSIZE_BVSIZE_SHIFT));
vsp1_rpf_write(rpf, dl, VI6_RPF_SRC_ESIZE,
-  (crop->width << VI6_RPF_SRC_ESIZE_EHSIZE_SHIFT) |
-  (crop->height << 
VI6_RPF_SRC_ESIZE_EVSIZE_SHIFT));
+  (crop.width << VI6_RPF_SRC_ESIZE_EHSIZE_SHIFT) |
+  (crop.height << VI6_RPF_SRC_ESIZE_EVSIZE_SHIFT));
 
-   offsets[0] = crop->top * format->plane_fmt[0].bytesperline
-   

[PATCH 11/13] v4l: vsp1: Determine partition requirements for scaled images

2016-09-13 Thread Laurent Pinchart
From: Kieran Bingham 

The partition algorithm needs to determine the capabilities of each
entity in the pipeline to identify the correct maximum partition width.

Extend the vsp1 entity operations to provide a max_width operation and
use this call to calculate the number of partitions that will be
processed by the algorithm.

Gen 2 hardware does not require multiple partitioning, and as such
will always return a single partition.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_entity.h |  3 +++
 drivers/media/platform/vsp1/vsp1_pipe.h   |  5 
 drivers/media/platform/vsp1/vsp1_sru.c| 19 +++
 drivers/media/platform/vsp1/vsp1_uds.c| 25 +++
 drivers/media/platform/vsp1/vsp1_video.c  | 40 +++
 5 files changed, 92 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_entity.h 
b/drivers/media/platform/vsp1/vsp1_entity.h
index 0e3e394c44cd..90a4d95c0a50 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -77,11 +77,14 @@ struct vsp1_route {
  * @destroy:   Destroy the entity.
  * @configure: Setup the hardware based on the entity state (pipeline, formats,
  * selection rectangles, ...)
+ * @max_width: Return the max supported width of data that the entity can
+ * process in a single operation.
  */
 struct vsp1_entity_operations {
void (*destroy)(struct vsp1_entity *);
void (*configure)(struct vsp1_entity *, struct vsp1_pipeline *,
  struct vsp1_dl_list *, enum vsp1_entity_params);
+   unsigned int (*max_width)(struct vsp1_entity *, struct vsp1_pipeline *);
 };
 
 struct vsp1_entity {
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index d20d997b1fda..af4cd23d399b 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -77,6 +77,8 @@ enum vsp1_pipeline_state {
  * @uds_input: entity at the input of the UDS, if the UDS is present
  * @entities: list of entities in the pipeline
  * @dl: display list associated with the pipeline
+ * @div_size: The maximum allowed partition size for the pipeline
+ * @partitions: The number of partitions used to process one frame
  */
 struct vsp1_pipeline {
struct media_pipeline pipe;
@@ -104,6 +106,9 @@ struct vsp1_pipeline {
struct list_head entities;
 
struct vsp1_dl_list *dl;
+
+   unsigned int div_size;
+   unsigned int partitions;
 };
 
 void vsp1_pipeline_reset(struct vsp1_pipeline *pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_sru.c 
b/drivers/media/platform/vsp1/vsp1_sru.c
index 9d4a1afb6634..b4e568a3b4ed 100644
--- a/drivers/media/platform/vsp1/vsp1_sru.c
+++ b/drivers/media/platform/vsp1/vsp1_sru.c
@@ -306,8 +306,27 @@ static void sru_configure(struct vsp1_entity *entity,
vsp1_sru_write(sru, dl, VI6_SRU_CTRL2, param->ctrl2);
 }
 
+static unsigned int sru_max_width(struct vsp1_entity *entity,
+ struct vsp1_pipeline *pipe)
+{
+   struct vsp1_sru *sru = to_sru(>subdev);
+   struct v4l2_mbus_framefmt *input;
+   struct v4l2_mbus_framefmt *output;
+
+   input = vsp1_entity_get_pad_format(>entity, sru->entity.config,
+  SRU_PAD_SINK);
+   output = vsp1_entity_get_pad_format(>entity, sru->entity.config,
+   SRU_PAD_SOURCE);
+
+   if (input->width != output->width)
+   return 512;
+   else
+   return 256;
+}
+
 static const struct vsp1_entity_operations sru_entity_ops = {
.configure = sru_configure,
+   .max_width = sru_max_width,
 };
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_uds.c 
b/drivers/media/platform/vsp1/vsp1_uds.c
index 62beae5d6944..706b6e85f47d 100644
--- a/drivers/media/platform/vsp1/vsp1_uds.c
+++ b/drivers/media/platform/vsp1/vsp1_uds.c
@@ -311,8 +311,33 @@ static void uds_configure(struct vsp1_entity *entity,
   (output->height << VI6_UDS_CLIP_SIZE_VSIZE_SHIFT));
 }
 
+static unsigned int uds_max_width(struct vsp1_entity *entity,
+ struct vsp1_pipeline *pipe)
+{
+   struct vsp1_uds *uds = to_uds(>subdev);
+   const struct v4l2_mbus_framefmt *output;
+   const struct v4l2_mbus_framefmt *input;
+   unsigned int hscale;
+
+   input = vsp1_entity_get_pad_format(>entity, uds->entity.config,
+  UDS_PAD_SINK);
+   output = vsp1_entity_get_pad_format(>entity, uds->entity.config,
+   UDS_PAD_SOURCE);
+   hscale = output->width / input->width;
+
+   if (hscale <= 2)
+

[PATCH 06/13] v4l: vsp1: Disable cropping on WPF sink pad

2016-09-13 Thread Laurent Pinchart
Cropping on the WPF sink pad restricts the left and top coordinates to
0-255. The same result can be obtained by cropping on the RPF without
any such restriction, this feature isn't useful. Disable it.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_rwpf.c | 37 +
 drivers/media/platform/vsp1/vsp1_wpf.c  | 18 +++-
 2 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c 
b/drivers/media/platform/vsp1/vsp1_rwpf.c
index 8cb87e96b78b..a3ace8df7f4d 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
@@ -66,7 +66,6 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
struct vsp1_rwpf *rwpf = to_rwpf(subdev);
struct v4l2_subdev_pad_config *config;
struct v4l2_mbus_framefmt *format;
-   struct v4l2_rect *crop;
int ret = 0;
 
mutex_lock(>entity.lock);
@@ -103,12 +102,16 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev 
*subdev,
 
fmt->format = *format;
 
-   /* Update the sink crop rectangle. */
-   crop = vsp1_rwpf_get_crop(rwpf, config);
-   crop->left = 0;
-   crop->top = 0;
-   crop->width = fmt->format.width;
-   crop->height = fmt->format.height;
+   if (rwpf->entity.type == VSP1_ENTITY_RPF) {
+   struct v4l2_rect *crop;
+
+   /* Update the sink crop rectangle. */
+   crop = vsp1_rwpf_get_crop(rwpf, config);
+   crop->left = 0;
+   crop->top = 0;
+   crop->width = fmt->format.width;
+   crop->height = fmt->format.height;
+   }
 
/* Propagate the format to the source pad. */
format = vsp1_entity_get_pad_format(>entity, config,
@@ -129,8 +132,10 @@ static int vsp1_rwpf_get_selection(struct v4l2_subdev 
*subdev,
struct v4l2_mbus_framefmt *format;
int ret = 0;
 
-   /* Cropping is implemented on the sink pad. */
-   if (sel->pad != RWPF_PAD_SINK)
+   /* Cropping is only supported on the RPF and is implemented on the sink
+* pad.
+*/
+   if (rwpf->entity.type == VSP1_ENTITY_WPF || sel->pad != RWPF_PAD_SINK)
return -EINVAL;
 
mutex_lock(>entity.lock);
@@ -175,8 +180,10 @@ static int vsp1_rwpf_set_selection(struct v4l2_subdev 
*subdev,
struct v4l2_rect *crop;
int ret = 0;
 
-   /* Cropping is implemented on the sink pad. */
-   if (sel->pad != RWPF_PAD_SINK)
+   /* Cropping is only supported on the RPF and is implemented on the sink
+* pad.
+*/
+   if (rwpf->entity.type == VSP1_ENTITY_WPF || sel->pad != RWPF_PAD_SINK)
return -EINVAL;
 
if (sel->target != V4L2_SEL_TGT_CROP)
@@ -190,9 +197,7 @@ static int vsp1_rwpf_set_selection(struct v4l2_subdev 
*subdev,
goto done;
}
 
-   /* Make sure the crop rectangle is entirely contained in the image. The
-* WPF top and left offsets are limited to 255.
-*/
+   /* Make sure the crop rectangle is entirely contained in the image. */
format = vsp1_entity_get_pad_format(>entity, config,
RWPF_PAD_SINK);
 
@@ -208,10 +213,6 @@ static int vsp1_rwpf_set_selection(struct v4l2_subdev 
*subdev,
 
sel->r.left = min_t(unsigned int, sel->r.left, format->width - 2);
sel->r.top = min_t(unsigned int, sel->r.top, format->height - 2);
-   if (rwpf->entity.type == VSP1_ENTITY_WPF) {
-   sel->r.left = min_t(unsigned int, sel->r.left, 255);
-   sel->r.top = min_t(unsigned int, sel->r.top, 255);
-   }
sel->r.width = min_t(unsigned int, sel->r.width,
 format->width - sel->r.left);
sel->r.height = min_t(unsigned int, sel->r.height,
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 748f5af90b7e..f3a593196282 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -212,7 +212,6 @@ static void wpf_configure(struct vsp1_entity *entity,
struct vsp1_device *vsp1 = wpf->entity.vsp1;
const struct v4l2_mbus_framefmt *source_format;
const struct v4l2_mbus_framefmt *sink_format;
-   const struct v4l2_rect *crop;
unsigned int i;
u32 outfmt = 0;
u32 srcrpf = 0;
@@ -237,16 +236,6 @@ static void wpf_configure(struct vsp1_entity *entity,
return;
}
 
-   /* Cropping */
-   crop = vsp1_rwpf_get_crop(wpf, wpf->entity.config);
-
-   vsp1_wpf_write(wpf, dl, VI6_WPF_HSZCLIP, VI6_WPF_SZCLIP_EN |
-  (crop->left << VI6_WPF_SZCLIP_OFST_SHIFT) |
-  (crop->width << VI6_WPF_SZCLIP_SIZE_SHIFT));
-   vsp1_wpf_write(wpf, dl, VI6_WPF_VSZCLIP, VI6_WPF_SZCLIP_EN |
-  

[PATCH 13/13] v4l: vsp1: wpf: Implement rotation support

2016-09-13 Thread Laurent Pinchart
Some WPF instances, on Gen3 devices, can perform 90° rotation when
writing frames to memory. Implement support for this using the
V4L2_CID_ROTATE control.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_rpf.c   |   2 +-
 drivers/media/platform/vsp1/vsp1_rwpf.c  |   5 +
 drivers/media/platform/vsp1/vsp1_rwpf.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_video.c |  10 +-
 drivers/media/platform/vsp1/vsp1_wpf.c   | 200 +++
 5 files changed, 169 insertions(+), 51 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index e6236ff2f74a..b54f0513f4b0 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -102,7 +102,7 @@ static void rpf_configure(struct vsp1_entity *entity,
 * of the pipeline.
 */
output = vsp1_entity_get_pad_format(wpf, wpf->config,
-   RWPF_PAD_SOURCE);
+   RWPF_PAD_SINK);
 
crop.width = pipe->partition.width * input_width
   / output->width;
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.c 
b/drivers/media/platform/vsp1/vsp1_rwpf.c
index a3ace8df7f4d..ca18c9cf1d6a 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.c
@@ -118,6 +118,11 @@ static int vsp1_rwpf_set_format(struct v4l2_subdev *subdev,
RWPF_PAD_SOURCE);
*format = fmt->format;
 
+   if (rwpf->flip.rotate) {
+   format->width = fmt->format.height;
+   format->height = fmt->format.width;
+   }
+
 done:
mutex_unlock(>entity.lock);
return ret;
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h 
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 1c98aff3da5d..b4ffc38f48af 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -56,9 +56,10 @@ struct vsp1_rwpf {
 
struct {
spinlock_t lock;
-   struct v4l2_ctrl *ctrls[2];
+   struct v4l2_ctrl *ctrls[3];
unsigned int pending;
unsigned int active;
+   bool rotate;
} flip;
 
struct vsp1_rwpf_memory mem;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 15d08cb50bd1..ef65d2c1e76e 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -179,9 +179,12 @@ static void vsp1_video_pipeline_setup_partitions(struct 
vsp1_pipeline *pipe)
struct vsp1_entity *entity;
unsigned int div_size;
 
+   /* Partitions are computed on the size before rotation, use the format
+* at the WPF sink.
+*/
format = vsp1_entity_get_pad_format(>output->entity,
pipe->output->entity.config,
-   RWPF_PAD_SOURCE);
+   RWPF_PAD_SINK);
div_size = format->width;
 
/* Gen2 hardware doesn't require image partitioning. */
@@ -221,9 +224,12 @@ static struct v4l2_rect vsp1_video_partition(struct 
vsp1_pipeline *pipe,
struct v4l2_rect partition;
unsigned int modulus;
 
+   /* Partitions are computed on the size before rotation, use the format
+* at the WPF sink.
+*/
format = vsp1_entity_get_pad_format(>output->entity,
pipe->output->entity.config,
-   RWPF_PAD_SOURCE);
+   RWPF_PAD_SINK);
 
/* A single partition simply processes the output size in full. */
if (pipe->partitions <= 1) {
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
b/drivers/media/platform/vsp1/vsp1_wpf.c
index fdee5a891e40..b4ecffbaa3e3 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -43,32 +43,92 @@ static inline void vsp1_wpf_write(struct vsp1_rwpf *wpf,
 enum wpf_flip_ctrl {
WPF_CTRL_VFLIP = 0,
WPF_CTRL_HFLIP = 1,
-   WPF_CTRL_MAX,
+   WPF_CTRL_ROTATE = 2,
 };
 
+static int vsp1_wpf_set_rotation(struct vsp1_rwpf *wpf, unsigned int rotation)
+{
+   struct media_device *mdev = >entity.vsp1->media_dev;
+   struct v4l2_mbus_framefmt *sink_format;
+   struct v4l2_mbus_framefmt *source_format;
+   bool rotate;
+   int ret = 0;
+
+   /* Only consider the 0°/180° from/to 90°/270° modifications, the rest
+* is taken care of by the flipping configuration.
+*/
+   rotate = rotation == 90 || rotation == 270;
+   if (rotate == wpf->flip.rotate)
+   return 0;

[PATCH 10/13] v4l: vsp1: Support chained display lists

2016-09-13 Thread Laurent Pinchart
From: Kieran Bingham 

When display lists are linked in a chain, they will be processed
automatically by the hardware, with each list linking to the next. Only
on the last display list will the frame end interrupt be fired to mark
the completion event.

Upon frame-end, the chain will be iterated to release each display list
back to the free list.

The chained lists use case (image partitioning) can require up to 64
lists per frame in the worst case scenario, bump up the number of
preallocated lists.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c  | 119 +++--
 drivers/media/platform/vsp1/vsp1_dl.h  |   1 +
 drivers/media/platform/vsp1/vsp1_wpf.c |   2 +-
 3 files changed, 102 insertions(+), 20 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 37c3518aa2a8..0af3e8fdc714 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -21,7 +21,6 @@
 #include "vsp1_dl.h"
 
 #define VSP1_DL_NUM_ENTRIES256
-#define VSP1_DL_NUM_LISTS  3
 
 #define VSP1_DLH_INT_ENABLE(1 << 1)
 #define VSP1_DLH_AUTO_START(1 << 0)
@@ -71,6 +70,7 @@ struct vsp1_dl_body {
  * @dma: DMA address for the header
  * @body0: first display list body
  * @fragments: list of extra display list bodies
+ * @chain: entry in the display list partition chain
  */
 struct vsp1_dl_list {
struct list_head list;
@@ -81,6 +81,9 @@ struct vsp1_dl_list {
 
struct vsp1_dl_body body0;
struct list_head fragments;
+
+   bool has_chain;
+   struct list_head chain;
 };
 
 enum vsp1_dl_mode {
@@ -262,7 +265,6 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct 
vsp1_dl_manager *dlm)
 
memset(dl->header, 0, sizeof(*dl->header));
dl->header->lists[0].addr = dl->body0.dma;
-   dl->header->flags = VSP1_DLH_INT_ENABLE;
}
 
return dl;
@@ -293,6 +295,11 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct 
vsp1_dl_manager *dlm)
if (!list_empty(>free)) {
dl = list_first_entry(>free, struct vsp1_dl_list, list);
list_del(>list);
+
+   /* The display list chain must be initialised to ensure every
+* display list can assert list_empty() if it is not in a chain.
+*/
+   INIT_LIST_HEAD(>chain);
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -303,9 +310,21 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct 
vsp1_dl_manager *dlm)
 /* This function must be called with the display list manager lock held.*/
 static void __vsp1_dl_list_put(struct vsp1_dl_list *dl)
 {
+   struct vsp1_dl_list *dl_child;
+
if (!dl)
return;
 
+   /* Release any linked display-lists which were chained for a single
+* hardware operation.
+*/
+   if (dl->has_chain) {
+   list_for_each_entry(dl_child, >chain, chain)
+   __vsp1_dl_list_put(dl_child);
+   }
+
+   dl->has_chain = false;
+
/* We can't free fragments here as DMA memory can only be freed in
 * interruptible context. Move all fragments to the display list
 * manager's list of fragments to be freed, they will be
@@ -383,6 +402,74 @@ int vsp1_dl_list_add_fragment(struct vsp1_dl_list *dl,
return 0;
 }
 
+/**
+ * vsp1_dl_list_add_chain - Add a display list to a chain
+ * @head: The head display list
+ * @dl: The new display list
+ *
+ * Add a display list to an existing display list chain. The chained lists
+ * will be automatically processed by the hardware without intervention from
+ * the CPU. A display list end interrupt will only complete after the last
+ * display list in the chain has completed processing.
+ *
+ * Adding a display list to a chain passes ownership of the display list to
+ * the head display list item. The chain is released when the head dl item is
+ * put back with __vsp1_dl_list_put().
+ *
+ * Chained display lists are only usable in header mode. Attempts to add a
+ * display list to a chain in header-less mode will return an error.
+ */
+int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
+  struct vsp1_dl_list *dl)
+{
+   /* Chained lists are only available in header mode. */
+   if (head->dlm->mode != VSP1_DL_MODE_HEADER)
+   return -EINVAL;
+
+   head->has_chain = true;
+   list_add_tail(>chain, >chain);
+   return 0;
+}
+
+static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last)
+{
+   struct vsp1_dl_header_list *hdr = dl->header->lists;
+   struct vsp1_dl_body *dlb;
+   unsigned int num_lists = 0;
+
+   /* Fill the header with the display list bodies addresses and sizes. The
+* 

[PATCH 08/13] v4l: vsp1: Pass parameter type to entity configuration operation

2016-09-13 Thread Laurent Pinchart
Replace the current boolean parameter (full / !full) with an explicit
enum.

- VSP1_ENTITY_PARAMS_INIT for parameters to be configured at pipeline
  initialization time only (V4L2 stream on or DRM atomic update)
- VSP1_ENTITY_PARAMS_RUNTIME for all parameters that can be freely
  modified at runtime (through V4L2 controls)

This will allow future extensions when implementing image partitioning
support.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_bru.c|  5 ++--
 drivers/media/platform/vsp1/vsp1_clu.c| 43 +--
 drivers/media/platform/vsp1/vsp1_drm.c|  6 +++--
 drivers/media/platform/vsp1/vsp1_entity.h | 12 -
 drivers/media/platform/vsp1/vsp1_hsit.c   |  5 ++--
 drivers/media/platform/vsp1/vsp1_lif.c|  5 ++--
 drivers/media/platform/vsp1/vsp1_lut.c| 24 ++---
 drivers/media/platform/vsp1/vsp1_rpf.c|  5 ++--
 drivers/media/platform/vsp1/vsp1_sru.c|  5 ++--
 drivers/media/platform/vsp1/vsp1_uds.c|  5 ++--
 drivers/media/platform/vsp1/vsp1_video.c  |  6 +++--
 drivers/media/platform/vsp1/vsp1_wpf.c|  5 ++--
 12 files changed, 78 insertions(+), 48 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index 26b9e2282a41..80fb948860d5 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -285,14 +285,15 @@ static const struct v4l2_subdev_ops bru_ops = {
 
 static void bru_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl, bool full)
+ struct vsp1_dl_list *dl,
+ enum vsp1_entity_params params)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
 
-   if (!full)
+   if (params != VSP1_ENTITY_PARAMS_INIT)
return;
 
format = vsp1_entity_get_pad_format(>entity, bru->entity.config,
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index e1fd03811dda..a0a69dfc38fc 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -214,42 +214,47 @@ static const struct v4l2_subdev_ops clu_ops = {
 
 static void clu_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl, bool full)
+ struct vsp1_dl_list *dl,
+ enum vsp1_entity_params params)
 {
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;
 
-   /* The format can't be changed during streaming, only verify it at
-* stream start and store the information internally for future partial
-* reconfiguration calls.
-*/
-   if (full) {
+   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;
 
format = vsp1_entity_get_pad_format(>entity,
clu->entity.config,
CLU_PAD_SINK);
clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
-   return;
+   break;
}
 
-   /* 2D mode can only be used with the YCbCr pixel encoding. */
-   if (clu->mode == V4L2_CID_VSP1_CLU_MODE_2D && clu->yuv_mode)
-   ctrl |= VI6_CLU_CTRL_AX1I_2D | VI6_CLU_CTRL_AX2I_2D
-|  VI6_CLU_CTRL_OS0_2D | VI6_CLU_CTRL_OS1_2D
-|  VI6_CLU_CTRL_OS2_2D | VI6_CLU_CTRL_M2D;
+   case VSP1_ENTITY_PARAMS_RUNTIME:
+   /* 2D mode can only be used with the YCbCr pixel encoding. */
+   if (clu->mode == V4L2_CID_VSP1_CLU_MODE_2D && clu->yuv_mode)
+   ctrl |= VI6_CLU_CTRL_AX1I_2D | VI6_CLU_CTRL_AX2I_2D
+|  VI6_CLU_CTRL_OS0_2D | VI6_CLU_CTRL_OS1_2D
+|  VI6_CLU_CTRL_OS2_2D | VI6_CLU_CTRL_M2D;
 
-   vsp1_clu_write(clu, dl, VI6_CLU_CTRL, ctrl);
+   vsp1_clu_write(clu, dl, VI6_CLU_CTRL, ctrl);
 
-   spin_lock_irqsave(>lock, flags);
-   dlb = clu->clu;
-   clu->clu = NULL;
-   spin_unlock_irqrestore(>lock, flags);
+   spin_lock_irqsave(>lock, flags);
+   dlb = clu->clu;
+   clu->clu = NULL;
+   spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
-   

[PATCH 09/13] v4l: vsp1: Replace .set_memory() with VSP1_ENTITY_PARAMS_PARTITION

2016-09-13 Thread Laurent Pinchart
The new VSP1_ENTITY_PARAMS_PARTITION configuration parameters type
covers all registers that need to be configured for every partition.
This prepares for support of image partitioning, and replaces the
.set_memory() operation as the memory registers take different values
for every partition.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_clu.c|  3 ++
 drivers/media/platform/vsp1/vsp1_drm.c|  9 +---
 drivers/media/platform/vsp1/vsp1_entity.h |  6 +--
 drivers/media/platform/vsp1/vsp1_lut.c|  3 ++
 drivers/media/platform/vsp1/vsp1_rpf.c| 78 ++--
 drivers/media/platform/vsp1/vsp1_rwpf.h   | 13 -
 drivers/media/platform/vsp1/vsp1_video.c  | 17 ++-
 drivers/media/platform/vsp1/vsp1_wpf.c| 85 +--
 8 files changed, 100 insertions(+), 114 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index a0a69dfc38fc..f052abd05166 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -237,6 +237,9 @@ static void clu_configure(struct vsp1_entity *entity,
break;
}
 
+   case VSP1_ENTITY_PARAMS_PARTITION:
+   break;
+
case VSP1_ENTITY_PARAMS_RUNTIME:
/* 2D mode can only be used with the YCbCr pixel encoding. */
if (clu->mode == V4L2_CID_VSP1_CLU_MODE_2D && clu->yuv_mode)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 6cbd3aeedbe3..832286975e71 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -496,14 +496,9 @@ void vsp1_du_atomic_flush(struct device *dev)
   VSP1_ENTITY_PARAMS_INIT);
entity->ops->configure(entity, pipe, pipe->dl,
   VSP1_ENTITY_PARAMS_RUNTIME);
+   entity->ops->configure(entity, pipe, pipe->dl,
+  VSP1_ENTITY_PARAMS_PARTITION);
}
-
-   /* The memory buffer address must be applied after configuring
-* the RPF to make sure the crop offset are computed.
-*/
-   if (entity->type == VSP1_ENTITY_RPF)
-   vsp1_rwpf_set_memory(to_rwpf(>subdev),
-pipe->dl);
}
 
vsp1_dl_list_commit(pipe->dl);
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h 
b/drivers/media/platform/vsp1/vsp1_entity.h
index 51835e73308d..0e3e394c44cd 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -38,10 +38,12 @@ enum vsp1_entity_type {
 /*
  * enum vsp1_entity_params - Entity configuration parameters class
  * @VSP1_ENTITY_PARAMS_INIT - Initial parameters
+ * @VSP1_ENTITY_PARAMS_PARTITION - Per-image partition parameters
  * @VSP1_ENTITY_PARAMS_RUNTIME - Runtime-configurable parameters
  */
 enum vsp1_entity_params {
VSP1_ENTITY_PARAMS_INIT,
+   VSP1_ENTITY_PARAMS_PARTITION,
VSP1_ENTITY_PARAMS_RUNTIME,
 };
 
@@ -73,15 +75,11 @@ struct vsp1_route {
 /**
  * struct vsp1_entity_operations - Entity operations
  * @destroy:   Destroy the entity.
- * @set_memory:Setup memory buffer access. This operation applies the 
settings
- * stored in the rwpf mem field to the display list. Valid for RPF
- * and WPF only.
  * @configure: Setup the hardware based on the entity state (pipeline, formats,
  * selection rectangles, ...)
  */
 struct vsp1_entity_operations {
void (*destroy)(struct vsp1_entity *);
-   void (*set_memory)(struct vsp1_entity *, struct vsp1_dl_list *dl);
void (*configure)(struct vsp1_entity *, struct vsp1_pipeline *,
  struct vsp1_dl_list *, enum vsp1_entity_params);
 };
diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index ace8acce2076..c67cc60db0db 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -202,6 +202,9 @@ static void lut_configure(struct vsp1_entity *entity,
vsp1_lut_write(lut, dl, VI6_LUT_CTRL, VI6_LUT_CTRL_EN);
break;
 
+   case VSP1_ENTITY_PARAMS_PARTITION:
+   break;
+
case VSP1_ENTITY_PARAMS_RUNTIME:
spin_lock_irqsave(>lock, flags);
dlb = lut->lut;
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index 795bf0fd1761..de5ef76c5004 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -46,18 +46,6 @@ static const struct v4l2_subdev_ops rpf_ops = {
  * VSP1 Entity Operations
  */
 
-static void rpf_set_memory(struct vsp1_entity *entity, struct 

[PATCH 07/13] v4l: vsp1: Fix RPF cropping

2016-09-13 Thread Laurent Pinchart
The RPF cropping offset for the chroma planes is incorrectly computed,
it needs to be divided by the horizontal subsampling factor.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_rpf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c 
b/drivers/media/platform/vsp1/vsp1_rpf.c
index 388838913205..3d6669dbeacf 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -105,7 +105,8 @@ static void rpf_configure(struct vsp1_entity *entity,
 
if (format->num_planes > 1) {
rpf->offsets[1] = crop->top * format->plane_fmt[1].bytesperline
-   + crop->left * fmtinfo->bpp[1] / 8;
+   + crop->left / fmtinfo->hsub * fmtinfo->bpp[1]
+   / 8;
pstride |= format->plane_fmt[1].bytesperline
<< VI6_RPF_SRCM_PSTRIDE_C_SHIFT;
} else {
-- 
Regards,

Laurent Pinchart



[PATCH 03/13] v4l: vsp1: Ensure pipeline locking in resume path

2016-09-13 Thread Laurent Pinchart
From: Kieran Bingham 

The vsp1_pipeline_ready() and vsp1_pipeline_run() functions must be
called with the pipeline lock held, fix the resume code path.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_pipe.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 3e75fb3fcace..474de82165d8 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -365,6 +365,7 @@ void vsp1_pipelines_suspend(struct vsp1_device *vsp1)
 
 void vsp1_pipelines_resume(struct vsp1_device *vsp1)
 {
+   unsigned long flags;
unsigned int i;
 
/* Resume all running pipelines. */
@@ -379,7 +380,9 @@ void vsp1_pipelines_resume(struct vsp1_device *vsp1)
if (pipe == NULL)
continue;
 
+   spin_lock_irqsave(>irqlock, flags);
if (vsp1_pipeline_ready(pipe))
vsp1_pipeline_run(pipe);
+   spin_unlock_irqrestore(>irqlock, flags);
}
 }
-- 
Regards,

Laurent Pinchart



[PATCH 00/13] Renesas R-Car VSP: Scaling and rotation support on Gen3

2016-09-13 Thread Laurent Pinchart
Hello,

This patch series adds support for scaling and rotation to the VSP1 driver on
the R-Car Gen3 SoCs.

Unlike Gen2 that can scale full resolution images, the Gen3 VSP scaler has a
width limitation that prevent full images from being processed in one go. They
must be partitioned in slices that are then processed individually. The
rotation engine present in the Gen3 VSP has a similar limitation, and so does
the SRU.

The hardware supports queuing processing of multiple slices without generating
any interrupt between slices, so partitioning the image will not raise the
number of interrupts. It however has an impact on CPU usage as the register
settings for each partitions need to be computed, but there's no way around
that.

The series starts with bug fixes (patches 01/13 to 04/13), followed by a few
preparatory changes (patches 05/13 to 07/13). Patches 08/13 to 12/13 then
implement image partitioning support, and patch 13/13 finally adds rotation
support.

All the changes have been tests with the VSP test suite available at

git://git.ideasonboard.com/renesas/vsp-tests.git master

on both Gen2 (H2 Lager) and Gen3 (H3 Salvator-X) boards. No regression has
been noticed.

Kieran Bingham (6):
  v4l: vsp1: Ensure pipeline locking in resume path
  v4l: vsp1: Repair race between frame end and qbuf handler
  v4l: vsp1: Use DFE instead of FRE for frame end
  v4l: vsp1: Support chained display lists
  v4l: vsp1: Determine partition requirements for scaled images
  v4l: vsp1: Support multiple partitions per frame

Laurent Pinchart (7):
  v4l: vsp1: Prevent pipelines from running when not streaming
  v4l: vsp1: Protect against race conditions between get and set format
  v4l: vsp1: Disable cropping on WPF sink pad
  v4l: vsp1: Fix RPF cropping
  v4l: vsp1: Pass parameter type to entity configuration operation
  v4l: vsp1: Replace .set_memory() with VSP1_ENTITY_PARAMS_PARTITION
  v4l: vsp1: wpf: Implement rotation support

 drivers/media/platform/vsp1/vsp1_bru.c|  33 +++-
 drivers/media/platform/vsp1/vsp1_clu.c|  61 ---
 drivers/media/platform/vsp1/vsp1_dl.c | 119 ++---
 drivers/media/platform/vsp1/vsp1_dl.h |   1 +
 drivers/media/platform/vsp1/vsp1_drm.c|  15 +-
 drivers/media/platform/vsp1/vsp1_drv.c|   2 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  22 ++-
 drivers/media/platform/vsp1/vsp1_entity.h |  25 ++-
 drivers/media/platform/vsp1/vsp1_hsit.c   |  20 ++-
 drivers/media/platform/vsp1/vsp1_lif.c|  20 ++-
 drivers/media/platform/vsp1/vsp1_lut.c|  42 +++--
 drivers/media/platform/vsp1/vsp1_pipe.c   |   3 +
 drivers/media/platform/vsp1/vsp1_pipe.h   |   8 +
 drivers/media/platform/vsp1/vsp1_rpf.c| 106 +++-
 drivers/media/platform/vsp1/vsp1_rwpf.c   |  86 ++
 drivers/media/platform/vsp1/vsp1_rwpf.h   |  16 +-
 drivers/media/platform/vsp1/vsp1_sru.c|  50 +-
 drivers/media/platform/vsp1/vsp1_uds.c|  71 ++--
 drivers/media/platform/vsp1/vsp1_video.c  | 188 ++--
 drivers/media/platform/vsp1/vsp1_wpf.c| 274 ++
 20 files changed, 880 insertions(+), 282 deletions(-)

-- 
Regards,

Laurent Pinchart



[PATCH 02/13] v4l: vsp1: Protect against race conditions between get and set format

2016-09-13 Thread Laurent Pinchart
The subdev userspace API isn't serialized in the core, serialize access
to formats and selection rectangles in the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_bru.c| 28 +++-
 drivers/media/platform/vsp1/vsp1_clu.c| 15 ---
 drivers/media/platform/vsp1/vsp1_entity.c | 22 +---
 drivers/media/platform/vsp1/vsp1_entity.h |  4 ++-
 drivers/media/platform/vsp1/vsp1_hsit.c   | 15 ---
 drivers/media/platform/vsp1/vsp1_lif.c| 15 ---
 drivers/media/platform/vsp1/vsp1_lut.c| 15 ---
 drivers/media/platform/vsp1/vsp1_rwpf.c   | 44 +++
 drivers/media/platform/vsp1/vsp1_sru.c| 26 +-
 drivers/media/platform/vsp1/vsp1_uds.c| 26 +-
 10 files changed, 161 insertions(+), 49 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index 8268b87727a7..26b9e2282a41 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -142,10 +142,15 @@ static int bru_set_format(struct v4l2_subdev *subdev,
struct vsp1_bru *bru = to_bru(subdev);
struct v4l2_subdev_pad_config *config;
struct v4l2_mbus_framefmt *format;
+   int ret = 0;
+
+   mutex_lock(>entity.lock);
 
config = vsp1_entity_get_pad_config(>entity, cfg, fmt->which);
-   if (!config)
-   return -EINVAL;
+   if (!config) {
+   goto done;
+   ret = -EINVAL;
+   }
 
bru_try_format(bru, config, fmt->pad, >format);
 
@@ -174,7 +179,9 @@ static int bru_set_format(struct v4l2_subdev *subdev,
}
}
 
-   return 0;
+done:
+   mutex_unlock(>entity.lock);
+   return ret;
 }
 
 static int bru_get_selection(struct v4l2_subdev *subdev,
@@ -201,7 +208,9 @@ static int bru_get_selection(struct v4l2_subdev *subdev,
if (!config)
return -EINVAL;
 
+   mutex_lock(>entity.lock);
sel->r = *bru_get_compose(bru, config, sel->pad);
+   mutex_unlock(>entity.lock);
return 0;
 
default:
@@ -217,6 +226,7 @@ static int bru_set_selection(struct v4l2_subdev *subdev,
struct v4l2_subdev_pad_config *config;
struct v4l2_mbus_framefmt *format;
struct v4l2_rect *compose;
+   int ret = 0;
 
if (sel->pad == bru->entity.source_pad)
return -EINVAL;
@@ -224,9 +234,13 @@ static int bru_set_selection(struct v4l2_subdev *subdev,
if (sel->target != V4L2_SEL_TGT_COMPOSE)
return -EINVAL;
 
+   mutex_lock(>entity.lock);
+
config = vsp1_entity_get_pad_config(>entity, cfg, sel->which);
-   if (!config)
-   return -EINVAL;
+   if (!config) {
+   ret = -EINVAL;
+   goto done;
+   }
 
/* The compose rectangle top left corner must be inside the output
 * frame.
@@ -246,7 +260,9 @@ static int bru_set_selection(struct v4l2_subdev *subdev,
compose = bru_get_compose(bru, config, sel->pad);
*compose = sel->r;
 
-   return 0;
+done:
+   mutex_unlock(>entity.lock);
+   return ret;
 }
 
 static const struct v4l2_subdev_pad_ops bru_pad_ops = {
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index b63d2dbe5ea3..e1fd03811dda 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -148,10 +148,15 @@ static int clu_set_format(struct v4l2_subdev *subdev,
struct vsp1_clu *clu = to_clu(subdev);
struct v4l2_subdev_pad_config *config;
struct v4l2_mbus_framefmt *format;
+   int ret = 0;
+
+   mutex_lock(>entity.lock);
 
config = vsp1_entity_get_pad_config(>entity, cfg, fmt->which);
-   if (!config)
-   return -EINVAL;
+   if (!config) {
+   ret = -EINVAL;
+   goto done;
+   }
 
/* Default to YUV if the requested format is not supported. */
if (fmt->format.code != MEDIA_BUS_FMT_ARGB_1X32 &&
@@ -164,7 +169,7 @@ static int clu_set_format(struct v4l2_subdev *subdev,
if (fmt->pad == CLU_PAD_SOURCE) {
/* The CLU output format can't be modified. */
fmt->format = *format;
-   return 0;
+   goto done;
}
 
format->code = fmt->format.code;
@@ -182,7 +187,9 @@ static int clu_set_format(struct v4l2_subdev *subdev,
CLU_PAD_SOURCE);
*format = fmt->format;
 
-   return 0;
+done:
+   mutex_unlock(>entity.lock);
+   return ret;
 }
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c 
b/drivers/media/platform/vsp1/vsp1_entity.c
index 

Re: [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.9

2016-09-13 Thread Arnd Bergmann
On Wednesday, September 7, 2016 9:49:30 AM CEST Simon Horman wrote:
> Second Round of Renesas ARM Based SoC DT Updates for v4.9
> 
> Fixes (for v4.9):
> * Correct PWM clock parent on r8a7794 SoC
> 
> Clean-up:
> * Remove obsolete vsp1 properties from r8a779[01] SoCs
> 
> New boards:
> * Add r8a7792/wheat and r7s72100/rskrza1 boards
> 
> Enablement:
> * Enable LEDs, DU, SDHI on r8a7792/blanche board
> * Enable MMCIF and SDHI on r8a7794/alt board
> * Add SPI and VSP1 to r8a7792 SoC
> * Add ethernet to r7s72100 SoC
> 

Pulled into next/dt, thanks!

Arnd



Re: [PATCH] pcie-rcar: MSI range allocation support

2016-09-13 Thread Simon Horman
On Thu, Sep 08, 2016 at 10:32:59PM +0300, Sergei Shtylyov wrote:
> From: Grigory Kletsko 
> 
> Impelment MSI setup_irqs() method which enables allocation of several MSIs
> at once.
> 
> [Sergei Shtylyov: removed unrelated/unneeded changes, fixed too long lines,
> reordered the variable declarations, reworded the summary/description.]
> 
> Signed-off-by: Grigory Kletsko 
> Signed-off-by: Sergei Shtylyov 

Acked-by: Simon Horman 



Re: [PATCH] pcie-rcar: try setting PCIe speed to 5 GT/s at boot

2016-09-13 Thread Simon Horman
On Wed, Sep 07, 2016 at 11:22:14PM +0300, Sergei Shtylyov wrote:
> From: Grigory Kletsko 
> 
> Initially, the PCIe link speed is set up only at 2.5 GT/s.
> For better performance,  we're trying to increase link speed to 5 GT/s.
> 
> [Sergei Shtylyov: indented the macro definitions with tabs, renamed the
> SPCHG register bits for consistency, renamed the link speed field/values,
> fixed too long lines, fixed redundancy in clearing the MACSR register bits,
> fixed grammar/typos in  the comments/messages, removed unrelated/useless
> changes, fixed bugs in rcar_rwm32() calls done to set the bits, removed
> unneeded braces, removed non-informative comment, reworded the patch
> summary/description.]
> 
> Signed-off-by: Grigory Kletsko 
> Signed-off-by: Sergei Shtylyov 

Acked-by: Simon Horman 



Re: [PATCH] pcie-rcar: fix some checkpatch warnings

2016-09-13 Thread Simon Horman
On Fri, Sep 09, 2016 at 01:26:18AM +0300, Sergei Shtylyov wrote:
> The R-Car PCIe driver causes 13 warnings from scripts/checkpatch.pl --
> let's fix at least 10 easier ones:
> 
> - line over 80 characters;
> 
> - blank line missing after declarations;
> 
> - statements not starting on a tabstop.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against the 'next' branch of Bjorn Helgaas' 'pci.git' repo plus
> two patches  posted  earlier...

This looks good to me.

Acked-by: Simon Horman 


Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

2016-09-13 Thread Ulf Hansson
On 13 September 2016 at 15:50, Chris Brandt  wrote:
> Here's a question:
>
> The DT regulator method is good if you want to be able to control the 
> regulator at run-time by the system.
>
> But for MMC and SDHI, why isn't there a way to just set the OCR voltage in 
> the board's DT if it's fixed (other than making a fixed regulator node)?
> Why isn't there a mmc-ocr-mask property? That's really what I want and it 
> seems like it would make a lot of dts files more simple.

Because, if you have an external regulator feeding the mmc with power
you should set it up and use it.

Now, we do have cases where it's actually the MMC controller that
manges the power to the card. So no external regulators being used.
For these case we have the "voltage-ranges" DT binding, but I don't
think you should be using that for these cases. :-)

Kind regards
Uffe


[GIT PULL FOR renesas-drivers] UHS-I SDR-104 support for sh_mobile_sdhi (crivers v7)

2016-09-13 Thread Simon Horman
Hi Geert,

please consider pulling updated UHS-I SDR-104 support for sh_mobile_sdhi
(drivers v7).

This updates a branch you already have in renesas-drivers,
topic/sdr104-v6, which should be dropped.

This pull request is based on mmc/next.


The following changes since commit 53fbd6126b3bdabf24f617d4e3b4926f583b494f:

  mmc: sunxi: add support for A64 mmc controller (2016-09-09 12:13:41 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-driver-v7

for you to fetch changes up to 354370aaa734fb22b6c2358e084fe44a010d697d:

  mmc: sh_mobile_sdhi: Add tuning support (2016-09-13 11:18:04 +0200)


Ai Kyuse (3):
  mmc: tmio: enhance illegal sequence handling
  mmc: tmio: Add hw reset support
  mmc: tmio: Add tuning support

Simon Horman (3):
  mmc: core: Add helper to see if a host can be retuned
  mmc: tmio: document mandatory and optional callbacks
  mmc: sh_mobile_sdhi: Add tuning support

 drivers/mmc/host/sh_mobile_sdhi.c | 265 +-
 drivers/mmc/host/tmio_mmc.h   |  18 ++-
 drivers/mmc/host/tmio_mmc_pio.c   |  87 -
 include/linux/mmc/host.h  |   5 +
 4 files changed, 367 insertions(+), 8 deletions(-)


[GIT PULL FOR renesas-drivers] UHS-I SDR-104 support for sh_mobile_sdhi (integration v7)

2016-09-13 Thread Simon Horman
Hi Geert,

please consider pulling updated UHS-I SDR-104 support for sh_mobile_sdhi
(integration v7).

This updates a branch you already have in renesas-drivers,
topic/sdr104-v6, which should be dropped.

This pull request is based on renesas-next-20160908-v4.8-rc1:

This pull request is a companion to one for topic/sdr104-drivers-v7
which I sent to you a little earlier.

The Gen 3 portion of this patchset is not much use from a performance point
of view without DMA support provided by "[GIT PULL FOR renesas-drivers]
mmc: renesas_sdhi: add R-Car Gen-3 DMA support", which I previously
submitted to you as topic/sdhi-gen 3-dma. As there are some conflicts
between that patchset and this one I have provided
the following branches in the renesas tree at the URL below.

* topic/sdhi-gen3-dma-v3.rebase

I have also prepared the following branches for testing purposes

* topic/sdr104-v7
  - A merge of topic/sdr104-drivers-v7 and topic/sdr104-integration-v7
with dependencies from renesas-drivers merged and other dependencies
cherry-picked.
* topic/sdr104-v7+sdhi-dma-v3
  - A merge of topic/sdhi-gen3-dma-v3.rebase and topic/sdr104-v7


The following changes since commit a64ca8158b213343b46cc8c220db564b6505df04:

  Merge branches 'fixes-for-v4.8', 'arm64-defconfig-for-v4.9', 
'arm64-dt-for-v4.9', 'defconfig-for-v4.9', 'dt-for-v4.9' and 'soc-for-v4.9' 
into next (2016-09-08 09:36:49 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-integration-v7

for you to fetch changes up to 4dc6fe955dafef69b02abe34e8d59bc092bdb99a:

  arm64: dts: r8a7796: salvator-x: Enable UHS-I SDR-104 (2016-09-09 17:50:20 
+0200)


Simon Horman (10):
  ARM: dts: lager: Enable UHS-I SDR-104
  arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104
  ARM: dts: r8a7791: set maximum frequency for SDHI clocks
  ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104
  ARM: dts: r8a7794: set maximum frequency for SDHI clocks
  ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104
  arm64: dts: r8a7796: add SDHI nodes
  arm64: dts: r8a7796: salvator-x: enable SDHI0 & 3
  arm64: dts: r8a7796: salvator-x: enable UHS for SDHI 0 & 3
  arm64: dts: r8a7796: salvator-x: Enable UHS-I SDR-104

Wolfram Sang (1):
  arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3

 arch/arm/boot/dts/r8a7790-lager.dts|   1 +
 arch/arm/boot/dts/r8a7791-koelsch.dts  |  34 ++-
 arch/arm/boot/dts/r8a7791.dtsi |   3 +
 arch/arm/boot/dts/r8a7794-alt.dts  |  23 -
 arch/arm/boot/dts/r8a7794.dtsi |   3 +
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  24 -
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 104 +
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  42 +
 8 files changed, 227 insertions(+), 7 deletions(-)


Re: [PATCH 1/4] pinctrl: sh-pfc: Support named pins with custom configuration

2016-09-13 Thread Laurent Pinchart
Hi Niklas,

Thank you for the patch

On Tuesday 13 Sep 2016 16:03:11 Niklas Söderlund wrote:
> Pins not associated with a GPIO port can still have other configuration
> parameters. Add a new macro SH_PFC_PIN_NAMED_CFG which allows for named
> pins to be declared with a set of configurations. The new macro is an
> modification of SH_PFC_PIN_NAMED to allow for optional configuration to
> be assigned.
> 
> The flag SH_PFC_PIN_CFG_NO_GPIO is still enforced as this should only be
> used to define pins not associated with a GPIO port.
> 
> Signed-off-by: Niklas Söderlund 

Acked-by: Laurent Pinchart 

> ---
>  drivers/pinctrl/sh-pfc/sh_pfc.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h
> b/drivers/pinctrl/sh-pfc/sh_pfc.h index 5e966c0..a6a2346 100644
> --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> @@ -507,6 +507,14 @@ extern const struct sh_pfc_soc_info shx3_pinmux_info;
>   .configs = SH_PFC_PIN_CFG_NO_GPIO,  \
>   }
> 
> +/* SH_PFC_PIN_NAMED_CFG - Expand to a sh_pfc_pin entry with the given name
> */ +#define SH_PFC_PIN_NAMED_CFG(row, col, _name, cfgs)   
\
> + {   \
> + .pin = PIN_NUMBER(row, col),\
> + .name = __stringify(PIN_##_name),   \
> + .configs = SH_PFC_PIN_CFG_NO_GPIO | cfgs,   \
> + }
> +
>  /* PINMUX_DATA_ALL - Expand to a list of PORT_name_DATA, PORT_name_FN0,
>   *PORT_name_OUT, PORT_name_IN marks
>   */

-- 
Regards,

Laurent Pinchart



Re: [PATCH v2 0/4] R-Car VSP1 1-D Histogram support

2016-09-13 Thread Laurent Pinchart
Hi Geert,

On Tuesday 13 Sep 2016 14:19:56 Geert Uytterhoeven wrote:
> On Wed, Aug 17, 2016 at 2:20 PM, Laurent Pinchart wrote:
> > This patch series implements support for the Renesas R-Car VSP1 1-D
> > histogram generator (HGO). It is based on top of the latest media tree's
> > master branch, and available for convenience at
> > 
> > git://linuxtv.org/pinchartl/media.git vsp1/hgo
> 
> I've dropped the above branch from today's renesas-drivers release due to
> too many merge conflicts.

No worries. I'll submit a rebased version soon.

-- 
Regards,

Laurent Pinchart



Re: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.9

2016-09-13 Thread Arnd Bergmann
On Monday, August 15, 2016 10:55:35 AM CEST Simon Horman wrote:
> Renesas ARM Based SoC DT Updates for v4.9
> 
> * Add DU, VIN, I2C, SDHI, EtherAVB, GPIO support to r8a7792
> * Enable CAN0 on r8a7792/blanche
> * Enable sound on r8a7794/silk
> * Correct SDHI register size on r8a7794
> 

Pulled into next/dt, thanks and sorry for the long delay.

Arnd



[PATCH 4/4] pinctrl: sh-pfc: r8a7795: Add group for QSPI0 and QSPI1 pins

2016-09-13 Thread Niklas Söderlund
Group the QSPI0 and QSPI1 pins into similar groups found in other sh-pfc
drivers.  The pins can not be muxed between functions other then QSPI
but there drive strength can be controlled.

Signed-off-by: Niklas Söderlund 
---
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 69 
 1 file changed, 69 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 7b9a355..192e272 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -3627,6 +3627,55 @@ static const unsigned int usb2_mux[] = {
USB2_PWEN_MARK, USB2_OVC_MARK,
 };
 
+/* - QSPI0 -- 
*/
+static const unsigned int qspi0_ctrl_pins[] = {
+   /* QSPI0_SPCLK, QSPI0_SSL */
+   PIN_NUMBER('W', 3), PIN_NUMBER('Y', 3),
+};
+static const unsigned int qspi0_ctrl_mux[] = {
+   QSPI0_SPCLK_MARK, QSPI0_SSL_MARK,
+};
+static const unsigned int qspi0_data2_pins[] = {
+   /* QSPI0_MOSI_IO0, QSPI0_MISO_IO1 */
+   PIN_A_NUMBER('C', 5), PIN_A_NUMBER('B', 4),
+};
+static const unsigned int qspi0_data2_mux[] = {
+   QSPI0_MOSI_IO0_MARK, QSPI0_MISO_IO1_MARK,
+};
+static const unsigned int qspi0_data4_pins[] = {
+   /* QSPI0_MOSI_IO0, QSPI0_MISO_IO1, QSPI0_IO2, QSPI0_IO3 */
+   PIN_A_NUMBER('C', 5), PIN_A_NUMBER('B', 4),
+   PIN_NUMBER('Y', 6), PIN_A_NUMBER('B', 6),
+};
+static const unsigned int qspi0_data4_mux[] = {
+   QSPI0_MOSI_IO0_MARK, QSPI0_MISO_IO1_MARK,
+   QSPI0_IO2_MARK, QSPI0_IO3_MARK,
+};
+/* - QSPI1 -- 
*/
+static const unsigned int qspi1_ctrl_pins[] = {
+   /* QSPI1_SPCLK, QSPI1_SSL */
+   PIN_NUMBER('V', 3), PIN_NUMBER('V', 5),
+};
+static const unsigned int qspi1_ctrl_mux[] = {
+   QSPI1_SPCLK_MARK, QSPI1_SSL_MARK,
+};
+static const unsigned int qspi1_data2_pins[] = {
+   /* QSPI1_MOSI_IO0, QSPI1_MISO_IO1 */
+   PIN_A_NUMBER('C', 7), PIN_A_NUMBER('E', 5),
+};
+static const unsigned int qspi1_data2_mux[] = {
+   QSPI1_MOSI_IO0_MARK, QSPI1_MISO_IO1_MARK,
+};
+static const unsigned int qspi1_data4_pins[] = {
+   /* QSPI1_MOSI_IO0, QSPI1_MISO_IO1, QSPI1_IO2, QSPI1_IO3 */
+   PIN_A_NUMBER('C', 7), PIN_A_NUMBER('E', 5),
+   PIN_A_NUMBER('E', 4), PIN_A_NUMBER('C', 3),
+};
+static const unsigned int qspi1_data4_mux[] = {
+   QSPI1_MOSI_IO0_MARK, QSPI1_MISO_IO1_MARK,
+   QSPI1_IO2_MARK, QSPI1_IO3_MARK,
+};
+
 static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(audio_clk_a_a),
SH_PFC_PIN_GROUP(audio_clk_a_b),
@@ -3919,6 +3968,12 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb1),
SH_PFC_PIN_GROUP(usb2),
+   SH_PFC_PIN_GROUP(qspi0_ctrl),
+   SH_PFC_PIN_GROUP(qspi0_data2),
+   SH_PFC_PIN_GROUP(qspi0_data4),
+   SH_PFC_PIN_GROUP(qspi1_ctrl),
+   SH_PFC_PIN_GROUP(qspi1_data2),
+   SH_PFC_PIN_GROUP(qspi1_data4),
 };
 
 static const char * const audio_clk_groups[] = {
@@ -4353,6 +4408,18 @@ static const char * const usb2_groups[] = {
"usb2",
 };
 
+static const char * const qspi0_groups[] = {
+   "qspi0_ctrl",
+   "qspi0_data2",
+   "qspi0_data4",
+};
+
+static const char * const qspi1_groups[] = {
+   "qspi1_ctrl",
+   "qspi1_data2",
+   "qspi1_data4",
+};
+
 static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(audio_clk),
SH_PFC_FUNCTION(avb),
@@ -4401,6 +4468,8 @@ static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(usb0),
SH_PFC_FUNCTION(usb1),
SH_PFC_FUNCTION(usb2),
+   SH_PFC_FUNCTION(qspi0),
+   SH_PFC_FUNCTION(qspi1),
 };
 
 static const struct pinmux_cfg_reg pinmux_config_regs[] = {
-- 
2.9.3



[PATCH 1/4] pinctrl: sh-pfc: Support named pins with custom configuration

2016-09-13 Thread Niklas Söderlund
Pins not associated with a GPIO port can still have other configuration
parameters. Add a new macro SH_PFC_PIN_NAMED_CFG which allows for named
pins to be declared with a set of configurations. The new macro is an
modification of SH_PFC_PIN_NAMED to allow for optional configuration to
be assigned.

The flag SH_PFC_PIN_CFG_NO_GPIO is still enforced as this should only be
used to define pins not associated with a GPIO port.

Signed-off-by: Niklas Söderlund 
---
 drivers/pinctrl/sh-pfc/sh_pfc.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 5e966c0..a6a2346 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -507,6 +507,14 @@ extern const struct sh_pfc_soc_info shx3_pinmux_info;
.configs = SH_PFC_PIN_CFG_NO_GPIO,  \
}
 
+/* SH_PFC_PIN_NAMED_CFG - Expand to a sh_pfc_pin entry with the given name */
+#define SH_PFC_PIN_NAMED_CFG(row, col, _name, cfgs)\
+   {   \
+   .pin = PIN_NUMBER(row, col),\
+   .name = __stringify(PIN_##_name),   \
+   .configs = SH_PFC_PIN_CFG_NO_GPIO | cfgs,   \
+   }
+
 /* PINMUX_DATA_ALL - Expand to a list of PORT_name_DATA, PORT_name_FN0,
  *  PORT_name_OUT, PORT_name_IN marks
  */
-- 
2.9.3



[PATCH 0/4] pinctrl: sh-pfc: r8a7795: Support none GPIO pins with configurable drive-strength

2016-09-13 Thread Niklas Söderlund
Hi,

This series adds support to control the drive strength for none GPIO 
pins. All pins expect one (FSCLKST) which can have its drive strength 
controlled is now supported. I have also added the new pins to the 
correct groups, or added groups to mimic other sh-pfc drivers. One 
notable exception is the group avb_mdc which on other SoC are called 
avb_mdio, see commit for explanation.

I did not add FSCLKST since I can't figure out which physical pin it's 
mapped to. Looking at the code that is already there and documentation 
it should be a GPIO pin controlled by IPSR7[15:12] but the documentation 
and code is lacking that part and I can't with a 100% certainty figure 
out which physical pin it is.

The series is based on top of v4.8-rc5 and tested on Salvator-X. My test 
is a bit crude and is setting a few of the AVB pins to a higher 
drive-strength value then the others and observing that the AVB fails to 
work after the pfc settings are applied (NFS root failing to mount after 
kernel is fetched over TFTP).

Niklas Söderlund (4):
  pinctrl: sh-pfc: Support named pins with custom configuration
  pinctrl: sh-pfc: r8a7795: Support none GPIO pins with configurable
drive-strength
  pinctrl: sh-pfc: r8a7795: Add group for AVB MDIO and MII pins
  pinctrl: sh-pfc: r8a7795: Add group for QSPI0 and QSPI1 pins

 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 254 ---
 drivers/pinctrl/sh-pfc/sh_pfc.h  |   8 ++
 2 files changed, 243 insertions(+), 19 deletions(-)

-- 
2.9.3



[PATCH 3/4] pinctrl: sh-pfc: r8a7795: Add group for AVB MDIO and MII pins

2016-09-13 Thread Niklas Söderlund
Group the AVB pins into similar groups found in other sh-pfc drivers.
The pins can not be muxed between functions other then AVB but there
drive strength can be controlled.

The group avb_mdc containing ADV_MDC and ADV_MDIO are on other SoCs
called avb_mdio. In pfc-r8a7795 the adv_mdc group already existed and
is in use in DT. Therefor the ADV_MDIO pin to the existing group
instead of renaming it.

Signed-off-by: Niklas Söderlund 
---
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 4a60f15..7b9a355 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -1635,11 +1635,11 @@ static const unsigned int avb_phy_int_mux[] = {
AVB_PHY_INT_MARK,
 };
 static const unsigned int avb_mdc_pins[] = {
-   /* AVB_MDC */
-   RCAR_GP_PIN(2, 9),
+   /* AVB_MDC, AVB_MDIO */
+   RCAR_GP_PIN(2, 9), PIN_NUMBER('A', 9),
 };
 static const unsigned int avb_mdc_mux[] = {
-   AVB_MDC_MARK,
+   AVB_MDC_MARK, AVB_MDIO_MARK,
 };
 static const unsigned int avb_avtp_pps_pins[] = {
/* AVB_AVTP_PPS */
@@ -1676,6 +1676,28 @@ static const unsigned int avb_avtp_capture_b_pins[] = {
 static const unsigned int avb_avtp_capture_b_mux[] = {
AVB_AVTP_CAPTURE_B_MARK,
 };
+static const unsigned int avb_mii_pins[] = {
+   /*
+* AVB_TX_CTL, AVB_TXC, AVB_TD0,
+* AVB_TD1, AVB_TD2, AVB_TD3,
+* AVB_RX_CTL, AVB_RXC, AVB_RD0,
+* AVB_RD1, AVB_RD2, AVB_RD3,
+* AVB_TXREFCLK
+*/
+   PIN_NUMBER('A', 8), PIN_NUMBER('A', 19), PIN_NUMBER('A', 18),
+   PIN_NUMBER('B', 18), PIN_NUMBER('A', 17), PIN_NUMBER('B', 17),
+   PIN_NUMBER('A', 16), PIN_NUMBER('B', 19), PIN_NUMBER('A', 13),
+   PIN_NUMBER('B', 13), PIN_NUMBER('A', 14), PIN_NUMBER('B', 14),
+   PIN_NUMBER('A', 12),
+
+};
+static const unsigned int avb_mii_mux[] = {
+   AVB_TX_CTL_MARK, AVB_TXC_MARK, AVB_TD0_MARK,
+   AVB_TD1_MARK, AVB_TD2_MARK, AVB_TD3_MARK,
+   AVB_RX_CTL_MARK, AVB_RXC_MARK, AVB_RD0_MARK,
+   AVB_RD1_MARK, AVB_RD2_MARK, AVB_RD3_MARK,
+   AVB_TXREFCLK_MARK,
+};
 
 /* - CAN -- */
 static const unsigned int can0_data_a_pins[] = {
@@ -3632,6 +3654,7 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(avb_avtp_capture_a),
SH_PFC_PIN_GROUP(avb_avtp_match_b),
SH_PFC_PIN_GROUP(avb_avtp_capture_b),
+   SH_PFC_PIN_GROUP(avb_mii),
SH_PFC_PIN_GROUP(can0_data_a),
SH_PFC_PIN_GROUP(can0_data_b),
SH_PFC_PIN_GROUP(can1_data),
@@ -3928,6 +3951,7 @@ static const char * const avb_groups[] = {
"avb_avtp_capture_a",
"avb_avtp_match_b",
"avb_avtp_capture_b",
+   "avb_mii",
 };
 
 static const char * const can0_groups[] = {
-- 
2.9.3



RE: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

2016-09-13 Thread Chris Brandt
Here's a question:

The DT regulator method is good if you want to be able to control the regulator 
at run-time by the system.

But for MMC and SDHI, why isn't there a way to just set the OCR voltage in the 
board's DT if it's fixed (other than making a fixed regulator node)?
Why isn't there a mmc-ocr-mask property? That's really what I want and it seems 
like it would make a lot of dts files more simple.


Chris




RE: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

2016-09-13 Thread Chris Brandt
On 9/13/2016, Ulf Hansson wrote:
> Regarding the ocr_mask; How do these SoCs provides the power to the mmc/sd
> card?
> 
> Do note, I am *not* talking about the I/O voltage but the core power to
> the card.

The SoC does not *provide* power to the card. It's not that fancy. How the 3.3v 
is supplied to the card slot is up to the board designer. But, the SoC spec 
says the I/O should be 3.3v, so we might as well fix the OCR as 3.3v because 
they don't have a choice.

I did see all the DT regulator stuff for the other Renesas SoC, but all that is 
beyond how this chip is being used.

Also note that this SoC (Renesas RZ/A1), unlike the others, is being used with 
XIP_KERNEL because it's possible to run a full kernel without any external 
memory (it comes in a 3MB, 5MB, or 10RM internal RAM versions). So, I'm trying 
to avoid adding extra DT "stuff" that just takes up more RAM resources and has 
no value for these simple embedded systems. I know in other DDR based system 
with Megs and Megs of RAM to spare this isn't a problem, but in an XIP_KERNEL 
environment, it all adds up.

One of the reasons why I haven't been trying to push our BSP upstream and move 
everyone is because I'm afraid of what all the new DT bloat is going to do to 
the kernel RAM usage.

Chris



Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

2016-09-13 Thread Geert Uytterhoeven
Hi Ulf,

On Tue, Sep 13, 2016 at 2:57 PM, Ulf Hansson  wrote:
> On 12 September 2016 at 16:15, Chris Brandt  wrote:
>> In moving platforms from board files to DT, there still needs to be a way
>> to set the ocr_mask setting for the tmio driver during probe. Without this
>> setting, the probe will fail because the supported voltages are not known.
>
> Regarding the ocr_mask; How do these SoCs provides the power to the mmc/sd 
> card?
>
> Do note, I am *not* talking about the I/O voltage but the core power
> to the card.
>
> The reason for raising the question is that we have infrastructures in
> the mmc core which can create the ocr_mask, by parsing a regulator's
> voltage range. This is the recommended method to use, instead of using
> hard coded ocr mask values.

On RSKRZA1, 3.3V is provided to the SD/MMC socket through an MIC2026
MOSFET switch.
On Genmai, 3.3V or 5V is provided through an LTC1471 switch.

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 v7 0/6] UHS-I SDR-104 support for sh_mobile_sdhi

2016-09-13 Thread Wolfram Sang
On Tue, Sep 13, 2016 at 02:48:26PM +0200, Ulf Hansson wrote:
> On 13 September 2016 at 12:56, Simon Horman  
> wrote:
> >
> > Hi,
> >
> > this series is based on work by Ai Kyuse to add UHS-I SDR-104 support for
> > sh_mobile_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William
> > Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I
> > SDR-50 support to the same driver.
> >
> > It is based on a merge of the next branches of the mmc tree.
> >
> > To aid review the following git branch is provided:
> > * https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> > topic/sdr104-driver-v7
> >
> > Overview of changes since v6:
> > * Address review by Ulf
> >   - Detailed in per-patch changelogs
> > * Move integration (arm/arm64 dt) patches to separate patchset
> >
> > Please see http://elinux.org/Tests:SD-SDHI-SDR104 for indicative tests
> > results.
> >
> >
> > Ai Kyuse (3):
> >   mmc: tmio: enhance illegal sequence handling
> >   mmc: tmio: Add hw reset support
> >   mmc: tmio: Add tuning support
> >
> > Simon Horman (3):
> >   mmc: core: Add helper to see if a host can be retuned
> >   mmc: tmio: document mandatory and optional callbacks
> >   mmc: sh_mobile_sdhi: Add tuning support
> >
> >  drivers/mmc/host/sh_mobile_sdhi.c | 265 
> > +-
> >  drivers/mmc/host/tmio_mmc.h   |  18 ++-
> >  drivers/mmc/host/tmio_mmc_pio.c   |  87 -
> >  include/linux/mmc/host.h  |   5 +
> >  4 files changed, 367 insertions(+), 8 deletions(-)
> >
> > --
> > 2.7.0.rc3.207.g0ac5344
> >
> 
> This looks good to me, although I would like to get an ack from
> Wolfram before I queue this up.

I'll test today or tomorrow. Same for the r7s72100 patches.

Thanks,

   Wolfram



signature.asc
Description: PGP signature


Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add ocr_mask option

2016-09-13 Thread Ulf Hansson
On 12 September 2016 at 16:15, Chris Brandt  wrote:
> In moving platforms from board files to DT, there still needs to be a way
> to set the ocr_mask setting for the tmio driver during probe. Without this
> setting, the probe will fail because the supported voltages are not known.

Regarding the ocr_mask; How do these SoCs provides the power to the mmc/sd card?

Do note, I am *not* talking about the I/O voltage but the core power
to the card.

The reason for raising the question is that we have infrastructures in
the mmc core which can create the ocr_mask, by parsing a regulator's
voltage range. This is the recommended method to use, instead of using
hard coded ocr mask values.

Kind regards
Uffe

>
> This patch will also traditional platform registration platforms to
> migrate to DT.
>
> Signed-off-by: Chris Brandt 
> ---
>  drivers/mmc/host/sh_mobile_sdhi.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c 
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index 5334f24..b033500 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -59,6 +59,7 @@ enum tmio_mmc_dmac_type {
>
>  struct sh_mobile_sdhi_of_data {
> unsigned long tmio_flags;
> +   u32   tmio_ocr_mask;
> unsigned long capabilities;
> unsigned long capabilities2;
> enum dma_slave_buswidth dma_buswidth;
> @@ -630,6 +631,7 @@ static int sh_mobile_sdhi_probe(struct platform_device 
> *pdev)
> const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
>
> mmc_data->flags |= of_data->tmio_flags;
> +   mmc_data->ocr_mask = of_data->tmio_ocr_mask;
> mmc_data->capabilities |= of_data->capabilities;
> mmc_data->capabilities2 |= of_data->capabilities2;
> mmc_data->dma_rx_offset = of_data->dma_rx_offset;
> --
> 2.9.2
>
>


Re: [PATCH v7 0/6] UHS-I SDR-104 support for sh_mobile_sdhi

2016-09-13 Thread Ulf Hansson
On 13 September 2016 at 12:56, Simon Horman  wrote:
>
> Hi,
>
> this series is based on work by Ai Kyuse to add UHS-I SDR-104 support for
> sh_mobile_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William
> Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I
> SDR-50 support to the same driver.
>
> It is based on a merge of the next branches of the mmc tree.
>
> To aid review the following git branch is provided:
> * https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> topic/sdr104-driver-v7
>
> Overview of changes since v6:
> * Address review by Ulf
>   - Detailed in per-patch changelogs
> * Move integration (arm/arm64 dt) patches to separate patchset
>
> Please see http://elinux.org/Tests:SD-SDHI-SDR104 for indicative tests
> results.
>
>
> Ai Kyuse (3):
>   mmc: tmio: enhance illegal sequence handling
>   mmc: tmio: Add hw reset support
>   mmc: tmio: Add tuning support
>
> Simon Horman (3):
>   mmc: core: Add helper to see if a host can be retuned
>   mmc: tmio: document mandatory and optional callbacks
>   mmc: sh_mobile_sdhi: Add tuning support
>
>  drivers/mmc/host/sh_mobile_sdhi.c | 265 
> +-
>  drivers/mmc/host/tmio_mmc.h   |  18 ++-
>  drivers/mmc/host/tmio_mmc_pio.c   |  87 -
>  include/linux/mmc/host.h  |   5 +
>  4 files changed, 367 insertions(+), 8 deletions(-)
>
> --
> 2.7.0.rc3.207.g0ac5344
>

This looks good to me, although I would like to get an ack from
Wolfram before I queue this up.

Kind regards
Uffe


Re: [GIT PULL FOR renesas-drivers] FDP1 Fine Display Processor support

2016-09-13 Thread Geert Uytterhoeven
Hi Kieran,

On Thu, Jun 30, 2016 at 11:29 AM, Kieran Bingham  wrote:
> The following changes since commit f50e3d0720c0f27476153c2c7129b18639228d1b:
>
>   Merge branch 'drm/next/dt' into for/renesas-drivers (2016-06-21 18:01:05 
> +0300)
>
> are available in the git repository at:
>
>   https://github.com/kbingham/linux.git renesas/fdp1

I've dropped (a rebased version of) the above branch from today's
renesas-drivers release due to a build failure (V4L2_YCBCR_ENC_SYCC
undeclared).

Thanks for your understanding.



-- 
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/4] R-Car VSP1 1-D Histogram support

2016-09-13 Thread Geert Uytterhoeven
Hi Laurent,

On Wed, Aug 17, 2016 at 2:20 PM, Laurent Pinchart
 wrote:
> This patch series implements support for the Renesas R-Car VSP1 1-D histogram
> generator (HGO). It is based on top of the latest media tree's master branch,
> and available for convenience at
>
> git://linuxtv.org/pinchartl/media.git vsp1/hgo

I've dropped the above branch from today's renesas-drivers release due to too
many merge conflicts.

Thanks for your understanding.

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-2016-09-13-v4.8-rc6

2016-09-13 Thread Geert Uytterhoeven
I have pushed renesas-drivers-2016-09-13-v4.8-rc6 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-20160908-v4.8-rc5.

Included branches with driver code:
  - clk-renesas-for-v4.9
  - sh-pfc-for-v4.9
  - topic/ipmmu-multi-arch-v4
  - topic/r8a7795-ipmmu-v2-rebased1
  - topic/r8a7796-ipmmu-v1-rebased1
  - topic/salvator-x-ipmmu-rfc-v3-rebased4
  - topic/rcar-secondary-booting-in-debug-mode-v1
  - topic/spi-slave-v2
  - topic/sdhi-gen3-dma-v3-rebased3
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-v6
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-v6+r8a7791,4
  - topic/i2c-demux-v3-rebased3
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/r8a7796-sdhi-v2.rebase
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#renesas/topic/pretimeout
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#renesas/topic/i2c_sdhi_maintenance
  - git://linuxtv.org/pinchartl/media.git#iommu/devel/du
  - topic/fcpf-v1-rebased7

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/cjb/mmc.git#mmc-next
  - git://git.linaro.org/people/ulf.hansson/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.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git#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://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - git://git.infradead.org/battery-2.6.git#master
  - 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-intel#topic/drm-misc
  - 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

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


[PATCH v7 00/11] ARM, arm64: renesas: Enable UHS-I SDR-104

2016-09-13 Thread Simon Horman
Hi,

this series enables SDHI UHS-I SDR-104 on:
* r8a7790/lager
* r8a7791/koelsch
* r8a7794/alt
* r8a7795/salvator-x
* r8a7796/salvator-x

It is based on renesas-next-20160908-v4.8-rc1.


For functional SDR-104 support the following dependencies are needed:
* [PATCH v7 0/6] UHS-I SDR-104 support for sh_mobile_sdhi
* [PATCH/RFT,v2,2/8] clk: renesas: r8a7796: Add SDIF clocks
* [PATCH] pinctrl: sh-pfc: r8a7796: Add voltage switch operations for SDHI
* [PATCH v2 0/3] pinctrl: sh-pfc: r8a779[14]: Implement voltage switching for 
SDHI

To aid review the following git branches are provided:
* This patchset:
  https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-integration-v7
* This patch-set and above dependencies
  https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-v7

Furthermore DMA support for R-Car Gen3 is need to achive higher
transfer rates on the r8a7795 and r8a7796. For convenience a
branch containing a merge of topic/sdr104-v7 (see above) and
"[PATCH/RFC v3 0/6] mmc: renesas_sdhi: add R-Car Gen-3 DMA support"
(rebased) is provided as:

* https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-v7+sdhi-dma-v3

Simon Horman (10):
  ARM: dts: lager: Enable UHS-I SDR-104
  arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104
  ARM: dts: r8a7791: set maximum frequency for SDHI clocks
  ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104
  ARM: dts: r8a7794: set maximum frequency for SDHI clocks
  ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104
  arm64: dts: r8a7796: add SDHI nodes
  arm64: dts: r8a7796: salvator-x: enable SDHI0 & 3
  arm64: dts: r8a7796: salvator-x: enable UHS for SDHI 0 & 3
  arm64: dts: r8a7796: salvator-x: Enable UHS-I SDR-104

Wolfram Sang (1):
  arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3

 arch/arm/boot/dts/r8a7790-lager.dts|   1 +
 arch/arm/boot/dts/r8a7791-koelsch.dts  |  34 ++-
 arch/arm/boot/dts/r8a7791.dtsi |   3 +
 arch/arm/boot/dts/r8a7794-alt.dts  |  23 -
 arch/arm/boot/dts/r8a7794.dtsi |   3 +
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  24 -
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 104 +
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  42 +
 8 files changed, 227 insertions(+), 7 deletions(-)

-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 07/11] ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104

2016-09-13 Thread Simon Horman
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1}.
And the sd-uhs-sdr104 property to SDHI0.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7794-alt.dts | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794-alt.dts 
b/arch/arm/boot/dts/r8a7794-alt.dts
index 8d1b35afaf82..ccb80d66076f 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -207,11 +207,25 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_uhs: sd0_uhs {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
};
 
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+   power-source = <3300>;
+   };
+
+   sdhi1_pins_uhs: sd1_uhs {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <1800>;
};
 };
 
@@ -255,23 +269,28 @@
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi0>;
vqmmc-supply = <_sdhi0>;
cd-gpios = < 6 GPIO_ACTIVE_LOW>;
wp-gpios = < 7 GPIO_ACTIVE_LOW>;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi1>;
vqmmc-supply = <_sdhi1>;
cd-gpios = < 14 GPIO_ACTIVE_LOW>;
wp-gpios = < 15 GPIO_ACTIVE_LOW>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104

2016-09-13 Thread Simon Horman
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
And the sd-uhs-sdr104 property to SDHI0.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 34 +++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f8a7d090fd01..be90639d2635 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -360,16 +360,37 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_uhs: sd0_uhs {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
};
 
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+   power-source = <3300>;
+   };
+
+   sdhi1_pins_uhs: sd1_uhs {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <1800>;
};
 
sdhi2_pins: sd2 {
groups = "sdhi2_data4", "sdhi2_ctrl";
function = "sdhi2";
+   power-source = <3300>;
+   };
+
+   sdhi2_pins_uhs: sd2_uhs {
+   groups = "sdhi2_data4", "sdhi2_ctrl";
+   function = "sdhi2";
+   power-source = <1800>;
};
 
qspi_pins: qspi {
@@ -454,33 +475,40 @@
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi0>;
vqmmc-supply = <_sdhi0>;
cd-gpios = < 6 GPIO_ACTIVE_LOW>;
wp-gpios = < 7 GPIO_ACTIVE_HIGH>;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi1>;
vqmmc-supply = <_sdhi1>;
cd-gpios = < 14 GPIO_ACTIVE_LOW>;
wp-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi2>;
vqmmc-supply = <_sdhi2>;
cd-gpios = < 22 GPIO_ACTIVE_LOW>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3

2016-09-13 Thread Simon Horman
From: Wolfram Sang 

Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
Signed-off-by: Simon Horman 
---
v6
* Updated patch prefix: s/salvator/&-x/

v5
* Added to series, previously posted by Wolfram independently
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index b1eab6876f8c..ff4e4fe843ed 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -237,11 +237,25 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_uhs: sd0_uhs {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
};
 
sdhi3_pins: sd3 {
groups = "sdhi3_data4", "sdhi3_ctrl";
function = "sdhi3";
+   power-source = <3300>;
+   };
+
+   sdhi3_pins_uhs: sd3_uhs {
+   groups = "sdhi3_data4", "sdhi3_ctrl";
+   function = "sdhi3";
+   power-source = <1800>;
};
 
sound_pins: sound {
@@ -371,25 +385,29 @@
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi0>;
vqmmc-supply = <_sdhi0>;
cd-gpios = < 12 GPIO_ACTIVE_LOW>;
wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi3>;
vqmmc-supply = <_sdhi3>;
cd-gpios = < 15 GPIO_ACTIVE_LOW>;
wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 08/11] arm64: dts: r8a7796: add SDHI nodes

2016-09-13 Thread Simon Horman
Add SDHI nodes to the DT of the r8a7796 SoC.

Based on the DT of the r8a7795 SoC.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 42 
 1 file changed, 42 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 9217da983525..3aae29fdd9d7 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -251,5 +251,47 @@
power-domains = < R8A7796_PD_ALWAYS_ON>;
status = "disabled";
};
+
+   sdhi0: sd@ee10 {
+   compatible = "renesas,sdhi-r8a7796";
+   reg = <0 0xee10 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 314>;
+   max-frequency = <2>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   sdhi1: sd@ee12 {
+   compatible = "renesas,sdhi-r8a7796";
+   reg = <0 0xee12 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 313>;
+   max-frequency = <2>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   status = "disabled";
+   };
+
+   sdhi2: sd@ee14 {
+   compatible = "renesas,sdhi-r8a7796";
+   reg = <0 0xee14 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 312>;
+   max-frequency = <2>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   cap-mmc-highspeed;
+   status = "disabled";
+   };
+
+   sdhi3: sd@ee16 {
+   compatible = "renesas,sdhi-r8a7796";
+   reg = <0 0xee16 0 0x2000>;
+   interrupts = ;
+   clocks = < CPG_MOD 311>;
+   max-frequency = <2>;
+   power-domains = < R8A7796_PD_ALWAYS_ON>;
+   cap-mmc-highspeed;
+   status = "disabled";
+   };
};
 };
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 06/11] ARM: dts: r8a7794: set maximum frequency for SDHI clocks

2016-09-13 Thread Simon Horman
Define the upper limit otherwise the driver cannot utilize max speeds.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7794.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 9365580a194f..57e0d27cb82e 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -731,6 +731,7 @@
dmas = < 0xcd>, < 0xce>,
   < 0xcd>, < 0xce>;
dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <19500>;
power-domains = < R8A7794_PD_ALWAYS_ON>;
status = "disabled";
};
@@ -743,6 +744,7 @@
dmas = < 0xc1>, < 0xc2>,
   < 0xc1>, < 0xc2>;
dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
power-domains = < R8A7794_PD_ALWAYS_ON>;
status = "disabled";
};
@@ -755,6 +757,7 @@
dmas = < 0xd3>, < 0xd4>,
   < 0xd3>, < 0xd4>;
dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
power-domains = < R8A7794_PD_ALWAYS_ON>;
status = "disabled";
};
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 04/11] ARM: dts: r8a7791: set maximum frequency for SDHI clocks

2016-09-13 Thread Simon Horman
Define the upper limit otherwise the driver cannot utilize max speeds.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7791.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 162b55c665a3..b07c799f72f2 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -584,6 +584,7 @@
dmas = < 0xcd>, < 0xce>,
   < 0xcd>, < 0xce>;
dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <19500>;
power-domains = < R8A7791_PD_ALWAYS_ON>;
status = "disabled";
};
@@ -596,6 +597,7 @@
dmas = < 0xc1>, < 0xc2>,
   < 0xc1>, < 0xc2>;
dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
power-domains = < R8A7791_PD_ALWAYS_ON>;
status = "disabled";
};
@@ -608,6 +610,7 @@
dmas = < 0xd3>, < 0xd4>,
   < 0xd3>, < 0xd4>;
dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
power-domains = < R8A7791_PD_ALWAYS_ON>;
status = "disabled";
};
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 09/11] arm64: dts: r8a7796: salvator-x: enable SDHI0 & 3

2016-09-13 Thread Simon Horman
Enable the exposed SD card slots in the DT of the r8a7796/salvator-x.

Based on work for the r8a7795/salvator-x by Ai Kyuse.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 84 ++
 1 file changed, 84 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 13db7d61c26c..a8373c248ad1 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -10,6 +10,7 @@
 
 /dts-v1/;
 #include "r8a7796.dtsi"
+#include 
 
 / {
model = "Renesas Salvator-X board based on r8a7796";
@@ -29,6 +30,55 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x7800>;
};
+
+   vcc_sdhi0: regulator-vcc-sdhi0 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI0 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 2 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi0: regulator-vccq-sdhi0 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
+
+   vcc_sdhi3: regulator-vcc-sdhi3 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI3 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 15 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   vccq_sdhi3: regulator-vccq-sdhi3 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI3 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
+
 };
 
  {
@@ -43,12 +93,46 @@
groups = "scif_clk_a";
function = "scif_clk";
};
+
+   sdhi0_pins: sd0 {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   };
+
+   sdhi3_pins: sd3 {
+   groups = "sdhi3_data4", "sdhi3_ctrl";
+   function = "sdhi3";
+   };
 };
 
 _clk {
clock-frequency = <1666>;
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   vmmc-supply = <_sdhi0>;
+   vqmmc-supply = <_sdhi0>;
+   cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+   wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   vmmc-supply = <_sdhi3>;
+   vqmmc-supply = <_sdhi3>;
+   cd-gpios = < 15 GPIO_ACTIVE_LOW>;
+   wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
+   bus-width = <4>;
+   status = "okay";
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 11/11] arm64: dts: r8a7796: salvator-x: Enable UHS-I SDR-104

2016-09-13 Thread Simon Horman
Add the sd-uhs-sdr104 property to SDHI0 and SDHI1.

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index a9947d45..91440eb2237e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -134,6 +134,7 @@
wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
@@ -148,6 +149,7 @@
wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 01/11] ARM: dts: lager: Enable UHS-I SDR-104

2016-09-13 Thread Simon Horman
Add the sd-uhs-sdr104 property to SDHI0.

Signed-off-by: Simon Horman 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 52b56fcaddf2..5e43763cec65 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -559,6 +559,7 @@
vqmmc-supply = <_sdhi0>;
cd-gpios = < 6 GPIO_ACTIVE_LOW>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 10/11] arm64: dts: r8a7796: salvator-x: enable UHS for SDHI 0 & 3

2016-09-13 Thread Simon Horman
Based on work for the r8a7796 by Wolfram Sang.

Cc: Wolfram Sang 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index a8373c248ad1..a9947d45 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -97,11 +97,25 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+   power-source = <3300>;
+   };
+
+   sdhi0_pins_uhs: sd0_uhs {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <1800>;
};
 
sdhi3_pins: sd3 {
groups = "sdhi3_data4", "sdhi3_ctrl";
function = "sdhi3";
+   power-source = <3300>;
+   };
+
+   sdhi3_pins_uhs: sd3_uhs {
+   groups = "sdhi3_data4", "sdhi3_ctrl";
+   function = "sdhi3";
+   power-source = <1800>;
};
 };
 
@@ -111,25 +125,29 @@
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi0>;
vqmmc-supply = <_sdhi0>;
cd-gpios = < 12 GPIO_ACTIVE_LOW>;
wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
  {
pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
 
vmmc-supply = <_sdhi3>;
vqmmc-supply = <_sdhi3>;
cd-gpios = < 15 GPIO_ACTIVE_LOW>;
wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
+   sd-uhs-sdr50;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 03/11] arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104

2016-09-13 Thread Simon Horman
Add the sd-uhs-sdr104 property to SDHI0 and SDHI1.

Signed-off-by: Simon Horman 
---
v5
* New patch
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index ff4e4fe843ed..8964b1ea3cea 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -394,6 +394,7 @@
wp-gpios = < 13 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
@@ -408,6 +409,7 @@
wp-gpios = < 16 GPIO_ACTIVE_HIGH>;
bus-width = <4>;
sd-uhs-sdr50;
+   sd-uhs-sdr104;
status = "okay";
 };
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 0/6] UHS-I SDR-104 support for sh_mobile_sdhi

2016-09-13 Thread Simon Horman

Hi,

this series is based on work by Ai Kyuse to add UHS-I SDR-104 support for
sh_mobile_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William
Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I
SDR-50 support to the same driver.

It is based on a merge of the next branches of the mmc tree.

To aid review the following git branch is provided:
* https:://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
topic/sdr104-driver-v7

Overview of changes since v6:
* Address review by Ulf
  - Detailed in per-patch changelogs
* Move integration (arm/arm64 dt) patches to separate patchset

Please see http://elinux.org/Tests:SD-SDHI-SDR104 for indicative tests
results.


Ai Kyuse (3):
  mmc: tmio: enhance illegal sequence handling
  mmc: tmio: Add hw reset support
  mmc: tmio: Add tuning support

Simon Horman (3):
  mmc: core: Add helper to see if a host can be retuned
  mmc: tmio: document mandatory and optional callbacks
  mmc: sh_mobile_sdhi: Add tuning support

 drivers/mmc/host/sh_mobile_sdhi.c | 265 +-
 drivers/mmc/host/tmio_mmc.h   |  18 ++-
 drivers/mmc/host/tmio_mmc_pio.c   |  87 -
 include/linux/mmc/host.h  |   5 +
 4 files changed, 367 insertions(+), 8 deletions(-)

-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 4/6] mmc: tmio: Add hw reset support

2016-09-13 Thread Simon Horman
From: Ai Kyuse 

Add hw reset support.

Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
This is required by tuning support which will
be introduced by follow-up patches.

v6
* Rely on core to retune on reset

v5
* As suggested by Ulf Hansson
  - Broke out of a larger patch
---
 drivers/mmc/host/tmio_mmc.h | 1 +
 drivers/mmc/host/tmio_mmc_pio.c | 9 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 4b36cb5c2d9c..4b71f31fba63 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -164,6 +164,7 @@ struct tmio_mmc_host {
int (*start_signal_voltage_switch)(struct mmc_host *mmc,
   struct mmc_ios *ios);
int (*write16_hook)(struct tmio_mmc_host *host, int addr);
+   void (*hw_reset)(struct tmio_mmc_host *host);
 };
 
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 806308ac93e7..f1d36f4533d2 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -756,6 +756,14 @@ static int tmio_mmc_start_data(struct tmio_mmc_host *host,
return 0;
 }
 
+static void tmio_mmc_hw_reset(struct mmc_host *mmc)
+{
+   struct tmio_mmc_host *host = mmc_priv(mmc);
+
+   if (host->hw_reset)
+   host->hw_reset(host);
+}
+
 /* Process requests from the MMC layer */
 static void tmio_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq)
 {
@@ -970,6 +978,7 @@ static struct mmc_host_ops tmio_mmc_ops = {
.get_cd = mmc_gpio_get_cd,
.enable_sdio_irq = tmio_mmc_enable_sdio_irq,
.multi_io_quirk = tmio_multi_io_quirk,
+   .hw_reset   = tmio_mmc_hw_reset,
 };
 
 static int tmio_mmc_init_ocr(struct tmio_mmc_host *host)
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 6/6] mmc: sh_mobile_sdhi: Add tuning support

2016-09-13 Thread Simon Horman
Add tuning support for use with SDR104 mode
This includes adding support for the sampling clock controller (SCC).

Based on work by Ai Kyuse.

Cc: Ai Kyuse 
Signed-off-by: Simon Horman 
---
v6 [Simon Horman]
* Rebase to use host->taps

v5 [Simon Horman]
* As suggested by Ulf Hansson
  - Use more descriptive name for callback to check for SSC error
* Correct return statement in sh_mobile_sdhi_hw_reset
* Reinstate Gen3 tuning support

v4 [Simon Horman]
As suggested by Geert Uytterhoeven:
* guard SDR104 specific portion of probe with host->mmc->caps &
  MMC_CAP_UHS_SDR104
* As suggested by Wolfram Sang:
  - Pass priv to sd_scc_{read,write}32 to save host_to_priv access
for each call
  - Use 0x0 instead of other representations of 0 in hex
  - Use CLK_CTL_SCLKEN
  - Do not add unused SH_MOBILE_SDHI_MAX_TAP
  - Use ternary operator in sh_mobile_sdhi_select_tuning
  - Do include as yet unsupported HS200 in error string
* Reintroduce retuning support: This was removed in v3.
* Revert to algorithm in v1 patchset, on further reading of the documentation
  it appears to be correct.

v3 [Simon Horman]
* As suggested by Kuninori Morimoto:
  - Do not add unused retuning callback to struct tmio_mmc_host
  - Change return type of prepare_tuning callback to void
  - Add tap_size parameter to select_tuning callback

v2 [Simon Horman]
* As suggested by Kuninori Morimoto
  - Use host->mmc->caps & MMC_CAP_UHS_SDR104 instead of
pdata->flags & TMIO_MMC_HAS_UHS_SCC to avoid needing the
MMC_CAP_UHS_SDR104 flag at all.
N.B: Morimoto-san suggested using but this flag is not actually
set there in by current probe come.
  - Simplify logic in sh_mobile_sdhi_inquiry_tuning
* As suggested by Wolfram Sang
  - Use clk_rate instead of clk for field in struct sh_mobile_sdhi_scc
  - Remove inquiry_tuning callback which is now unnecessary as calling
of tuning is handled by the core
  - Removed unused sh_mobile_sdhi_set_clk_div callback
  - Save sci_base address rather than calculating it on each read and write
* Update selection logic in sh_mobile_sdhi_select_tuning to match spec
* Use bool instead of long for taps parameter of
  sh_mobile_sdhi_select_tuning()
* Return 0 from sh_mobile_sdhi_init_tuning() if the
  SDR104 capability is not set and thus tuning should not
  be performed because it is not supported by the hardware

v1 [Simon Horman]
* Rebase
* Always use value of 0x8 for TAPNUM field of DTCNTL register
  rather than reading value from DT property. There does not
  seem to be a need to expose this in DT at this point.
* Do not include tmio_mmc_start_signal_voltage_switch changes which
  are already in mainline in a different form
* Do not add renesas,clk-rate property as the max-frequency property, which
  is now present in mainline, seems to provide the needed rate
* Omit Gen3 specific changes
* Do not provide renesas,mmc-scc-tappos DT property.
  Instead, always use taps provided in driver.
* Do not parse sd-uhs-sdr50 and sd-uhs-sdr104 properties.
  This is handled by the core.

v0 [Ai Kyuse]

Signed-off-by: Simon Horman 
---
 drivers/mmc/host/sh_mobile_sdhi.c | 265 +-
 1 file changed, 264 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c 
b/drivers/mmc/host/sh_mobile_sdhi.c
index 49edff7fee49..32d3e01e0840 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -47,6 +47,11 @@
 
 #define host_to_priv(host) container_of((host)->pdata, struct sh_mobile_sdhi, 
mmc_data)
 
+struct sh_mobile_sdhi_scc {
+   unsigned long clk_rate; /* clock rate for SDR104 */
+   u32 tap;/* sampling clock position for SDR104 */
+};
+
 struct sh_mobile_sdhi_of_data {
unsigned long tmio_flags;
unsigned long capabilities;
@@ -54,6 +59,9 @@ struct sh_mobile_sdhi_of_data {
enum dma_slave_buswidth dma_buswidth;
dma_addr_t dma_rx_offset;
unsigned bus_shift;
+   int scc_offset;
+   struct sh_mobile_sdhi_scc *taps;
+   int taps_num;
 };
 
 static const struct sh_mobile_sdhi_of_data of_default_cfg = {
@@ -66,12 +74,35 @@ static const struct sh_mobile_sdhi_of_data 
of_rcar_gen1_compatible = {
.capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
 };
 
+/* Definitions for sampling clocks */
+static struct sh_mobile_sdhi_scc rcar_gen2_scc_taps[] = {
+   {
+   .clk_rate = 15600,
+   .tap = 0x0703,
+   },
+   {
+   .clk_rate = 0,
+   .tap = 0x0300,
+   },
+};
+
 static const struct sh_mobile_sdhi_of_data of_rcar_gen2_compatible = {
.tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE |
  TMIO_MMC_CLK_ACTUAL | TMIO_MMC_MIN_RCAR2,
.capabilities   = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.dma_buswidth   = DMA_SLAVE_BUSWIDTH_4_BYTES,

[PATCH v7 2/6] mmc: tmio: enhance illegal sequence handling

2016-09-13 Thread Simon Horman
From: Ai Kyuse 

An illegal sequence command error may occur if there is a stopbit or
cmd_index error as well as a CRC error. The correct course of action
is to re-enable IRQs

An illegal sequence data error may occur if there is a CRC or stopbit
error,  or underrun. In this case set data->error correctly.

This is in preparation for enabling tuning support which relies on
differentiating between illegal sequence and other errors.

Signed-off-by: Ai Kyuse 
[simon: broken out of a larger patch]
Signed-off-by: Simon Horman 
Reviewed-by: Wolfram Sang 
---
v4
* Added Ack from Wolfram Sang

v3
* No change

v2
* Broken out of a larger patch (but forgot to post)
---
 drivers/mmc/host/tmio_mmc_pio.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 192817850dff..806308ac93e7 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -520,7 +520,7 @@ void tmio_mmc_do_data_irq(struct tmio_mmc_host *host)
schedule_work(>done);
 }
 
-static void tmio_mmc_data_irq(struct tmio_mmc_host *host)
+static void tmio_mmc_data_irq(struct tmio_mmc_host *host, unsigned int stat)
 {
struct mmc_data *data;
spin_lock(>lock);
@@ -529,6 +529,9 @@ static void tmio_mmc_data_irq(struct tmio_mmc_host *host)
if (!data)
goto out;
 
+   if (stat & TMIO_STAT_CRCFAIL || stat & TMIO_STAT_STOPBIT_ERR ||
+   stat & TMIO_STAT_TXUNDERRUN)
+   data->error = -EILSEQ;
if (host->chan_tx && (data->flags & MMC_DATA_WRITE) && 
!host->force_pio) {
u32 status = sd_ctrl_read16_and_16_as_32(host, CTL_STATUS);
bool done = false;
@@ -577,8 +580,6 @@ static void tmio_mmc_cmd_irq(struct tmio_mmc_host *host,
goto out;
}
 
-   host->cmd = NULL;
-
/* This controller is sicker than the PXA one. Not only do we need to
 * drop the top 8 bits of the first response word, we also need to
 * modify the order of the response for short response command types.
@@ -598,14 +599,16 @@ static void tmio_mmc_cmd_irq(struct tmio_mmc_host *host,
 
if (stat & TMIO_STAT_CMDTIMEOUT)
cmd->error = -ETIMEDOUT;
-   else if (stat & TMIO_STAT_CRCFAIL && cmd->flags & MMC_RSP_CRC)
+   else if ((stat & TMIO_STAT_CRCFAIL && cmd->flags & MMC_RSP_CRC) ||
+stat & TMIO_STAT_STOPBIT_ERR ||
+stat & TMIO_STAT_CMD_IDX_ERR)
cmd->error = -EILSEQ;
 
/* If there is data to handle we enable data IRQs here, and
 * we will ultimatley finish the request in the data_end handler.
 * If theres no data or we encountered an error, finish now.
 */
-   if (host->data && !cmd->error) {
+   if (host->data && (!cmd->error || cmd->error == -EILSEQ)) {
if (host->data->flags & MMC_DATA_READ) {
if (host->force_pio || !host->chan_rx)
tmio_mmc_enable_mmc_irqs(host, 
TMIO_MASK_READOP);
@@ -666,7 +669,7 @@ static bool __tmio_mmc_sdcard_irq(struct tmio_mmc_host 
*host,
/* Data transfer completion */
if (ireg & TMIO_STAT_DATAEND) {
tmio_mmc_ack_mmc_irqs(host, TMIO_STAT_DATAEND);
-   tmio_mmc_data_irq(host);
+   tmio_mmc_data_irq(host, status);
return true;
}
 
-- 
2.7.0.rc3.207.g0ac5344



[PATCH v7 5/6] mmc: tmio: Add tuning support

2016-09-13 Thread Simon Horman
From: Ai Kyuse 

Add tuning support for use with SDR104 mode

Signed-off-by: Ai Kyuse 
Signed-off-by: Simon Horman 
---
v7 [Simon Horman]
* As per review by Ulf Hansson:
  - Use tmio_mmc_hw_reset() rather than mmc_hw_reset() in
tmio_mmc_execute_tuning()
  - Do not zero host->mmc->retune_period in tmio_mmc_execute_tuning()
  - Do not perform a reset if host->select_tuning() fails in
tmio_mmc_host_runtime_resume() retuning should be
performed if a request subsequently fails.
* Do not implicitly trigger retuning if host->check_scc_error() returns true

v6 [Simon Horman]
* As suggested by Ulf Hansson:
  - Restore saved tuning parameters on resume

v5 [Simon Horman]
* As suggested by Ulf Hansson:
  - Move hw reset support into a separate patch
  - Use more descriptive name for callback to check for SSC error
  - Rely on core to retune in case of -EILSEQ
  - Document mandatory and optional callbacks

v4 [Simon Horman]
* As suggested by Wolfram Sang:
  - Do not perform tuning if host->select_tuning is not set:
it seems to make little sense to do so and moreover there is currently
no such use-case
  - Do not add mrc->sbc handling from tmio_mmc_request,
this is a hang-over from earlier versions of this patchset which
did not use core infrastructure for retuning
  - Tidy up local variable usage
* Correct index passed to prepare_tuning(): this seems to have
  been the last piece of resolving the timeouts during tuning puzzle
* Further cleanups to tmio_mmc_execute_tuning():
  - Ensure tap is sized proportionally to its members
  - Remove stray '*' in comment
  - Use mmc rather than host->mmc, these are equivalent but
the former seems tidier
  - Correct inverted logic in setting tap values
* Re-introduce retuning support. This was removed in v3.

v3 [Simon Horman]
* As suggested by Kuninori Morimoto:
  - Do not add unused retuning callback to struct tmio_mmc_host
  - Change return type of prepare_tuning callback to void
  - Add tap_size parameter to select_tuning callback

v2 [Simon Horman]
* As suggested by Kuninori Morimoto:
  - Actually remove unnecessary TMIO_MMC_HAS_UHS_SCC define
* As suggested by Wolfram Sang:
  - Rely on core to call tuning. This simplifies things somewhat.
  - Use mmc_send_tuning()
- A side affect of this appears to be that we now see some recoverable
  errors logged during tuning. These are typically corrected by
  subsequent tuning. It is the logging that is the apparent side effect
  of this change.
  e.g.
  sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
  sh_mobile_sdhi ee10.sd: Tuning procedure failed
* Use bool rather than unsigned long to pass test status
  to select_tuning() callback
* Do not retune if init_tuning callback is not present or
  indicates that there are no taps present
* Retune on hardware reset

v1 [Simon Horman]
* Omit start_signal_voltage_switch and tmio_mmc_card_busy changes which are
  already present in mainline in a different form
* Return num from init_tuning rather than passing an extra parameter
  to hold the return value
* Only call host->init_tuning if it is non-NULL
* Place tmio_mmc_execute_tuning() such that no new forward declarations are
  required
* Remove unused TMIO_MMC_HAS_UHS_SCC define

v0 [Ai Kyuse]
---
 drivers/mmc/host/tmio_mmc.h | 12 
 drivers/mmc/host/tmio_mmc_pio.c | 63 +
 2 files changed, 75 insertions(+)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 4b71f31fba63..4b501f2d529f 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -150,6 +150,7 @@ struct tmio_mmc_host {
struct mutexios_lock;   /* protect set_ios() context */
boolnative_hotplug;
boolsdio_irq_enabled;
+   u32 scc_tappos;
 
/* Mandatory callback */
int (*clk_enable)(struct tmio_mmc_host *host);
@@ -165,6 +166,17 @@ struct tmio_mmc_host {
   struct mmc_ios *ios);
int (*write16_hook)(struct tmio_mmc_host *host, int addr);
void (*hw_reset)(struct tmio_mmc_host *host);
+   void (*prepare_tuning)(struct tmio_mmc_host *host, unsigned long tap);
+   bool (*check_scc_error)(struct tmio_mmc_host *host);
+
+   /* Mandatory callback for tuning to occur which is
+* optional for SDR50 and mandatory for SDR104 */
+   unsigned int (*init_tuning)(struct tmio_mmc_host *host);
+   int (*select_tuning)(struct tmio_mmc_host *host);
+
+   /* Tuning values: 1 for success, 0 for failure */
+   DECLARE_BITMAP(taps, BITS_PER_BYTE * sizeof(long));
+   unsigned int tap_num;
 };
 
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c 

[PATCH v7 3/6] mmc: tmio: document mandatory and optional callbacks

2016-09-13 Thread Simon Horman
Signed-off-by: Simon Horman 
---
v5
* New patch
---
 drivers/mmc/host/tmio_mmc.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 1f1cb2628f67..4b36cb5c2d9c 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -151,8 +151,10 @@ struct tmio_mmc_host {
boolnative_hotplug;
boolsdio_irq_enabled;
 
-   int (*write16_hook)(struct tmio_mmc_host *host, int addr);
+   /* Mandatory callback */
int (*clk_enable)(struct tmio_mmc_host *host);
+
+   /* Optional callbacks */
unsigned int (*clk_update)(struct tmio_mmc_host *host,
   unsigned int new_clock);
void (*clk_disable)(struct tmio_mmc_host *host);
@@ -161,6 +163,7 @@ struct tmio_mmc_host {
int (*card_busy)(struct mmc_host *mmc);
int (*start_signal_voltage_switch)(struct mmc_host *mmc,
   struct mmc_ios *ios);
+   int (*write16_hook)(struct tmio_mmc_host *host, int addr);
 };
 
 struct tmio_mmc_host *tmio_mmc_host_alloc(struct platform_device *pdev);
-- 
2.7.0.rc3.207.g0ac5344



Re: [PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for obtaining mode pin state

2016-09-13 Thread Geert Uytterhoeven
Hi Stephen,

On Tue, Sep 13, 2016 at 12:16 AM, Stephen Boyd  wrote:
> On 09/01, Geert Uytterhoeven wrote:
>> On Thu, Jun 30, 2016 at 10:14 PM, Stephen Boyd  wrote:
>> > On 06/01, Geert Uytterhoeven wrote:
>> >> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> >> state of the mode pins either by a call from the board code, or directly
>> >> by using a hardcoded register access. This is a bit messy, and creates a
>> >> dependency between driver and platform code.
>> >>
>> >> This RFC patch series converts the various Renesas R-Car clock drivers
>> >> and support code from reading the mode pin states using a hardcoded
>> >> register access to using a new R-Car RST driver.
>> >
>> > Dumb question, can we use the nvmem reading APIs instead of an
>> > SoC specific function to read the modes?
>>
>> Thanks for your suggestion, the nvmem API indeed looks like a suitable API,
>> as it does support read-only nvmems.
>>
>> Unfortunately I also see a few disadvantages:
>>   1. nvmem_init() is a subsys_initcall(), while most of our users (except for
>>  the recent renesas-cpg-mssr driver) are clock drivers using
>>  CLK_OF_DECLARE(), and are thus initialized from of_clk_init() at much
>>  earlier time_init() time.
>>  Of course the mvmem subsystem and/or the clock drivers can be changed, 
>> if
>>  deemed useful.
>
> Sounds like this is solvable.

Sure.

>>   2. Using the nvmem DT bindings means we have to add more DT glue from the
>>  nvmem consumer(s) to the nvmem provider. As we need to provide backwards
>>  compatibility with old DTSes, this means we need more C code or DT fixup
>>  code to handle that.
>
> Ah I wasn't aware we were keeping backwards compatibility around.
>
>>   3. The nvmem subsystem may be overkill to provide access to a simple 32-bit
>>  read-only register that never changes value after boot.
>
> The nvmem subsystem is designed to read values from things that
> mostly never change. Overkill may be true, but the nice thing
> about using nvmem APIs is that the driver doesn't have to use
> some platform specific function that duplicates similar
> functionality. It's unfortunate that backwards incompatibility
> limits our ability to move to common linux frameworks when they
> are created after the binding is used.

This is continuing work to support old, current, and new SoCs properly.
When the first support for R-Car Gen2 SoCs was added, many frameworks
didn't have DT support, or didn't even exist.

Unlike in the mobile market, development and life span is much larger than
6 months here...

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