[PATCH] v4l: Add support for STD ioctls on subdev nodes

[Niklas Söderlund]

Signed-off-by: Niklas Söderlund 
---
 Documentation/media/uapi/v4l/vidioc-g-std.rst| 14 ++
 Documentation/media/uapi/v4l/vidioc-querystd.rst | 11 +++
 drivers/media/v4l2-core/v4l2-subdev.c| 12 
 include/uapi/linux/v4l2-subdev.h |  3 +++
 4 files changed, 32 insertions(+), 8 deletions(-)

---

Hi Hans,

I have tested this on Renesas Gen3 Salvator-XS M3-N using the AFE 
subdevice from the adv748x driver together with the R-Car VIN and CSI-2 
pipeline.  

I wrote a prototype patch for v4l2-ctl which adds three new options 
(--get-subdev-standard, --set-subdev-standard and 
--get-subdev-detected-standard) to ease testing which I plan to submit 
after some cleanup if this patch receives positive feedback.

If you or anyone else is interested in testing this patch the v4l2-utils 
prototype patches are available at

git://git.ragnatech.se/v4l-utils#subdev-std

Regards,
// Niklas

diff --git a/Documentation/media/uapi/v4l/vidioc-g-std.rst 
b/Documentation/media/uapi/v4l/vidioc-g-std.rst
index 90791ab51a5371b8..8d94f0404df270db 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-std.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-std.rst
@@ -2,14 +2,14 @@
 
 .. _VIDIOC_G_STD:
 
-
-ioctl VIDIOC_G_STD, VIDIOC_S_STD
-
+**
+ioctl VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_SUBDEV_G_STD, VIDIOC_SUBDEV_S_STD
+**
 
 Name
 
 
-VIDIOC_G_STD - VIDIOC_S_STD - Query or select the video standard of the 
current input
+VIDIOC_G_STD - VIDIOC_S_STD - VIDIOC_SUBDEV_G_STD - VIDIOC_SUBDEV_S_STD - 
Query or select the video standard of the current input
 
 
 Synopsis
@@ -21,6 +21,12 @@ Synopsis
 .. c:function:: int ioctl( int fd, VIDIOC_S_STD, const v4l2_std_id *argp )
 :name: VIDIOC_S_STD
 
+.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_G_STD, v4l2_std_id *argp )
+:name: VIDIOC_SUBDEV_G_STD
+
+.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_S_STD, const v4l2_std_id 
*argp )
+:name: VIDIOC_SUBDEV_S_STD
+
 
 Arguments
 =
diff --git a/Documentation/media/uapi/v4l/vidioc-querystd.rst 
b/Documentation/media/uapi/v4l/vidioc-querystd.rst
index cf40bca19b9f8665..a8385cc7481869dd 100644
--- a/Documentation/media/uapi/v4l/vidioc-querystd.rst
+++ b/Documentation/media/uapi/v4l/vidioc-querystd.rst
@@ -2,14 +2,14 @@
 
 .. _VIDIOC_QUERYSTD:
 
-*
-ioctl VIDIOC_QUERYSTD
-*
+*
+ioctl VIDIOC_QUERYSTD, VIDIOC_SUBDEV_QUERYSTD
+*
 
 Name
 
 
-VIDIOC_QUERYSTD - Sense the video standard received by the current input
+VIDIOC_QUERYSTD - VIDIOC_SUBDEV_QUERYSTD - Sense the video standard received 
by the current input
 
 
 Synopsis
@@ -18,6 +18,9 @@ Synopsis
 .. c:function:: int ioctl( int fd, VIDIOC_QUERYSTD, v4l2_std_id *argp )
 :name: VIDIOC_QUERYSTD
 
+.. c:function:: int ioctl( int fd, VIDIOC_SUBDEV_QUERYSTD, v4l2_std_id *argp )
+:name: VIDIOC_SUBDEV_QUERYSTD
+
 
 Arguments
 =
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index f9eed938d3480b74..a156b1812e923721 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -494,6 +494,18 @@ static long subdev_do_ioctl(struct file *file, unsigned 
int cmd, void *arg)
 
case VIDIOC_SUBDEV_S_DV_TIMINGS:
return v4l2_subdev_call(sd, video, s_dv_timings, arg);
+
+   case VIDIOC_SUBDEV_G_STD:
+   return v4l2_subdev_call(sd, video, g_std, arg);
+
+   case VIDIOC_SUBDEV_S_STD: {
+   v4l2_std_id *std = arg;
+
+   return v4l2_subdev_call(sd, video, s_std, *std);
+   }
+
+   case VIDIOC_SUBDEV_QUERYSTD:
+   return v4l2_subdev_call(sd, video, querystd, arg);
 #endif
default:
return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
diff --git a/include/uapi/linux/v4l2-subdev.h b/include/uapi/linux/v4l2-subdev.h
index c95a53e6743cb040..133696a1f324ffdc 100644
--- a/include/uapi/linux/v4l2-subdev.h
+++ b/include/uapi/linux/v4l2-subdev.h
@@ -170,8 +170,11 @@ struct v4l2_subdev_selection {
 #define VIDIOC_SUBDEV_G_SELECTION  _IOWR('V', 61, struct 
v4l2_subdev_selection)
 #define VIDIOC_SUBDEV_S_SELECTION  _IOWR('V', 62, struct 
v4l2_subdev_selection)
 /* The following ioctls are identical to the ioctls in videodev2.h */
+#define VIDIOC_SUBDEV_G_STD_IOR('V', 23, v4l2_std_id)
+#define VIDIOC_SUBDEV_S_STD_IOW('V', 24, v4l2_std_id)
 #define VIDIOC_SUBDEV_G_EDID   _IOWR('V', 40, struct v4l2_edid)
 #define VIDIOC_SUBDEV_S_EDID   _IOWR('V', 41, struct v4l2_edid)
+#define 

Re: [PATCH v9 4/8] media: vsp1: Convert display lists to use new body pool

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:35:43 EEST Kieran Bingham wrote:
> Adapt the dl->body0 object to use an object from the body pool. This
> greatly reduces the pressure on the TLB for IPMMU use cases, as all of
> the lists use a single allocation for the main body.
> 
> The CLU and LUT objects pre-allocate a pool containing three bodies,
> allowing a userspace update before the hardware has committed a previous
> set of tables.
> 
> Bodies are no longer 'freed' in interrupt context, but instead released
> back to their respective pools. This allows us to remove the garbage
> collector in the DLM.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
> v9:
>  - Remove redundant reference to gc_bodies
> 
> v8:
>  - Don't pass dlm->pool through vsp1_dl_list_alloc()  as it's already in the
> dlm. - Fix up comments
> 
> v4-v7:
>  - No changes (except rebases)
> 
> v3:
>  - 's/fragment/body', 's/fragments/bodies/'
>  - CLU/LUT now allocate 3 bodies
>  - vsp1_dl_list_fragments_free -> vsp1_dl_list_bodies_put
> 
> v2:
>  - Use dl->body0->max_entries to determine header offset, instead of the
>global constant VSP1_DL_NUM_ENTRIES which is incorrect.
>  - squash updates for LUT, CLU, and fragment cleanup into single patch.
>(Not fully bisectable when separated)
> ---
>  drivers/media/platform/vsp1/vsp1_clu.c |  27 ++-
>  drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
>  drivers/media/platform/vsp1/vsp1_dl.c  | 221 ++
>  drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
>  drivers/media/platform/vsp1/vsp1_lut.c |  27 ++-
>  drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
>  6 files changed, 100 insertions(+), 180 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
> b/drivers/media/platform/vsp1/vsp1_clu.c index ebfbb915dcdc..8efa12f5e53f
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_clu.c
> +++ b/drivers/media/platform/vsp1/vsp1_clu.c
> @@ -19,6 +19,8 @@
>  #define CLU_MIN_SIZE 4U
>  #define CLU_MAX_SIZE 8190U
> 
> +#define CLU_SIZE (17 * 17 * 17)
> +
>  /*
> ---
> -- * Device Access
>   */
> @@ -43,19 +45,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct
> v4l2_ctrl *ctrl) struct vsp1_dl_body *dlb;
>   unsigned int i;
> 
> - dlb = vsp1_dl_body_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
> + dlb = vsp1_dl_body_get(clu->pool);
>   if (!dlb)
>   return -ENOMEM;
> 
>   vsp1_dl_body_write(dlb, VI6_CLU_ADDR, 0);
> - for (i = 0; i < 17 * 17 * 17; ++i)
> + for (i = 0; i < CLU_SIZE; ++i)
>   vsp1_dl_body_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
> 
>   spin_lock_irq(>lock);
>   swap(clu->clu, dlb);
>   spin_unlock_irq(>lock);
> 
> - vsp1_dl_body_free(dlb);
> + vsp1_dl_body_put(dlb);
>   return 0;
>  }
> 
> @@ -216,8 +218,16 @@ static void clu_configure(struct vsp1_entity *entity,
>   }
>  }
> 
> +static void clu_destroy(struct vsp1_entity *entity)
> +{
> + struct vsp1_clu *clu = to_clu(>subdev);
> +
> + vsp1_dl_body_pool_destroy(clu->pool);
> +}
> +
>  static const struct vsp1_entity_operations clu_entity_ops = {
>   .configure = clu_configure,
> + .destroy = clu_destroy,
>  };
> 
>  /*
> ---
> -- @@ -243,6 +253,17 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device
> *vsp1) if (ret < 0)
>   return ERR_PTR(ret);
> 
> + /*
> +  * Pre-allocate a body pool, with 3 bodies allowing a userspace update
> +  * before the hardware has committed a previous set of tables, handling
> +  * both the queued and pending dl entries. One extra entry is added to
> +  * the CLU_SIZE to allow for the VI6_CLU_ADDR header.
> +  */
> + clu->pool = vsp1_dl_body_pool_create(clu->entity.vsp1, 3, CLU_SIZE + 1,
> +  0);
> + if (!clu->pool)
> + return ERR_PTR(-ENOMEM);
> +
>   /* Initialize the control handler. */
>   v4l2_ctrl_handler_init(>ctrls, 2);
>   v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
> diff --git a/drivers/media/platform/vsp1/vsp1_clu.h
> b/drivers/media/platform/vsp1/vsp1_clu.h index c45e6e707592..cef2f44481ba
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_clu.h
> +++ b/drivers/media/platform/vsp1/vsp1_clu.h
> @@ -32,6 +32,7 @@ struct vsp1_clu {
>   spinlock_t lock;
>   unsigned int mode;
>   struct vsp1_dl_body *clu;
> + struct vsp1_dl_body_pool *pool;
>  };
> 
>  static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev)
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index 41ace89a585b..617c46a03dec
> 100644
> --- 

Re: [PATCH v9 3/8] media: vsp1: Provide a body pool

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Thursday, 3 May 2018 16:35:42 EEST 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 IOMMU TLB, and a large number of display list
> allocations adds pressure to this resource.
> 
> Reduce TLB pressure on the IPMMUs by allocating multiple display list
> bodies in a single allocation, and providing these to the display list
> through a 'body pool'. A pool can be allocated by the display list
> manager or entities which require their own body allocations.
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> ---
> v8:
>  - Update commit message
>  - Fix comments and descriptions
> 
> v4:
>  - Provide comment explaining extra allocation on body pool
>highlighting area for optimisation later.
> 
> v3:
>  - s/fragment/body/, s/fragments/bodies/
>  - qty -> num_bodies
>  - indentation fix
>  - s/vsp1_dl_body_pool_{alloc,free}/vsp1_dl_body_pool_{create,destroy}/'
>  - Add kerneldoc to non-static functions
> 
> v2:
>  - assign dlb->dma correctly
> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 163 +++-
>  drivers/media/platform/vsp1/vsp1_dl.h |   8 +-
>  2 files changed, 171 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index 51965c30dec2..41ace89a585b
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -41,6 +41,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
> @@ -50,6 +52,9 @@ struct vsp1_dl_entry {
>   */
>  struct vsp1_dl_body {
>   struct list_head list;
> + struct list_head free;
> +
> + struct vsp1_dl_body_pool *pool;
>   struct vsp1_device *vsp1;
> 
>   struct vsp1_dl_entry *entries;
> @@ -61,6 +66,30 @@ struct vsp1_dl_body {
>  };
> 
>  /**
> + * struct vsp1_dl_body_pool - display list body pool
> + * @dma: DMA address of the entries
> + * @size: size of the full DMA memory pool in bytes
> + * @mem: CPU memory pointer for the pool
> + * @bodies: Array of DLB structures for the pool
> + * @free: List of free DLB entries
> + * @lock: Protects the free list
> + * @vsp1: the VSP1 device
> + */
> +struct vsp1_dl_body_pool {
> + /* DMA allocation */
> + dma_addr_t dma;
> + size_t size;
> + void *mem;
> +
> + /* Body management */
> + struct vsp1_dl_body *bodies;
> + struct list_head free;
> + spinlock_t lock;
> +
> + struct vsp1_device *vsp1;
> +};
> +
> +/**
>   * struct vsp1_dl_list - Display list
>   * @list: entry in the display list manager lists
>   * @dlm: the display list manager
> @@ -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: body pool for the display list bodies
>   * @gc_work: bodies garbage collector work struct
>   * @gc_bodies: array of display list bodies waiting to be freed
>   */
> @@ -119,6 +149,8 @@ struct vsp1_dl_manager {
>   struct vsp1_dl_list *queued;
>   struct vsp1_dl_list *pending;
> 
> + struct vsp1_dl_body_pool *pool;
> +
>   struct work_struct gc_work;
>   struct list_head gc_bodies;
>  };
> @@ -127,6 +159,137 @@ struct vsp1_dl_manager {
>   * Display List Body Management
>   */
> 
> +/**
> + * vsp1_dl_body_pool_create - Create a pool of bodies from a single
> allocation + * @vsp1: The VSP1 device
> + * @num_bodies: The number of bodies to allocate
> + * @num_entries: The maximum number of entries that a body can contain
> + * @extra_size: Extra allocation provided for the bodies
> + *
> + * Allocate a pool of display list bodies each with enough memory to
> contain the + * requested number of entries plus the @extra_size.
> + *
> + * Return a pointer to a pool on success or NULL if memory can't be
> allocated. + */
> +struct vsp1_dl_body_pool *
> +vsp1_dl_body_pool_create(struct vsp1_device *vsp1, unsigned int num_bodies,
> +  unsigned int num_entries, size_t extra_size)
> +{
> + struct vsp1_dl_body_pool *pool;
> + size_t dlb_size;
> + unsigned int i;
> +
> + pool = kzalloc(sizeof(*pool), GFP_KERNEL);
> + if (!pool)
> + return NULL;
> +
> + pool->vsp1 = vsp1;
> +
> + /*
> +  * TODO: 'extra_size' is only used by vsp1_dlm_create(), to allocate
> +  * extra memory for the display list header. We need only one header per
> +  * display list, not per 

[PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints

[Niklas Söderlund]

The style for referring to ports and endpoint are wrong. Refer to them
using lowercase and a unit address, port@x and endpoint@x.

Signed-off-by: Niklas Söderlund 
Reported-by: Geert Uytterhoeven 
---
 .../devicetree/bindings/media/rcar_vin.txt| 20 +--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index c2c57dcf73f4851b..a574b9c037c05a3c 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -45,23 +45,23 @@ The per-board settings Gen2 platforms:
 The per-board settings Gen3 platforms:
 
 Gen3 platforms can support both a single connected parallel input source
-from external SoC pins (port0) and/or multiple parallel input sources
-from local SoC CSI-2 receivers (port1) depending on SoC.
+from external SoC pins (port@0) and/or multiple parallel input sources
+from local SoC CSI-2 receivers (port@1) depending on SoC.
 
 - renesas,id - ID number of the VIN, VINx in the documentation.
 - ports
-- port 0 - sub-node describing a single endpoint connected to the VIN
+- port@0 - sub-node describing a single endpoint connected to the VIN
   from external SoC pins described in video-interfaces.txt[1].
-  Describing more then one endpoint in port 0 is invalid. Only VIN
-  instances that are connected to external pins should have port 0.
-- port 1 - sub-nodes describing one or more endpoints connected to
+  Describing more then one endpoint in port@0 is invalid. Only VIN
+  instances that are connected to external pins should have port@0.
+- port@1 - sub-nodes describing one or more endpoints connected to
   the VIN from local SoC CSI-2 receivers. The endpoint numbers must
   use the following schema.
 
-- Endpoint 0 - sub-node describing the endpoint connected to CSI20
-- Endpoint 1 - sub-node describing the endpoint connected to CSI21
-- Endpoint 2 - sub-node describing the endpoint connected to CSI40
-- Endpoint 3 - sub-node describing the endpoint connected to CSI41
+- endpoint@0 - sub-node describing the endpoint connected to CSI20
+- endpoint@1 - sub-node describing the endpoint connected to CSI21
+- endpoint@2 - sub-node describing the endpoint connected to CSI40
+- endpoint@3 - sub-node describing the endpoint connected to CSI41
 
 Device node example for Gen2 platforms
 --
-- 
2.17.0

[PATCH] rcar-vin: sync which hardware buffer to start capture from

[Niklas Söderlund]

When starting the VIN capture procedure we are not guaranteed that the
first buffer writing to is VnMB1 to which we assigned the first buffer
queued. This is problematic for two reasons. Buffers might not be
dequeued in the same order they where queued for capture. Future
features planed for the VIN driver is support for outputing frames in
SEQ_TB/BT format and to do that it's important that capture starts from
the first buffer slot, VnMB1.

We are guaranteed that capturing always happens in sequence (VnMB1 ->
VnMB2 -> VnMB3 -> VnMB1). So drop up to two frames when starting
capturing so that the driver always returns buffers in the same order
they are queued and prepare for SEQ_TB/BT output.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 16 +++-
 drivers/media/platform/rcar-vin/rcar-vin.h |  2 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ac07f99e3516a620..cfe5d7a9d44ee0e1 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -856,7 +856,7 @@ static int rvin_capture_start(struct rvin_dev *vin)
/* Continuous Frame Capture Mode */
rvin_write(vin, VNFC_C_FRAME, VNFC_REG);
 
-   vin->state = RUNNING;
+   vin->state = STARTING;
 
return 0;
 }
@@ -910,6 +910,20 @@ static irqreturn_t rvin_irq(int irq, void *data)
vnms = rvin_read(vin, VNMS_REG);
slot = (vnms & VNMS_FBS_MASK) >> VNMS_FBS_SHIFT;
 
+   /*
+* To hand buffers back in a known order to userspace start
+* to capture first from slot 0.
+*/
+   if (vin->state == STARTING) {
+   if (slot != 0) {
+   vin_dbg(vin, "Starting sync slot: %d\n", slot);
+   goto done;
+   }
+
+   vin_dbg(vin, "Capture start synced!\n");
+   vin->state = RUNNING;
+   }
+
/* Capture frame */
if (vin->queue_buf[slot]) {
vin->queue_buf[slot]->field = vin->format.field;
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index c2aef789b491ab31..ff747e22d8cfb643 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -53,11 +53,13 @@ enum rvin_csi_id {
 
 /**
  * STOPPED  - No operation in progress
+ * STARTING - Capture starting up
  * RUNNING  - Operation in progress have buffers
  * STOPPING - Stopping operation
  */
 enum rvin_dma_state {
STOPPED = 0,
+   STARTING,
RUNNING,
STOPPING,
 };
-- 
2.17.0

[PATCH] rcar-csi2: set default format if a unsupported one is requested

[Niklas Söderlund]

Instead of failing the set_fmt() if a unsupported format is requested
set a default one and return the changed format to the user.

Signed-off-by: Niklas Söderlund 
Reported-by: Sakari Ailus 
---
 drivers/media/platform/rcar-vin/rcar-csi2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
b/drivers/media/platform/rcar-vin/rcar-csi2.c
index e64f07fe184e7675..daef72d410a3425d 100644
--- a/drivers/media/platform/rcar-vin/rcar-csi2.c
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -613,7 +613,7 @@ static int rcsi2_set_pad_format(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *framefmt;
 
if (!rcsi2_code_to_fmt(format->format.code))
-   return -EINVAL;
+   format->format.code = rcar_csi2_formats[0].code;
 
if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
priv->mf = format->format;
-- 
2.17.0

Re: [PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

On 2018-05-16 15:42:09 +0200, Jacopo Mondi wrote:
> Describe HDMI input connector and ADV7612 HDMI decoder installed on
> R-Car Gen3 Draak board.
> 
> The video signal routing to the HDMI decoder to the video input interface
> VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> on-board switches SW-49, SW-50, SW-51 and SW-52.
> 
> As the default board switches configuration connects CVBS input to VIN4,
> leave the HDMI decoder unconnected in DTS.
> 
> Signed-off-by: Jacopo Mondi 

I'm not sure we have a policy about describing hardware which can't be 
used without flipping switches. I have no opinion on if we should do 
that or not I leave that to others, but for the change itself.

Reviewed-by: Niklas Söderlund 

I think it's good we describe it as it's part of the Draak board itself 
and not an expansion board which we have seen a lot of :-) Maybe even 
add a commented out line in the adv7612 port@2 which hints which VIN 
this is connected to if the switches are flipped?

> ---
>  arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 38 
> ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index 9aba28f..ea99dc9 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -59,6 +59,17 @@
>   };
>   };
>  
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
>   memory@4800 {
>   device_type = "memory";
>   /* first 128MB is reserved for secure area. */
> @@ -170,6 +181,33 @@
>   };
>   };
>   };
> +
> + hdmi-decoder@4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + default-input = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7612_in: endpoint {
> + remote-endpoint = <_con_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + adv7612_out: endpoint {
> + pclk-sample = <0>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + };
> + };
> + };
> + };
>  };
>  
>   {
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 6/6] ARM: dts: rcar-gen2: Add 'data-active' property

