Re: [PATCH ] gpio: rcar: Add r8a7745 (RZ/G1E) support

[Rob Herring]

On Wed, Aug 16, 2017 at 12:12:16PM +0100, Biju Das wrote:
> Renesas RZ/G1E (R8A7745) SoC GPIO blocks are identical to the R-Car Gen2
> family. Add support for its GPIO controllers.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is tested against linux-next tag next-20170816 as well as 
> gpio-devel.
> 
>  Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH] dt-bindings: mmc: sh_mmcif: Document r8a7745 DT bindings

[Rob Herring]

On Tue, Aug 15, 2017 at 05:53:27PM +0100, Fabrizio Castro wrote:
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Chris Paterson 
> ---
>  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH v7] media: platform: Renesas IMR driver

[Sergei Shtylyov]

Hello!

On 08/17/2017 10:59 AM, Hans Verkuil wrote:


A quick review. I'm concentrating on the mesh ioctl, since that's what sets this
driver apart.


   OK, waiting for the detailed review...


Index: media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
===
--- /dev/null
+++ media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
@@ -0,0 +1,372 @@
+Renesas R-Car Image Renderer (IMR) Driver
+=
+
+This file documents some driver-specific aspects of the IMR driver, such as
+the driver-specific ioctl.


Just drop the part ', such as...'.

Can you add a high-level description of the functionality here? Similar to what
you did in the bindings document.


   Sure, I can.


+
+The ioctl reference
+~~~
+
+See ``include/uapi/linux/rcar_imr.h`` for the data structures used.
+
+VIDIOC_IMR_MESH - Set mapping data
+^^
+
+Argument: ``struct imr_map_desc``
+
+**Description**:
+
+This ioctl sets up the mesh through which the input frames will be transformed
+into the output frames. The mesh can be strictly rectangular (when
+``IMR_MAP_MESH`` bit is set in ``imr_map_desc::type``) or arbitrary (when that
+bit is not set).


Wouldn't something like 'IMR_MAP_RECTANGULAR' be much more descriptive than 
_MESH?
There is nothing in the name _MESH to indicate that this switches the data to
rectangles.


   Well, in my Russian mind, mesh consists of the rectangles. :-)


+
+A rectangular mesh consists of the imr_mesh structure followed by M*N vertex
+objects (where M is ``imr_mesh::rows`` and N is ``imr_mesh::columns``).
+In case either ``IMR_MAP_AUTOSG`` or ``IMR_MAP_AUTODG`` (not both) bits are
+set in ``imr_map_desc::type``, ``imr_mesh::{x|y}0`` specify the coordinates
+of the top left corner of the auto-generated mesh and ``imr_mesh::d{x|y}``
+specify the mesh's X/Y steps.


So if the auto bits are set, then there are no vertex objects?


   No, there are no source or destination (not both) coordinate structures 
present in the vertex object; at least one of them must always be there.



Since it's auto generated by the hardware?


   Yes.


I believe we discussed in the past whether 'type' should be split in a 'type'
and 'flags' field.


   In this version, I still tried Cogent's original userland working, so the 
structures were left intact (aside of renaming).



+
+An arbitrary mesh consists of the imr_vbo structure followed by N triangle
+objects (where N is ``imr_vbo::num``), consisting of 3 vertex objects each.
+Setting ``IMR_MAP_AUTODG`` and ``IMR_MAP_AUTOSG`` bits in
+``imr_map_desc::type``) isn't allowed for this type of mesh.
+
+The vertex object has a complex structure depending on some of the bits in
+``imr_map_desc::type``:
+
+    ==  ==  
===
+IMR_MAP_CLCE  IMR_MAP_LUCE  IMR_MAP_AUTODG  IMR_MAP_AUTOSG  Vertex structure 
variant


You should explain the meaning of these bits in this section. I.e., what does
CLCE or AUTODG stand for?


   I think I have explained the IRM_MAPO_AUTO* bits above.


+    ==  ==  
===
+\   ``imr_full_coord``
+\   X   ``imr_dst_coord``
+\   X   ``imr_src_coord``
+\ X 
``imr_full_coord_any_correct``
+\ X X   
``imr_auto_coord_any_correct``
+\ X X   
``imr_auto_coord_any_crrect``


crrect -> correct


+X   
``imr_full_coord_any_correct``
+X   X   
``imr_auto_coord_any_correct``
+X   X   
``imr_auto_coord_any_correct``
+X X 
``imr_full_coord_both_correct``
+X X X   
``imr_auto_coord_both_correct``
+X X X   
``imr_auto_coord_both_correct``
+    ==  ==  
===
+
+The luma correction is calculated according to the following formula (where
+``Y`` is the luma value after texture mapping, ``Y'`` is the luma value after
+luma correction, ``lscal`` and ``lofst`` are the luma correction scale and
+offset taken from ``struct imr_luma_correct``, ``YLDPO`` is a luma correction
+scale decimal point position specified by ``IMR_MAP_YLDPO(n)``): ::
+
+   Y' = ((Y * lscal) >> YLDPO) + lofst
+
+The chroma correction is calculated according to the following formula (where
+``U/V`` are the chroma values after 

Re: [PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support

[Rob Herring]

On Mon, Aug 14, 2017 at 12:39:26PM +0100, Biju Das wrote:
> Add support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5) SDHI
> is identical to the R-Car Gen2 family.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is compiled and tested againt linux next tag
> next-20170811. This patch depend on the driver change
> [PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support
> https://patchwork.kernel.org/patch/9898611/
> 
> 
>  Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

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

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

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

[snip]

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

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

/*
 * The format can't be changed during streaming. Cache it internally
 * for future runtime configuration calls.
 */

> + struct v4l2_mbus_framefmt *format;
> +
> + format = vsp1_entity_get_pad_format(>entity,
> + clu->entity.config,
> + CLU_PAD_SINK);
> + clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
> +}

[snip]

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

[snip]

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

Now moving to the bikeshedding territory, I'm not sure if prepare and 
configure are the best names for those operations. I'd like to also point out 
that we could go one step further by caching the partition-related parameters 
too, in which case we would need a third operation (or possibly passing the 
partition number to the prepare operation). While I won't mind if you 
implement this now, the issue could also be addressed later, but I'd like the 
operations to already support that use case to avoid yet another painful 
rename patch.

>   * @max_width:   Return the max supported width of data that the entity
> can
>   *   process in a single operation.
>   * @partition:   Process the partition construction based on this
> entity's

[snip]

The rest of the patch looks good to me.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 7/8] v4l: vsp1: Move video configuration to a cached dlb

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Monday 14 Aug 2017 16:13:30 Kieran Bingham wrote:
> We are now able to configure a pipeline directly into a local display
> list body. Take advantage of this fact, and create a cacheable body to
> store the configuration of the pipeline in the video object.
> 
> vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
> Convert this function to use the cached video->config body and obtain a
> local display list reference.
> 
> Attach the video->config body to the display list when needed before
> committing to hardware.
> 
> The pipe object is marked as un-configured when entering a suspend. This
> ensures that upon resume, where the hardware is reset - our cached
> configuration will be re-attached to the next committed DL.
> 
> Signed-off-by: Kieran Bingham 
> ---
> 
> Our video DL usage now looks like the below output:
> 
> dl->body0 contains our disposable runtime configuration. Max 41.
> dl_child->body0 is our partition specific configuration. Max 12.
> dl->fragments shows our constant configuration and LUTs.
> 
>   These two are LUT/CLU:
>  * dl->fragments[x]->num_entries 256 / max 256
>  * dl->fragments[x]->num_entries 4914 / max 4914
> 
> Which shows that our 'constant' configuration cache is currently
> utilised to a maximum of 64 entries.
> 
> trace-cmd report | \
> grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;
> 
>   dl->body0->num_entries 13 / max 128
>   dl->body0->num_entries 14 / max 128
>   dl->body0->num_entries 16 / max 128
>   dl->body0->num_entries 20 / max 128
>   dl->body0->num_entries 27 / max 128
>   dl->body0->num_entries 34 / max 128
>   dl->body0->num_entries 41 / max 128
>   dl_child->body0->num_entries 10 / max 128
>   dl_child->body0->num_entries 12 / max 128
>   dl->fragments[x]->num_entries 15 / max 128
>   dl->fragments[x]->num_entries 16 / max 128
>   dl->fragments[x]->num_entries 17 / max 128
>   dl->fragments[x]->num_entries 18 / max 128
>   dl->fragments[x]->num_entries 20 / max 128
>   dl->fragments[x]->num_entries 21 / max 128
>   dl->fragments[x]->num_entries 256 / max 256
>   dl->fragments[x]->num_entries 31 / max 128
>   dl->fragments[x]->num_entries 32 / max 128
>   dl->fragments[x]->num_entries 39 / max 128
>   dl->fragments[x]->num_entries 40 / max 128
>   dl->fragments[x]->num_entries 47 / max 128
>   dl->fragments[x]->num_entries 48 / max 128
>   dl->fragments[x]->num_entries 4914 / max 4914
>   dl->fragments[x]->num_entries 55 / max 128
>   dl->fragments[x]->num_entries 56 / max 128
>   dl->fragments[x]->num_entries 63 / max 128
>   dl->fragments[x]->num_entries 64 / max 128
> ---
>  drivers/media/platform/vsp1/vsp1_pipe.c  |  4 +-
>  drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
>  drivers/media/platform/vsp1/vsp1_video.c | 67 -
>  drivers/media/platform/vsp1/vsp1_video.h |  2 +-
>  4 files changed, 51 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
> b/drivers/media/platform/vsp1/vsp1_pipe.c index 5012643583b6..7d1f7ba43060
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> @@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
>   vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
>  VI6_CMD_STRCMD);
>   pipe->state = VSP1_PIPELINE_RUNNING;
> + pipe->configured = true;
>   }
> 
>   pipe->buffers_ready = 0;
> @@ -430,6 +431,9 @@ void vsp1_pipelines_suspend(struct vsp1_device *vsp1)
>   spin_lock_irqsave(>irqlock, flags);
>   if (pipe->state == VSP1_PIPELINE_RUNNING)
>   pipe->state = VSP1_PIPELINE_STOPPING;
> +
> + /* After a suspend, the hardware will be reset */
> + pipe->configured = false;

It shouldn't make a difference in practice, but I think it would be more 
logical to set the configured field to false after the hardware has been 
reset. I'd move this to the resume handler and update the comment to "The 
hardware might have been reset during suspend and need a full 
reconfiguration". 

>   spin_unlock_irqrestore(>irqlock, flags);
>   }
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
> b/drivers/media/platform/vsp1/vsp1_pipe.h index 90d29492b9b9..e7ad6211b4d0
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_pipe.h
> +++ b/drivers/media/platform/vsp1/vsp1_pipe.h
> @@ -90,6 +90,7 @@ struct vsp1_partition {
>   * @irqlock: protects the pipeline state
>   * @state: current state
>   * @wq: wait queue to wait for state change completion
> + * @configured: flag determining if the hardware has run since reset
>   * @frame_end: frame end interrupt handler
>   * @lock: protects the pipeline use count and stream count
>   * @kref: pipeline reference count
> @@ -117,6 +118,7 @@ struct vsp1_pipeline {
>   spinlock_t irqlock;
>   

Re: [PATCH v2 6/8] v4l: vsp1: Adapt entities to configure into a body

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Monday 14 Aug 2017 16:13:29 Kieran Bingham wrote:
> Currently the entities store their configurations into a display list.
> Adapt this such that the code can be configured into a body fragment
> directly, allowing greater flexibility and control of the content.
> 
> All users of vsp1_dl_list_write() are removed in this process, thus it
> too is removed.
> 
> A helper, vsp1_dl_list_body() is provided to access the internal body0
> from the display list.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
>  drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
>  drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
>  drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
>  drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
>  drivers/media/platform/vsp1/vsp1_entity.c | 16 -
>  drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
>  drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
>  drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
>  drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
>  drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
>  drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
>  drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
>  drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
>  drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
>  drivers/media/platform/vsp1/vsp1_sru.c| 14 
>  drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
>  drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
>  drivers/media/platform/vsp1/vsp1_video.c  | 11 --
>  drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
>  20 files changed, 168 insertions(+), 153 deletions(-)

This is quite intrusive, and it bothers me slightly that we need to pass both 
the DL and the DLB to the configure function in order to add fragments to the 
DL in the CLU and LUT modules. Wouldn't it be simpler to add a pointer to the 
current body in the DL structure, and modify vsp1_dl_list_write() to write to 
the current fragment ?

-- 
Regards,

Laurent Pinchart

[PATCH 2/2] ARM: dtsi: iwg22m: Add eMMC support

[Fabrizio Castro]

Add eMMC support for iW-RainboW-G22M-SM.

Signed-off-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi 
b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
index 9dbd854..afb1148 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
+++ b/arch/arm/boot/dts/r8a7745-iwg22m.dtsi
@@ -17,8 +17,34 @@
device_type = "memory";
reg = <0 0x4000 0 0x2000>;
};
+
+   reg_3p3v: 3p3v {
+   compatible = "regulator-fixed";
+   regulator-name = "3P3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
 _clk {
clock-frequency = <2000>;
 };
+
+ {
+   mmcif0_pins: mmc {
+   groups = "mmc_data8", "mmc_ctrl";
+   function = "mmc";
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   vmmc-supply = <_3p3v>;
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
+};
-- 
2.7.4

[PATCH 1/2] ARM: dts: r8a7745: Add MMC interface support

[Fabrizio Castro]

Add MMC interface support for r8a7745 SoC.

Signed-off-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a7745.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index aff90df..e17289f 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -508,6 +508,22 @@
#size-cells = <0>;
status = "disabled";
};
+
+   mmcif0: mmc@ee20 {
+   compatible = "renesas,mmcif-r8a7745",
+"renesas,sh-mmcif";
+   reg = <0 0xee20 0 0x80>;
+   interrupts = ;
+   clocks = < CPG_MOD 315>;
+   dmas = < 0xd1>, < 0xd2>,
+  < 0xd1>, < 0xd2>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
+   resets = < 315>;
+   reg-io-width = <4>;
+   max-frequency = <9750>;
+   status = "disabled";
+   };
};
 
/* External root clock */
-- 
2.7.4

[PATCH 0/2] ARM: dtsi: r8a7745: iwg22m: Add eMMC support

[Fabrizio Castro]

This series adds eMMC support to r8a7745 SoC and iW-RainboW-G22M-SM SoM.

Testing has been made on top of Renesas's devel branch.

The patches contained in this series depend on the following patches:
[1/2] ARM: dts: iwg22m: Add iWave RZG1E SODIMM SOM - 
https://patchwork.kernel.org/patch/9901619/
[2/2] ARM: dts: iwg22d-sodimm: Add support for iWave G22D-SODIMM board - 
https://patchwork.kernel.org/patch/9901623/
dt-bindings: mmc: sh_mmcif: Document r8a7745 DT bindings - 
https://patchwork.kernel.org/patch/9902199/

Regards,

Fabrizio Castro (2):
  ARM: dts: r8a7745: Add MMC interface support
  ARM: dtsi: iwg22m: Add eMMC support

 arch/arm/boot/dts/r8a7745-iwg22m.dtsi | 26 ++
 arch/arm/boot/dts/r8a7745.dtsi| 16 
 2 files changed, 42 insertions(+)

-- 
2.7.4

Re: [PATCH v2 8/8] v4l: vsp1: Reduce display list body size

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Monday 14 Aug 2017 16:13:31 Kieran Bingham wrote:
> The display list originally allocated a body of 256 entries to store all
> of the register lists required for each frame.
> 
> This has now been separated into fragments for constant stream setup, and
> runtime updates.
> 
> Empirical testing shows that the body0 now uses a maximum of 41
> registers for each frame, for both DRM and Video API pipelines thus a
> rounded 64 entries provides a suitable allocation.

Didn't you mention in patch 7/8 that one of the fragments uses exactly 64 
entries ? Which one is it, and is there a risk it could use more ? 

> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index 176a258146ac..b3f5eb2f9a4f
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -21,7 +21,7 @@
>  #include "vsp1.h"
>  #include "vsp1_dl.h"
> 
> -#define VSP1_DL_NUM_ENTRIES  256
> +#define VSP1_DL_NUM_ENTRIES  64
> 
>  #define VSP1_DLH_INT_ENABLE  (1 << 1)
>  #define VSP1_DLH_AUTO_START  (1 << 0)

-- 
Regards,

Laurent Pinchart

[PATCH ] ARM: dts: iwg22d-sodimm: Add pinctl support for scif4

[Biju Das]

Adding pinctrl support for scif4 interface.

Signed-off-by: Biju Das 
---
This patch depends upon the below patch series
[PATCH  0/2] ARM: dts: Add iWave RZ/G1E board support
http://www.spinics.net/lists/devicetree/msg190513.html

This patch is tested against renesas-dev tag 
renesas-devel-20170815-v4.13-rc5 + above dependency patch.

 arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts 
b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
index cbc19fe..442a5cb 100644
--- a/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
+++ b/arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts
@@ -24,6 +24,16 @@
};
 };
 