[Niklas Söderlund]

Hi Jacopo,

Thanks for your work.

On 2018-05-16 18:32:32 +0200, Jacopo Mondi wrote:
> The 'data-active' property needs to be specified when using embedded
> synchronization. Add it to the Gen-2 boards using composite video input.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/arm/boot/dts/r8a7790-lager.dts   | 1 +
>  arch/arm/boot/dts/r8a7791-koelsch.dts | 1 +
>  arch/arm/boot/dts/r8a7791-porter.dts  | 1 +
>  arch/arm/boot/dts/r8a7793-gose.dts| 1 +
>  arch/arm/boot/dts/r8a7794-alt.dts | 1 +
>  arch/arm/boot/dts/r8a7794-silk.dts| 1 +
>  6 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> b/arch/arm/boot/dts/r8a7790-lager.dts
> index b56b309..48fcb44 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -893,6 +893,7 @@
> 
>   vin1ep0: endpoint {
>   remote-endpoint = <>;
> + data-active = <1>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
> b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 9967666..fa0b25f 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -868,6 +868,7 @@
> 
>   vin1ep: endpoint {
>   remote-endpoint = <>;
> + data-active = <1>;

Depending on how we interpret the data-active property this can be good 
or bad. But if we interpret it as the polarity of the VIn_CLKENB pin 
this is not good as this is not connected for the adv7180 on Koelsch.

I have not checked all the Gen2 schematics as I'm still not sure how to 
interpret the property.


>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
> b/arch/arm/boot/dts/r8a7791-porter.dts
> index 055a7f1..96b9605 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -391,6 +391,7 @@
> 
>   vin0ep: endpoint {
>   remote-endpoint = <>;
> + data-active = <1>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
> b/arch/arm/boot/dts/r8a7793-gose.dts
> index 9d3fba2..80b4fa8 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -779,6 +779,7 @@
> 
>   vin1ep: endpoint {
>   remote-endpoint = <_out>;
> + data-active = <1>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts 
> b/arch/arm/boot/dts/r8a7794-alt.dts
> index 4bbb9cc..00df605d 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -380,6 +380,7 @@
> 
>   vin0ep: endpoint {
>   remote-endpoint = <>;
> + data-active = <1>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts 
> b/arch/arm/boot/dts/r8a7794-silk.dts
> index c0c5d31..ed17376 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -480,6 +480,7 @@
> 
>   vin0ep: endpoint {
>   remote-endpoint = <>;
> + data-active = <1>;
>   };
>   };
>  };
> --
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties

[Niklas Söderlund]

Hi Jacopo,

Thanks for your work.

On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> driver and only confuse users. Remove them in all Gen2 SoC that used
> them.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/arm/boot/dts/r8a7790-lager.dts   | 3 ---
>  arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
>  arch/arm/boot/dts/r8a7791-porter.dts  | 1 -
>  arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
>  arch/arm/boot/dts/r8a7794-alt.dts | 1 -
>  arch/arm/boot/dts/r8a7794-silk.dts| 1 -
>  6 files changed, 12 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> b/arch/arm/boot/dts/r8a7790-lager.dts
> index 063fdb6..b56b309 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -873,10 +873,8 @@
>   port {
>   vin0ep2: endpoint {
>   remote-endpoint = <_out>;
> - bus-width = <24>;

I can't really make up my mind if this is a good thing or not. Device 
tree describes the hardware and not what the drivers make use of. And 
the fact is that this bus is 24 bits wide. So I'm not sure we should 
remove these properties. But I would love to hear what others think 
about this.

>   hsync-active = <0>;
>   vsync-active = <0>;
> - pclk-sample = <1>;
>   data-active = <1>;
>   };
>   };
> @@ -895,7 +893,6 @@
> 
>   vin1ep0: endpoint {
>   remote-endpoint = <>;
> - bus-width = <8>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
> b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index f40321a..9967666 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -849,10 +849,8 @@
> 
>   vin0ep2: endpoint {
>   remote-endpoint = <_out>;
> - bus-width = <24>;
>   hsync-active = <0>;
>   vsync-active = <0>;
> - pclk-sample = <1>;
>   data-active = <1>;
>   };
>   };
> @@ -870,7 +868,6 @@
> 
>   vin1ep: endpoint {
>   remote-endpoint = <>;
> - bus-width = <8>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
> b/arch/arm/boot/dts/r8a7791-porter.dts
> index c14e6fe..055a7f1 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -391,7 +391,6 @@
> 
>   vin0ep: endpoint {
>   remote-endpoint = <>;
> - bus-width = <8>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
> b/arch/arm/boot/dts/r8a7793-gose.dts
> index 9ed6961..9d3fba2 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -759,10 +759,8 @@
> 
>   vin0ep2: endpoint {
>   remote-endpoint = <_out>;
> - bus-width = <24>;
>   hsync-active = <0>;
>   vsync-active = <0>;
> - pclk-sample = <1>;
>   data-active = <1>;
>   };
>   };
> @@ -781,7 +779,6 @@
> 
>   vin1ep: endpoint {
>   remote-endpoint = <_out>;
> - bus-width = <8>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts 
> b/arch/arm/boot/dts/r8a7794-alt.dts
> index 26a8834..4bbb9cc 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -380,7 +380,6 @@
> 
>   vin0ep: endpoint {
>   remote-endpoint = <>;
> - bus-width = <8>;
>   };
>   };
>  };
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts 
> b/arch/arm/boot/dts/r8a7794-silk.dts
> index 351cb3b..c0c5d31 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -480,7 +480,6 @@
> 
>   vin0ep: endpoint {
>   remote-endpoint = <>;
> - bus-width = <8>;
>   };
>   };
>  };
> --
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 4/6] media: rcar-vin: Handle CLOCKENB pin polarity

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

I'm happy that you dig into this as it clearly needs doing!

On 2018-05-16 18:32:30 +0200, Jacopo Mondi wrote:
> Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is
> not specified.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index ac07f99..7a84eae 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -123,6 +123,8 @@
>  /* Video n Data Mode Register 2 bits */
>  #define VNDMR2_VPS   (1 << 30)
>  #define VNDMR2_HPS   (1 << 29)
> +#define VNDMR2_CES   (1 << 28)
> +#define VNDMR2_CHS   (1 << 23)
>  #define VNDMR2_FTEV  (1 << 17)
>  #define VNDMR2_VLV(n)((n & 0xf) << 12)
>  
> @@ -691,6 +693,15 @@ static int rvin_setup(struct rvin_dev *vin)
>   dmr2 |= VNDMR2_VPS;
>  
>   /*
> +  * Clock-enable active level select.
> +  * Use HSYNC as enable if not specified
> +  */
> + if (vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW)
> + dmr2 |= VNDMR2_CES;
> + else if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_HIGH))
> + dmr2 |= VNDMR2_CHS;

After studying the datasheet for a while I'm getting more and more 
convinced this should be (with context leftout in this patch context) 
something like this:

/* Hsync Signal Polarity Select */
if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_HPS;

/* Vsync Signal Polarity Select */
if (!(vin->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_VPS;

/* Clock Enable Signal Polarity Select */
if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW))
dmr2 |= VNDMR2_CES;

/* Use HSYNC as clock enable if VIn_CLKENB is not available. */
if (!(vin->mbus_cfg.flags & (V4L2_MBUS_DATA_ACTIVE_LOW | 
V4L2_MBUS_DATA_ACTIVE_HIGH)))
dmr2 |= VNDMR2_CHS;

Or am I misunderstanding something?

> +
> + /*
>* Output format
>*/
>   switch (vin->format.pixelformat) {
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 3/6] media: rcar-vin: Handle data-active property

[Niklas Söderlund]

Hi Jacopo,

Thanks for your work.

On 2018-05-16 18:32:29 +0200, Jacopo Mondi wrote:
> The data-active property has to be specified when running with embedded
> synchronization. The VIN peripheral can use HSYNC in place of CLOCKENB
> when the CLOCKENB pin is not connected, this requires explicit
> synchronization to be in use.

Is this really the intent of the data-active property? I read the 
video-interfaces.txt document as such as if no hsync-active, 
vsync-active and data-active we should use the embedded synchronization 
else set the polarity for the requested pins. What am I not 
understanding here?

> 
> Now that the driver supports 'data-active' property, it makes not sense
> to zero the mbus configuration flags when running with implicit synch
> (V4L2_MBUS_BT656).
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index d3072e1..075d08f 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -531,15 +531,21 @@ static int rvin_digital_parse_v4l2(struct device *dev,
>   return -ENOTCONN;
>  
>   vin->mbus_cfg.type = vep->bus_type;
> + vin->mbus_cfg.flags = vep->bus.parallel.flags;
>  
>   switch (vin->mbus_cfg.type) {
>   case V4L2_MBUS_PARALLEL:
>   vin_dbg(vin, "Found PARALLEL media bus\n");
> - vin->mbus_cfg.flags = vep->bus.parallel.flags;
>   break;
>   case V4L2_MBUS_BT656:
>   vin_dbg(vin, "Found BT656 media bus\n");
> - vin->mbus_cfg.flags = 0;
> +
> + if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_HIGH) &&
> + !(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW)) {
> + vin_err(vin,
> + "Missing data enable signal polarity 
> property\n");

I fear this can't be an error as that would break backward comp ability 
with existing dtb's.

> + return -EINVAL;
> + }
>   break;
>   default:
>   vin_err(vin, "Unknown media bus type\n");
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active

[Niklas Söderlund]

Hi Jacopo,

Thanks for your work.

On 2018-05-16 18:32:28 +0200, Jacopo Mondi wrote:
> Document 'data-active' property in R-Car VIN device tree bindings.
> The property is optional when running with explicit synchronization
> (eg. BT.601) but mandatory when embedded synchronization is in use (eg.
> BT.656) as specified by the hardware manual.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index c53ce4e..17eac8a 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>   If both HSYNC and VSYNC polarities are not specified, embedded
>   synchronization is selected.
> 
> +- data-active: active state of data enable signal (CLOCKENB pin).

I'm not sure what you mean by active state here. video-interfaces.txt 
defines data-active as 'similar to HSYNC and VSYNC, specifies data line 
polarity' so I assume this is the polarity of the CLOCKENB pin?

> +  0/1 for LOW/HIGH respectively. If not specified, use HSYNC as
> +  data enable signal. When using embedded synchronization this
> +  property is mandatory.

I'm confused, why is this mandatory if we have no embedded sync (that is 
hsync-active and vsync-active not defined)? I can't find any reference 
to this in the Gen2 datasheet but I'm sure I'm just missing it :-)

> +
>  - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> --
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v6] gpio: dwapb: Add support for 1 interrupt per port A GPIO

[Hoan Tran]

Hi Phil,

On 5/11/18, 1:31 AM, "Phil Edworthy"  wrote:

The DesignWare GPIO IP can be configured for either 1 interrupt or 1
per GPIO in port A, but the driver currently only supports 1 interrupt.
See the DesignWare DW_apb_gpio Databook description of the
'GPIO_INTR_IO' parameter.

This change allows the driver to work with up to 32 interrupts, it will
get as many interrupts as specified in the DT 'interrupts' property.
It doesn't do anything clever with the different interrupts, it just calls
the same handler used for single interrupt hardware.

Signed-off-by: Phil Edworthy 
Reviewed-by: Rob Herring 
Acked-by: Lee Jones 
---
One point to mention is that I have made it possible for users to have
unconnected interrupts by specifying holes in the list of interrupts. This 
is
done by supporting the interrupts-extended DT prop.
However, I have no use for this and had to hack some test case for this.
Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?

v6:
 - Treat DT and ACPI the same as much as possible. Note that we can't use
   platform_get_irq() to get the DT interrupts as they are in the port
   sub-node and hence do not have an associated platform device.
v5:
 - Rolled ACPI companion code provided by Hoan Tran into this patch.
v4:
 - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping()
v3:
 - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect 
problems
v2:
 - Replaced interrupt-mask DT prop with support for the interrupts-extended
   prop. This means replacing the call to irq_of_parse_and_map() with calls
   to of_irq_parse_one() and irq_create_of_mapping().
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 +++-
 drivers/gpio/gpio-dwapb.c  | 49 
+++---
 drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
 include/linux/platform_data/gpio-dwapb.h   |  3 +-
 4 files changed, 45 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
index 4a75da7..3c1118b 100644
--- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -26,8 +26,13 @@ controller.
   the second encodes the triger flags encoded as described in
   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - interrupt-parent : The parent interrupt controller.
-- interrupts : The interrupt to the parent controller raised when GPIOs
-  generate the interrupts.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+  generate the interrupts. If the controller provides one combined 
interrupt
+  for all GPIOs, specify a single interrupt. If the controller provides one
+  interrupt for each GPIO, provide a list of interrupts that correspond to 
each
+  of the GPIO pins. When specifying multiple interrupts, if any are 
unconnected,
+  use the interrupts-extended property to specify the interrupts and set 
the
+  interrupt controller handle for unused interrupts to 0.
 - snps,nr-gpios : The number of pins in the port, a single cell.
 - resets : Reset line for the controller.
 
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 226977f..15b4154 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -441,14 +441,19 @@ static void dwapb_configure_irqs(struct dwapb_gpio 
*gpio,
irq_gc->chip_types[1].handler = handle_edge_irq;
 
if (!pp->irq_shared) {
-   irq_set_chained_handler_and_data(pp->irq, dwapb_irq_handler,
-gpio);
+   int i;
+
+   for (i = 0; i < pp->ngpio; i++) {
+   if (pp->irq[i] >= 0)
+   irq_set_chained_handler_and_data(pp->irq[i],
+   dwapb_irq_handler, gpio);
+   }
} else {
/*
 * Request a shared IRQ since where MFD would have devices
 * using the same irq pin
 */
-   err = devm_request_irq(gpio->dev, pp->irq,
+   err = devm_request_irq(gpio->dev, pp->irq[0],
   dwapb_irq_handler_mfd,
   IRQF_SHARED, "gpio-dwapb-mfd", gpio);
if (err) {
@@ -524,7 +529,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
if (pp->idx == 0)
port->gc.set_config = dwapb_gpio_set_config;
 
-   if 

Re: [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

On 2018-05-16 18:32:27 +0200, Jacopo Mondi wrote:
> Describe the optional endpoint properties for endpoint nodes of port@0
> and port@1 of the R-Car VIN driver device tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 

Acked-by: Niklas Söderlund 

> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1..c53ce4e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>from external SoC pins described in video-interfaces.txt[1].
>Describing more then one endpoint in port 0 is invalid. Only VIN
>instances that are connected to external pins should have port 0.
> +
> +  - Optional properties for endpoint nodes of port@0:
> +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +
> + If both HSYNC and VSYNC polarities are not specified, embedded
> + synchronization is selected.
> +
>  - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>  - Endpoint 2 - sub-node describing the endpoint connected to CSI40
>  - Endpoint 3 - sub-node describing the endpoint connected to CSI41
> 
> +  Endpoint nodes of port@1 do not support any optional endpoint property.
> +
>  Device node example for Gen2 platforms
>  --
> 
> @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite 
> video input)
> 
>  vin1ep0: endpoint {
>  remote-endpoint = <>;
> -bus-width = <8>;
>  };
>  };
>  };
> --
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 0/6] media: rcar-vin: Brush endpoint properties

[Niklas Söderlund]

Hi Jacopo,

On 2018-05-16 18:32:26 +0200, Jacopo Mondi wrote:
> Hello,
>this series touches the bindings and the driver handling endpoint
> properties for digital subdevices of the R-Car VIN driver.
> 
> The first patch simply documents what are the endpoint properties supported
> at the moment, then the second one extends them with 'data-active'.
> 
> As the VIN hardware allows to use HSYNC as data enable signal when the CLCKENB
> pin is left unconnected, the 'data-active' property presence determinates
> if HSYNC has to be used or not as data enable signal. As a consequence, when
> running with embedded synchronism, and there is not HSYNC signal, it becomes
> mandatory to specify 'data-active' polarity in DTS.
> 
> To address this, all Gen-2 boards featuring a composite video input and
> running with embedded synchronization, now need that property to be specified
> in DTS. Before adding it, remove un-used properties as 'pclk-sample' and
> 'bus-width' from the Gen-2 bindings, as they are not parsed by the VIN driver
> and only confuse users.
> 
> Niklas, as you already know I don't have any Gen2 board. Could you give this
> a spin on Koelsch if you like the series?

I tested this on my Koelsch and capture is still working :-)

> 
> Thanks
>j
> 
> Jacopo Mondi (6):
>   dt-bindings: media: rcar-vin: Describe optional ep properties
>   dt-bindings: media: rcar-vin: Document data-active
>   media: rcar-vin: Handle data-active property
>   media: rcar-vin: Handle CLOCKENB pin polarity
>   ARM: dts: rcar-gen2: Remove unused VIN properties
>   ARM: dts: rcar-gen2: Add 'data-active' property
> 
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 18 +-
>  arch/arm/boot/dts/r8a7790-lager.dts  |  4 +---
>  arch/arm/boot/dts/r8a7791-koelsch.dts|  4 +---
>  arch/arm/boot/dts/r8a7791-porter.dts |  2 +-
>  arch/arm/boot/dts/r8a7793-gose.dts   |  4 +---
>  arch/arm/boot/dts/r8a7794-alt.dts|  2 +-
>  arch/arm/boot/dts/r8a7794-silk.dts   |  2 +-
>  drivers/media/platform/rcar-vin/rcar-core.c  | 10 --
>  drivers/media/platform/rcar-vin/rcar-dma.c   | 11 +++
>  9 files changed, 42 insertions(+), 15 deletions(-)
> 
> --
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 3/4] media: rcar-vin: Handle digital subdev in link_notify

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch,

On 2018-05-16 14:16:55 +0200, Jacopo Mondi wrote:
> Handle digital subdevices in link_notify callback. If the notified link
> involves a digital subdevice, do not change routing of the VIN-CSI-2
> devices.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 30 
> +++--
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 1003c8c..ea74c55 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -168,10 +168,36 @@ static int rvin_group_link_notify(struct media_link 
> *link, u32 flags,
>   }
>  
>   /* Add the new link to the existing mask and check if it works. */
> - csi_id = rvin_group_entity_to_csi_id(group, link->source->entity);
>   channel = rvin_group_csi_pad_to_channel(link->source->index);
> - mask_new = mask & rvin_group_get_mask(vin, csi_id, channel);
> + csi_id = rvin_group_entity_to_csi_id(group, link->source->entity);
> + if (csi_id == -ENODEV) {
> + struct v4l2_subdev *sd;
> + unsigned int i;
> +
> + /*
> +  * Make sure the source entity subdevice is registered as
> +  * a digital input of one of the enabled VINs if it is not
> +  * one of the CSI-2 subdevices.
> +  *
> +  * No hardware configuration required for digital inputs,
> +  * we can return here.
> +  */
> + sd = media_entity_to_v4l2_subdev(link->source->entity);
> + for (i = 0; i < RCAR_VIN_NUM; i++) {
> + if (group->vin[i] && group->vin[i]->digital &&
> + group->vin[i]->digital->subdev == sd) {
> + ret = 0;
> + goto out;
> + }
> + }
> +
> + vin_err(vin, "Subdevice %s not registered to any VIN\n",
> + link->source->entity->name);
> + ret = -ENODEV;
> + goto out;
> + }

I like this patch, you made it so simple. I feared this would be the 
ugly part when adding parallel support to Gen3. All that is missing is 
handling of vin->mbus_cfg or how you think we best handle that for the 
different input buses.

>  
> + mask_new = mask & rvin_group_get_mask(vin, csi_id, channel);
>   vin_dbg(vin, "Try link change mask: 0x%x new: 0x%x\n", mask, mask_new);
>  
>   if (!mask_new) {
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 2/4] media: rcar-vin: Handle mc in digital notifier ops

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

I only have one generic comment to this patch as I fear comments on 1/4 
have the potential to change quiet a few things here :-(

On 2018-05-16 14:16:54 +0200, Jacopo Mondi wrote:
> Handle media-controller in the digital notifier operations (bound,
> unbind and complete) registered for VIN instances handling a digital
> input subdevice.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 94 
> -
>  1 file changed, 65 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 0ea21ab..1003c8c 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -379,7 +379,7 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
> direction)
>   * Digital async notifier
>   */
>  
> -/* The vin lock should be held when calling the subdevice attach and detach 
> */
> +/* The vin lock should be held when calling the subdevice attach. */
>  static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
>struct v4l2_subdev *subdev)
>  {
> @@ -388,15 +388,6 @@ static int rvin_digital_subdevice_attach(struct rvin_dev 
> *vin,
>   };
>   int ret;
>  
> - /* Find source and sink pad of remote subdevice */
> - ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> - if (ret < 0)
> - return ret;
> - vin->digital->source_pad = ret;
> -
> - ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> - vin->digital->sink_pad = ret < 0 ? 0 : ret;
> -
>   /* Find compatible subdevices mbus format */
>   vin->mbus_code = 0;
>   code.index = 0;
> @@ -450,23 +441,14 @@ static int rvin_digital_subdevice_attach(struct 
> rvin_dev *vin,
>  
>   vin->vdev.ctrl_handler = >ctrl_handler;
>  
> - vin->digital->subdev = subdev;
> -
>   return 0;
>  }
>  
> -static void rvin_digital_subdevice_detach(struct rvin_dev *vin)

Please don't fold this function into the caller. I tired the same thing 
when adding Gen3 support but keeping the _attach and _detach functions 
keeps a nice abstraction on what happens when we add and remove a 
parallel subdevice to the internal data structures separated from the 
housekeeping stuff in the callbacks :-)


> -{
> - rvin_v4l2_unregister(vin);
> - v4l2_ctrl_handler_free(>ctrl_handler);
> -
> - vin->vdev.ctrl_handler = NULL;
> - vin->digital->subdev = NULL;
> -}
> -
>  static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
> + struct media_entity *source;
> + struct media_entity *sink;
>   int ret;
>  
>   ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
> @@ -475,7 +457,26 @@ static int rvin_digital_notify_complete(struct 
> v4l2_async_notifier *notifier)
>   return ret;
>   }
>  
> - return rvin_v4l2_register(vin);
> + if (!video_is_registered(>vdev)) {
> + ret = rvin_v4l2_register(vin);
> + if (ret < 0)
> + return ret;
> + }
> +
> + if (!vin->info->use_mc)
> + return 0;
> +
> + /* If we're running with media controller, link the subdevice. */
> + source = >digital->subdev->entity;
> + sink = >vdev.entity;
> +
> + ret = media_create_pad_link(source, vin->digital->source_pad,
> + sink, vin->digital->sink_pad, 0);
> + if (ret)
> + vin_err(vin, "Error adding link from %s to %s\n",
> + source->name, sink->name);
> +
> + return ret;
>  }
>  
>  static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
> @@ -487,7 +488,14 @@ static void rvin_digital_notify_unbind(struct 
> v4l2_async_notifier *notifier,
>   vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
>  
>   mutex_lock(>lock);
> - rvin_digital_subdevice_detach(vin);
> +
> + rvin_v4l2_unregister(vin);
> + vin->digital->subdev = NULL;
> + if (!vin->info->use_mc) {
> + v4l2_ctrl_handler_free(>ctrl_handler);
> + vin->vdev.ctrl_handler = NULL;
> + }
> +
>   mutex_unlock(>lock);
>  }
>  
> @@ -499,10 +507,29 @@ static int rvin_digital_notify_bound(struct 
> v4l2_async_notifier *notifier,
>   int ret;
>  
>   mutex_lock(>lock);
> - ret = rvin_digital_subdevice_attach(vin, subdev);
> - mutex_unlock(>lock);
> - if (ret)
> +
> + /* Find source and sink pad of remote subdevice */
> + ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> + if (ret < 0) {
> + mutex_unlock(>lock);
>   return ret;
> + }
> + vin->digital->source_pad = ret;
> +
> + ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> + vin->digital->sink_pad = ret < 0 ? 0 : ret;
> +
> + 

Re: [PATCH 1/3] sh_eth: add RGMII support

[Andrew Lunn]

> > Hi Sergei
> > 
> > What about
> > PHY_INTERFACE_MODE_RGMII_ID,
> > PHY_INTERFACE_MODE_RGMII_RXID,
> > PHY_INTERFACE_MODE_RGMII_TXID,
> 
>Oops, totally forgot about those... :-/

Everybody does. I keep intending to write a email template for
this, and phy_interface_mode_is_rgmii() :-)

Andrew

Re: [PATCH 1/3] sh_eth: add RGMII support

[Sergei Shtylyov]

On 05/16/2018 11:30 PM, Andrew Lunn wrote:

>> The R-Car V3H (AKA R8A77980) GEther controller  adds support for the RGMII
>> PHY interface mode as a new  value  for the RMII_MII register.
>>
>> Based on the original (and large) patch by Vladimir Barinov.
>>
>> Signed-off-by: Vladimir Barinov 
>> Signed-off-by: Sergei Shtylyov 
>>
>> ---
>>  drivers/net/ethernet/renesas/sh_eth.c |3 +++
>>  1 file changed, 3 insertions(+)
>>
>> Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
>> ===
>> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
>> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
>> @@ -466,6 +466,9 @@ static void sh_eth_select_mii(struct net
>>  u32 value;
>>  
>>  switch (mdp->phy_interface) {
>> +case PHY_INTERFACE_MODE_RGMII:
>> +value = 0x3;
>> +break;
> 
> Hi Sergei
> 
> What about
>   PHY_INTERFACE_MODE_RGMII_ID,
>   PHY_INTERFACE_MODE_RGMII_RXID,
>   PHY_INTERFACE_MODE_RGMII_TXID,

   Oops, totally forgot about those... :-/

>  Andrew

MBR, Sergei

Re: [PATCH v2 1/4] media: rcar-vin: Parse digital input in mc-path

[Niklas Söderlund]

Hi Jacopo,

Thanks for your work!

First let me apologies for the use of the keyword 'digital' in the 
driver it should have been parallel... Someday we should remedy this.

If you touch any parts of the code where such a transition make sens I 
would not complain about the intermixed use of digital/parallel. Once 
your work is done we could follow up with a cleanup patch to complete 
the transition. Or if you rather stick with digital here I'm fine with 
that too.

On 2018-05-16 14:16:53 +0200, Jacopo Mondi wrote:
> Add support for digital input subdevices to Gen-3 rcar-vin.
> The Gen-3, media-controller compliant, version has so far only accepted
> CSI-2 input subdevices. Remove assumptions on the supported bus_type and
> accepted number of subdevices, and allow digital input connections on port@0.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 99 
> +++--
>  drivers/media/platform/rcar-vin/rcar-vin.h  | 15 +
>  2 files changed, 93 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index d3072e1..0ea21ab 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -562,7 +562,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
>   return ret;
>  
>   if (!vin->digital)
> - return -ENODEV;
> + return -ENOTCONN;
>  
>   vin_dbg(vin, "Found digital subdevice %pOF\n",
>   to_of_node(vin->digital->asd.match.fwnode));
> @@ -703,15 +703,13 @@ static int rvin_mc_parse_of_endpoint(struct device *dev,
>  {
>   struct rvin_dev *vin = dev_get_drvdata(dev);
>  
> - if (vep->base.port != 1 || vep->base.id >= RVIN_CSI_MAX)
> + if (vep->base.port != RVIN_PORT_CSI2 || vep->base.id >= RVIN_CSI_MAX)

I don't like this RVIN_PORT_CSI2. It makes the code harder to read as I 
have have to go and lookup which port RVIN_PORT_CSI2 represents. I would 
rater just keep vep->base.port != 1 as I think it's much clearer whats 
going on. And it's not as we will move the CSI-2 input to a different 
port as it's described in the bindings.

>   return -EINVAL;
>  
>   if (!of_device_is_available(to_of_node(asd->match.fwnode))) {
> -
>   vin_dbg(vin, "OF device %pOF disabled, ignoring\n",
>   to_of_node(asd->match.fwnode));
>   return -ENOTCONN;
> -
>   }
>  
>   if (vin->group->csi[vep->base.id].fwnode) {
> @@ -720,6 +718,8 @@ static int rvin_mc_parse_of_endpoint(struct device *dev,
>   return -ENOTCONN;
>   }
>  
> + vin->mbus_cfg.type = V4L2_MBUS_CSI2;
> + vin->mbus_cfg.flags = 0;

I like this move of mbus_cfg handling! Makes the two cases more aligned 
which are good. Unfortunately I fear it needs more work :-(

With this series addition of parallel input support. There are now two 
input types CSI-2 and parallel which can be changed at runtime for the 
same VIN. The mbus connected to the VIN will therefor be different 
depending on which media graph link is connected to a particular VIN and 
this effects hardware configuration, see 'vin->mbus_cfg.type == 
V4L2_MBUS_CSI2' in rvin_setup().

Maybe the best solution is to move mbus_cfg into struct 
rvin_graph_entity, rename that struct rvin_parallel_input and cache the 
parallel input settings in there, much like we do today for the pads.
Remove mbus_cfg from struct rvin_dev and replace it with a bool flag 
(input_csi or similar)?

In rvin_setup() use this flag to check which input type is in use and if 
it's needed fetch mbus_cfg from this cache. Then in 
rvin_group_link_notify() you could handle this input_csi flag depending 
on which link is activated. But I'm open to other solutions.

>   vin->group->csi[vep->base.id].fwnode = asd->match.fwnode;
>  
>   vin_dbg(vin, "Add group OF device %pOF to slot %u\n",
> @@ -742,7 +742,14 @@ static int rvin_mc_parse_of_graph(struct rvin_dev *vin)
>   return -EINVAL;
>   }
>  
> - /* If not all VIN's are registered don't register the notifier. */
> + /* Collect digital subdevices in this VIN device node. */
> + ret = rvin_digital_graph_init(vin);
> + if (ret < 0 && ret != -ENOTCONN) {
> + mutex_unlock(>group->lock);
> + return ret;
> + }

Why do you need to add this here? Is it not better to in 
rcar_vin_probe() do something like:

ret = rvin_digital_graph_init(vin);
if (ret < 0)
goto error;

if (vin->info->use_mc) {
ret = rvin_mc_init(vin);
if (ret < 0)
goto error;
}

That way we can try and keep to two code paths separated and at lest for 
me that increases readability a lot.

> +
> + /* Only the last registered VIN instance collects CSI-2 subdevices. */
>   for (i = 0; i < RCAR_VIN_NUM; i++)
>   if 

Re: [PATCH 1/3] sh_eth: add RGMII support

[Andrew Lunn]

On Wed, May 16, 2018 at 10:56:45PM +0300, Sergei Shtylyov wrote:
> The R-Car V3H (AKA R8A77980) GEther controller  adds support for the RGMII
> PHY interface mode as a new  value  for the RMII_MII register.
> 
> Based on the original (and large) patch by Vladimir Barinov.
> 
> Signed-off-by: Vladimir Barinov 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  drivers/net/ethernet/renesas/sh_eth.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
> ===
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
> @@ -466,6 +466,9 @@ static void sh_eth_select_mii(struct net
>   u32 value;
>  
>   switch (mdp->phy_interface) {
> + case PHY_INTERFACE_MODE_RGMII:
> + value = 0x3;
> + break;

Hi Sergei

What about
PHY_INTERFACE_MODE_RGMII_ID,
PHY_INTERFACE_MODE_RGMII_RXID,
PHY_INTERFACE_MODE_RGMII_TXID,

 Andrew

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Sergei Shtylyov]

Hello!

On 05/16/2018 02:56 AM, Florian Fainelli wrote:

> A number of drivers have the following pattern:
> 
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
> 
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
> 
> Signed-off-by: Florian Fainelli 
[...]

> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index ac621f44237a..02e8982519ce 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
>   priv->slave_mii_bus->parent = ds->dev->parent;
>   priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
>  
> - if (dn)
> - err = of_mdiobus_register(priv->slave_mii_bus, dn);
> - else
> - err = mdiobus_register(priv->slave_mii_bus);
> -
> - if (err)
> + err = of_mdiobus_register(priv->slave_mii_bus, dn);
> + if (err && dn)

   of_node_put() checks for NULL.

>   of_node_put(dn);
>  
>   return err;
[...]
> diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc8eb5b..f3e43db0d6cb 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
> *pdev)
>   fep->mii_bus->parent = >dev;
>  
>   node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> - if (node) {
> - err = of_mdiobus_register(fep->mii_bus, node);
> + err = of_mdiobus_register(fep->mii_bus, node);
> + if (node)
>   of_node_put(node);

   Same comment here.

[...]
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
> b/drivers/net/ethernet/renesas/sh_eth.c
> index 5970d9e5ddf1..8dd41e08a6c6 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -3025,15 +3025,10 @@ static int sh_mdio_init(struct sh_eth_private *mdp,
>pdev->name, pdev->id);
>  
>   /* register MDIO bus */
> - if (dev->of_node) {
> - ret = of_mdiobus_register(mdp->mii_bus, dev->of_node);
> - } else {
> - if (pd->phy_irq > 0)
> - mdp->mii_bus->irq[pd->phy] = pd->phy_irq;
> -
> - ret = mdiobus_register(mdp->mii_bus);
> - }
> + if (pd->phy_irq > 0)
> + mdp->mii_bus->irq[pd->phy] = pd->phy_irq;
>  
> + ret = of_mdiobus_register(mdp->mii_bus, dev->of_node);
>   if (ret)
>   goto out_free_bus;
>  

   This part is:

Acked-by: Sergei Shtylyov 

[...]
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index 91761436709a..8dff87ec6d99 100644
> --- a/drivers/net/usb/lan78xx.c
> +++ b/drivers/net/usb/lan78xx.c
> @@ -1843,12 +1843,9 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
>   }
>  
>   node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
> - if (node) {
> - ret = of_mdiobus_register(dev->mdiobus, node);
> + ret = of_mdiobus_register(dev->mdiobus, node);
> + if (node)
>   of_node_put(node);

   of_node_put() checks for NULL, again...

MBR, Sergei

[PATCH 3/3] sh_eth: add R8A77980 support

[Sergei Shtylyov]

Finally, add support for the DT probing of the R-Car V3H (AKA R8A77980) --
it's the only R-Car gen3 SoC having the GEther controller -- others have
only EtherAVB...

Based on the original (and large) patch by Vladimir Barinov.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 

---
 Documentation/devicetree/bindings/net/sh_eth.txt |1 
 drivers/net/ethernet/renesas/sh_eth.c|   44 +++
 2 files changed, 45 insertions(+)

Index: net-next/Documentation/devicetree/bindings/net/sh_eth.txt
===
--- net-next.orig/Documentation/devicetree/bindings/net/sh_eth.txt
+++ net-next/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -14,6 +14,7 @@ Required properties:
  "renesas,ether-r8a7791"  if the device is a part of R8A7791 SoC.
  "renesas,ether-r8a7793"  if the device is a part of R8A7793 SoC.
  "renesas,ether-r8a7794"  if the device is a part of R8A7794 SoC.
+ "renesas,gether-r8a77980" if the device is a part of R8A77980 SoC.
  "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
  "renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
  "renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -753,6 +753,49 @@ static struct sh_eth_cpu_data rcar_gen2_
.rmiimode   = 1,
.magic  = 1,
 };
+
+/* R8A77980 */
+static struct sh_eth_cpu_data r8a77980_data = {
+   .soft_reset = sh_eth_soft_reset_gether,
+
+   .set_duplex = sh_eth_set_duplex,
+   .set_rate   = sh_eth_set_rate_gether,
+
+   .register_type  = SH_ETH_REG_GIGABIT,
+
+   .edtrr_trns = EDTRR_TRNS_GETHER,
+   .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD | ECSR_MPD,
+   .ecsipr_value   = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP |
+ ECSIPR_MPDIP,
+   .eesipr_value   = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP |
+ EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
+
+   .tx_check   = EESR_FTC | EESR_CD | EESR_RTO,
+   .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
+ EESR_RFE | EESR_RDE | EESR_RFRMER |
+ EESR_TFE | EESR_TDE | EESR_ECI,
+   .fdr_value  = 0x070f,
+
+   .apr= 1,
+   .mpr= 1,
+   .tpauser= 1,
+   .bculr  = 1,
+   .hw_swap= 1,
+   .nbst   = 1,
+   .rpadir = 1,
+   .rpadir_value   = 2 << 16,
+   .no_trimd   = 1,
+   .no_ade = 1,
+   .xdfar_rw   = 1,
+   .hw_checksum= 1,
+   .select_mii = 1,
+   .magic  = 1,
+   .cexcr  = 1,
+};
 #endif /* CONFIG_OF */
 
 static void sh_eth_set_rate_sh7724(struct net_device *ndev)
@@ -3134,6 +3177,7 @@ static const struct of_device_id sh_eth_
{ .compatible = "renesas,ether-r8a7791", .data = _gen2_data },
{ .compatible = "renesas,ether-r8a7793", .data = _gen2_data },
{ .compatible = "renesas,ether-r8a7794", .data = _gen2_data },
+   { .compatible = "renesas,gether-r8a77980", .data = _data },
{ .compatible = "renesas,ether-r7s72100", .data = _data },
{ .compatible = "renesas,rcar-gen1-ether", .data = _gen1_data },
{ .compatible = "renesas,rcar-gen2-ether", .data = _gen2_data },

[PATCH 2/3] sh_eth: add EDMR.NBST support

[Sergei Shtylyov]

The R-Car V3H (AKA R8A77980) GEther controller adds the DMA burst mode bit
(NBST) in EDMR and the manual tells to always set it before doing any DMA.

Based on the original (and large) patch by Vladimir Barinov.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/sh_eth.c |4 
 drivers/net/ethernet/renesas/sh_eth.h |2 ++
 2 files changed, 6 insertions(+)

Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1434,6 +1434,10 @@ static int sh_eth_dev_init(struct net_de
 
sh_eth_write(ndev, mdp->cd->trscer_err_mask, TRSCER);
 
+   /* DMA transfer burst mode */
+   if (mdp->cd->nbst)
+   sh_eth_modify(ndev, EDMR, EDMR_NBST, EDMR_NBST);
+
if (mdp->cd->bculr)
sh_eth_write(ndev, 0x800, BCULR);   /* Burst sycle set */
 
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -184,6 +184,7 @@ enum GECMR_BIT {
 
 /* EDMR */
 enum DMAC_M_BIT {
+   EDMR_NBST = 0x80,
EDMR_EL = 0x40, /* Litte endian */
EDMR_DL1 = 0x20, EDMR_DL0 = 0x10,
EDMR_SRST_GETHER = 0x03,
@@ -505,6 +506,7 @@ struct sh_eth_cpu_data {
unsigned bculr:1;   /* EtherC have BCULR */
unsigned tsu:1; /* EtherC have TSU */
unsigned hw_swap:1; /* E-DMAC have DE bit in EDMR */
+   unsigned nbst:1;/* E-DMAC has NBST bit in EDMR */
unsigned rpadir:1;  /* E-DMAC have RPADIR */
unsigned no_trimd:1;/* E-DMAC DO NOT have TRIMD */
unsigned no_ade:1;  /* E-DMAC DO NOT have ADE bit in EESR */

[PATCH 1/3] sh_eth: add RGMII support

[Sergei Shtylyov]

The R-Car V3H (AKA R8A77980) GEther controller  adds support for the RGMII
PHY interface mode as a new  value  for the RMII_MII register.

Based on the original (and large) patch by Vladimir Barinov.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 

---
 drivers/net/ethernet/renesas/sh_eth.c |3 +++
 1 file changed, 3 insertions(+)

Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -466,6 +466,9 @@ static void sh_eth_select_mii(struct net
u32 value;
 
switch (mdp->phy_interface) {
+   case PHY_INTERFACE_MODE_RGMII:
+   value = 0x3;
+   break;
case PHY_INTERFACE_MODE_GMII:
value = 0x2;
break;

[PATCH 0/3] Add R8A77980 GEther support

[Sergei Shtylyov]

Hello!

Here's a set of 3 patches against DaveM's 'net-next.git' repo. They (gradually)
add R8A77980 GEther support to the 'sh_eth' driver, starting with couple new
register bits/values introduced with this chip, and ending with adding a new
'struct sh_eth_cpu_data' instance connected to the new DT "compatible" prop
value...

[1/1] sh_eth: add RGMII support
[2/3] sh_eth: add EDMR.NBST support
[3/3] sh_eth: add R8A77980 support

MBR, Sergei

Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[kbuild test robot]

Hi Florian,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/of-mdio-Fall-back-to-mdiobus_register-with-np-is-NULL/20180516-203317
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   drivers/net//ethernet/ti/davinci_mdio.c: In function 'davinci_mdio_probe':
>> drivers/net//ethernet/ti/davinci_mdio.c:457:12: error: invalid storage class 
>> for function 'davinci_mdio_remove'
static int davinci_mdio_remove(struct platform_device *pdev)
   ^~~
>> drivers/net//ethernet/ti/davinci_mdio.c:457:1: warning: ISO C90 forbids 
>> mixed declarations and code [-Wdeclaration-after-statement]
static int davinci_mdio_remove(struct platform_device *pdev)
^~
>> drivers/net//ethernet/ti/davinci_mdio.c:471:12: error: invalid storage class 
>> for function 'davinci_mdio_runtime_suspend'
static int davinci_mdio_runtime_suspend(struct device *dev)
   ^~~~
>> drivers/net//ethernet/ti/davinci_mdio.c:485:12: error: invalid storage class 
>> for function 'davinci_mdio_runtime_resume'
static int davinci_mdio_runtime_resume(struct device *dev)
   ^~~
>> drivers/net//ethernet/ti/davinci_mdio.c:495:12: error: invalid storage class 
>> for function 'davinci_mdio_suspend'
static int davinci_mdio_suspend(struct device *dev)
   ^~~~
>> drivers/net//ethernet/ti/davinci_mdio.c:512:12: error: invalid storage class 
>> for function 'davinci_mdio_resume'
static int davinci_mdio_resume(struct device *dev)
   ^~~
   In file included from include/linux/device.h:23:0,
from include/linux/platform_device.h:14,
from drivers/net//ethernet/ti/davinci_mdio.c:29:
>> drivers/net//ethernet/ti/davinci_mdio.c:527:21: error: initializer element 
>> is not constant
 SET_RUNTIME_PM_OPS(davinci_mdio_runtime_suspend,
^
   include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_suspend = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:527:21: note: (near initialization 
for 'davinci_mdio_pm_ops.runtime_suspend')
 SET_RUNTIME_PM_OPS(davinci_mdio_runtime_suspend,
^
   include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_suspend = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:528:7: error: initializer element is 
not constant
  davinci_mdio_runtime_resume, NULL)
  ^
   include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_resume = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:528:7: note: (near initialization 
for 'davinci_mdio_pm_ops.runtime_resume')
  davinci_mdio_runtime_resume, NULL)
  ^
   include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_resume = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:330:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .suspend_late = suspend_fn, \
 ^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: note: (near initialization 
for 'davinci_mdio_pm_ops.suspend_late')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:330:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .suspend_late = suspend_fn, \
 ^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
   include/linux/pm.h:331:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .resume_early = resume_fn, \
 ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: note: (near initialization 
for 'davinci_mdio_pm_ops.resume_early')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  

Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995

[Niklas Söderlund]

Hi Ulrich,

On 2018-05-16 15:07:01 +0200, Ulrich Hecht wrote:
> On Wed, Apr 11, 2018 at 11:01 AM, jacopo mondi  wrote:
> > Hello Kaneko-san,
> >
> > On Tue, Apr 03, 2018 at 09:43:02PM +0900, Yoshihiro Kaneko wrote:
> >> This series adds thermal support for r8a77995.
> >> R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
> >> Therefore this series adds r8a77995 support to rcar_thermal driver not
> >> rcar_gen3_thermal driver.
> >
> > I tested this on D3 Draak.
> >
> > I generated load expecting the detected temperature to rise.
> >
> > It took a while, and I only see a slight increase of the temperature
> > reported by the 'temp' attribute.
> 
> Pointing a heat gun at the SoC, I managed to get the temperature up to
> 8, and it went back to 4 when I removed it. I'd say this
> works.

I like your style! I contemplated using a hairdryer when testing some 
Gen3 thermal work but decided against it. Good too see others are not as 
weak minded as my self :-)

> 
> Tested-By: Ulrich Hecht 
> 
> CU
> Uli

-- 
Regards,
Niklas Söderlund

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[David Miller]

From: Florian Fainelli 
Date: Tue, 15 May 2018 16:56:17 -0700

> This patch series updates of_mdiobus_register() such that when the device_node
> argument is NULL, it calls mdiobus_register() directly. This is consistent 
> with
> the behavior of of_mdiobus_register() when CONFIG_OF=n.
> 
> I only converted the most obvious drivers, there are others that have a much
> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
> 
> Changes in v2:
> 
> - fixed build error in davincin_mdio.c (Grygorii)
> - reworked first patch a bit: commit message, subject and removed useless
>   code comment

Based upon Andrew's response to Geert's feedback, I'm applying this series.

Thanks.

Re: [PATCH 1/2] arm64: dts: r8a77995: Add MSIOF device nodes

[Geert Uytterhoeven]

Hi Uli,

On Wed, May 16, 2018 at 3:05 PM, Ulrich Hecht
 wrote:
> From: Hiromitsu Yamasaki 
>
> This patch adds MSIOF device nodes for the R8A77995 SoC.
>
> Signed-off-by: Hiromitsu Yamasaki 
> Signed-off-by: Takeshi Kihara 
> [uli: remove unimplemented ref clock]

I think you should remove the clock-names properties, too.

> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi | 66 
> +++
>  1 file changed, 66 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> index 2506f46..2f712ac 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -783,6 +783,72 @@
> compatible = "renesas,prr";
> reg = <0 0xfff00044 0 4>;
> };
> +
> +   msiof0: spi@e6e9 {
> +   compatible = "renesas,msiof-r8a77995",
> +"renesas,rcar-gen3-msiof";
> +   reg = <0 0xe6e9 0 0x0064>;
> +   interrupts = ;
> +   clocks = < CPG_MOD 211>;
> +   clock-names = "msiof_clk";
> +   dmas = < 0x41>, < 0x40>,
> +  < 0x41>, < 0x40>;
> +   dma-names = "tx", "rx", "tx", "rx";
> +   power-domains = < R8A77995_PD_ALWAYS_ON>;
> +   resets = < 211>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   status = "disabled";
> +   };

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Sergei Shtylyov]

On 05/16/2018 04:06 PM, Ulrich Hecht wrote:

 Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.

 Signed-off-by: Ulrich Hecht 
 ---
   drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
   1 file changed, 6 insertions(+)

 diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
 b/drivers/gpu/drm/rcar-du/rcar_lvds.c
 index 3d2d3bb..58fb9f8 100644
 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
 +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
 @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info
 rcar_lvds_r8a77970_info = {
 .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
   };
   +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
 +   .gen = 3,
 +   .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
 +};
>>>
>>>
>>> This new structure seems to be identical to rcar_lvds_r8a77970_info.
>>
>>> Could we consolidate somehow?
>>
>>In my book, that one has 2 quirk flags. What tree are you looking at?
> 
> IIRC the other one was for the PLL, which is not supported yet.

   V3M PLL is surely supported and it's surely different from D3 one. My point 
was that r8a77970 data can't be reused...

> CU
> Uli

MBR, Sergei

[PATCH 4/6] media: rcar-vin: Handle CLOCKENB pin polarity

[Jacopo Mondi]

Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is
not specified.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ac07f99..7a84eae 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -123,6 +123,8 @@
 /* Video n Data Mode Register 2 bits */
 #define VNDMR2_VPS (1 << 30)
 #define VNDMR2_HPS (1 << 29)
+#define VNDMR2_CES (1 << 28)
+#define VNDMR2_CHS (1 << 23)
 #define VNDMR2_FTEV(1 << 17)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
 
@@ -691,6 +693,15 @@ static int rvin_setup(struct rvin_dev *vin)
dmr2 |= VNDMR2_VPS;
 
/*
+* Clock-enable active level select.
+* Use HSYNC as enable if not specified
+*/
+   if (vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_LOW)
+   dmr2 |= VNDMR2_CES;
+   else if (!(vin->mbus_cfg.flags & V4L2_MBUS_DATA_ACTIVE_HIGH))
+   dmr2 |= VNDMR2_CHS;
+
+   /*
 * Output format
 */
switch (vin->format.pixelformat) {
-- 
2.7.4

[PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active

[Jacopo Mondi]

Document 'data-active' property in R-Car VIN device tree bindings.
The property is optional when running with explicit synchronization
(eg. BT.601) but mandatory when embedded synchronization is in use (eg.
BT.656) as specified by the hardware manual.

Signed-off-by: Jacopo Mondi 
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index c53ce4e..17eac8a 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
If both HSYNC and VSYNC polarities are not specified, embedded
synchronization is selected.

+- data-active: active state of data enable signal (CLOCKENB pin).
+  0/1 for LOW/HIGH respectively. If not specified, use HSYNC as
+  data enable signal. When using embedded synchronization this
+  property is mandatory.
+
 - port 1 - sub-nodes describing one or more endpoints connected to
   the VIN from local SoC CSI-2 receivers. The endpoint numbers must
   use the following schema.
--
2.7.4

[PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties

[Jacopo Mondi]

The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
driver and only confuse users. Remove them in all Gen2 SoC that used
them.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r8a7790-lager.dts   | 3 ---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
 arch/arm/boot/dts/r8a7791-porter.dts  | 1 -
 arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
 arch/arm/boot/dts/r8a7794-alt.dts | 1 -
 arch/arm/boot/dts/r8a7794-silk.dts| 1 -
 6 files changed, 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 063fdb6..b56b309 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -873,10 +873,8 @@
port {
vin0ep2: endpoint {
remote-endpoint = <_out>;
-   bus-width = <24>;
hsync-active = <0>;
vsync-active = <0>;
-   pclk-sample = <1>;
data-active = <1>;
};
};
@@ -895,7 +893,6 @@

vin1ep0: endpoint {
remote-endpoint = <>;
-   bus-width = <8>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f40321a..9967666 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -849,10 +849,8 @@

vin0ep2: endpoint {
remote-endpoint = <_out>;
-   bus-width = <24>;
hsync-active = <0>;
vsync-active = <0>;
-   pclk-sample = <1>;
data-active = <1>;
};
};
@@ -870,7 +868,6 @@

vin1ep: endpoint {
remote-endpoint = <>;
-   bus-width = <8>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index c14e6fe..055a7f1 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -391,7 +391,6 @@

vin0ep: endpoint {
remote-endpoint = <>;
-   bus-width = <8>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index 9ed6961..9d3fba2 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -759,10 +759,8 @@

vin0ep2: endpoint {
remote-endpoint = <_out>;
-   bus-width = <24>;
hsync-active = <0>;
vsync-active = <0>;
-   pclk-sample = <1>;
data-active = <1>;
};
};
@@ -781,7 +779,6 @@

vin1ep: endpoint {
remote-endpoint = <_out>;
-   bus-width = <8>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts 
b/arch/arm/boot/dts/r8a7794-alt.dts
index 26a8834..4bbb9cc 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -380,7 +380,6 @@

vin0ep: endpoint {
remote-endpoint = <>;
-   bus-width = <8>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts 
b/arch/arm/boot/dts/r8a7794-silk.dts
index 351cb3b..c0c5d31 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -480,7 +480,6 @@

vin0ep: endpoint {
remote-endpoint = <>;
-   bus-width = <8>;
};
};
 };
--
2.7.4

[PATCH 0/6] media: rcar-vin: Brush endpoint properties

[Jacopo Mondi]

Hello,
   this series touches the bindings and the driver handling endpoint
properties for digital subdevices of the R-Car VIN driver.

The first patch simply documents what are the endpoint properties supported
at the moment, then the second one extends them with 'data-active'.

As the VIN hardware allows to use HSYNC as data enable signal when the CLCKENB
pin is left unconnected, the 'data-active' property presence determinates
if HSYNC has to be used or not as data enable signal. As a consequence, when
running with embedded synchronism, and there is not HSYNC signal, it becomes
mandatory to specify 'data-active' polarity in DTS.

To address this, all Gen-2 boards featuring a composite video input and
running with embedded synchronization, now need that property to be specified
in DTS. Before adding it, remove un-used properties as 'pclk-sample' and
'bus-width' from the Gen-2 bindings, as they are not parsed by the VIN driver
and only confuse users.

Niklas, as you already know I don't have any Gen2 board. Could you give this
a spin on Koelsch if you like the series?

Thanks
   j

Jacopo Mondi (6):
  dt-bindings: media: rcar-vin: Describe optional ep properties
  dt-bindings: media: rcar-vin: Document data-active
  media: rcar-vin: Handle data-active property
  media: rcar-vin: Handle CLOCKENB pin polarity
  ARM: dts: rcar-gen2: Remove unused VIN properties
  ARM: dts: rcar-gen2: Add 'data-active' property

 Documentation/devicetree/bindings/media/rcar_vin.txt | 18 +-
 arch/arm/boot/dts/r8a7790-lager.dts  |  4 +---
 arch/arm/boot/dts/r8a7791-koelsch.dts|  4 +---
 arch/arm/boot/dts/r8a7791-porter.dts |  2 +-
 arch/arm/boot/dts/r8a7793-gose.dts   |  4 +---
 arch/arm/boot/dts/r8a7794-alt.dts|  2 +-
 arch/arm/boot/dts/r8a7794-silk.dts   |  2 +-
 drivers/media/platform/rcar-vin/rcar-core.c  | 10 --
 drivers/media/platform/rcar-vin/rcar-dma.c   | 11 +++
 9 files changed, 42 insertions(+), 15 deletions(-)

--
2.7.4

[PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties

[Jacopo Mondi]

Describe the optional endpoint properties for endpoint nodes of port@0
and port@1 of the R-Car VIN driver device tree bindings documentation.

Signed-off-by: Jacopo Mondi 
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index a19517e1..c53ce4e 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
   from external SoC pins described in video-interfaces.txt[1].
   Describing more then one endpoint in port 0 is invalid. Only VIN
   instances that are connected to external pins should have port 0.
+
+  - Optional properties for endpoint nodes of port@0:
+- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
+ respectively. Default is active high.
+- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
+ respectively. Default is active high.
+
+   If both HSYNC and VSYNC polarities are not specified, embedded
+   synchronization is selected.
+
 - port 1 - sub-nodes describing one or more endpoints connected to
   the VIN from local SoC CSI-2 receivers. The endpoint numbers must
   use the following schema.
@@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
 - Endpoint 2 - sub-node describing the endpoint connected to CSI40
 - Endpoint 3 - sub-node describing the endpoint connected to CSI41

+  Endpoint nodes of port@1 do not support any optional endpoint property.
+
 Device node example for Gen2 platforms
 --

@@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite 
video input)

 vin1ep0: endpoint {
 remote-endpoint = <>;
-bus-width = <8>;
 };
 };
 };
--
2.7.4

[PATCH 6/6] ARM: dts: rcar-gen2: Add 'data-active' property

[Jacopo Mondi]

The 'data-active' property needs to be specified when using embedded
synchronization. Add it to the Gen-2 boards using composite video input.

Signed-off-by: Jacopo Mondi 
---
 arch/arm/boot/dts/r8a7790-lager.dts   | 1 +
 arch/arm/boot/dts/r8a7791-koelsch.dts | 1 +
 arch/arm/boot/dts/r8a7791-porter.dts  | 1 +
 arch/arm/boot/dts/r8a7793-gose.dts| 1 +
 arch/arm/boot/dts/r8a7794-alt.dts | 1 +
 arch/arm/boot/dts/r8a7794-silk.dts| 1 +
 6 files changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index b56b309..48fcb44 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -893,6 +893,7 @@

vin1ep0: endpoint {
remote-endpoint = <>;
+   data-active = <1>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 9967666..fa0b25f 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -868,6 +868,7 @@

vin1ep: endpoint {
remote-endpoint = <>;
+   data-active = <1>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index 055a7f1..96b9605 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -391,6 +391,7 @@

vin0ep: endpoint {
remote-endpoint = <>;
+   data-active = <1>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index 9d3fba2..80b4fa8 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -779,6 +779,7 @@

vin1ep: endpoint {
remote-endpoint = <_out>;
+   data-active = <1>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts 
b/arch/arm/boot/dts/r8a7794-alt.dts
index 4bbb9cc..00df605d 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -380,6 +380,7 @@

vin0ep: endpoint {
remote-endpoint = <>;
+   data-active = <1>;
};
};
 };
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts 
b/arch/arm/boot/dts/r8a7794-silk.dts
index c0c5d31..ed17376 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -480,6 +480,7 @@

vin0ep: endpoint {
remote-endpoint = <>;
+   data-active = <1>;
};
};
 };
--
2.7.4

[PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input

[Jacopo Mondi]

Describe HDMI input connector and ADV7612 HDMI decoder installed on
R-Car Gen3 Draak board.

The video signal routing to the HDMI decoder to the video input interface
VIN4 is multiplexed with CVBS input path, and enabled/disabled through
on-board switches SW-49, SW-50, SW-51 and SW-52.

As the default board switches configuration connects CVBS input to VIN4,
leave the HDMI decoder unconnected in DTS.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index 9aba28f..ea99dc9 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -59,6 +59,17 @@
};
};
 
+   hdmi-in {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
memory@4800 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
@@ -170,6 +181,33 @@
};
};
};
+
+   hdmi-decoder@4c {
+   compatible = "adi,adv7612";
+   reg = <0x4c>;
+   default-input = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7612_in: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   adv7612_out: endpoint {
+   pclk-sample = <0>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   };
+   };
+   };
+   };
 };
 
  {
-- 
2.7.4

[PATCH v2 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support

[Jacopo Mondi]

Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by
rcar-vin driver.

Signed-off-by: Jacopo Mondi 
Acked-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Simon Horman 
---
 Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index a19517e1..5c6f2a7 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -22,6 +22,7 @@ on Gen3 platforms to a CSI-2 receiver.
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7796" for the R8A7796 device
- "renesas,vin-r8a77970" for the R8A77970 device
+   - "renesas,vin-r8a77995" for the R8A77995 device
- "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
  device.
 
-- 
2.7.4

[PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input

[Jacopo Mondi]

Describe CVBS video input through analog video decoder ADV7180
connected to video input interface VIN4.

The video input signal path is shared with HDMI video input, and
selected by on-board switches SW-53 and SW-54 with CVBS input selected
by the default switches configuration.
---
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 36 ++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts 
b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
index d03f194..9aba28f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
@@ -142,6 +142,11 @@
groups = "usb0";
function = "usb0";
};
+
+   vin4_pins_cvbs: vin4 {
+   groups = "vin4_data8", "vin4_sync", "vin4_clk";
+   function = "vin4";
+   };
 };
 
  {
@@ -154,6 +159,17 @@
reg = <0x50>;
pagesize = <8>;
};
+
+   analog-video@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+
+   port {
+   adv7180_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
 };
 
  {
@@ -246,3 +262,23 @@
timeout-sec = <60>;
status = "okay";
 };
+
+ {
+   pinctrl-0 = <_pins_cvbs>;
+   pinctrl-names = "default";
+
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   vin4_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
-- 
2.7.4

[PATCH v2 0/3] arm64: dts: Draak: Enable video inputs and VIN4

[Jacopo Mondi]

Hello,
   the second iteration of this series enables HDMI and CVBS video inputs
for the Draak board.

>From v1 series the description of VIN4 video interface for R8A77995 SoC has
already been collected by Simon, thus I'm not resending it.

This new version describes the HDMI input as v1 did, but does not connect it
to the VIN4 interface, as the video input path is shared between HDMI and
CVBS, and the default switches configuration selects CVBS.

I've not been able to test CVBS capture as I don't have any CVBS video source
here, but the devices shows up in the media controller graph as expected.

---
[root@alarm ~]# media-ctl  -p -d /dev/media1
Media controller API version 4.17.0

Media device information

driver  rcar_vin
model   renesas,vin-r8a77995
serial
bus infoplatform:e6ef4000.video
hw revision 0x0
driver version  4.17.0

Device topology
- entity 1: adv7180 0-0020 (1 pad, 1 link)
type V4L2 subdev subtype Unknown flags 20004
device node name /dev/v4l-subdev6
pad0: Source
[fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m]
-> "VIN4 output":0 []

- entity 5: VIN4 output (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video3
pad0: Sink
<- "adv7180 0-0020":0 []
---

Compared to Gen2 boards that use adv7180 (Lager, Alt, Koelsch, Porter, Gose
and Silk) I have removed the 'bus-width' property as it is not parsed by the
driver nor mentioned in the chip device tree binding description.

Switching from CVBS to HDMI input requires connecting the HDMI decoder endpoint
to VIN4, change the pin muxing to increase the VIN4 input bus width to 24 bits,
and add the synchronism signal polarities to the vin endpoint, as the HDMI
decoder uses BT.601 while the analog video decoder uses BT.656 unconditionally.

The series has been developed on top of media-master tree but applies cleanly
on top of latest renesas-driver.

Patches for testing are available at:
git://jmondi.org/linux d3/media-master/driver-v2
git://jmondi.org/linux d3/media-master/dts-v2
git://jmondi.org/vin-tests d3

Thanks
j

Jacopo Mondi (3):
  dt-bindings: media: rcar-vin: Add R8A77995 support
  arm64: dts: renesas: draak: Describe CVBS input
  arm64: dts: renesas: draak: Describe HDMI input

 .../devicetree/bindings/media/rcar_vin.txt |  1 +
 arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 74 ++
 2 files changed, 75 insertions(+)

--
2.7.4

Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995

[Ulrich Hecht]

On Wed, Apr 11, 2018 at 11:01 AM, jacopo mondi  wrote:
> Hello Kaneko-san,
>
> On Tue, Apr 03, 2018 at 09:43:02PM +0900, Yoshihiro Kaneko wrote:
>> This series adds thermal support for r8a77995.
>> R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
>> Therefore this series adds r8a77995 support to rcar_thermal driver not
>> rcar_gen3_thermal driver.
>
> I tested this on D3 Draak.
>
> I generated load expecting the detected temperature to rise.
>
> It took a while, and I only see a slight increase of the temperature
> reported by the 'temp' attribute.

Pointing a heat gun at the SoC, I managed to get the temperature up to
8, and it went back to 4 when I removed it. I'd say this
works.

Tested-By: Ulrich Hecht 

CU
Uli

Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Ulrich Hecht]

On Wed, May 16, 2018 at 10:59 AM, Sergei Shtylyov
 wrote:
> Hello!
>
> On 5/16/2018 10:54 AM, Simon Horman wrote:
>
>>> Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
>>>
>>> Signed-off-by: Ulrich Hecht 
>>> ---
>>>   drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> index 3d2d3bb..58fb9f8 100644
>>> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
>>> @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info
>>> rcar_lvds_r8a77970_info = {
>>> .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
>>>   };
>>>   +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
>>> +   .gen = 3,
>>> +   .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
>>> +};
>>
>>
>> This new structure seems to be identical to rcar_lvds_r8a77970_info.
>
>> Could we consolidate somehow?
>
>In my book, that one has 2 quirk flags. What tree are you looking at?

IIRC the other one was for the PLL, which is not supported yet.

CU
Uli

[PATCH 1/2] dmaengine: usb-dmac: Document R8A7799{0,5} bindings

[Ulrich Hecht]

From: Hiroyuki Yokoyama 

Renesas R-Car D3 (R8A77995) and E3 (R8A77990) SoCs also have the R-Car
gen2/3 compatible DMA controllers, so document the SoC specific binding.

Signed-off-by: Hiroyuki Yokoyama 
[uli: squashed]
Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt 
b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
index 9dc935e..482e543 100644
--- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
@@ -12,6 +12,8 @@ Required Properties:
  - "renesas,r8a7795-usb-dmac" (R-Car H3)
  - "renesas,r8a7796-usb-dmac" (R-Car M3-W)
  - "renesas,r8a77965-usb-dmac" (R-Car M3-N)
+ - "renesas,r8a77990-usb-dmac" (R-Car E3)
+ - "renesas,r8a77995-usb-dmac" (R-Car D3)
 - reg: base address and length of the registers block for the DMAC
 - interrupts: interrupt specifiers for the DMAC, one for each entry in
   interrupt-names.
-- 
2.7.4

[PATCH 2/2] dmaengine: rcar-dmac: Document R8A77990 bindings

[Ulrich Hecht]

From: Hiroyuki Yokoyama 

Renesas R-Car E3 (R8A77990) SoC also has the R-Car gen2/3 compatible DMA
controllers, so document the SoC specific binding.

Signed-off-by: Hiroyuki Yokoyama 
Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt 
b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
index b1ba6395..946229c 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
@@ -29,6 +29,7 @@ Required Properties:
- "renesas,dmac-r8a77965" (R-Car M3-N)
- "renesas,dmac-r8a77970" (R-Car V3M)
- "renesas,dmac-r8a77980" (R-Car V3H)
+   - "renesas,dmac-r8a77990" (R-Car E3)
- "renesas,dmac-r8a77995" (R-Car D3)
 
 - reg: base address and length of the registers block for the DMAC
-- 
2.7.4

[PATCH] arm64: dts: r8a77995: Add SCIF-{0,1,3,4,5} device nodes

[Ulrich Hecht]

From: Takeshi Kihara 

This patch adds the device nodes for SCIF-{0,1,3,4,5} serial ports,
incl. clocks and power domain.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 4b05dc2..73d6589 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -628,6 +628,34 @@
status = "disabled";
};
 
+   scif0: serial@e6e6 {
+   compatible = "renesas,scif-r8a77995",
+"renesas,rcar-gen3-scif", "renesas,scif";
+   reg = <0 0xe6e6 0 64>;
+   interrupts = ;
+   clocks = < CPG_MOD 207>,
+< CPG_CORE R8A77995_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 207>;
+   status = "disabled";
+   };
+
+   scif1: serial@e6e68000 {
+   compatible = "renesas,scif-r8a77995",
+"renesas,rcar-gen3-scif", "renesas,scif";
+   reg = <0 0xe6e68000 0 64>;
+   interrupts = ;
+   clocks = < CPG_MOD 206>,
+< CPG_CORE R8A77995_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 206>;
+   status = "disabled";
+   };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a77995",
 "renesas,rcar-gen3-scif", "renesas,scif";
@@ -645,6 +673,48 @@
status = "disabled";
};
 
+   scif3: serial@e6c5 {
+   compatible = "renesas,scif-r8a77995",
+"renesas,rcar-gen3-scif", "renesas,scif";
+   reg = <0 0xe6c5 0 64>;
+   interrupts = ;
+   clocks = < CPG_MOD 204>,
+< CPG_CORE R8A77995_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 204>;
+   status = "disabled";
+   };
+
+   scif4: serial@e6c4 {
+   compatible = "renesas,scif-r8a77995",
+"renesas,rcar-gen3-scif", "renesas,scif";
+   reg = <0 0xe6c4 0 64>;
+   interrupts = ;
+   clocks = < CPG_MOD 203>,
+< CPG_CORE R8A77995_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 203>;
+   status = "disabled";
+   };
+
+   scif5: serial@e6f3 {
+   compatible = "renesas,scif-r8a77995",
+"renesas,rcar-gen3-scif", "renesas,scif";
+   reg = <0 0xe6f3 0 64>;
+   interrupts = ;
+   clocks = < CPG_MOD 202>,
+< CPG_CORE R8A77995_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 202>;
+   status = "disabled";
+   };
+
vin4: video@e6ef4000 {
compatible = "renesas,vin-r8a77995";
reg = <0 0xe6ef4000 0 0x1000>;
-- 
2.7.4

[PATCH 1/2] arm64: dts: r8a77995: Add MSIOF device nodes

[Ulrich Hecht]

From: Hiromitsu Yamasaki 

This patch adds MSIOF device nodes for the R8A77995 SoC.

Signed-off-by: Hiromitsu Yamasaki 
Signed-off-by: Takeshi Kihara 
[uli: remove unimplemented ref clock]
Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 66 +++
 1 file changed, 66 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 2506f46..2f712ac 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -783,6 +783,72 @@
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
};
+
+   msiof0: spi@e6e9 {
+   compatible = "renesas,msiof-r8a77995",
+"renesas,rcar-gen3-msiof";
+   reg = <0 0xe6e9 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 211>;
+   clock-names = "msiof_clk";
+   dmas = < 0x41>, < 0x40>,
+  < 0x41>, < 0x40>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 211>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   msiof1: spi@e6ea {
+   compatible = "renesas,msiof-r8a77995",
+"renesas,rcar-gen3-msiof";
+   reg = <0 0xe6ea 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 210>;
+   clock-names = "msiof_clk";
+   dmas = < 0x43>, < 0x42>,
+  < 0x43>, < 0x42>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 210>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   msiof2: spi@e6c0 {
+   compatible = "renesas,msiof-r8a77995",
+"renesas,rcar-gen3-msiof";
+   reg = <0 0xe6c0 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 209>;
+   clock-names = "msiof_clk";
+   dmas = < 0x45>, < 0x44>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 209>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   msiof3: spi@e6c1 {
+   compatible = "renesas,msiof-r8a77995",
+"renesas,rcar-gen3-msiof";
+   reg = <0 0xe6c1 0 0x0064>;
+   interrupts = ;
+   clocks = < CPG_MOD 208>;
+   clock-names = "msiof_clk";
+   dmas = < 0x47>, < 0x46>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 208>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
};
 
timer {
-- 
2.7.4

[PATCH 2/2] spi: sh-msiof: Document R-Car D3 support

[Ulrich Hecht]

Document support for the MSIOF module in the Renesas D3 (r8a77995) SoC.

No driver update is needed.

Signed-off-by: Ulrich Hecht 
---
 Documentation/devicetree/bindings/spi/sh-msiof.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt 
b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index 3980632..914036d 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -11,6 +11,7 @@ Required properties:
 "renesas,msiof-r8a7795" (R-Car H3)
 "renesas,msiof-r8a7796" (R-Car M3-W)
 "renesas,msiof-r8a77965" (R-Car M3-N)
+"renesas,msiof-r8a77995" (R-Car D3)
 "renesas,msiof-sh73a0" (SH-Mobile AG5)
 "renesas,sh-mobile-msiof" (generic SH-Mobile 
compatibile device)
 "renesas,rcar-gen2-msiof" (generic R-Car Gen2 and 
RZ/G1 compatible device)
-- 
2.7.4

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Andrew Lunn]

On Wed, May 16, 2018 at 10:54:12AM +0200, Geert Uytterhoeven wrote:
> Hi Florian,
> 
> Thanks for your series!
> I like the effect on simplifying drivers.
> 
> On Wed, May 16, 2018 at 1:56 AM, Florian Fainelli  
> wrote:
> > This patch series updates of_mdiobus_register() such that when the 
> > device_node
> > argument is NULL, it calls mdiobus_register() directly. This is consistent 
> > with
> > the behavior of of_mdiobus_register() when CONFIG_OF=n.
> 
> IMHO the CONFIG_OF=n behavior of of_mdiobus_register() (which I wasn't
> aware of) is inconsistent with the behavior of other of_*() functions,
> which are just empty stubs.
> 
> So I'm wondering if you should do it the other way around, and let
> mdiobus_register() call of_mdiobus_register() if dev->of_node exists?

Hi Geert

dev->of_node is often not the correct OF node. The mdio properties are
often embedded inside a MAC driver, and use an 'mdio' container
node. This container node is needed, not the device node.

> I haven't looked at the ACPI handling, but perhaps this can be moved
> inside mdiobus_register() as well?

The ACPI binding for MDIO and PHYs has not been defined yet.

Andrew

[PATCH v2 2/4] media: rcar-vin: Handle mc in digital notifier ops

[Jacopo Mondi]

Handle media-controller in the digital notifier operations (bound,
unbind and complete) registered for VIN instances handling a digital
input subdevice.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 94 -
 1 file changed, 65 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 0ea21ab..1003c8c 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -379,7 +379,7 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
direction)
  * Digital async notifier
  */
 
-/* The vin lock should be held when calling the subdevice attach and detach */
+/* The vin lock should be held when calling the subdevice attach. */
 static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
 struct v4l2_subdev *subdev)
 {
@@ -388,15 +388,6 @@ static int rvin_digital_subdevice_attach(struct rvin_dev 
*vin,
};
int ret;
 
-   /* Find source and sink pad of remote subdevice */
-   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
-   if (ret < 0)
-   return ret;
-   vin->digital->source_pad = ret;
-
-   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
-   vin->digital->sink_pad = ret < 0 ? 0 : ret;
-
/* Find compatible subdevices mbus format */
vin->mbus_code = 0;
code.index = 0;
@@ -450,23 +441,14 @@ static int rvin_digital_subdevice_attach(struct rvin_dev 
*vin,
 
vin->vdev.ctrl_handler = >ctrl_handler;
 
-   vin->digital->subdev = subdev;
-
return 0;
 }
 
-static void rvin_digital_subdevice_detach(struct rvin_dev *vin)
-{
-   rvin_v4l2_unregister(vin);
-   v4l2_ctrl_handler_free(>ctrl_handler);
-
-   vin->vdev.ctrl_handler = NULL;
-   vin->digital->subdev = NULL;
-}
-
 static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
 {
struct rvin_dev *vin = notifier_to_vin(notifier);
+   struct media_entity *source;
+   struct media_entity *sink;
int ret;
 
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
@@ -475,7 +457,26 @@ static int rvin_digital_notify_complete(struct 
v4l2_async_notifier *notifier)
return ret;
}
 
-   return rvin_v4l2_register(vin);
+   if (!video_is_registered(>vdev)) {
+   ret = rvin_v4l2_register(vin);
+   if (ret < 0)
+   return ret;
+   }
+
+   if (!vin->info->use_mc)
+   return 0;
+
+   /* If we're running with media controller, link the subdevice. */
+   source = >digital->subdev->entity;
+   sink = >vdev.entity;
+
+   ret = media_create_pad_link(source, vin->digital->source_pad,
+   sink, vin->digital->sink_pad, 0);
+   if (ret)
+   vin_err(vin, "Error adding link from %s to %s\n",
+   source->name, sink->name);
+
+   return ret;
 }
 
 static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
@@ -487,7 +488,14 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
 
mutex_lock(>lock);
-   rvin_digital_subdevice_detach(vin);
+
+   rvin_v4l2_unregister(vin);
+   vin->digital->subdev = NULL;
+   if (!vin->info->use_mc) {
+   v4l2_ctrl_handler_free(>ctrl_handler);
+   vin->vdev.ctrl_handler = NULL;
+   }
+
mutex_unlock(>lock);
 }
 
@@ -499,10 +507,29 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
int ret;
 
mutex_lock(>lock);
-   ret = rvin_digital_subdevice_attach(vin, subdev);
-   mutex_unlock(>lock);
-   if (ret)
+
+   /* Find source and sink pad of remote subdevice */
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
+   if (ret < 0) {
+   mutex_unlock(>lock);
return ret;
+   }
+   vin->digital->source_pad = ret;
+
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
+   vin->digital->sink_pad = ret < 0 ? 0 : ret;
+
+   vin->digital->subdev = subdev;
+
+   if (!vin->info->use_mc) {
+   ret = rvin_digital_subdevice_attach(vin, subdev);
+   if (ret) {
+   mutex_unlock(>lock);
+   return ret;
+   }
+   }
+
+   mutex_unlock(>lock);
 
v4l2_set_subdev_hostdata(subdev, vin);
 
@@ -555,9 +582,10 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 {
int ret;
 
-   ret = v4l2_async_notifier_parse_fwnode_endpoints(
+   ret = v4l2_async_notifier_parse_fwnode_endpoints_by_port(
vin->dev, >notifier,
-   sizeof(struct rvin_graph_entity), rvin_digital_parse_v4l2);
+

[PATCH v2 0/4] rcar-vin: Add support for digital input on Gen3

[Jacopo Mondi]

Hello,
   this series add support for 'digital' input to the Gen3 version of rcar-vin
driver.

'Digital' inputs (the terms comes from the existing Gen2 version of the driver)
describe parallel video input sources connected to a VIN instance. So far, the
Gen3-version of the driver (the media-controller compliant one) only supported
CSI-2 inputs.

This series extends the device tree parsing to accept a connection on port@0,
and parses the 'digital' subdevice reusing the Gen-2 functions.

Compared to v1, this series drops all changes to rcar-dma module, as Niklas
sent a proper fix for both crop and compose rectangle managment and field
signal toggling method. This series is thus based on the media master branch
with Niklas' series on top.

Compared to v1 I incorporated Niklas' suggestion to re-use Gen2 functions for
parsing the digital input device nodes, and register one notifier for each VIN
that has an active connection on port@0. The 'group' notifier then only collects
async subdevices for CSI-2 inputs.

A separate series for the VIN4 and HDMI input enabling on Draak board has been
sent to renesas-soc list.

The vin-tests repository patches to automate capture testing have been extended
to support D3 board and capture from HDMI output, and patches have been sent
to Niklas.

Tested capturing HDMI input images on D3 and for backward compatibility on
Salvator-X M3-W too (seems like I didn't break anything there).

Patches for testing on D3 are available at:
git://jmondi.org/linux d3/media-master/driver-v2
git://jmondi.org/linux d3/media-master/dts
git://jmondi.org/linux d3/media-master/test
git://jmondi.org/vin-tests d3

Patches to test on M3-W (based on latest renesas drivers, which includes an
older version of VIN series, but has CSI-2 driver) available at:
git://jmondi.org/linux d3/renesas-drivers/test

Thanks
j

Jacopo Mondi (4):
  media: rcar-vin: Parse digital input in mc-path
  media: rcar-vin: Handle mc in digital notifier ops
  media: rcar-vin: Handle digital subdev in link_notify
  media: rcar-vin: Add support for R-Car R8A77995 SoC

 drivers/media/platform/rcar-vin/rcar-core.c | 239 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |  15 ++
 2 files changed, 202 insertions(+), 52 deletions(-)

--
2.7.4

[PATCH v2 3/4] media: rcar-vin: Handle digital subdev in link_notify

[Jacopo Mondi]

Handle digital subdevices in link_notify callback. If the notified link
involves a digital subdevice, do not change routing of the VIN-CSI-2
devices.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 30 +++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 1003c8c..ea74c55 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -168,10 +168,36 @@ static int rvin_group_link_notify(struct media_link 
*link, u32 flags,
}
 
/* Add the new link to the existing mask and check if it works. */
-   csi_id = rvin_group_entity_to_csi_id(group, link->source->entity);
channel = rvin_group_csi_pad_to_channel(link->source->index);
-   mask_new = mask & rvin_group_get_mask(vin, csi_id, channel);
+   csi_id = rvin_group_entity_to_csi_id(group, link->source->entity);
+   if (csi_id == -ENODEV) {
+   struct v4l2_subdev *sd;
+   unsigned int i;
+
+   /*
+* Make sure the source entity subdevice is registered as
+* a digital input of one of the enabled VINs if it is not
+* one of the CSI-2 subdevices.
+*
+* No hardware configuration required for digital inputs,
+* we can return here.
+*/
+   sd = media_entity_to_v4l2_subdev(link->source->entity);
+   for (i = 0; i < RCAR_VIN_NUM; i++) {
+   if (group->vin[i] && group->vin[i]->digital &&
+   group->vin[i]->digital->subdev == sd) {
+   ret = 0;
+   goto out;
+   }
+   }
+
+   vin_err(vin, "Subdevice %s not registered to any VIN\n",
+   link->source->entity->name);
+   ret = -ENODEV;
+   goto out;
+   }
 
+   mask_new = mask & rvin_group_get_mask(vin, csi_id, channel);
vin_dbg(vin, "Try link change mask: 0x%x new: 0x%x\n", mask, mask_new);
 
if (!mask_new) {
-- 
2.7.4

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Jose Abreu]

On 16-05-2018 00:56, Florian Fainelli wrote:
> A number of drivers have the following pattern:
>
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
>
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
>
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/dsa/bcm_sf2.c |  8 ++--
>  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>  drivers/net/ethernet/marvell/mvmdio.c |  5 +
>  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +

For stmmac:

Reviewed-by: Jose Abreu 

Thanks and Best Regards,
Jose Miguel Abreu

>  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
>  drivers/net/phy/mdio-gpio.c   |  6 +-
>  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>  drivers/net/usb/lan78xx.c |  7 ++-
>  11 files changed, 20 insertions(+), 61 deletions(-)
>

[ANNOUNCE] Renesas tree closed for v4.18

[Simon Horman]

Hi,

I would like to stop accepting non-bug-fix patches for v4.18 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.17-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.19 as new patches are ready.

[PATCH v3 01/26] drm/bridge: allow optionally specifying an owner .odev device

[Peter Rosin]

Bridge drivers can now (temporarily, in a transition phase) select if
they want to provide a full owner device or keep just providing an
of_node.

By providing a full owner device, the bridge drivers no longer need
to provide an of_node since that node is available via the owner
device.

When all bridge drivers provide an owner device, that will become
mandatory and the .of_node member will be removed.

There is an interaction with the rockchip lvds driver, since that
driver peeks into somewhat private parts of the bridge struct in
order to find out things about the remote bridge. When there are
now two ways to get to the remote bridge, the rockchip lvds driver
has to adapt. That said, the correct thing to do for the rockchip
lvds driver is to use some other way than DT to find things out
about the remote bridge, but that is orthogonal to this patch.

Reviewed-by: Andrzej Hajda 
Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
 include/drm/drm_bridge.h | 2 ++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..3872f5379998 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
*np)
mutex_lock(_lock);
 
list_for_each_entry(bridge, _list, list) {
-   if (bridge->of_node == np) {
+   if ((bridge->odev && bridge->odev->of_node == np) ||
+   bridge->of_node == np) {
mutex_unlock(_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..557e0079c98d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
-   else
+   else if (lvds->bridge->of_node)
remote = lvds->bridge->of_node;
+   else
+   remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", ))
/* default set it as output rgb */
lvds->output = DISPLAY_OUTPUT_RGB;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7c17977c3537 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -254,6 +254,7 @@ struct drm_bridge_timings {
 
 /**
  * struct drm_bridge - central DRM bridge control structure
+ * @odev: device that owns the bridge
  * @dev: DRM device this bridge belongs to
  * @encoder: encoder to which this bridge is connected
  * @next: the next bridge in the encoder chain
@@ -265,6 +266,7 @@ struct drm_bridge_timings {
  * @driver_private: pointer to the bridge driver's internal context
  */
 struct drm_bridge {
+   struct device *odev;
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
-- 
2.11.0

[PATCH v3 00/26] device link, bridge supplier <-> drm device

[Peter Rosin]

Hi!

It was noted by Russell King [1] that bridges (not using components)
might disappear unexpectedly if the owner of the bridge was unbound.
Jyri Sarha had previously noted the same thing with panels [2]. Jyri
came up with using device links to resolve the panel issue, which
was also my (independent) reaction to the note from Russell.

This series builds up to the addition of that link in the last
patch, but in my opinion the other 25 patches do have merit on their
own.

The last patch needs testing, while the others look trivial. Jyri, are
you able to test? That said, I might have missed some subtlety.

Oh, and the reason I'm pushing this is of course so that the issue
noted by Russell in [1] is addressed which in turn means that the
tda998x bridge driver can be patched according to that series without
objection (hopefully) and then used from the atmel-hlcdc driver (and
other drivers that are not componentized).

Changes since v2https://lkml.org/lkml/2018/5/4/443

- Russell King spells his name this way. Sorry!
- Add review tag from Andrzej Hajda (patches 1, 25 and 26).
- Add ack tag from Daniel Vetter (patches 1, 24, 25 and 26).
- Mention the interaction with the rockchip_lvds driver in the
  commit message for patch 1.
- Change the comment for the new @link member in patch 26, so that a
  symmetric relationchip between cunsumer/supplier isn't implied.

Changes since v1https://lkml.org/lkml/2018/4/26/1018

- rename .owner to .odev to not get mixed up with the module owner.
- added patches for new recent drivers thc63lvd1024 and cdns-dsi
- fix for problem in the rockchip_lvds driver reported by 0day
- added a WARN in drm_bridge_add if there is no .odev owner device

Cheers,
Peter

[1] https://lkml.org/lkml/2018/4/23/769
[2] https://www.spinics.net/lists/dri-devel/msg174275.html

Peter Rosin (26):
  drm/bridge: allow optionally specifying an owner .odev device
  drm/bridge: adv7511: provide an owner .odev device
  drm/bridge/analogix: core: specify the owner .odev of the bridge
  drm/bridge: analogix-anx78xx: provide an owner .odev device
  drm/bridge: cdns-dsi: provide an owner .odev device
  drm/bridge: vga-dac: provide an owner .odev device
  drm/bridge: lvds-encoder: provide an owner .odev device
  drm/bridge: megachips-stdp-ge-b850v3-fw: provide an owner .odev
device
  drm/bridge: nxp-ptn3460: provide an owner .odev device
  drm/bridge: panel: provide an owner .odev device
  drm/bridge: ps8622: provide an owner .odev device
  drm/bridge: sii902x: provide an owner .odev device
  drm/bridge: sii9234: provide an owner .odev device
  drm/bridge: sii8620: provide an owner .odev device
  drm/bridge: synopsys: provide an owner .odev device for the bridges
  drm/bridge: tc358767: provide an owner .odev device
  drm/bridge: thc63lvd1024: provide an owner .odev device
  drm/bridge: ti-tfp410: provide an owner .odev device
  drm/exynos: mic: provide an owner .odev device for the bridge
  drm/mediatek: hdmi: provide an owner .odev device for the bridge
  drm/msm: specify the owner .odev of the bridges
  drm/rcar-du: lvds: provide an owner .odev device for the bridge
  drm/sti: provide an owner .odev device for the bridges
  drm/bridge: remove the .of_node member
  drm/bridge: require the owner .odev to be filled in on
drm_bridge_add/attach
  drm/bridge: establish a link between the bridge supplier and consumer

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |  5 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  1 +
 drivers/gpu/drm/bridge/cdns-dsi.c  |  2 +-
 drivers/gpu/drm/bridge/dumb-vga-dac.c  |  2 +-
 drivers/gpu/drm/bridge/lvds-encoder.c  |  2 +-
 .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  2 +-
 drivers/gpu/drm/bridge/nxp-ptn3460.c   |  2 +-
 drivers/gpu/drm/bridge/panel.c |  4 +---
 drivers/gpu/drm/bridge/parade-ps8622.c |  2 +-
 drivers/gpu/drm/bridge/sii902x.c   |  2 +-
 drivers/gpu/drm/bridge/sii9234.c   |  2 +-
 drivers/gpu/drm/bridge/sil-sii8620.c   |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  4 +---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c  |  4 +---
 drivers/gpu/drm/bridge/tc358767.c  |  2 +-
 drivers/gpu/drm/bridge/thc63lvd1024.c  |  2 +-
 drivers/gpu/drm/bridge/ti-tfp410.c |  2 +-
 drivers/gpu/drm/drm_bridge.c   | 26 +-
 drivers/gpu/drm/exynos/exynos_drm_mic.c|  2 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  2 +-
 drivers/gpu/drm/msm/dsi/dsi_manager.c  |  1 +
 drivers/gpu/drm/msm/edp/edp_bridge.c   |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  1 +
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  2 +-
 drivers/gpu/drm/rockchip/rockchip_lvds.c   |  2 +-
 

[PATCH v3 22/26] drm/rcar-du: lvds: provide an owner .odev device for the bridge

[Peter Rosin]

The .of_node member is going away.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bbd1342..efda02f55c95 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -463,9 +463,9 @@ static int rcar_lvds_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
+   lvds->bridge.odev = >dev;
lvds->bridge.driver_private = lvds;
lvds->bridge.funcs = _lvds_bridge_ops;
-   lvds->bridge.of_node = pdev->dev.of_node;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
lvds->mmio = devm_ioremap_resource(>dev, mem);
-- 
2.11.0

[PATCH v3 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach

[Peter Rosin]

The .odev owner device will be handy to have around.

Reviewed-by: Andrzej Hajda 
Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index df084db33494..78d186b6831b 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -70,6 +70,9 @@ static LIST_HEAD(bridge_list);
  */
 void drm_bridge_add(struct drm_bridge *bridge)
 {
+   if (WARN_ON(!bridge->odev))
+   return;
+
mutex_lock(_lock);
list_add_tail(>list, _list);
mutex_unlock(_lock);
@@ -115,6 +118,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
if (!encoder || !bridge)
return -EINVAL;
 
+   if (WARN_ON(!bridge->odev))
+   return -EINVAL;
+
if (previous && (!previous->dev || previous->encoder != encoder))
return -EINVAL;
 
-- 
2.11.0

[PATCH v3 24/26] drm/bridge: remove the .of_node member

[Peter Rosin]

It is unused.

Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 3 +--
 drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
 include/drm/drm_bridge.h | 4 
 3 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 3872f5379998..df084db33494 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,8 +365,7 @@ struct drm_bridge *of_drm_find_bridge(struct device_node 
*np)
mutex_lock(_lock);
 
list_for_each_entry(bridge, _list, list) {
-   if ((bridge->odev && bridge->odev->of_node == np) ||
-   bridge->of_node == np) {
+   if (bridge->odev->of_node == np) {
mutex_unlock(_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 557e0079c98d..e77d4c909582 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct 
device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
-   else if (lvds->bridge->of_node)
-   remote = lvds->bridge->of_node;
else
remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", ))
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 7c17977c3537..b656e505d11e 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -258,7 +258,6 @@ struct drm_bridge_timings {
  * @dev: DRM device this bridge belongs to
  * @encoder: encoder to which this bridge is connected
  * @next: the next bridge in the encoder chain
- * @of_node: device node pointer to the bridge
  * @list: to keep track of all added bridges
  * @timings: the timing specification for the bridge, if any (may
  * be NULL)
@@ -270,9 +269,6 @@ struct drm_bridge {
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
-#ifdef CONFIG_OF
-   struct device_node *of_node;
-#endif
struct list_head list;
const struct drm_bridge_timings *timings;
 
-- 
2.11.0

[PATCH v3 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Peter Rosin]

If the bridge supplier is unbound, this will bring the bridge consumer
down along with the bridge. Thus, there will no longer linger any
dangling pointers from the bridge consumer (the drm_device) to some
non-existent bridge supplier.

Reviewed-by: Andrzej Hajda 
Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/drm_bridge.c | 18 ++
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 78d186b6831b..0259f0a3ff27 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -26,6 +26,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
if (bridge->dev)
return -EBUSY;
 
+   if (encoder->dev->dev != bridge->odev) {
+   bridge->link = device_link_add(encoder->dev->dev,
+  bridge->odev, 0);
+   if (!bridge->link) {
+   dev_err(bridge->odev, "failed to link bridge to %s\n",
+   dev_name(encoder->dev->dev));
+   return -EINVAL;
+   }
+   }
+
bridge->dev = encoder->dev;
bridge->encoder = encoder;
 
if (bridge->funcs->attach) {
ret = bridge->funcs->attach(bridge);
if (ret < 0) {
+   if (bridge->link)
+   device_link_del(bridge->link);
+   bridge->link = NULL;
bridge->dev = NULL;
bridge->encoder = NULL;
return ret;
@@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
if (bridge->funcs->detach)
bridge->funcs->detach(bridge);
 
+   if (bridge->link)
+   device_link_del(bridge->link);
+   bridge->link = NULL;
+
bridge->dev = NULL;
 }
 
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index b656e505d11e..bd1265c5a0bc 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -261,6 +261,7 @@ struct drm_bridge_timings {
  * @list: to keep track of all added bridges
  * @timings: the timing specification for the bridge, if any (may
  * be NULL)
+ * @link: device link between the drm consumer and the bridge supplier
  * @funcs: control functions
  * @driver_private: pointer to the bridge driver's internal context
  */
@@ -271,6 +272,7 @@ struct drm_bridge {
struct drm_bridge *next;
struct list_head list;
const struct drm_bridge_timings *timings;
+   struct device_link *link;
 
const struct drm_bridge_funcs *funcs;
void *driver_private;
-- 
2.11.0

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Daniel Vetter]

On Tue, May 15, 2018 at 01:09:59PM +0200, Peter Rosin wrote:
> On 2018-05-15 12:22, Daniel Vetter wrote:
> > On Mon, May 14, 2018 at 10:40 PM, Peter Rosin  wrote:
> >> On 2018-05-14 18:28, Daniel Vetter wrote:
> >>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>  On 2018-05-10 10:10, Andrzej Hajda wrote:
> > On 04.05.2018 15:52, Peter Rosin wrote:
> >> If the bridge supplier is unbound, this will bring the bridge consumer
> >> down along with the bridge. Thus, there will no longer linger any
> >> dangling pointers from the bridge consumer (the drm_device) to some
> >> non-existent bridge supplier.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/drm_bridge.c | 18 ++
> >>  include/drm/drm_bridge.h |  2 ++
> >>  2 files changed, 20 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_bridge.c 
> >> b/drivers/gpu/drm/drm_bridge.c
> >> index 78d186b6831b..0259f0a3ff27 100644
> >> --- a/drivers/gpu/drm/drm_bridge.c
> >> +++ b/drivers/gpu/drm/drm_bridge.c
> >> @@ -26,6 +26,7 @@
> >>  #include 
> >>
> >>  #include 
> >> +#include 
> >>  #include 
> >>
> >>  #include "drm_crtc_internal.h"
> >> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder 
> >> *encoder, struct drm_bridge *bridge,
> >>if (bridge->dev)
> >>return -EBUSY;
> >>
> >> +  if (encoder->dev->dev != bridge->odev) {
> >
> > I wonder why device_link_add does not handle this case (self dependency)
> > silently as noop, as it seems to be a correct behavior.
> 
>  It's kind-of a silly corner-case though, so perfectly understandable
>  that it isn't handled.
> 
> >> +  bridge->link = device_link_add(encoder->dev->dev,
> >> + bridge->odev, 0);
> >> +  if (!bridge->link) {
> >> +  dev_err(bridge->odev, "failed to link bridge to 
> >> %s\n",
> >> +  dev_name(encoder->dev->dev));
> >> +  return -EINVAL;
> >> +  }
> >> +  }
> >> +
> >>bridge->dev = encoder->dev;
> >>bridge->encoder = encoder;
> >>
> >>if (bridge->funcs->attach) {
> >>ret = bridge->funcs->attach(bridge);
> >>if (ret < 0) {
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >>bridge->dev = NULL;
> >>bridge->encoder = NULL;
> >>return ret;
> >> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >>if (bridge->funcs->detach)
> >>bridge->funcs->detach(bridge);
> >>
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >> +
> >>bridge->dev = NULL;
> >>  }
> >>
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index b656e505d11e..804189c63a4c 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> >>   * @list: to keep track of all added bridges
> >>   * @timings: the timing specification for the bridge, if any (may
> >>   * be NULL)
> >> + * @link: drm consumer <-> bridge supplier
> >
> > Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> > to the bridge" would be better.
> 
>  I meant "<->" to indicate that the link is bidirectional, not that the
>  relationship is in any way symmetric. I wasn't aware of any implication
>  of a symmetric relationship when using "<->", do you have a reference?
>  But I guess the different arrow notations in math are somewhat overloaded
>  and that someone at some point must have used "<->" to indicate a
>  symmetric relationship...
> >>>
> >>> Yeah I agree with Andrzej here, for me <-> implies a symmetric
> >>> relationship. Spelling it out like Andrzej suggested sounds like the
> >>> better idea.
> >>> -Daniel
> >>
> >> Ok, I guess that means I have to do a v3 after all. Or can this
> >> trivial documentation update be done by the committer? I hate to
> >> spam everyone with another volley...
> >>
> >> Or perhaps I should squash patches 2-23 that are all rather similar
> >> and mechanic? I separated them to allow for easier review from
> >> individual driver maintainers, but that didn't seem to happen
> >> anyway...
> > 
> > Do another volley of the full set, or in-reply-to to just replace the
> > patch that needs to be respun (but some people don't like that).
> > 
> > When resending just make sure you're picking up all the acks/r-bs you
> > have already.
> 
> 

Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Sergei Shtylyov]

Hello!

On 5/16/2018 10:54 AM, Simon Horman wrote:


Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.

Signed-off-by: Ulrich Hecht 
---
  drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 3d2d3bb..58fb9f8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info 
rcar_lvds_r8a77970_info = {
.quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
  };
  
+static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {

+   .gen = 3,
+   .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
+};


This new structure seems to be identical to rcar_lvds_r8a77970_info.

> Could we consolidate somehow?

   In my book, that one has 2 quirk flags. What tree are you looking at?

[...]

MBR, Sergei

Re: [PATCH v2 2/2] soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}

[Simon Horman]

On Wed, May 16, 2018 at 09:47:04AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 15, 2018 at 2:07 PM, Yoshihiro Shimoda
>  wrote:
> > This patch adds workaround for 3DG-{A,B} of R-Car E3 ES1.0 because
> > the SoC has a restriction about the order.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, accepted.

Re: [PATCH v2 1/2] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

[Simon Horman]

On Wed, May 16, 2018 at 09:45:30AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 15, 2018 at 2:07 PM, Yoshihiro Shimoda
>  wrote:
> > From: Takeshi Kihara 
> >
> > This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
> > A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.
> >
> > Signed-off-by: Takeshi Kihara 
> > [shimoda: fix 3DG-{A,B} and add SPDX-License-Identifier]
> > Signed-off-by: Yoshihiro Shimoda 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Geert Uytterhoeven]

Hi Florian,

Thanks for your series!
I like the effect on simplifying drivers.

On Wed, May 16, 2018 at 1:56 AM, Florian Fainelli  wrote:
> This patch series updates of_mdiobus_register() such that when the device_node
> argument is NULL, it calls mdiobus_register() directly. This is consistent 
> with
> the behavior of of_mdiobus_register() when CONFIG_OF=n.

IMHO the CONFIG_OF=n behavior of of_mdiobus_register() (which I wasn't
aware of) is inconsistent with the behavior of other of_*() functions,
which are just empty stubs.

So I'm wondering if you should do it the other way around, and let
mdiobus_register() call of_mdiobus_register() if dev->of_node exists?

This does mean mdiobus_register() should gain a struct device * parameter,
and thus changes to many more drivers are needed.

> I only converted the most obvious drivers, there are others that have a much
> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.

I haven't looked at the ACPI handling, but perhaps this can be moved
inside mdiobus_register() as well?

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 2/2] ARM: dts: r8a7740: Add CEU0

[Simon Horman]

On Wed, May 16, 2018 at 09:40:09AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Thu, Apr 26, 2018 at 8:24 PM, Jacopo Mondi  
> wrote:
> > Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> >
> > Reported-by: Geert Uytterhoeven 
> > Signed-off-by: Jacopo Mondi 
> 
> Thanks for your patch!
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> Minor question below.
> 
> > --- a/arch/arm/boot/dts/r8a7740.dtsi
> > +++ b/arch/arm/boot/dts/r8a7740.dtsi
> > @@ -67,6 +67,16 @@
> > power-domains = <_d4>;
> > };
> >
> > +   ceu0: ceu@fe91 {
> > +   reg = <0xfe91 0x3000>;
> > +   compatible = "renesas,r8a7740-ceu";
> > +   interrupts = ;
> > +   clocks = <_clks R8A7740_CLK_CEU20>;
> > +   clock-names = "ceu20";
> 
> Why the "clock-names" property? It's not mentioned in the DT bindings, and
> may cause issues if the bindings are ever amended.

I have dropped that property for now.

> 
> > +   power-domains = <_a4r>;
> > +   status = "disabled";
> > +   };
> > +
> 
> 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 4/5] arm64: dts: renesas: r8a77995-draak: add HDMI output

[Simon Horman]

On Tue, May 15, 2018 at 02:20:39PM +0200, Ulrich Hecht wrote:
> Adds LVDS decoder, HDMI encoder and connector for Draak boards.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 80 
> ++
>  1 file changed, 80 insertions(+)

This looks fine but I will wait to see if there are other reviews before
applying.

Reviewed-by: Simon Horman 

Re: [PATCH 3/5] arm64: dts: renesas: r8a77995: Add LVDS support

[Simon Horman]

On Tue, May 15, 2018 at 02:20:38PM +0200, Ulrich Hecht wrote:
> From: Kieran Bingham 
> 
> The r8a77995 D3 platform has 2 LVDS channels connected to the DU.
> 
> Signed-off-by: Kieran Bingham 
> [uli: moved lvds* into the soc node, added PM domains, resets]
> Signed-off-by: Ulrich Hecht 

This looks fine but I will wait to see if there are other reviews before
applying.

Reviewed-by: Simon Horman 

Re: [PATCH 1/5] drm: rcar-du: Add r8a77995 device support

[Simon Horman]

On Tue, May 15, 2018 at 02:20:36PM +0200, Ulrich Hecht wrote:
> From: Koji Matsuoka 
> 
> Add support for the R-Car D3 (R8A77995) SoC to the R-Car DU driver.
> 
> Signed-off-by: Koji Matsuoka 
> Signed-off-by: Ulrich Hecht 

Reviewed-by: Simon Horman 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 05745e8..ba82842 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -266,6 +266,31 @@ static const struct rcar_du_device_info 
> rcar_du_r8a77970_info = {
>   .num_lvds = 1,
>  };
>  
> +static const struct rcar_du_device_info rcar_du_r8a77995_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> +   | RCAR_DU_FEATURE_EXT_CTRL_REGS
> +   | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .num_crtcs = 2,
> + .routes = {
> + /* R8A77995 has two LVDS output and one RGB output.
> +  */
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(0) | BIT(1),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 1,
> + },
> + [RCAR_DU_OUTPUT_LVDS1] = {
> + .possible_crtcs = BIT(1),
> + .port = 2,
> + },
> + },
> + .num_lvds = 2,
> +};
> +
>  static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
>   { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> @@ -278,6 +303,7 @@ static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
>   { .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
>   { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
> + { .compatible = "renesas,du-r8a77995", .data = _du_r8a77995_info },
>   { }
>  };
>  
> -- 
> 2.7.4
> 

Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support

[Simon Horman]

On Tue, May 15, 2018 at 02:20:37PM +0200, Ulrich Hecht wrote:
> Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
> 
> Signed-off-by: Ulrich Hecht 
> ---
>  drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 3d2d3bb..58fb9f8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info 
> rcar_lvds_r8a77970_info = {
>   .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
>  };
>  
> +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
> + .gen = 3,
> + .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
> +};

This new structure seems to be identical to rcar_lvds_r8a77970_info.
Could we consolidate somehow?

> +
>  static const struct of_device_id rcar_lvds_of_table[] = {
>   { .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info 
> },
> @@ -519,6 +524,7 @@ static const struct of_device_id rcar_lvds_of_table[] = {
>   { .compatible = "renesas,r8a7795-lvds", .data = _lvds_gen3_info },
>   { .compatible = "renesas,r8a7796-lvds", .data = _lvds_gen3_info },
>   { .compatible = "renesas,r8a77970-lvds", .data = 
> _lvds_r8a77970_info },
> + { .compatible = "renesas,r8a77995-lvds", .data = 
> _lvds_r8a77995_info },
>   { }
>  };
>  
> -- 
> 2.7.4
> 

Re: [PATCH 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support

[Simon Horman]

On Tue, May 15, 2018 at 10:36:27AM +0200, jacopo mondi wrote:
> Hi Simon,
> 
> On Fri, May 11, 2018 at 03:35:14PM +0200, Simon Horman wrote:
> > On Fri, May 11, 2018 at 12:00:00PM +0200, Jacopo Mondi wrote:
> > > Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by
> > > rcar-vin driver.
> > >
> > > Signed-off-by: Jacopo Mondi 
> >
> > Reviewed-by: Simon Horman 
> >
> 
> Does this goes in through your tree? I will send a v2, should I
> include this one or you have collected it already?

No, it means I am reviewing it with the expectation that it will
go through someone else's tree. So if you need to post a v2 please include
this patch with my Reviewed-by tag.

Re: [PATCH v2 2/2] soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B}

[Geert Uytterhoeven]

On Tue, May 15, 2018 at 2:07 PM, Yoshihiro Shimoda
 wrote:
> This patch adds workaround for 3DG-{A,B} of R-Car E3 ES1.0 because
> the SoC has a restriction about the order.
>
> Signed-off-by: Yoshihiro Shimoda 

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 1/2] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

[Geert Uytterhoeven]

On Tue, May 15, 2018 at 2:07 PM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
> A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara 
> [shimoda: fix 3DG-{A,B} and add SPDX-License-Identifier]
> Signed-off-by: Yoshihiro Shimoda 

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 3/3] arm64: dts: renesas: r8a7795: add ccree binding

[Simon Horman]

On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
> Hi Gilad,
> 
> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef  wrote:
> > Add bindings for CryptoCell instance in the SoC.
> >
> > Signed-off-by: Gilad Ben-Yossef 
> 
> Thanks for your patch!
> 
> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> > @@ -528,6 +528,14 @@
> > status = "disabled";
> > };
> >
> > +   arm_cc630p: crypto@e6601000 {
> > +   compatible = "arm,cryptocell-630p-ree";
> > +   interrupts = ;
> > +   #interrupt-cells = <2>;
> 
> I believe the #interrupt-cells property is not needed.
> 
> > +   reg = <0x0 0xe6601000 0 0x1000>;
> > +   clocks = < CPG_MOD 229>;
> > +   };
> 
> The rest looks good, but I cannot verify the register block.
> 
> > +
> > i2c3: i2c@e66d {
> > #address-cells = <1>;
> > #size-cells = <0>;

Thanks, I have applied this after dropping the #interrupt-cells property.

Re: [PATCH v2] ARM: dts: r8a7740: Add CEU1

[Geert Uytterhoeven]

Hi Simon,

On Tue, May 15, 2018 at 10:00 AM, Simon Horman
 wrote:
> Describe CEU1 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
>
> Signed-off-by: Simon Horman 
> ---
> v2
> * Correct register range start address

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven 

Minor question below.

> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -77,6 +77,16 @@
> status = "disabled";
> };
>
> +   ceu1: ceu@fe914000 {
> +   reg = <0xfe914000 0x3000>;
> +   compatible = "renesas,r8a7740-ceu";
> +   interrupts = ;
> +   clocks = <_clks R8A7740_CLK_CEU21>;
> +   clock-names = "ceu21";

Why the "clock-names" property? It's not mentioned in the DT bindings, and
may cause issues if the bindings are ever amended.

> +   power-domains = <_a4r>;
> +   status = "disabled";
> +   };
> +

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 2/2] ARM: dts: r8a7740: Add CEU0

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Apr 26, 2018 at 8:24 PM, Jacopo Mondi  wrote:
> Describe CEU0 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
>
> Reported-by: Geert Uytterhoeven 
> Signed-off-by: Jacopo Mondi 

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven 

Minor question below.

> --- a/arch/arm/boot/dts/r8a7740.dtsi
> +++ b/arch/arm/boot/dts/r8a7740.dtsi
> @@ -67,6 +67,16 @@
> power-domains = <_d4>;
> };
>
> +   ceu0: ceu@fe91 {
> +   reg = <0xfe91 0x3000>;
> +   compatible = "renesas,r8a7740-ceu";
> +   interrupts = ;
> +   clocks = <_clks R8A7740_CLK_CEU20>;
> +   clock-names = "ceu20";

Why the "clock-names" property? It's not mentioned in the DT bindings, and
may cause issues if the bindings are ever amended.

> +   power-domains = <_a4r>;
> +   status = "disabled";
> +   };
> +

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 0/7] arm64: dts: renesas: enable VIN, CSI-2 and ADV7482

[Simon Horman]

On Wed, May 16, 2018 at 03:58:47AM +0200, Niklas Söderlund wrote:
> Hi Simon,
> 
> This series enable capture for H3, M3-W, M3-N Salvator-X and Salvator-XS 
> boards. It also adds the VIN and CSI-2 nodes for V3M, but as the ADV7482 
> is on the V3M expansion boards I have chosen not include that enablement 
> in this series.
> 
> Patch 1-5/6 adds the VIN and CSI-2 for each SoC, patch 5/6 adds the 
> ADV7482 to the common salvator-common.dtsi which is shared between all 
> Salvator-{X,XS} boards. And finally patch 6/6 set the status of the VINs 
> to okay.
> 
> The CSI-2 bindings are acked and in Sakaris branch for-4.18-6 [1]. All 
> VIN bindings except r8a77965 is already in the media tree [2]. The 
> r8a77965 compability string [3] have not yet been picked up but as it 
> just building on the already accepted pattern I see little risk. If this 
> troubles please disregard patch 4/6.
> 
> 1. https://git.linuxtv.org/sailus/media_tree.git/
> 2. https://git.linuxtv.org/media_tree.git/
> 3. https://patchwork.linuxtv.org/patch/49476/
> 
> Kieran Bingham (1):
>   arm64: dts: renesas: salvator-common: Add ADV7482 support
> 
> Niklas Söderlund (6):
>   arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes
>   arm64: dts: renesas: r8a7795-es1: add CSI-2 node
>   arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes
>   arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes
>   arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes
>   arm64: dts: renesas: salvator-common: enable VIN

Thanks, applied.

Re: [RFT] arm64: dts: r8a77965: add I2C support

[Simon Horman]

On Sun, May 13, 2018 at 01:48:33PM +0200, Niklas Söderlund wrote:
> Hi Simon,
> 
> On 2018-05-13 10:19:13 +0200, Simon Horman wrote:
> > On Fri, May 11, 2018 at 04:00:29PM +0200, Niklas Söderlund wrote:
> > > Signed-off-by: Niklas Söderlund 
> > > ---
> > >  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 99 ---
> > >  1 file changed, 90 insertions(+), 9 deletions(-)
> > > 
> > > Hi Simon,
> > > 
> > > I have only tested i2c4 and the adv7482 which is connected there. But it 
> > > seemed silly to post this patch without enable all i2c as they are 
> > > according to the datasheet are the same as on H3 and M3-W.
> > 
> > Thanks Niklas,
> > 
> > I agree this makes sense. Do we have any way to test those nodes?
> 
> Looking at the DT for M3-N the i2c busses used are i2c2 and i2c4. I 
> already verified i2c4 and for i2c2 it turned out some PFC parts where 
> missing, I just sent a patch for that [1]. Using that patch i2c2 also 
> successfully finds the devices described in DT.
> 
> > If not I'm inclined to accept the patch without testing.
> 
> I also think it would be OK for you to pickup this patch without testing 
> all the buses.
> 
> 1. [PATCH] pinctrl: sh-pfc: r8a77965: Add I2C pin support

Thanks, applied.

Re: [PATCH 4/4] arm64: dts: renesas: r8a77990: ebisu: Enable EthernetAVB

[Simon Horman]

On Sun, May 13, 2018 at 11:28:58AM +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 01:31:21PM +0900, Yoshihiro Shimoda wrote:
> > This patch enables EthernetAVB for r8a77990 Ebisu board.
> > 
> > Based on a patch from Takeshi Kihara 
> > 
> > Signed-off-by: Yoshihiro Shimoda 
> 
> This looks fine but I will wait to see if there are other reviews before
> applying.
> 
> Reviewed-by: Simon Horman 

Applied.

Re: [PATCH 3/4] arm64: dts: renesas: r8a77990: Add EthernetAVB device nodes

[Simon Horman]

On Sun, May 13, 2018 at 11:16:16AM +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 01:31:20PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds EthernetAVB node for r8a77990 (R-Car E3).
> > 
> > Based on a patch from Takeshi Kihara 
> > 
> > Signed-off-by: Yoshihiro Shimoda 
> 
> This looks fine but I will wait to see if there are other reviews before
> applying.
> 
> Reviewed-by: Simon Horman 

Applied.

Re: [PATCH 2/4] arm64: dts: renesas: r8a77990: Add GPIO device nodes

[Simon Horman]

On Sun, May 13, 2018 at 11:02:05AM +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 01:31:19PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds GPIO nodes for r8a77990 (R-Car E3).
> > 
> > Based on a patch from Takeshi Kihara 
> > 
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a77990.dtsi | 112 
> > ++
> >  1 file changed, 112 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi 
> > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > index efc3c0b..d94e047 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > @@ -60,6 +60,118 @@
> > #size-cells = <2>;
> > ranges;
> >  
> > +   gpio0: gpio@e605 {
> > +   compatible = "renesas,gpio-r8a77990",
> > +"renesas,rcar-gen3-gpio",
> > +"renesas,gpio-rcar";
> 
> "renesas,gpio-rcar" is deprecated and thus should not be added to DT any
> more. I will see about removing it from r8a77995.dtsi which seems to be the
> only place that it used in mainline.
> 
> Otherwise this patch looks good to me.

I have applied this patch after removing "renesas,gpio-rcar".

The result is as follows.


From: Yoshihiro Shimoda 
Subject: [PATCH] arm64: dts: renesas: r8a77990: Add GPIO device nodes

This patch adds GPIO nodes for r8a77990 (R-Car E3).

Based on a patch from Takeshi Kihara 

Signed-off-by: Yoshihiro Shimoda 
[simon: dropped use of deprecated "renesas,gpio-rcar"]
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 105 ++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index efc3c0ba36c2..bbc3db50bc01 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -60,6 +60,111 @@
#size-cells = <2>;
ranges;
 
+   gpio0: gpio@e605 {
+   compatible = "renesas,gpio-r8a77990",
+"renesas,rcar-gen3-gpio";
+   reg = <0 0xe605 0 0x50>;
+   interrupts = ;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-ranges = < 0 0 18>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   clocks = < CPG_MOD 912>;
+   power-domains = < 32>;
+   resets = < 912>;
+   };
+
+   gpio1: gpio@e6051000 {
+   compatible = "renesas,gpio-r8a77990",
+"renesas,rcar-gen3-gpio";
+   reg = <0 0xe6051000 0 0x50>;
+   interrupts = ;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-ranges = < 0 32 23>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   clocks = < CPG_MOD 911>;
+   power-domains = < 32>;
+   resets = < 911>;
+   };
+
+   gpio2: gpio@e6052000 {
+   compatible = "renesas,gpio-r8a77990",
+"renesas,rcar-gen3-gpio";
+   reg = <0 0xe6052000 0 0x50>;
+   interrupts = ;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-ranges = < 0 64 26>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   clocks = < CPG_MOD 910>;
+   power-domains = < 32>;
+   resets = < 910>;
+   };
+
+   gpio3: gpio@e6053000 {
+   compatible = "renesas,gpio-r8a77990",
+"renesas,rcar-gen3-gpio";
+   reg = <0 0xe6053000 0 0x50>;
+   interrupts = ;
+   #gpio-cells = <2>;
+   gpio-controller;
+   gpio-ranges = < 0 96 16>;
+   #interrupt-cells = <2>;
+   interrupt-controller;
+   clocks = < CPG_MOD 909>;
+   power-domains = < 32>;
+   resets = < 909>;
+   };
+
+   gpio4: gpio@e6054000 {
+   compatible = "renesas,gpio-r8a77990",
+"renesas,rcar-gen3-gpio";
+   

Re: [PATCH 1/4] arm64: dts: renesas: r8a77990: Add PFC device node

[Simon Horman]

On Mon, May 14, 2018 at 10:27:21PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Sun, May 13, 2018 at 10:14 AM, Simon Horman  wrote:
> > On Fri, May 11, 2018 at 01:31:18PM +0900, Yoshihiro Shimoda wrote:
> >> This patch adds PFC device node for r8a77990 (R-Car E3).
> >>
> >> Signed-off-by: Yoshihiro Shimoda 
> >> ---
> >>  arch/arm64/boot/dts/renesas/r8a77990.dtsi | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi 
> >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> index 4658029..efc3c0b 100644
> >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >> @@ -60,6 +60,11 @@
> >>   #size-cells = <2>;
> >>   ranges;
> >>
> >> + pfc: pin-controller@e606 {
> >> + compatible = "renesas,pfc-r8a77990";
> >> + reg = <0 0xe606 0 0x508>;
> >> + };
> >
> > Here the register size is 0x508 which matches r8a77995.dtsi in mainline.
> > Other variants there are:
> > * 0x50c: r8a7795.dtsi, r8a77965.dtsi, r8a7796.dtsi
> > * 0x504: r8a77970.dtsi
> 
> The number of registers is SoC-specific.
> R-Car H3, M3-W, and M3-N share PFC documentation.
> 
> > My reading of the documentation is that the size of the register range is
> > 0x50c. So I suggest we either use that value consistently or move to a
> > larger value after some rounding-up. Geert?
> 
> According to Section 6D ("Pin Function Controller (PFC)" for R-Car E3)
> of the datasheet, the last register is at offset 0x504, so length 0x508 is
> correct.
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks for the explanation, applied.

Re: [PATCH 2/2] arm64: dts: renesas: initial V3HSK board device tree

[Simon Horman]

On Sun, May 13, 2018 at 10:07:04AM +0200, Simon Horman wrote:
> On Thu, May 10, 2018 at 09:12:30PM +0300, Sergei Shtylyov wrote:
> > Add the initial device  tree for  the V3H Starter Kit board.
> > The board has 1 debug serial port (SCIF0); include support for it,
> > so that the serial console can work.
> > 
> > Based on the original (and large) patch by Vladimir Barinov.
> > 
> > Signed-off-by: Vladimir Barinov 
> > Signed-off-by: Sergei Shtylyov 
> 
> This looks fine but I will wait to see if there are other reviews before
> applying.
> 
> Reviewed-by: Simon Horman 

Applied

Re: [PATCH v2] ARM: dts: r8a7740: Add CEU1

[Simon Horman]

On Tue, May 15, 2018 at 10:23:10AM +0200, jacopo mondi wrote:
> Hi Simon,
> 
> On Tue, May 15, 2018 at 10:00:38AM +0200, Simon Horman wrote:
> > Describe CEU1 peripheral for Renesas R-Mobile A1 R8A7740 Soc.
> >
> > Signed-off-by: Simon Horman 
> 
> Reviewed-by: Jacopo Mondi 

Thanks, applied.

Re: [PATCH] ARM: multi_v7_defconfig: Enable RENESAS_WDT

[Simon Horman]

On Wed, May 02, 2018 at 11:43:53AM +0200, Simon Horman wrote:
> R-Car Gen2 and RZ/G1 platforms come with a watchdog IP, therefore enable
> its driver by default. It is enabled as a module to avoid increasing
> the kernel image size.
> 
> Signed-off-by: Simon Horman 

Applied.

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Antoine Tenart]

Hi Florian,

On Tue, May 15, 2018 at 04:56:19PM -0700, Florian Fainelli wrote:
> A number of drivers have the following pattern:
> 
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
> 
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/dsa/bcm_sf2.c |  8 ++--
>  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>  drivers/net/ethernet/marvell/mvmdio.c |  5 +

For mvmdio,
Reviewed-by: Antoine Tenart 

Thanks!
Antoine

>  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
>  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
>  drivers/net/phy/mdio-gpio.c   |  6 +-
>  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>  drivers/net/usb/lan78xx.c |  7 ++-
>  11 files changed, 20 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index ac621f44237a..02e8982519ce 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
>   priv->slave_mii_bus->parent = ds->dev->parent;
>   priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
>  
> - if (dn)
> - err = of_mdiobus_register(priv->slave_mii_bus, dn);
> - else
> - err = mdiobus_register(priv->slave_mii_bus);
> -
> - if (err)
> + err = of_mdiobus_register(priv->slave_mii_bus, dn);
> + if (err && dn)
>   of_node_put(dn);
>  
>   return err;
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c 
> b/drivers/net/dsa/mv88e6xxx/chip.c
> index b23c11d9f4b2..2bb3f03ee1cb 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct 
> mv88e6xxx_chip *chip,
>   return err;
>   }
>  
> - if (np)
> - err = of_mdiobus_register(bus, np);
> - else
> - err = mdiobus_register(bus);
> + err = of_mdiobus_register(bus, np);
>   if (err) {
>   dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
>   mv88e6xxx_g2_irq_mdio_free(chip, bus);
> diff --git a/drivers/net/ethernet/cadence/macb_main.c 
> b/drivers/net/ethernet/cadence/macb_main.c
> index b4c9268100bb..3e93df5d4e3b 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
>   dev_set_drvdata(>dev->dev, bp->mii_bus);
>  
>   np = bp->pdev->dev.of_node;
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
>  
> - if (np) {
> - err = of_mdiobus_register(bp->mii_bus, np);
> - } else {
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> - err = mdiobus_register(bp->mii_bus);
> - }
> -
> + err = of_mdiobus_register(bp->mii_bus, np);
>   if (err)
>   goto err_out_free_mdiobus;
>  
> diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc8eb5b..f3e43db0d6cb 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
> *pdev)
>   fep->mii_bus->parent = >dev;
>  
>   node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> - if (node) {
> - err = of_mdiobus_register(fep->mii_bus, node);
> + err = of_mdiobus_register(fep->mii_bus, node);
> + if (node)
>   of_node_put(node);
> - } else {
> - err = mdiobus_register(fep->mii_bus);
> - }
> -
>   if (err)
>   goto err_out_free_mdiobus;
>  
> diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
> b/drivers/net/ethernet/marvell/mvmdio.c
> index 0495487f7b42..c5dac6bd2be4 100644
> --- a/drivers/net/ethernet/marvell/mvmdio.c
> +++ b/drivers/net/ethernet/marvell/mvmdio.c
> @@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
>   goto out_mdio;
>   }
>  
> - if (pdev->dev.of_node)
> - ret = of_mdiobus_register(bus, pdev->dev.of_node);
> - else
> - ret = mdiobus_register(bus);
> + ret = of_mdiobus_register(bus, pdev->dev.of_node);
>   if (ret < 0) {
>   dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
>   goto out_mdio;
> diff --git