+ {
+   scif4_pins: scif4 {
+   groups = "scif4_data_b";
+   function = "scif4";
+   };
+};
+
  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
status = "okay";
 };
-- 
1.9.1

[RFC PATCH v4 4/6] i2c: sh_mobile: use helper to decide if DMA is useful

[Wolfram Sang]

This ensures that we fall back to PIO if the message length is too small
for DMA being useful. Otherwise, we use DMA. A bounce buffer might be
applied by the helper if the original message buffer is not DMA safe.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-sh_mobile.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-sh_mobile.c 
b/drivers/i2c/busses/i2c-sh_mobile.c
index 2e097d97d258bc..5efdb7becd83d6 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -145,6 +145,7 @@ struct sh_mobile_i2c_data {
struct dma_chan *dma_rx;
struct scatterlist sg;
enum dma_data_direction dma_direction;
+   u8 *dma_buf;
 };
 
 struct sh_mobile_dt_config {
@@ -548,6 +549,8 @@ static void sh_mobile_i2c_dma_callback(void *data)
pd->pos = pd->msg->len;
pd->stop_after_dma = true;
 
+   i2c_release_dma_safe_msg_buf(pd->msg, pd->dma_buf);
+
iic_set_clr(pd, ICIC, 0, ICIC_TDMAE | ICIC_RDMAE);
 }
 
@@ -608,7 +611,7 @@ static void sh_mobile_i2c_xfer_dma(struct 
sh_mobile_i2c_data *pd)
if (IS_ERR(chan))
return;
 
-   dma_addr = dma_map_single(chan->device->dev, pd->msg->buf, 
pd->msg->len, dir);
+   dma_addr = dma_map_single(chan->device->dev, pd->dma_buf, pd->msg->len, 
dir);
if (dma_mapping_error(chan->device->dev, dma_addr)) {
dev_dbg(pd->dev, "dma map failed, using PIO\n");
return;
@@ -665,7 +668,8 @@ static int start_ch(struct sh_mobile_i2c_data *pd, struct 
i2c_msg *usr_msg,
pd->pos = -1;
pd->sr = 0;
 
-   if (pd->msg->len > 8)
+   pd->dma_buf = i2c_get_dma_safe_msg_buf(pd->msg, 8);
+   if (pd->dma_buf)
sh_mobile_i2c_xfer_dma(pd);
 
/* Enable all interrupts to begin with */
-- 
2.11.0

[RFC PATCH v4 5/6] i2c: rcar: skip DMA if buffer is not safe

[Wolfram Sang]

This HW is prone to races, so it needs to setup new messages in irq
context. That means we can't alloc bounce buffers if a message buffer is
not DMA safe. So, in that case, simply fall back to PIO.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/busses/i2c-rcar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 93c1a54981df08..5654a7142bffec 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -359,7 +359,7 @@ static void rcar_i2c_dma(struct rcar_i2c_priv *priv)
int len;
 
/* Do not use DMA if it's not available or for messages < 8 bytes */
-   if (IS_ERR(chan) || msg->len < 8)
+   if (IS_ERR(chan) || msg->len < 8 || !(msg->flags & I2C_M_DMA_SAFE))
return;
 
if (read) {
-- 
2.11.0

[RFC PATCH v4 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

[Wolfram Sang]

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/i2c-dev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 6f638bbc922db4..bbc7aadb4c899d 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -280,6 +280,8 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client 
*client,
res = PTR_ERR(rdwr_pa[i].buf);
break;
}
+   /* memdup_user allocates with GFP_KERNEL, so DMA is ok */
+   rdwr_pa[i].flags |= I2C_M_DMA_SAFE;
 
/*
 * If the message length is received from the slave (similar
-- 
2.11.0

[RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it

[Wolfram Sang]

So, after revisiting old mail threads, taking part in a similar discussion on
the USB list, and implementing a not-convincing solution before, here is what I
cooked up to document and ease DMA handling for I2C within Linux. Please have a
look at the documentation introduced in patch 3 for details.

While the previous versions tried to magically apply bounce buffers when
needed, it became clear that detecting DMA safe buffers is too fragile. This
approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The
outcome so far is very convincing IMO. The core additions are simple and easy
to understand (makes me even think of inlining them again?). The driver changes
for the Renesas IP cores became easier to understand, too. While only a tad for
the i2c-sh_mobile driver, the situation became a LOT better for the i2c-rcar
driver. No more DMA disabling for the whole transfer in case of unsafe buffers,
we are back to per-msg handling. And the code fix is now an easy to understand
one line change. Yay!

Of course, we must now whitelist DMA safe buffers. An example for I2C_RDWR case
is in this series. It makes the i2ctransfer utility have DMA_SAFE buffers,
which is nice for testing as i2cdump will (currently) not use DMA_SAFE buffers.
My plan is to add two new calls: i2c_master_{send|receive}_dma_safe which can
be used if DMA_SAFE buffers are provided. So, drivers can simply switch to
them. Also, the buffers used within i2c_smbus_xfer_emulated() need to be
converted to be DMA_SAFE which will cover a huge bunch of use cases. The rest
is then updating drivers which can be done when needed.

As these conversions are not done yet, this patch series has RFC status. But I
already would like to get opinions on this approach, so I'll cc mailing lists
of the heavier I2C users. Please let me know what you think.

All patches have been tested with a Renesas Salvator-X board (r8a7796/M3-W).

The branch can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
renesas/topic/i2c-core-dma-rfc-v4

And big kudos to Renesas Electronics for funding this work, thank you very much!

Regards,

   Wolfram

Changes since v3:
* completely redesigned

Wolfram Sang (6):
  i2c: add a message flag for DMA safe buffers
  i2c: add helpers to ease DMA handling
  i2c: add docs to clarify DMA handling
  i2c: sh_mobile: use helper to decide if DMA is useful
  i2c: rcar: skip DMA if buffer is not safe
  i2c: dev: mark RDWR buffers as DMA_SAFE

 Documentation/i2c/DMA-considerations | 50 
 drivers/i2c/busses/i2c-rcar.c|  2 +-
 drivers/i2c/busses/i2c-sh_mobile.c   |  8 --
 drivers/i2c/i2c-core-base.c  | 45 
 drivers/i2c/i2c-dev.c|  2 ++
 include/linux/i2c.h  |  3 +++
 include/uapi/linux/i2c.h |  3 +++
 7 files changed, 110 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/i2c/DMA-considerations

-- 
2.11.0

[RFC PATCH v4 2/6] i2c: add helpers to ease DMA handling

[Wolfram Sang]

One helper checks if DMA is suitable and optionally creates a bounce
buffer, if not. The other function returns the bounce buffer and makes
sure the data is properly copied back to the message.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/i2c-core-base.c | 45 +
 include/linux/i2c.h |  3 +++
 2 files changed, 48 insertions(+)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 12822a4b8f8f09..a104ebc2d05af8 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -2241,6 +2241,51 @@ void i2c_put_adapter(struct i2c_adapter *adap)
 }
 EXPORT_SYMBOL(i2c_put_adapter);
 
+/**
+ * i2c_get_dma_safe_msg_buf() - get a DMA safe buffer for the given i2c_msg
+ * @msg: the message to be checked
+ * @threshold: the amount of byte from which using DMA makes sense
+ *
+ * Return: NULL if a DMA safe buffer was not obtained. Use msg->buf with PIO.
+ *
+ *Or a valid pointer to be used with DMA. Note that it can either be
+ *msg->buf or a bounce buffer. After use, release it by calling
+ *i2c_release_dma_safe_msg_buf().
+ *
+ * This function must only be called from process context!
+ */
+u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold)
+{
+   if (msg->len < threshold)
+   return NULL;
+
+   if (msg->flags & I2C_M_DMA_SAFE)
+   return msg->buf;
+
+   if (msg->flags & I2C_M_RD)
+   return kzalloc(msg->len, GFP_KERNEL);
+   else
+   return kmemdup(msg->buf, msg->len, GFP_KERNEL);
+}
+EXPORT_SYMBOL_GPL(i2c_get_dma_safe_msg_buf);
+
+/**
+ * i2c_release_dma_safe_msg_buf - release DMA safe buffer and sync with i2c_msg
+ * @msg: the message to be synced with
+ * @buf: the buffer obtained from i2c_get_dma_safe_msg_buf(). May be NULL.
+ */
+void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf)
+{
+   if (!buf || buf == msg->buf)
+   return;
+
+   if (msg->flags & I2C_M_RD)
+   memcpy(msg->buf, buf, msg->len);
+
+   kfree(buf);
+}
+EXPORT_SYMBOL_GPL(i2c_release_dma_safe_msg_buf);
+
 MODULE_AUTHOR("Simon G. Vogl ");
 MODULE_DESCRIPTION("I2C-Bus main module");
 MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index d501d3956f13f0..1e99342f180f45 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -767,6 +767,9 @@ static inline u8 i2c_8bit_addr_from_msg(const struct 
i2c_msg *msg)
return (msg->addr << 1) | (msg->flags & I2C_M_RD ? 1 : 0);
 }
 
+u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold);
+void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf);
+
 int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short 
addr);
 /**
  * module_i2c_driver() - Helper macro for registering a modular I2C driver
-- 
2.11.0

[RFC PATCH v4 1/6] i2c: add a message flag for DMA safe buffers

[Wolfram Sang]

I2C has no requirement that the buffer of a message needs to be DMA
safe. In case it is, it can now be flagged, so drivers wishing to
do DMA can use the buffer directly.

Signed-off-by: Wolfram Sang 
---
 include/uapi/linux/i2c.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
index 009e27bb9abe19..1c683cb319e4b7 100644
--- a/include/uapi/linux/i2c.h
+++ b/include/uapi/linux/i2c.h
@@ -71,6 +71,9 @@ struct i2c_msg {
 #define I2C_M_RD   0x0001  /* read data, from slave to master */
/* I2C_M_RD is guaranteed to be 0x0001! 
*/
 #define I2C_M_TEN  0x0010  /* this is a ten bit chip address */
+#define I2C_M_DMA_SAFE 0x0200  /* the buffer of this message is DMA 
safe */
+   /* makes only sense in kernelspace */
+   /* userspace buffers are copied anyway 
*/
 #define I2C_M_RECV_LEN 0x0400  /* length will be first received byte */
 #define I2C_M_NO_RD_ACK0x0800  /* if 
I2C_FUNC_PROTOCOL_MANGLING */
 #define I2C_M_IGNORE_NAK   0x1000  /* if I2C_FUNC_PROTOCOL_MANGLING */
-- 
2.11.0

[RFC PATCH v4 3/6] i2c: add docs to clarify DMA handling

[Wolfram Sang]

Signed-off-by: Wolfram Sang 
---
 Documentation/i2c/DMA-considerations | 50 
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/i2c/DMA-considerations

diff --git a/Documentation/i2c/DMA-considerations 
b/Documentation/i2c/DMA-considerations
new file mode 100644
index 00..a4b4a107102452
--- /dev/null
+++ b/Documentation/i2c/DMA-considerations
@@ -0,0 +1,50 @@
+Linux I2C and DMA
+-
+
+Given that I2C is a low-speed bus where largely small messages are transferred,
+it is not considered a prime user of DMA access. At this time of writing, only
+10% of I2C bus master drivers have DMA support implemented. And the vast
+majority of transactions are so small that setting up DMA for it will likely
+add more overhead than a plain PIO transfer.
+
+Therefore, it is *not* mandatory that the buffer of an I2C message is DMA safe.
+It does not seem reasonable to apply additional burdens when the feature is so
+rarely used. However, it is recommended to use a DMA-safe buffer if your
+message size is likely applicable for DMA. Most drivers have this threshold
+around 8 bytes (as of today, this is mostly an educated guess, however). For
+any message of 16 byte or larger, it is probably a really good idea.
+
+If you use such a buffer in a i2c_msg, set the I2C_M_DMA_SAFE flag with it.
+Then, the I2C core and drivers know they can safely operate DMA on it. Note
+that setting this flag makes only sense in kernel space. User space data is
+copied into kernel space anyhow. The I2C core makes sure the destination
+buffers in kernel space are always DMA capable.
+
+FIXME: Need to implement i2c_master_{send|receive}_dma and proper buffers for 
i2c_smbus_xfer_emulated.
+
+Drivers wishing to implement DMA can use helper functions from the I2C core.
+One gives you a DMA-safe buffer for a given i2c_msg as long as a certain
+threshold is met.
+
+   dma_buf = i2c_get_dma_safe_msg_buf(msg, threshold_in_byte);
+
+If a buffer is returned, it either msg->buf for the I2C_M_DMA_SAFE case or a
+bounce buffer. But you don't need to care about that detail. If NULL is
+returned, the threshold was not met or a bounce buffer could not be allocated.
+Fall back to PIO in that case.
+
+In any case, a buffer obtained from above needs to be released. It ensures data
+is copied back to the message and a potentially used bounce buffer is freed.
+
+   i2c_release_dma_safe_msg_buf(msg, dma_buf);
+
+The bounce buffer handling from the core is generic and simple. It will always
+allocate a new bounce buffer. If you want a more sophisticated handling (e.g.
+reusing pre-allocated buffers), you are free to implement your own.
+
+Please also check the in-kernel documentation for details. The i2c-sh_mobile
+driver can be used as a reference example how to use the above helpers.
+
+Final note: If you plan to use DMA with I2C (or with anything else, actually)
+make sure you have CONFIG_DMA_API_DEBUG enabled during development. It can help
+you find various issues which can be complex to debug otherwise.
-- 
2.11.0

[PATCH ] ARM: multi_v7_defconfig: Enable BQ32000 RTC driver

[Biju Das]

The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).
To increase hardware support enable the driver in the
multi_v7_defconfig multiplatform configuration.

Signed-off-by: Biju Das <biju@bp.renesas.com>
---
This patch is tested against linux-next tag next-20170817 as well as 
renesas-dev tag renesas-devel-20170815-v4.13-rc5 .

 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 18e1f80..02dc373 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -766,6 +766,7 @@ CONFIG_RTC_DRV_MAX8997=m
 CONFIG_RTC_DRV_MAX77686=y
 CONFIG_RTC_DRV_RK808=m
 CONFIG_RTC_DRV_RS5C372=m
+CONFIG_RTC_DRV_BQ32K=y
 CONFIG_RTC_DRV_PALMAS=y
 CONFIG_RTC_DRV_ST_LPC=y
 CONFIG_RTC_DRV_TWL4030=y
-- 
1.9.1

Re: [PATCH 04/14] pinctrl: sh-pfc: r8a7796: Fix MOD_SEL register pin assignment for SSI pins group

[Geert Uytterhoeven]

Hi Kaneko-san, Kihara-san,

On Sun, Jul 23, 2017 at 6:32 PM, Yoshihiro Kaneko  wrote:
> I'm very sorry that for the long delay in my reply.

No problem. Likewise, I've been on holidays.

> 2017-07-13 18:12 GMT+09:00 Geert Uytterhoeven :
>> On Wed, Jul 12, 2017 at 6:55 PM, Yoshihiro Kaneko  
>> wrote:
>>> From: Takeshi Kihara 
>>>
>>> This patch fixes MOD_SEL1 bit20 and MOD_SEL2 bit20, bit21 pin assignment
>>> for SSI pins group.
>>>
>>> This is a correction to the incorrect implementation of MOD_SEL register
>>> pin assignment for R8A7796 SoC specification of R-Car Gen3 Hardware
>>> User's Manual Rev.0.51E or later.
>>>
>>> Fixes: f9aece7344bd ("pinctrl: sh-pfc: Initial R8A7796 PFC support")
>>> Signed-off-by: Takeshi Kihara 
>>> Signed-off-by: Yoshihiro Kaneko 
>>> ---
>>>  drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 38 
>>> ++--
>>>  1 file changed, 19 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c 
>>> b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
>>> index 4d070c2..18c9c61 100644
>>> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
>>> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
>>
>>> @@ -1277,7 +1277,7 @@ enum {
>>> PINMUX_IPSR_MSEL(IP14_3_0,  RX5_A,  
>>> SEL_SCIF5_0),
>>> PINMUX_IPSR_MSEL(IP14_3_0,  NFWP_N_A,   SEL_NDF_0),
>>> PINMUX_IPSR_MSEL(IP14_3_0,  AUDIO_CLKA_C,   
>>> SEL_ADG_A_2),
>>> -   PINMUX_IPSR_MSEL(IP14_3_0,  SSI_SCK2_A, SEL_SSI_0),
>>> +   PINMUX_IPSR_MSEL(IP14_3_0,  SSI_SCK2_A, SEL_SSI2_0),
>>
>> The SSI_SCK2_A part seems to have been removed in Rev.052E and later?
>> However, I can't find that in the errata for Rev.051E.

It's the same in Rev. 0.55 (page 6-39, second row at the top), where the cell
that used to contain SSI_SCK2_A is blank.

Kihara-san, is the datasheet correct w.r.t. this?

> Indeed, SSI_SCK2_A seems to have been removed from configuration of
> SEL_SSI2 in Rev.0.52E, but the definition of IP14[3:0] does not
> change.

Correct.

> Should I remove the entry of SSI_SCK2_A from pinmux_data[]?

Please wait for that until we have confirmation about the correctness of the
datasheet.

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH ] gpio: rcar: Add r8a7745 (RZ/G1E) support

[Geert Uytterhoeven]

On Wed, Aug 16, 2017 at 1:12 PM, Biju Das  wrote:
> Renesas RZ/G1E (R8A7745) SoC GPIO blocks are identical to the R-Car Gen2
> family. Add support for its GPIO controllers.
>
> Signed-off-by: Biju Das 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2] ARM: debug-ll: Add support for r8a7745

[Geert Uytterhoeven]

On Wed, Aug 16, 2017 at 12:20 PM, Fabrizio Castro
 wrote:
> Enable low-level debugging support for RZ/G1E (r8a7745). RZ/G1E uses
> SCIF4 for the debug console.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Chris Paterson 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 4/8] v4l: vsp1: Use reference counting for fragments

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Monday 14 Aug 2017 16:13:27 Kieran Bingham wrote:
> Extend the display list body with a reference count, allowing bodies to
> be kept as long as a reference is maintained. This provides the ability
> to keep a cached copy of bodies which will not change, so that they can
> be re-applied to multiple display lists.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> This could be squashed into the fragment update code, but it's not a
> straightforward squash as the refcounts will affect both:
>   v4l: vsp1: Provide a fragment pool
> and
>   v4l: vsp1: Convert display lists to use new fragment pool
> therefore, I have kept this separate to prevent breaking bisectability
> of the vsp-tests.

Sounds good to me.

> ---
>  drivers/media/platform/vsp1/vsp1_clu.c |  7 ++-
>  drivers/media/platform/vsp1/vsp1_dl.c  | 15 ++-
>  drivers/media/platform/vsp1/vsp1_lut.c |  7 ++-
>  3 files changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
> b/drivers/media/platform/vsp1/vsp1_clu.c index 52c523625e2f..175717018e11
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_clu.c
> +++ b/drivers/media/platform/vsp1/vsp1_clu.c
> @@ -257,8 +257,13 @@ static void clu_configure(struct vsp1_entity *entity,
>   clu->clu = NULL;
>   spin_unlock_irqrestore(>lock, flags);
> 
> - if (dlb)
> + if (dlb) {
>   vsp1_dl_list_add_fragment(dl, dlb);
> +
> + /* release our local reference */
> + vsp1_dl_fragment_put(dlb);
> + }
> +
>   break;
>   }
>  }
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index 6ffdc3549283..37feda248946
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -58,6 +59,8 @@ struct vsp1_dl_body {
>   struct list_head list;
>   struct list_head free;
> 
> + refcount_t refcnt;
> +
>   struct vsp1_dl_fragment_pool *pool;
>   struct vsp1_device *vsp1;
> 
> @@ -230,6 +233,7 @@ struct vsp1_dl_body *vsp1_dl_fragment_get(struct
> vsp1_dl_fragment_pool *pool)
>   if (!list_empty(>free)) {
>   dlb = list_first_entry(>free, struct vsp1_dl_body,
> free);
>   list_del(>free);
> + refcount_set(>refcnt, 1);
>   }
> 
>   spin_unlock_irqrestore(>lock, flags);
> @@ -244,6 +248,9 @@ void vsp1_dl_fragment_put(struct vsp1_dl_body *dlb)
>   if (!dlb)
>   return;
> 
> + if (!refcount_dec_and_test(>refcnt))
> + return;
> +
>   dlb->num_entries = 0;
> 
>   spin_lock_irqsave(>pool->lock, flags);
> @@ -428,7 +435,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32
> reg, u32 data)
>   * list, in the order in which fragments are added.
>   *
>   * Adding a fragment to a display list passes ownership of the fragment to
> the
> - * list. The caller must not touch the fragment after this call.
> + * list. The caller must not modify the fragment after this call, but can
> retain
> + * a reference to it for future use if necessary, to add to subsequent
> lists.

I think there's a bit of contradiction here, if the ownership passes to the 
list then the caller shouldn't touch it anymore. How about stating it as 
follows ?

 * The caller retains its reference to the fragment when adding it to a
 * display list, but is not allowed to add new entries to the fragment.
 * The reference must be explicitly released by a call to
 * vsp1_dl_fragment_put() when the fragment isn't needed anymore.

> the
> - * list. The caller must not touch the fragment after this call.
> + * list. The caller must not modify the fragment after this call, but can
> retain
> + * a reference to it for future use if necessary, to add to subsequent
> lists.
> + *
> + * The reference count of the body is incremented by this attachment, and
> thus
> + * the caller should release it's reference if does not want to cache the
> body.
>   *
>   * Fragments are only usable for display lists in header mode. Attempt to
>   * add a fragment to a header-less display list will return an error.
> @@ -440,6 +451,8 @@ int vsp1_dl_list_add_fragment(struct vsp1_dl_list *dl,
>   if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
>   return -EINVAL;
> 
> + refcount_inc(>refcnt);
> +
>   list_add_tail(>list, >fragments);
>   return 0;
>  }
> diff --git a/drivers/media/platform/vsp1/vsp1_lut.c
> b/drivers/media/platform/vsp1/vsp1_lut.c index 57482e057e54..388bd89ade0b
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_lut.c
> +++ b/drivers/media/platform/vsp1/vsp1_lut.c
> @@ -213,8 +213,13 @@ static void lut_configure(struct vsp1_entity *entity,
>   lut->lut = NULL;
>   

Re: [RFC PATCH 2/3] watchdog: renesas_wdt: make 'clk' a variable local to probe()

[Geert Uytterhoeven]

On Wed, Jul 26, 2017 at 11:54 PM, Wolfram Sang
 wrote:
> It is not needed outside probe() anymore.
>
> Signed-off-by: Wolfram Sang 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [RFC PATCH 1/3] watchdog: renesas_wdt: consistently use RuntimePM for clock management

[Geert Uytterhoeven]

On Wed, Jul 26, 2017 at 11:54 PM, Wolfram Sang
 wrote:
> On Renesas R-Car archs, RuntimePM does all the clock handling. So, use
> it consistently to enable/disable the clocks. Also make sure that clocks
> are really enabled around clk_get_rate(). clk_summary looks proper now:
>
> clock   enable_cnt  prepare_cnt rate ...
> Before this commit:
>
> At boot:rwdt1   1   32768 0 0
> WDT running:rwdt2   2   32768 0 0
>
> After this commit:
>
> At boot:rwdt0   1   32768 0 0
> WDT running rwdt1   1   32768 0 0
>
> Signed-off-by: Wolfram Sang 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] clk: cs2000: Add cs2000_set_saved_rate

[Geert Uytterhoeven]

Hi Stephen,

On Fri, Jul 21, 2017 at 10:16 PM, Stephen Boyd  wrote:
> On 04/20, Yoshihiro Kaneko wrote:
>> From: Gaku Inami 
>>
>> This patch adds the common function to reset the clk rate in order to
>> be able to use it in other cases.
>>
>> Signed-off-by: Gaku Inami 
>> Signed-off-by: Hiroyuki Yokoyama 
>> Signed-off-by: Yoshihiro Kaneko 
>> ---
>> This patch is based on the clk-next branch of linux-clk tree.
>
> Geert?

The CS2000 clock generator is not a Renesas part, so please take it directly.
Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 3/8] v4l: vsp1: Convert display lists to use new fragment pool

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Monday 14 Aug 2017 16:13:26 Kieran Bingham wrote:
> Adapt the dl->body0 object to use an object from the fragment pool.
> This greatly reduces the pressure on the TLB for IPMMU use cases, as
> all of the lists use a single allocation for the main body.
> 
> The CLU and LUT objects pre-allocate a pool containing two bodies,
> allowing a userspace update before the hardware has committed a previous
> set of tables.

I think you'll need three bodies, one for the DL queued to the hardware, one 
for the pending DL and one for the new DL needed when you update the LUT/CLU. 
Given that the VSP test suite hasn't caught this problem, we also need a new 
test :-)

> Fragments are no longer 'freed' in interrupt context, but instead
> released back to their respective pools.  This allows us to remove the
> garbage collector in the DLM.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> v2:
>  - Use dl->body0->max_entries to determine header offset, instead of the
>global constant VSP1_DL_NUM_ENTRIES which is incorrect.
>  - squash updates for LUT, CLU, and fragment cleanup into single patch.
>(Not fully bisectable when separated)
> ---
>  drivers/media/platform/vsp1/vsp1_clu.c |  22 ++-
>  drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
>  drivers/media/platform/vsp1/vsp1_dl.c  | 223 +-
>  drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
>  drivers/media/platform/vsp1/vsp1_lut.c |  23 ++-
>  drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
>  6 files changed, 90 insertions(+), 183 deletions(-)

This is a nice diffstat, but only if you add kerneldoc for the new functions 
introduced in patch 2/8, otherwise the overall documentation diffstat looks 
bad :-)

> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
> b/drivers/media/platform/vsp1/vsp1_clu.c index f2fb26e5ab4e..52c523625e2f
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_clu.c
> +++ b/drivers/media/platform/vsp1/vsp1_clu.c

[snip]

> @@ -288,6 +298,12 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device
> *vsp1) if (ret < 0)
>   return ERR_PTR(ret);
> 
> + /* Allocate a fragment pool */

The comment would be more useful if you explained why you need to allocate a 
pool here. Same comment for the LUT.

> + clu->pool = vsp1_dl_fragment_pool_alloc(clu->entity.vsp1, 2,
> + CLU_SIZE + 1, 0);
> + if (!clu->pool)
> + return ERR_PTR(-ENOMEM);
> +
>   /* Initialize the control handler. */
>   v4l2_ctrl_handler_init(>ctrls, 2);
>   v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);

[snip]

> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index aab9dd6ec0eb..6ffdc3549283
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c

[snip]


> @@ -379,41 +289,39 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct
> vsp1_dl_manager *dlm) INIT_LIST_HEAD(>fragments);
>   dl->dlm = dlm;
> 
> - /*
> -  * Initialize the display list body and allocate DMA memory for the 
body
> -  * and the optional header. Both are allocated together to avoid 
memory
> -  * fragmentation, with the header located right after the body in
> -  * memory.
> -  */
> - header_size = dlm->mode == VSP1_DL_MODE_HEADER
> - ? ALIGN(sizeof(struct vsp1_dl_header), 8)
> - : 0;
> -
> - ret = vsp1_dl_body_init(dlm->vsp1, >body0, VSP1_DL_NUM_ENTRIES,
> - header_size);
> - if (ret < 0) {
> - kfree(dl);
> + /* Retrieve a body from our DLM body pool */
> + dl->body0 = vsp1_dl_fragment_get(pool);
> + if (!dl->body0)
>   return NULL;
> - }
> -
>   if (dlm->mode == VSP1_DL_MODE_HEADER) {
> - size_t header_offset = VSP1_DL_NUM_ENTRIES
> -  * sizeof(*dl->body0.entries);
> + size_t header_offset = dl->body0->max_entries
> +  * sizeof(*dl->body0->entries);
> 
> - dl->header = ((void *)dl->body0.entries) + header_offset;
> - dl->dma = dl->body0.dma + header_offset;
> + dl->header = ((void *)dl->body0->entries) + header_offset;
> + dl->dma = dl->body0->dma + header_offset;
> 
>   memset(dl->header, 0, sizeof(*dl->header));
> - dl->header->lists[0].addr = dl->body0.dma;
> + dl->header->lists[0].addr = dl->body0->dma;
>   }
> 
>   return dl;
>  }
> 
> +static void vsp1_dl_list_fragments_free(struct vsp1_dl_list *dl)

This function doesn't free fragments put puts them back to the free list. I'd 
call it vsp1_dl_list_fragments_put().

> +{
> + struct vsp1_dl_body *dlb, *tmp;
> +
> + list_for_each_entry_safe(dlb, tmp, >fragments, list) {
> + list_del(>list);
> + 

Re: [PATCH v2 2/8] v4l: vsp1: Provide a fragment pool

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Monday 14 Aug 2017 16:13:25 Kieran Bingham wrote:
> Each display list allocates a body to store register values in a dma
> accessible buffer from a dma_alloc_wc() allocation. Each of these
> results in an entry in the TLB, and a large number of display list
> allocations adds pressure to this resource.
> 
> Reduce TLB pressure on the IPMMUs by allocating multiple display list
> bodies in a single allocation, and providing these to the display list
> through a 'fragment pool'. A pool can be allocated by the display list
> manager or entities which require their own body allocations.
> 
> Signed-off-by: Kieran Bingham 
> 
> ---
> v2:
>  - assign dlb->dma correctly
> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 129 +++-
>  drivers/media/platform/vsp1/vsp1_dl.h |   8 ++-
>  2 files changed, 137 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index cb4625ae13c2..aab9dd6ec0eb
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -45,6 +45,8 @@ struct vsp1_dl_entry {
>  /**
>   * struct vsp1_dl_body - Display list body
>   * @list: entry in the display list list of bodies
> + * @free: entry in the pool free body list
> + * @pool: pool to which this body belongs
>   * @vsp1: the VSP1 device
>   * @entries: array of entries
>   * @dma: DMA address of the entries
> @@ -54,6 +56,9 @@ struct vsp1_dl_entry {
>   */
>  struct vsp1_dl_body {
>   struct list_head list;
> + struct list_head free;
> +
> + struct vsp1_dl_fragment_pool *pool;
>   struct vsp1_device *vsp1;
> 
>   struct vsp1_dl_entry *entries;
> @@ -65,6 +70,30 @@ struct vsp1_dl_body {
>  };
> 
>  /**
> + * struct vsp1_dl_fragment_pool - display list body/fragment pool
> + * @dma: DMA address of the entries
> + * @size: size of the full DMA memory pool in bytes
> + * @mem: CPU memory pointer for the pool
> + * @bodies: Array of DLB structures for the pool
> + * @free: List of free DLB entries
> + * @lock: Protects the pool and free list
> + * @vsp1: the VSP1 device
> + */
> +struct vsp1_dl_fragment_pool {
> + /* DMA allocation */
> + dma_addr_t dma;
> + size_t size;
> + void *mem;
> +
> + /* Body management */
> + struct vsp1_dl_body *bodies;
> + struct list_head free;
> + spinlock_t lock;
> +
> + struct vsp1_device *vsp1;
> +};
> +
> +/**
>   * struct vsp1_dl_list - Display list
>   * @list: entry in the display list manager lists
>   * @dlm: the display list manager
> @@ -104,6 +133,7 @@ enum vsp1_dl_mode {
>   * @active: list currently being processed (loaded) by hardware
>   * @queued: list queued to the hardware (written to the DL registers)
>   * @pending: list waiting to be queued to the hardware
> + * @pool: fragment pool for the display list bodies
>   * @gc_work: fragments garbage collector work struct
>   * @gc_fragments: array of display list fragments waiting to be freed
>   */
> @@ -119,6 +149,8 @@ struct vsp1_dl_manager {
>   struct vsp1_dl_list *queued;
>   struct vsp1_dl_list *pending;
> 
> + struct vsp1_dl_fragment_pool *pool;
> +
>   struct work_struct gc_work;
>   struct list_head gc_fragments;
>  };
> @@ -128,6 +160,103 @@ struct vsp1_dl_manager {
>   */
> 
>  /*
> + * Fragment pool's reduce the pressure on the iommu TLB by allocating a
> single
> + * large area of DMA memory and allocating it as a pool of fragment bodies
> + */

Could you document non-static function using kerneldoc ? Parameters to this 
function would benefit from some documentation. I'd also like to see the 
fragment get/put functions documented, as you remove existing kerneldoc for 
the alloc/free existing functions in patch 3/8.

> +struct vsp1_dl_fragment_pool *
> +vsp1_dl_fragment_pool_alloc(struct vsp1_device *vsp1, unsigned int qty,

I think I would name this function vsp1_dl_fragment_pool_create(), as it does 
more than just allocating memory. Similarly I'd call the free function 
vsp1_dl_fragment_pool_destroy().

qty is a bit vague, I'd rename it to num_fragments.

> + unsigned int num_entries, size_t extra_size)
> +{
> + struct vsp1_dl_fragment_pool *pool;
> + size_t dlb_size;
> + unsigned int i;
> +
> + pool = kzalloc(sizeof(*pool), GFP_KERNEL);
> + if (!pool)
> + return NULL;
> +
> + pool->vsp1 = vsp1;
> +
> + dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;

extra_size is only used by vsp1_dlm_create(), to allocate extra memory for the 
display list header. We need one header per display list, not per display list 
body.

> + pool->size = dlb_size * qty;
> +
> + pool->bodies = kcalloc(qty, sizeof(*pool->bodies), GFP_KERNEL);
> + if (!pool->bodies) {
> + kfree(pool);
> + return NULL;
> + }
> +
> + pool->mem = dma_alloc_wc(vsp1->bus_master, 

[PATCH] arm64: defconfig: Enable Renesas R8A77995 SoC

[Geert Uytterhoeven]

Enable support for the Renesas R-Car D3 SoC.

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b0cc318abea8fae7..ccca96ff8a19bf89 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -50,6 +50,7 @@ CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_R8A7795=y
 CONFIG_ARCH_R8A7796=y
+CONFIG_ARCH_R8A77995=y
 CONFIG_ARCH_STRATIX10=y
 CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_SPRD=y
-- 
2.7.4

[PATCH] arm64: dts: r8a7795-es1: Drop extra zero from usb unit address

[Geert Uytterhoeven]

With W=1:

arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dtb: Warning 
(simple_bus_reg): Node /soc/usb@ee040 simple-bus unit address format error, 
expected "ee04"
arch/arm64/boot/dts/renesas/r8a7795-es1-h3ulcb.dtb: Warning 
(simple_bus_reg): Node /soc/usb@ee040 simple-bus unit address format error, 
expected "ee04"

Fixes: 291e0c4994d0813f ("arm64: dts: r8a7795: Add support for R-Car H3 ES2.0")
Fixes: 171f2ef82284f61b ("arm64: dts: r8a7795: Add USB3.0 host device nodes")
Signed-off-by: Geert Uytterhoeven 
---
The second fixes tag is for the original r8a7795.dtsi, before
r8a7795-es1.dtsi was split off.
---
 arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index aaa5e67a963ea9ff..655dd30639c55027 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -11,7 +11,7 @@
 #include "r8a7795.dtsi"
 
  {
-   xhci1: usb@ee040 {
+   xhci1: usb@ee04 {
compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci";
reg = <0 0xee04 0 0xc00>;
interrupts = ;
-- 
2.7.4

[PATCH] dt-bindings: serial: sh-sci: Add support for r8a77995 (H)SCIF

[Geert Uytterhoeven]

Document support for the (H)SCIF serial ports in the Renesas R-Car D3
(r8a77995) SoC.

No driver update is needed.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt 
b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 8d27d1a603e7bf75..4fc96946f81d6afc 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -41,6 +41,8 @@ Required properties:
 - "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART.
 - "renesas,scif-r8a7796" for R8A7796 (R-Car M3-W) SCIF compatible UART.
 - "renesas,hscif-r8a7796" for R8A7796 (R-Car M3-W) HSCIF compatible UART.
+- "renesas,scif-r8a77995" for R8A77995 (R-Car D3) SCIF compatible UART.
+- "renesas,hscif-r8a77995" for R8A77995 (R-Car D3) HSCIF compatible UART.
 - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART.
 - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART.
 - "renesas,rcar-gen1-scif" for R-Car Gen1 SCIF compatible UART,
-- 
2.7.4

[PATCH] dt-bindings: watchdog: renesas-wdt: Add support for the r8a77995 wdt

[Geert Uytterhoeven]

Document support for the Watchdog Timer (WDT) Controller in the Renesas
R-Car D3 (r8a77995) SoC.

No driver update is needed.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/watchdog/renesas-wdt.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
index 9e306afbbd49e91b..bf6d1ca58af7d198 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/renesas-wdt.txt
@@ -6,6 +6,7 @@ Required properties:
   Examples with soctypes are:
 - "renesas,r8a7795-wdt" (R-Car H3)
 - "renesas,r8a7796-wdt" (R-Car M3-W)
+- "renesas,r8a77995-wdt" (R-Car D3)
 - "renesas,r7s72100-wdt" (RZ/A1)
 
   When compatible with the generic version, nodes must list the SoC-specific
-- 
2.7.4

Re: [PATCH 0/4] arm64: dts: renesas: Add Support for R-Car D3 and Draak

[Simon Horman]

On Thu, Aug 17, 2017 at 11:47:33AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Jul 27, 2017 at 5:16 PM, Simon Horman  wrote:
> > On Thu, Jul 20, 2017 at 02:54:33PM +0200, Geert Uytterhoeven wrote:
> >> This patch series adds minimal support for the R-Car D3 SoC and the
> >> Draak development board, allowing to boot from a ramdisk using a serial
> >> console.
> >>
> >>   - The first two patches add DT sources for R-Car D3 and Draak.
> >> Due to the use of hardcoded constants, they have no further (build)
> >> dependencies (obviously there is a runtime dependency).
> >>   - The last two patches replace the hardcoded constants by symbols from
> >> DT binding headers, and thus depend on those headers.  Hence it
> >> should be postponed to v4.15.
> 
> > So I have applied the first two patches for v4.14.
> 
> Thank you!
> 
> > Please repost the remaining two after v4.13-rc6 at which time I should
> > be able to queue them up for v4.15.
> 
> You mean after v4.14-rc1? Else you still won't have them in renesas-devel.

I was thinking I could merge a stable branch in after v4.13-rc6.
But waiting for v4.14-rc1 is simpler for me.

Re: [GIT PULL] Fourth Round of Renesas ARM Based SoC Fixes for v4.13

[Simon Horman]

On Thu, Aug 17, 2017 at 11:01:05AM +0200, Arnd Bergmann wrote:
> On Thu, Aug 17, 2017 at 10:56 AM, Simon Horman
>  wrote:
> > Hi Olof, Hi Kevin, Hi Arnd,
> >
> > Please consider these fourth round of Renesas ARM based SoC fixes for v4.13.
> >
> > This pull request is based on the second round of
> > such requests, tagged as renesas-fixes2-for-v4.13,
> > which I you have already pulled.
> >
> > It is not based on the third round of fixes as they
> > are not related to arm64 DT and have a different base.
> 
> Pulled into the fixes branch, thanks!

Thanks, that was quick :)

[GIT PULL] Second Round of Renesas ARM Based SoC Defconfig Updates for v4.14

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM based SoC defconfig updates 
for v4.14.

This pull request is based on the previous round of
such requests, tagged as renesas-defconfig-for-v4.14,
which you have already pulled.


The following changes since commit 52078ca712cd933844721aaa700b3bd85234841f:

  ARM: multi_v7_defconfig: Enable DMA for Renesas serial ports (2017-07-27 
16:06:23 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-defconfig2-for-v4.14

for you to fetch changes up to 0736aad1290d61bc3668f20253e1e1997ad8b3c1:

  ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig (2017-08-09 11:03:26 
+0200)


Second Round of Renesas ARM Based SoC Defconfig Updates for v4.14

* Enable BQ32000 rtc in shmobile_defconfig

  Biju Das says "The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).  To
  increase hardware support enable the driver in the shmobile_defconfig
  multiplatform configuration."


Biju Das (1):
  ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig

 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

[PATCH] ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig

[Simon Horman]

From: Biju Das 

The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).
To increase hardware support enable the driver in the
shmobile_defconfig multiplatform configuration.

Signed-off-by: Biju Das 
Signed-off-by: Simon Horman 
---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 18886c53424a..7b4fc0143148 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -193,6 +193,7 @@ CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_BQ32K=y
 CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_RX8581=y
 CONFIG_RTC_DRV_DA9063=y
-- 
2.1.4

[ANNOUNCE] Renesas tree closed for v4.14

[Simon Horman]

Hi,

I would like to stop accepting non-bug-fix patches for v4.14 and get
the last pull requests posted by the end of this week. This is in order
for them to be sent before the release of v4.13-rc6, the deadline set by the
ARM SoC maintainers.  As patches should ideally progress from the renesas
tree into linux-next before sending pull requests there is a few days lead
time involved.

I intend to begin queueing up patches for v4.15 as new patches are ready.

Re: [PATCH 0/4] arm64: dts: renesas: Add Support for R-Car D3 and Draak

[Geert Uytterhoeven]

Hi Simon,

On Thu, Jul 27, 2017 at 5:16 PM, Simon Horman  wrote:
> On Thu, Jul 20, 2017 at 02:54:33PM +0200, Geert Uytterhoeven wrote:
>> This patch series adds minimal support for the R-Car D3 SoC and the
>> Draak development board, allowing to boot from a ramdisk using a serial
>> console.
>>
>>   - The first two patches add DT sources for R-Car D3 and Draak.
>> Due to the use of hardcoded constants, they have no further (build)
>> dependencies (obviously there is a runtime dependency).
>>   - The last two patches replace the hardcoded constants by symbols from
>> DT binding headers, and thus depend on those headers.  Hence it
>> should be postponed to v4.15.

> So I have applied the first two patches for v4.14.

Thank you!

> Please repost the remaining two after v4.13-rc6 at which time I should
> be able to queue them up for v4.15.

You mean after v4.14-rc1? Else you still won't have them in renesas-devel.

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

[git pull] pinctrl: sh-pfc: Updates for v4.14

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/sh-pfc-for-v4.14-tag1

for you to fetch changes up to 56d57391ab6720c4b7bbc0a0cbc079c7b7d653fb:

  pinctrl: sh-pfc: r8a77995: Add voltage switch operations for MMC (2017-08-16 
14:26:32 +0200)


A bit delayed due to holidays, but here they are!

pinctrl: sh-pfc: Updates for v4.14

  - Propagate errors on group config, now r8a7740-armadillo800eva.dts is
fixed,
  - Add MSIOF and USB2.0 pin groups on R-Car H3 ES2.0,
  - Add USB2.0 and USB3.0 pin groups on R-Car M3-W,
  - Add a missing MMC pin group on R-Car M2-W and RZ/G1M,
  - Add initial support for R-Car D3,
  - Small fixes and cleanups.

Thanks for pulling!

Geert Uytterhoeven (3):
  pinctrl: sh-pfc: r8a7795: Add MSIOF pins, groups and functions
  pinctrl: sh-pfc: r8a7796: Fix MSIOF3 SS2_E mux
  pinctrl: sh-pfc: r8a7791: Add missing mmc_data8_b pin group

Takeshi Kihara (30):
  pinctrl: sh-pfc: r8a7795: Fix MSIOF3_{SS1,SS2}_E pin function definitions
  pinctrl: sh-pfc: r8a7796: Fix MSIOF3_{SS1,SS2}_E pin function definitions
  pinctrl: sh-pfc: r8a7796: Fix IPSR setting for MSIOF3_SS1_E pin
  pinctrl: sh-pfc: r8a7796: Fix MOD_SEL1 bit[25:24] to 0x3 when using 
STP_ISEN_1_D
  pinctrl: sh-pfc: r8a7796: Fix MOD_SEL2 bit26 to 0x0 when using SCK5_A
  pinctrl: sh-pfc: r8a7796: Fix SCIF_CLK_{A,B} pin's MOD_SEL assignment to 
MOD_SEL1 bit10
  pinctrl: sh-pfc: r8a7796: Fix FMCLK{_C,_D} and FMIN{_C,_D} pin function 
definitions
  pinctrl: sh-pfc: r8a7796: Fix NFDATA{0..13} and NF{ALE,CLE,WE_N,RE_N} pin 
function definitions
  pinctrl: sh-pfc: r8a7796: Fix MOD_SEL register pin assignment for 
TCLK{1,2}_{A,B} pins group
  pinctrl: sh-pfc: r8a7796: Fix to delete FSCLKST pin and IPSR7 bit[15:12] 
register definitions
  pinctrl: sh-pfc: r8a7796: Fix to delete SATA_DEVSLP_B pins function 
definitions
  pinctrl: sh-pfc: r8a7796: Fix to delete MOD_SEL0 bit2 register definitions
  pinctrl: sh-pfc: r8a7796: Fix IPSR and MOD_SEL register pin assignment 
for FSO pins group
  pinctrl: sh-pfc: r8a7796: Rename CS1# pin function definitions
  pinctrl: sh-pfc: r8a7795: Fix MOD_SEL1 bit[25:24] to 0x3 when using 
STP_ISEN_1_D
  pinctrl: sh-pfc: r8a7795: Fix MOD_SEL2 bit26 to 0x0 when using SCK5_A
  pinctrl: sh-pfc: r8a7795: Fix SCIF_CLK_{A,B} pin's MOD_SEL assignment to 
MOD_SEL1 bit10
  pinctrl: sh-pfc: r8a7795: Fix FMCLK{_C,_D} and FMIN{_C,_D} pin function 
definitions
  pinctrl: sh-pfc: r8a7795: Fix NFDATA{0..13} and NF{ALE,CLE,WE_N,RE_N} pin 
function definitions
  pinctrl: sh-pfc: r8a7795: Fix MOD_SEL register pin assignment for 
TCLK{1,2}_{A,B} pins group
  pinctrl: sh-pfc: r8a7795: Fix to delete FSCLKST pin and IPSR7 bit[15:12] 
register definitions
  pinctrl: sh-pfc: r8a7795: Rename CS1# pin function definitions
  pinctrl: sh-pfc: r8a7795: Fix to reserved MOD_SEL2 bit22
  pinctrl: sh-pfc: r8a7796: Add USB2.0 host pins, groups and functions
  pinctrl: sh-pfc: r8a7796: Add USB3.0 host pins, groups and functions
  pinctrl: sh-pfc: Initial R8A77995 PFC support
  pinctrl: sh-pfc: r8a77995: Add SCIF pins, groups and functions
  pinctrl: sh-pfc: r8a77995: Add I2C pins, groups and functions
  pinctrl: sh-pfc: r8a77995: Add MMC pins, groups and functions
  pinctrl: sh-pfc: r8a77995: Add voltage switch operations for MMC

Wolfram Sang (1):
  pinctrl: sh-pfc: Propagate errors on group config

Yoshihiro Shimoda (3):
  pinctrl: sh-pfc: r8a7795: Change USB3_{OVC,PWEN} definitions
  pinctrl: sh-pfc: r8a7795: Add USB 2.0 pins, groups and functions
  pinctrl: sh-pfc: Add PORT_GP_{10,2[01]} helper macros

 .../bindings/pinctrl/renesas,pfc-pinctrl.txt   |1 +
 drivers/pinctrl/sh-pfc/Kconfig |5 +
 drivers/pinctrl/sh-pfc/Makefile|1 +
 drivers/pinctrl/sh-pfc/core.c  |6 +
 drivers/pinctrl/sh-pfc/pfc-r8a7791.c   |   15 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c   | 1082 +++-
 drivers/pinctrl/sh-pfc/pfc-r8a7796.c   |  146 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c  | 1812 
 drivers/pinctrl/sh-pfc/pinctrl.c   |9 +-
 drivers/pinctrl/sh-pfc/sh_pfc.h|   23 +-
 10 files changed, 2978 insertions(+), 122 deletions(-)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77995.c

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 

RE: [PATCH 2/2] ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig

[Biju Das]

> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 17 August 2017 10:01
> To: Biju Das 
> Cc: Rob Herring ; Mark Rutland
> ; Magnus Damm ;
> Russell King ; Chris Paterson
> ; devicet...@vger.kernel.org; linux-renesas-
> s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 2/2] ARM: shmobile: Enable BQ32000 rtc in
> shmobile_defconfig
>
> On Wed, Aug 09, 2017 at 11:04:21AM +0200, Simon Horman wrote:
> > On Tue, Aug 08, 2017 at 02:04:25PM +0100, Biju Das wrote:
> > > The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).
> > > To increase hardware support enable the driver in the
> > > shmobile_defconfig multiplatform configuration.
> > >
> > > Signed-off-by: Biju Das 
> >
> > Thanks, applied for v4.14.
>
> Please consider posting a similar patch for multi_v7_defconfig.

Thanks , I will do this.


Regards,
Biju



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

Re: [PATCH 2/2] ARM: shmobile: Enable BQ32000 rtc in shmobile_defconfig

[Simon Horman]

On Wed, Aug 09, 2017 at 11:04:21AM +0200, Simon Horman wrote:
> On Tue, Aug 08, 2017 at 02:04:25PM +0100, Biju Das wrote:
> > The iWave RZ/G1M Q7 SOM supports RTC (TI BQ32000).
> > To increase hardware support enable the driver in the
> > shmobile_defconfig multiplatform configuration.
> > 
> > Signed-off-by: Biju Das 
> 
> Thanks, applied for v4.14.

Please consider posting a similar patch for multi_v7_defconfig.

> > ---
> >  arch/arm/configs/shmobile_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/configs/shmobile_defconfig 
> > b/arch/arm/configs/shmobile_defconfig
> > index 18886c5..7b4fc01 100644
> > --- a/arch/arm/configs/shmobile_defconfig
> > +++ b/arch/arm/configs/shmobile_defconfig
> > @@ -193,6 +193,7 @@ CONFIG_LEDS_CLASS=y
> >  CONFIG_LEDS_GPIO=y
> >  CONFIG_RTC_CLASS=y
> >  CONFIG_RTC_DRV_RS5C372=y
> > +CONFIG_RTC_DRV_BQ32K=y
> >  CONFIG_RTC_DRV_S35390A=y
> >  CONFIG_RTC_DRV_RX8581=y
> >  CONFIG_RTC_DRV_DA9063=y
> > -- 
> > 1.9.1
> > 
> 

Re: [GIT PULL] Fourth Round of Renesas ARM Based SoC Fixes for v4.13

[Arnd Bergmann]

On Thu, Aug 17, 2017 at 10:56 AM, Simon Horman
 wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these fourth round of Renesas ARM based SoC fixes for v4.13.
>
> This pull request is based on the second round of
> such requests, tagged as renesas-fixes2-for-v4.13,
> which I you have already pulled.
>
> It is not based on the third round of fixes as they
> are not related to arm64 DT and have a different base.

Pulled into the fixes branch, thanks!

   Arnd

[GIT PULL] Fourth Round of Renesas ARM Based SoC Fixes for v4.13

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these fourth round of Renesas ARM based SoC fixes for v4.13.

This pull request is based on the second round of
such requests, tagged as renesas-fixes2-for-v4.13,
which I you have already pulled.

It is not based on the third round of fixes as they
are not related to arm64 DT and have a different base.


The following changes since commit 2752660a37aed65b1e00fd4563d9f152eefb8200:

  arm64: dts: renesas: ulcb: sound clock-frequency needs descending order 
(2017-07-10 10:28:07 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-fixes4-for-v4.13

for you to fetch changes up to 8cd7b51ff57c74260b20c97623b0e0d420c22be8:

  arm64: renesas: salvator-common: avoid audio_clkout naming conflict 
(2017-08-07 09:50:10 +0200)


Fourth Round of Renesas ARM Based SoC Fixes for v4.13

* Avoid audio_clkout naming conflict for salvator boards using
  Renesas R-Car Gen 3 SoCs

  Morimoto-san says "The clock name of "audio_clkout" is used by the
  Renesas sound driver.  This duplicated naming breaks its clock
  registering/unregistering.  Especially when unbind/bind it can't handle
  clkout correctly.  This patch renames "audio_clkout" to "audio-clkout" to
  avoid the naming conflict."


Kuninori Morimoto (1):
  arm64: renesas: salvator-common: avoid audio_clkout naming conflict

 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] arm64: renesas: salvator-common: avoid audio_clkout naming conflict

[Simon Horman]

From: Kuninori Morimoto 

clock name of "audio_clkout" is used by Renesas sound driver.
This duplicated naming breaks its clock registering/unregistering.
Especially, when unbind/bind it can't handle clkout correctly.
This patch renames "audio_clkout" to "audio-clkout" to avoid
naming conflict.

Fixes: 8a8f181d2cfd ("arm64: renesas: salvator-x: use CS2000 as AUDIO_CLK_B")
Signed-off-by: Kuninori Morimoto 
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index a451996f590a..f903957da504 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -45,7 +45,7 @@
stdout-path = "serial0:115200n8";
};
 
-   audio_clkout: audio_clkout {
+   audio_clkout: audio-clkout {
/*
 * This is same as <_sound 0>
 * but needed to avoid cs2000/rcar_sound probe dead-lock
-- 
2.1.4

Re: [PATCH v7] media: platform: Renesas IMR driver

[Hans Verkuil]

On 08/17/17 09:59, Hans Verkuil wrote:
> Hi Sergei,
> 
> A quick review. I'm concentrating on the mesh ioctl, since that's what sets 
> this
> driver apart.
> 
> On 08/04/2017 08:03 PM, Sergei Shtylyov wrote:
> 
> 
> 
>> Index: media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
>> ===
>> --- /dev/null
>> +++ media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
>> @@ -0,0 +1,372 @@
>> +Renesas R-Car Image Renderer (IMR) Driver
>> +=
>> +
>> +This file documents some driver-specific aspects of the IMR driver, such as
>> +the driver-specific ioctl.
> 
> Just drop the part ', such as...'.
> 
> Can you add a high-level description of the functionality here? Similar to 
> what
> you did in the bindings document.
> 
>> +
>> +The ioctl reference
>> +~~~
>> +
>> +See ``include/uapi/linux/rcar_imr.h`` for the data structures used.
>> +
>> +VIDIOC_IMR_MESH - Set mapping data
>> +^^
>> +
>> +Argument: ``struct imr_map_desc``
>> +
>> +**Description**:
>> +
>> +This ioctl sets up the mesh through which the input frames will be 
>> transformed
>> +into the output frames. The mesh can be strictly rectangular (when
>> +``IMR_MAP_MESH`` bit is set in ``imr_map_desc::type``) or arbitrary (when 
>> that
>> +bit is not set).
> 
> Wouldn't something like 'IMR_MAP_RECTANGULAR' be much more descriptive than 
> _MESH?
> There is nothing in the name _MESH to indicate that this switches the data to
> rectangles.
> 
>> +
>> +A rectangular mesh consists of the imr_mesh structure followed by M*N vertex
>> +objects (where M is ``imr_mesh::rows`` and N is ``imr_mesh::columns``).
>> +In case either ``IMR_MAP_AUTOSG`` or ``IMR_MAP_AUTODG`` (not both) bits are
>> +set in ``imr_map_desc::type``, ``imr_mesh::{x|y}0`` specify the coordinates
>> +of the top left corner of the auto-generated mesh and ``imr_mesh::d{x|y}``
>> +specify the mesh's X/Y steps.
> 
> So if the auto bits are set, then there are no vertex objects? Since it's auto
> generated by the hardware?
> 
> I believe we discussed in the past whether 'type' should be split in a 'type'
> and 'flags' field.
> 
>> +
>> +An arbitrary mesh consists of the imr_vbo structure followed by N triangle
>> +objects (where N is ``imr_vbo::num``), consisting of 3 vertex objects each.
>> +Setting ``IMR_MAP_AUTODG`` and ``IMR_MAP_AUTOSG`` bits in
>> +``imr_map_desc::type``) isn't allowed for this type of mesh.
>> +
>> +The vertex object has a complex structure depending on some of the bits in
>> +``imr_map_desc::type``:
>> +
>> +    ==  ==  
>> ===
>> +IMR_MAP_CLCE  IMR_MAP_LUCE  IMR_MAP_AUTODG  IMR_MAP_AUTOSG  Vertex 
>> structure variant
> 
> You should explain the meaning of these bits in this section. I.e., what does
> CLCE or AUTODG stand for?
> 
>> +    ==  ==  
>> ===
>> +\   
>> ``imr_full_coord``
>> +\   X   
>> ``imr_dst_coord``
>> +\   X   
>> ``imr_src_coord``
>> +\ X 
>> ``imr_full_coord_any_correct``
>> +\ X X   
>> ``imr_auto_coord_any_correct``
>> +\ X X   
>> ``imr_auto_coord_any_crrect``
> 
> crrect -> correct
> 
>> +X   
>> ``imr_full_coord_any_correct``
>> +X   X   
>> ``imr_auto_coord_any_correct``
>> +X   X   
>> ``imr_auto_coord_any_correct``
>> +X X 
>> ``imr_full_coord_both_correct``
>> +X X X   
>> ``imr_auto_coord_both_correct``
>> +X X X   
>> ``imr_auto_coord_both_correct``
>> +    ==  ==  
>> ===
>> +
>> +The luma correction is calculated according to the following formula (where
>> +``Y`` is the luma value after texture mapping, ``Y'`` is the luma value 
>> after
>> +luma correction, ``lscal`` and ``lofst`` are the luma correction scale and
>> +offset taken from ``struct imr_luma_correct``, ``YLDPO`` is a luma 
>> correction
>> +scale decimal point position specified by ``IMR_MAP_YLDPO(n)``): ::
>> +
>> +Y' = ((Y * lscal) >> YLDPO) + lofst
>> +
>> +The chroma correction is calculated according to the following formula 
>> (where
>> +``U/V`` are the chroma values after texture mapping, ``U'/V'`` are the 
>> chroma
>> +values after chroma correction, ``ubscl/vrscl`` and 

Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

[Simon Horman]

On Mon, Aug 14, 2017 at 05:46:54PM +0200, Wolfram Sang wrote:
> Hi Simon,
> 
> On Mon, Aug 14, 2017 at 07:10:23AM +0200, Simon Horman wrote:
> > On Tue, Aug 08, 2017 at 08:54:45PM +0200, Wolfram Sang wrote:
> > > 
> > > > As it is an "RFT" I'm happy to apply it if you repost
> > > > it or otherwise indicate that is what you would like to happen.
> > > 
> > > As discussed in a chat, I tried SDR104 with my SDIO WiFi cards:
> > > 
> > > H3:
> > > - one slot worked flawlessly
> > > - one slot could load FW but failed to read status
> > > (with SDR50: both slots work)
> > > 
> > > M3-W:
> > > - both slots could not load the firmware
> > > (with SDR50: one slot works, one fails to load FW)
> > > 
> > > The cards, however, were correctly identified as SDR104 and there were
> > > no tuning errors and no other SDHI related warnings.
> > > 
> > > Changing TDSEL in the PFC did not change anything.
> > > 
> > > The manual of the WiFi card (u-blox EMMY-W1) mentions a maximum line
> > > length of 100mm. Measuring a direct line from the SoC to the slots,
> > > I'd think we are very much on the edge of that. And given the length
> > > of the SDIO adapter, we are surely exceeding that :(
> > > 
> > > Maybe we should do more tests with more boards? On the other hand, it
> > > seems the WiFi card is running out of the specs.
> > > 
> > > So much for now. I'll sleep over it and try to get more data tomorrow.
> > 
> > Thanks. Unfortunately my H3 is out of arms length but I can arrange
> > some testing if it is helpful.
> 
> Do you have UHS-SDIO cards? Otherwise, some more testing in Spain will
> be good.

I am unable to locate my SDIO card :(

> > Is one possibility to enable it for the slots listed above that are now
> > thought to work but not for the other one?
> 
> I don't think so. We'd need more test coverage. My gut feeling is that
> it varies from board to board. Or more precisely: from environment
> around the board to environment around the board. I'd like to test a)
> more boards) and b) a resoldered WLAN card to skip the extra cabling
> there. I still think the wire length of ~23cm (exceeding the spec of max
> 10cm) is a factor here, so resoldering would save ~6cm. That all sounds
> to me like a hacking sprint for our next meeting.
> 
> Maybe ULCB has less line lengths? Would be interesting to check, too.
> 
> I could also try to apply more shielding here at home, too.

More testing is fine by me.

> > The SDR50 failure on M3-W seems particularly troubling as that
> > has been enabled in upstream for a while, right?
> 
> Not nice, yes. Yet, until this thread, there have been no issues
> reported. So, it doesn't look like a substantial fault to me (famous
> last words?)

More testing need here too :)

Re: [PATCH 0/3] Add SMP support

[Simon Horman]

On Fri, Aug 11, 2017 at 09:37:45AM +, Biju Das wrote:
> Hello,
> 
> 
> > -Original Message-
> > From: Biju Das
> > Sent: 10 August 2017 12:19
> > To: 'Simon Horman' 
> > Cc: 'Rob Herring' ; 'Mark Rutland'
> > ; 'Magnus Damm' ;
> > 'Russell King' ; Chris Paterson
> > ; 'devicet...@vger.kernel.org'
> > ; 'linux-renesas-soc@vger.kernel.org'  > renesas-...@vger.kernel.org>; 'linux-arm-ker...@lists.infradead.org'  > arm-ker...@lists.infradead.org>
> > Subject: RE: [PATCH 0/3] Add SMP support
> >
> >
> >
> > > -Original Message-
> > > From: Biju Das
> > > Sent: 10 August 2017 10:17
> > > To: 'Simon Horman' 
> > > Cc: Rob Herring ; Mark Rutland
> > > ; Magnus Damm ;
> > Russell
> > > King ; Chris Paterson
> > > ; devicet...@vger.kernel.org;
> > > linux-renesas- s...@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org
> > > Subject: RE: [PATCH 0/3] Add SMP support
> > >
> > >
> > > > -Original Message-
> > > > From: Simon Horman [mailto:ho...@verge.net.au]
> > > > Sent: 09 August 2017 09:36
> > > > To: Biju Das 
> > > > Cc: Rob Herring ; Mark Rutland
> > > > ; Magnus Damm ;
> > > Russell
> > > > King ; Chris Paterson
> > > > ; devicet...@vger.kernel.org;
> > > > linux-renesas- s...@vger.kernel.org;
> > > > linux-arm-ker...@lists.infradead.org
> > > > Subject: Re: [PATCH 0/3] Add SMP support
> > > >
> > > > On Tue, Aug 08, 2017 at 11:56:30AM +0100, Biju Das wrote:
> > > > > This series aims to add SMP support for r8a7743 SoC.
> > > > >
> > > > > This series has been tested against Linux-next tag 20170727 and
> > > > > renesas-dev branch.
> > > >
> > > > It seems that these patches are targeted at the renesas tree.
> > > > The best practice in that case is to base patches on the latest devel 
> > > > branch.
> > > > Please consider doing so in future.
> > > >
> > > > The patches themselves seem good to me, however, I would like to
> > > > enquire about testing. In particular, have you tested CPU hotplug
> > > > and suspend to RAM with these patches (and without in the case of the
> > latter)?
> > >
> > > I have tested CPU hotplug with this patch and it works ok.
> > >
> > > Currently iWave platform doesn't support STR I guess. But we should
> > > check the changes on other M2 platforms to prove that things don't break.
> 
> I have tested STR on iWave RZ-G1M platform as well. I  used ttySC0 as wake up
> Source(echo enabled > /sys/class/tty/ttySC0/power/wakeup)
> 
> It works fine with and without the patch .
> 
> It is tested against renesas-developer branch tag 20170809-v4.13-rc4.
> 
> > I have tested STR on RZ-G1M SK(r8a7743) platform using gpio-key as wake up
> > source.
> > It works fine with and without the patch . It is tested against 
> > renesas-developer
> > branch.
> >
> > Also I have tested STR on R-Car M2 board.it works fine with gpio-key as wake
> > up source.
> >
> > > [>]
> > > > I am cautious about any regressions that may creep in when going
> > > > from UP to SMP.

Thanks for testing, I have applied this series.

Re: [PATCH repost 0/2] ARM: shmobile: document iWave's iW-RainboW-G22D-SODIMM RZ/G1E SODIMM development platform

[Simon Horman]

On Thu, Aug 10, 2017 at 10:11:48AM +0200, Simon Horman wrote:
> On Wed, Aug 09, 2017 at 12:27:38PM +0100, Fabrizio Castro wrote:
> > Hello,
> > 
> > This series aims to add the documentation for the device tree bindings
> > of the iWave iW-RainboW-G22D-SODIMM RZ/G1E SODIMM development kit:
> > http://www.iwavesystems.com/product/development-platform/sodimm-evaluation-boards/rz-g1e-sodimm-development-kit-28/rz-g1e-sodimm-development-kit.html
> > 
> > which consists of a System on Module (iW-RainboW-G22M-SM) and a carrier
> > card (iW-RainboW-G22D).
> 
> Hi Fabrizio,
> 
> Thanks for reposting with myself and linux-renesas-soc CCed.
> 
> As is the common practice for DT binding updates I will wait to see if Rob
> or others wish to Ack this change before applying it.  Please ping me, f.e.
> by a reply-to-all to this email, in one week if there has been no further
> activity.

I have applied these for v4.14.

[git pull] clk: renesas: Updates for v4.14

[Geert Uytterhoeven]

Hi Mike, Stephen,

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/clk-renesas-for-v4.14-tag1

for you to fetch changes up to c29f82951b974f27e0bc4ce2525db164f86f2e4d:

  clk: renesas: r8a7796: Add USB3.0 clock (2017-08-17 09:22:26 +0200)


A bit delayed due to holidays, but here they are!

clk: renesas: Updates for v4.14

  - Add more module clocks for R-Car V2H and M3-W,
  - Add support for the R-Car Gen3 USB 2.0 clock selector PHY,
  - Add support for the new R-Car D3 SoC,
  - Allow compile-testing of all (sub)drivers now all dummy infrastructure
is available,
  - Small fixes and cleanups.

Thanks for pulling!

Geert Uytterhoeven (7):
  clk: renesas: div6: Document fields used for parent selection
  clk: renesas: r8a7792: Add IMR-LX3/LSX3 clocks
  clk: renesas: Allow compile-testing of all (sub)drivers
  clk: renesas: Add r8a77995 CPG Core Clock Definitions
  clk: renesas: rcar-gen3: Add divider support for PLL1 and PLL3
  clk: renesas: rcar-gen3: Add support for SCCG/Clean peripheral clocks
  clk: renesas: cpg-mssr: Add R8A77995 support

Hiromitsu Yamasaki (1):
  clk: renesas: r8a7796: Add USB3.0 clock

Wolfram Sang (2):
  clk: renesas: rcar-gen3-cpg: Drop superfluous variable
  clk: renesas: rcar-gen3-cpg: Refactor checks for accessing the div table

Yoshihiro Shimoda (1):
  clk: renesas: rcar-usb2-clock-sel: Add R-Car USB 2.0 clock selector PHY

 .../devicetree/bindings/clock/renesas,cpg-mssr.txt |   3 +-
 .../bindings/clock/renesas,rcar-usb2-clock-sel.txt |  55 +
 drivers/clk/renesas/Kconfig|  48 +++--
 drivers/clk/renesas/Makefile   |   2 +
 drivers/clk/renesas/clk-div6.c |   3 +
 drivers/clk/renesas/r8a7792-cpg-mssr.c |   7 +
 drivers/clk/renesas/r8a7795-cpg-mssr.c |  34 +--
 drivers/clk/renesas/r8a7796-cpg-mssr.c |  35 +--
 drivers/clk/renesas/r8a77995-cpg-mssr.c| 236 +
 drivers/clk/renesas/rcar-gen3-cpg.c|  69 +++---
 drivers/clk/renesas/rcar-gen3-cpg.h|  15 +-
 drivers/clk/renesas/rcar-usb2-clock-sel.c  | 188 
 drivers/clk/renesas/renesas-cpg-mssr.c |   6 +
 drivers/clk/renesas/renesas-cpg-mssr.h |   1 +
 include/dt-bindings/clock/r8a77995-cpg-mssr.h  |  57 +
 15 files changed, 674 insertions(+), 85 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt
 create mode 100644 drivers/clk/renesas/r8a77995-cpg-mssr.c
 create mode 100644 drivers/clk/renesas/rcar-usb2-clock-sel.c
 create mode 100644 include/dt-bindings/clock/r8a77995-cpg-mssr.h

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] arm64: dts: renesas: r8a77995: add pfc device node

[Simon Horman]

On Thu, Aug 10, 2017 at 10:13:19AM +0200, Simon Horman wrote:
> On Wed, Aug 09, 2017 at 09:20:47PM +0900, Yoshihiro Shimoda wrote:
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> > 
> >  This patch set is based on the renesas-drivers.git /
> > topic/r8a77995-integration branch and depends on the following patch
> >  "pinctrl: sh-pfc: r8a77995: Initial R8A77995 PFC support"
> 
> Thanks Shimoda-san,
> 
> this patch looks fine to me, however, I am marking it as deferred pending
> acceptance of the dependency listed above. Please repost or otherwise
> ping me once Geert has indicated he will accept that patch.

That dependency appears to be satisfied now,
I have applied this patch.

Re: [PATCH 0/2] arm64: dts: r8a7796: add USB-DMAC and HSUSB device nodes

[Simon Horman]

On Fri, Aug 04, 2017 at 01:00:27PM +0200, Simon Horman wrote:
> On Thu, Aug 03, 2017 at 09:29:15PM +0900, Yoshihiro Shimoda wrote:
> > This patch is based on the renesas.git / renesas-devel-20170731v2-v4.13-rc3 
> > tag.
> > 
> > For usb-dmac, we should wait for the following patch (even if we don't apply
> > the patch, the usb-dmac driver can be probed correctly though.)
> >  https://patchwork.kernel.org/patch/9876639/
> > 
> > For hsusb, we need the "arm64: dts: r8a7796: add usb host device nodes" 
> > patch
> > set for using usb2_phy0.
> 
> Thanks, I am marking this series as deferred pending acceptance of
> the dependencies of "arm64: dts: r8a7796: add usb host device nodes".
> Please repost this series or otherwise ping me once those
> dependencies are in place.

The dependency is now in place and I have applied this series.

Re: [PATCH 3/3] arm64: dts: r8a7795: Add USB3.0 host device node

[Simon Horman]

On Thu, Aug 03, 2017 at 09:28:44PM +0900, Yoshihiro Shimoda wrote:
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

I applied this as "arm64: dts: r8a7796: Add USB3.0 host device node"
Note the '6'.

Also, I know I am guilty of this too, but please consider including a
body in the changelog for future patches.

Re: Status of r8a7795 SDHI support?

[Dirk Behme]

On 17.08.2017 09:29, Wolfram Sang wrote:



What's the status of SDHI support in mainline and/or renesas-drivers
(renesas-drivers-2017-08-16-v4.13-rc5)?


I use it daily here, even with SDR104 enabled.



On ES2.0? I wonder how if not even the pinmux is there ;)



sdhci-pltfm: SDHCI platform and OF driver helper


Wrong driver? We have SDHI not SDHCI.



Changing the config a little I have

--cut --
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_PWRSEQ_EMMC is not set
# CONFIG_PWRSEQ_SIMPLE is not set
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MMC_SPI is not set
CONFIG_MMC_TMIO_CORE=y
CONFIG_MMC_SDHI=y
CONFIG_MMC_SDHI_SYS_DMAC=y
CONFIG_MMC_SDHI_INTERNAL_DMAC=y
-- cut --

now.

As SDHCI is disabled, now, I don't get anything SD/MMC related in the 
boot log any more. Not even an error message. Hmm ...


The device tree has [1].

Best regards

Dirk

[1]

 {
pinctrl-0 = <_pins>;
pinctrl-1 = <_pins_uhs>;
pinctrl-names = "default";

vmmc-supply = <_3p3v>;
non-removable; /* Workaround due to CD on CPLD */
bus-width = <4>;
no-1-8-v;
status = "okay";
};

 {
/* used for on-board 8bit eMMC */
pinctrl-0 = <_pins>;
pinctrl-1 = <_pins_uhs>;
pinctrl-names = "default", "state_uhs";

vmmc-supply = <_3p3v>;
vqmmc-supply = <_1p8v>;
mmc-hs400-1_8v;
bus-width = <8>;
non-removable;
status = "okay";
};

Re: [PATCH 0/3] arm64: dts: r8a7796: add usb host device nodes

[Simon Horman]

On Fri, Aug 04, 2017 at 12:59:19PM +0200, Simon Horman wrote:
> On Thu, Aug 03, 2017 at 09:28:41PM +0900, Yoshihiro Shimoda wrote:
> > This patch is based on the renesas.git / renesas-devel-20170731v2-v4.13-rc3 
> > tag.
> > 
> > For usb2.0 host, we need the following patch:
> >  https://patchwork.kernel.org/patch/9864583/
> > 
> > For usb3.0 host, we need the following patch:
> >  https://patchwork.kernel.org/patch/9864579/
> 
> Thanks, I am marking this series as deferred pending acceptance of the
> above patches. Please repost this series or otherwise ping me once the
> dependencies are in place.

It looks like Geert has accepted the patches above,
accordingly I have applied this series.

Re: [PATCH v2 1/8] v4l: vsp1: Protect fragments against overflow

[Kieran Bingham]

Hi Laurent,

Thanks for your review,

On 16/08/17 22:53, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.

> How about
> 
>   if (WARN_ONCE(dlb->num_entries >= dlb->max_entries,
> "DLB size exceeded (max %u)", dlb->max_entries))
>   return;
> 
> (WARN_ONCE contains the unlikely() already)
> 
> I'm not fussed either way,

That does seem cleaner. Updated ready for any repost.

Thanks
--
Kieran

Re: [PATCH] dt-bindings: mmc: sh_mmcif: Document r8a7745 DT bindings

[Simon Horman]

On Tue, Aug 15, 2017 at 05:53:27PM +0100, Fabrizio Castro wrote:
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Chris Paterson 

Acked-by: Simon Horman 

> ---
>  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt 
> b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> index 703e18c..5ff1e12 100644
> --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> @@ -12,6 +12,7 @@ Required properties:
>   - "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs
>   - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
>   - "renesas,mmcif-r8a7743" for the MMCIF found in r8a7743 SoCs
> + - "renesas,mmcif-r8a7745" for the MMCIF found in r8a7745 SoCs
>   - "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs
>   - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
>   - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
> @@ -22,7 +23,7 @@ Required properties:
>  - interrupts: Some SoCs have only 1 shared interrupt, while others have 
> either
>2 or 3 individual interrupts (error, int, card detect). Below is the number
>of interrupts for each SoC:
> -1: r8a73a4, r8a7743, r8a7778, r8a7790, r8a7791, r8a7793, r8a7794
> +1: r8a73a4, r8a7743, r8a7745, r8a7778, r8a7790, r8a7791, r8a7793, r8a7794
>  2: r8a7740, sh73a0
>  3: r7s72100
>  
> -- 
> 2.7.4
> 

Re: [PATCH 3/4] arm: dts: renesas: add cec clock for Koelsch board

[Simon Horman]

On Mon, Aug 14, 2017 at 05:34:41PM +0200, Geert Uytterhoeven wrote:
> On Sun, Jul 30, 2017 at 3:07 PM, Hans Verkuil  wrote:
> > From: Hans Verkuil 
> 
> Probably the one-line summary should be
> 
> ARM: dts: koelsch: Add CEC clock  for HDMI transmitter
> 
> > The adv7511 on the Koelsch board has a 12 MHz fixed clock
> > for the CEC block. Specify this in the dts to enable CEC support.
> >
> > Signed-off-by: Hans Verkuil 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, I have applied this patch with the updated one-line summary.

Re: [PATCH ] gpio: rcar: Add r8a7745 (RZ/G1E) support

[Simon Horman]

On Wed, Aug 16, 2017 at 12:12:16PM +0100, Biju Das wrote:
> Renesas RZ/G1E (R8A7745) SoC GPIO blocks are identical to the R-Car Gen2
> family. Add support for its GPIO controllers.
> 
> Signed-off-by: Biju Das 

Acked-by: Simon Horman 

> ---
> This patch is tested against linux-next tag next-20170816 as well as 
> gpio-devel.
> 
>  Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt 
> b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> index 48634b0..51c86f6 100644
> --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> @@ -4,6 +4,7 @@ Required Properties:
>  
>- compatible: should contain one or more of the following:
>  - "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO 
> controller.
> +- "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO 
> controller.
>  - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO 
> controller.
>  - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO 
> controller.
>  - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO 
> controller.
> -- 
> 1.9.1
> 

Re: [PATCH v7] media: platform: Renesas IMR driver

[Hans Verkuil]

Hi Sergei,

A quick review. I'm concentrating on the mesh ioctl, since that's what sets this
driver apart.

On 08/04/2017 08:03 PM, Sergei Shtylyov wrote:



> Index: media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
> ===
> --- /dev/null
> +++ media_tree/Documentation/media/v4l-drivers/rcar_imr.rst
> @@ -0,0 +1,372 @@
> +Renesas R-Car Image Renderer (IMR) Driver
> +=
> +
> +This file documents some driver-specific aspects of the IMR driver, such as
> +the driver-specific ioctl.

Just drop the part ', such as...'.

Can you add a high-level description of the functionality here? Similar to what
you did in the bindings document.

> +
> +The ioctl reference
> +~~~
> +
> +See ``include/uapi/linux/rcar_imr.h`` for the data structures used.
> +
> +VIDIOC_IMR_MESH - Set mapping data
> +^^
> +
> +Argument: ``struct imr_map_desc``
> +
> +**Description**:
> +
> +This ioctl sets up the mesh through which the input frames will be 
> transformed
> +into the output frames. The mesh can be strictly rectangular (when
> +``IMR_MAP_MESH`` bit is set in ``imr_map_desc::type``) or arbitrary (when 
> that
> +bit is not set).

Wouldn't something like 'IMR_MAP_RECTANGULAR' be much more descriptive than 
_MESH?
There is nothing in the name _MESH to indicate that this switches the data to
rectangles.

> +
> +A rectangular mesh consists of the imr_mesh structure followed by M*N vertex
> +objects (where M is ``imr_mesh::rows`` and N is ``imr_mesh::columns``).
> +In case either ``IMR_MAP_AUTOSG`` or ``IMR_MAP_AUTODG`` (not both) bits are
> +set in ``imr_map_desc::type``, ``imr_mesh::{x|y}0`` specify the coordinates
> +of the top left corner of the auto-generated mesh and ``imr_mesh::d{x|y}``
> +specify the mesh's X/Y steps.

So if the auto bits are set, then there are no vertex objects? Since it's auto
generated by the hardware?

I believe we discussed in the past whether 'type' should be split in a 'type'
and 'flags' field.

> +
> +An arbitrary mesh consists of the imr_vbo structure followed by N triangle
> +objects (where N is ``imr_vbo::num``), consisting of 3 vertex objects each.
> +Setting ``IMR_MAP_AUTODG`` and ``IMR_MAP_AUTOSG`` bits in
> +``imr_map_desc::type``) isn't allowed for this type of mesh.
> +
> +The vertex object has a complex structure depending on some of the bits in
> +``imr_map_desc::type``:
> +
> +    ==  ==  
> ===
> +IMR_MAP_CLCE  IMR_MAP_LUCE  IMR_MAP_AUTODG  IMR_MAP_AUTOSG  Vertex structure 
> variant

You should explain the meaning of these bits in this section. I.e., what does
CLCE or AUTODG stand for?

> +    ==  ==  
> ===
> +\   
> ``imr_full_coord``
> +\   X   ``imr_dst_coord``
> +\   X   ``imr_src_coord``
> +\ X 
> ``imr_full_coord_any_correct``
> +\ X X   
> ``imr_auto_coord_any_correct``
> +\ X X   
> ``imr_auto_coord_any_crrect``

crrect -> correct

> +X   
> ``imr_full_coord_any_correct``
> +X   X   
> ``imr_auto_coord_any_correct``
> +X   X   
> ``imr_auto_coord_any_correct``
> +X X 
> ``imr_full_coord_both_correct``
> +X X X   
> ``imr_auto_coord_both_correct``
> +X X X   
> ``imr_auto_coord_both_correct``
> +    ==  ==  
> ===
> +
> +The luma correction is calculated according to the following formula (where
> +``Y`` is the luma value after texture mapping, ``Y'`` is the luma value after
> +luma correction, ``lscal`` and ``lofst`` are the luma correction scale and
> +offset taken from ``struct imr_luma_correct``, ``YLDPO`` is a luma correction
> +scale decimal point position specified by ``IMR_MAP_YLDPO(n)``): ::
> +
> + Y' = ((Y * lscal) >> YLDPO) + lofst
> +
> +The chroma correction is calculated according to the following formula (where
> +``U/V`` are the chroma values after texture mapping, ``U'/V'`` are the chroma
> +values after chroma correction, ``ubscl/vrscl`` and ``ubofs/vrofs`` are the
> +U/V value chroma correction scales and offsets taken from
> +``struct imr_chroma_correct``, ``UBDPO/VRDPO`` are the chroma correction 
> scale
> +decimal point positions specified by 

Re: [PATCH 1/3] ARM: dts: r8a7745: add PFC support

[Simon Horman]

On Wed, Aug 16, 2017 at 02:00:37PM +0300, Sergei Shtylyov wrote:
> On 08/15/2017 07:00 PM, Simon Horman wrote:
> 
> >Define the generic R8A7745 part of the PFC device node.
> >
> >Signed-off-by: Sergei Shtylyov 
> 
> Reviewed-by: Geert Uytterhoeven 
> >>>
> >>>It looks like the dependencies for this patch are met now [1].
> >>>
> >>>Are you happy to accept this patch? (and presumably the others in the 
> >>>series for the sk-rzg1e board).
> >>>
> >>>We plan to add GPIO support for r8a7745, but need this patch in place 
> >>>first.
> >>>
> >>>
> >>>[1] https://patchwork.kernel.org/patch/9705249/
> >>
> >>Actually, R8A774x PFC support has hit the Linus' tree in the meanwhile.
> >>Simon, please merge the .dts patches.
> >>
> >>>Kind regards, Chris
> >
> >Thanks, I have applied the series for v4.14.
> 
>Are you going to finally push the devel branch? I'm not seeing changes
> since the Monday tags.

Sorry, about the delay.
I have (finally) pushed Tuesday's tags.

Re: Status of r8a7795 SDHI support?

[Dirk Behme]

On 17.08.2017 09:48, Geert Uytterhoeven wrote:

Hi Dirk,

On Thu, Aug 17, 2017 at 9:44 AM, Dirk Behme  wrote:

On 17.08.2017 09:33, Geert Uytterhoeven wrote:

On Thu, Aug 17, 2017 at 9:23 AM, Dirk Behme 
wrote:

since ages I tried recent mainline (v4.13-rc5) on a custom r8a7795 board.


R-Car H3 ES1.x or ES2.0?


ES2.0


I tried with the attachment and picked some patches from
renesas-drivers-2017-08-16-v4.13-rc5 [1] but it doesn't look like any SD
card / eMMC is detected at all [2].


That patch is for ES2.0. There are indeed no SDHI pins in the upstream
pinctrl
driver for ES2.0 yet.


So its fine to send the attached patch for integration?


Yes, iff it works. But you claim it doesn't?



Well, at least it removes the error messages regarding pinctrl [1]. Yes, 
as mentioned, if in the end SD / eMMC work I can't say, yet.



Best regards

Dirk


[1]

sh-pfc e606.pin-controller: function 'sdhi0' not supported
sh-pfc e606.pin-controller: invalid function sdhi0 in map table
sh-pfc e606.pin-controller: does not have pin group sdhi0_data4
sh-pfc e606.pin-controller: could not map group config for "sdhi0_data4"
sh-pfc e606.pin-controller: function 'sdhi0' not supported
sh-pfc e606.pin-controller: invalid function sdhi0 in map table
sh-pfc e606.pin-controller: does not have pin group sdhi0_ctrl
sh-pfc e606.pin-controller: could not map group config for "sdhi0_ctrl"
sh-pfc e606.pin-controller: function 'sdhi0' not supported
sh-pfc e606.pin-controller: invalid function sdhi0 in map table
sh-pfc e606.pin-controller: does not have pin group sdhi0_data4
sh-pfc e606.pin-controller: could not map group config for "sdhi0_data4"
sh-pfc e606.pin-controller: function 'sdhi0' not supported
sh-pfc e606.pin-controller: invalid function sdhi0 in map table
sh-pfc e606.pin-controller: does not have pin group sdhi0_ctrl
sh-pfc e606.pin-controller: could not map group config for "sdhi0_ctrl"
sh_mobile_sdhi: probe of ee10.sd failed with error -22

Re: Status of r8a7795 SDHI support?

[Geert Uytterhoeven]

Hi Dirk,

On Thu, Aug 17, 2017 at 9:44 AM, Dirk Behme  wrote:
> On 17.08.2017 09:33, Geert Uytterhoeven wrote:
>> On Thu, Aug 17, 2017 at 9:23 AM, Dirk Behme 
>> wrote:
>>> since ages I tried recent mainline (v4.13-rc5) on a custom r8a7795 board.
>>
>> R-Car H3 ES1.x or ES2.0?
>
> ES2.0
>
>>> I tried with the attachment and picked some patches from
>>> renesas-drivers-2017-08-16-v4.13-rc5 [1] but it doesn't look like any SD
>>> card / eMMC is detected at all [2].
>>
>> That patch is for ES2.0. There are indeed no SDHI pins in the upstream
>> pinctrl
>> driver for ES2.0 yet.
>
> So its fine to send the attached patch for integration?

Yes, iff it works. But you claim it doesn't?

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: Status of r8a7795 SDHI support?

[Dirk Behme]

On 17.08.2017 09:33, Geert Uytterhoeven wrote:

Hi Dirk,

On Thu, Aug 17, 2017 at 9:23 AM, Dirk Behme  wrote:

since ages I tried recent mainline (v4.13-rc5) on a custom r8a7795 board.


R-Car H3 ES1.x or ES2.0?



ES2.0



I tried with the attachment and picked some patches from
renesas-drivers-2017-08-16-v4.13-rc5 [1] but it doesn't look like any SD
card / eMMC is detected at all [2].


That patch is for ES2.0. There are indeed no SDHI pins in the upstream pinctrl
driver for ES2.0 yet.



So its fine to send the attached patch for integration?


Best regards

Dirk

Re: Status of r8a7795 SDHI support?

[Geert Uytterhoeven]

Hi Dirk,

On Thu, Aug 17, 2017 at 9:23 AM, Dirk Behme  wrote:
> since ages I tried recent mainline (v4.13-rc5) on a custom r8a7795 board.

R-Car H3 ES1.x or ES2.0?

> I tried with the attachment and picked some patches from
> renesas-drivers-2017-08-16-v4.13-rc5 [1] but it doesn't look like any SD
> card / eMMC is detected at all [2].

That patch is for ES2.0. There are indeed no SDHI pins in the upstream pinctrl
driver for ES2.0 yet.

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: Status of r8a7795 SDHI support?

[Wolfram Sang]

> What's the status of SDHI support in mainline and/or renesas-drivers
> (renesas-drivers-2017-08-16-v4.13-rc5)?

I use it daily here, even with SDR104 enabled.

> sdhci-pltfm: SDHCI platform and OF driver helper

Wrong driver? We have SDHI not SDHCI.



signature.asc
Description: PGP signature

Re: [renesas-drivers:clk-renesas-for-v4.14 10/11] drivers/clk/renesas/rcar-usb2-clock-sel.c:149:5-17: duplicated argument to && or || (fwd)

[Geert Uytterhoeven]

Hi Julia,

On Wed, Aug 16, 2017 at 8:59 PM, Julia Lawall  wrote:
> On line 149, it looks like one extal should instead be xtal.

Thank you, that is correct. Fixed.

-- Forwarded message --
> Date: Thu, 17 Aug 2017 02:43:28 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: [renesas-drivers:clk-renesas-for-v4.14 10/11]
> drivers/clk/renesas/rcar-usb2-clock-sel.c:149:5-17: duplicated argument to
> && or ||
>
> CC: kbuild-...@01.org
> CC: linux-renesas-soc@vger.kernel.org
> TO: Yoshihiro Shimoda 
> CC: Geert Uytterhoeven 
>
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> clk-renesas-for-v4.14
> head:   344fae7f354bdb869115212a56d39d5f2034466d
> commit: 0b2934329320899150286a7fdec9c7d143d0bdb9 [10/11] clk: renesas: 
> rcar-usb2-clock-sel: Add R-Car USB 2.0 clock selector PHY
> :: branch date: 11 hours ago
> :: commit date: 11 hours ago
>
>>> drivers/clk/renesas/rcar-usb2-clock-sel.c:149:5-17: duplicated argument to 
>>> && or ||
>
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?id=0b2934329320899150286a7fdec9c7d143d0bdb9
> git remote add renesas-drivers 
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> git remote update renesas-drivers
> git checkout 0b2934329320899150286a7fdec9c7d143d0bdb9
> vim +149 drivers/clk/renesas/rcar-usb2-clock-sel.c
>
> 0b293432 Yoshihiro Shimoda 2017-07-25  116
> 0b293432 Yoshihiro Shimoda 2017-07-25  117  static int 
> rcar_usb2_clock_sel_probe(struct platform_device *pdev)
> 0b293432 Yoshihiro Shimoda 2017-07-25  118  {

> 0b293432 Yoshihiro Shimoda 2017-07-25 @149  if (!priv->extal && 
> !priv->extal) {
> 0b293432 Yoshihiro Shimoda 2017-07-25  150  dev_err(dev, "This 
> driver needs usb_extal or usb_xtal\n");
> 0b293432 Yoshihiro Shimoda 2017-07-25  151  return -ENOENT;
> 0b293432 Yoshihiro Shimoda 2017-07-25  152  }

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

Status of r8a7795 SDHI support?

[Dirk Behme]

Hi,

since ages I tried recent mainline (v4.13-rc5) on a custom r8a7795 board.

What's the status of SDHI support in mainline and/or renesas-drivers 
(renesas-drivers-2017-08-16-v4.13-rc5)?


I tried with the attachment and picked some patches from 
renesas-drivers-2017-08-16-v4.13-rc5 [1] but it doesn't look like any SD 
card / eMMC is detected at all [2].


In contrast to this, using recent 4.9 based Renesas BSP works quite well 
with both, SD card and eMMC.


Anything I missed or should pick additionally?

Best regards

Dirk

[1]

a3e6e7e64191 mmc: renesas-sdhi: provide a whitelist for Gen3 SoC ES versions
bc3db4f2fd33 mmc: renesas_sdhi_core: on R-Car 2+, make use of CBSY bit
2fcc3bd20347 mmc: tmio: don't wait on R-Car2+ when handling the clock
c67c49abb8cc mmc: tmio: no magic values when enabling DMA
b22af30b538b mmc: tmio: add references to bit defines in the header
9189f77a81fe mmc: tmio: remove obsolete TMIO_BBS
9493a1c932e5 mmc: tmio: fix CMD12 (STOP) handling
52c175e556f2 mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC
b713254ddb3e mmc: tmio, renesas-sdhi: add dataend to DMA ops
12c02bec700b mmc: tmio, renesas-sdhi: add max_{segs, blk_count} to 
tmio_mmc_data

ae0ba4472354 pinctrl: sh-pfc: r8a7795: Add SDHIx support
ef954844c7ac Linux 4.13-rc5

[2]

...
rcar_gen3_thermal e6198000.thermal: TSC2: Loaded 1 trip points
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
hidraw: raw HID events driver (C) Jiri Kosina
NET: Registered protocol family 17
...

From ae0ba44723548f835824ad8f2f96dd971cfedb0f Mon Sep 17 00:00:00 2001
From: Dirk Behme 
Date: Thu, 17 Aug 2017 08:02:14 +0200
Subject: [PATCH] pinctrl: sh-pfc: r8a7795: Add SDHIx support

Taken from the Renesas BSP

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/pinctrl/sh-pfc/pfc-r8a7795.c

FIXME: Clarify why this isn't mainline and mainline it.

Signed-off-by: Dirk Behme 
---
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 275 +++
 1 file changed, 275 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 1656295af2b0..60def0dc0761 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -2040,6 +2040,213 @@ static const unsigned int scif5_clk_b_mux[] = {
SCK5_B_MARK,
 };
 
+/* - SDHI0 -- 
*/
+static const unsigned int sdhi0_data1_pins[] = {
+   /* D0 */
+   RCAR_GP_PIN(3, 2),
+};
+static const unsigned int sdhi0_data1_mux[] = {
+   SD0_DAT0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+   /* D[0:3] */
+   RCAR_GP_PIN(3, 2), RCAR_GP_PIN(3, 3),
+   RCAR_GP_PIN(3, 4), RCAR_GP_PIN(3, 5),
+};
+static const unsigned int sdhi0_data4_mux[] = {
+   SD0_DAT0_MARK, SD0_DAT1_MARK,
+   SD0_DAT2_MARK, SD0_DAT3_MARK,
+};
+static const unsigned int sdhi0_ctrl_pins[] = {
+   /* CLK, CMD */
+   RCAR_GP_PIN(3, 0), RCAR_GP_PIN(3, 1),
+};
+static const unsigned int sdhi0_ctrl_mux[] = {
+   SD0_CLK_MARK, SD0_CMD_MARK,
+};
+static const unsigned int sdhi0_cd_pins[] = {
+   /* CD */
+   RCAR_GP_PIN(3, 12),
+};
+static const unsigned int sdhi0_cd_mux[] = {
+   SD0_CD_MARK,
+};
+static const unsigned int sdhi0_wp_pins[] = {
+   /* WP */
+   RCAR_GP_PIN(3, 13),
+};
+static const unsigned int sdhi0_wp_mux[] = {
+   SD0_WP_MARK,
+};
+/* - SDHI1 -- 
*/
+static const unsigned int sdhi1_data1_pins[] = {
+   /* D0 */
+   RCAR_GP_PIN(3, 8),
+};
+static const unsigned int sdhi1_data1_mux[] = {
+   SD1_DAT0_MARK,
+};
+static const unsigned int sdhi1_data4_pins[] = {
+   /* D[0:3] */
+   RCAR_GP_PIN(3, 8),  RCAR_GP_PIN(3, 9),
+   RCAR_GP_PIN(3, 10), RCAR_GP_PIN(3, 11),
+};
+static const unsigned int sdhi1_data4_mux[] = {
+   SD1_DAT0_MARK, SD1_DAT1_MARK,
+   SD1_DAT2_MARK, SD1_DAT3_MARK,
+};
+static const unsigned int sdhi1_ctrl_pins[] = {
+   /* CLK, CMD */
+   RCAR_GP_PIN(3, 6), RCAR_GP_PIN(3, 7),
+};
+static const unsigned int sdhi1_ctrl_mux[] = {
+   SD1_CLK_MARK, SD1_CMD_MARK,
+};
+static const unsigned int sdhi1_cd_pins[] = {
+   /* CD */
+   RCAR_GP_PIN(3, 14),
+};
+static const unsigned int sdhi1_cd_mux[] = {
+   SD1_CD_MARK,
+};
+static const unsigned int sdhi1_wp_pins[] = {
+   /* WP */
+   RCAR_GP_PIN(3, 15),
+};
+static const unsigned int sdhi1_wp_mux[] = {
+   SD1_WP_MARK,
+};
+/* - SDHI2 -- 
*/
+static const unsigned int sdhi2_data1_pins[] = {
+   /* D0 */
+   RCAR_GP_PIN(4, 2),
+};
+static const unsigned int sdhi2_data1_mux[] = {
+   SD2_DAT0_MARK,
+};
+static const unsigned int sdhi2_data4_pins[] = {
+   /* 

Re: [PATCH v7] media: platform: Renesas IMR driver

[Hans Verkuil]

Hi Sergei,

A few high level comments (I'll look at the patch itself later):

- There is no MAINTAINERS entry, please add one.
- Don't attach the patch, post it inline (ideally with 'git send-email')
- Split up the patch into 4 separate patches: bindings, doc changes,
  driver and MAINTAINERS patch. This will make it easier to review.
- Please give the v4l2-compliance output in the cover letter of the v8
  patch series. I can't merge this driver without being certain there
  are no compliance issues.
- You also have IMR-LSX3 and IMR-LX3 patches, why not add them to the
  patch series? I can review the set as a single unit. Up to you, though.

Regards,

Hans