RE: [PATCH v5] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Yoshihiro Shimoda]

Hi Heikki,

> From: Heikki Krogerus, Sent: Monday, May 28, 2018 10:05 PM
> 
> On Fri, May 25, 2018 at 04:12:56PM +0900, Yoshihiro Shimoda wrote:
> > @@ -2573,6 +2635,12 @@ static void renesas_usb3_init_ram(struct 
> > renesas_usb3 *usb3, struct device *dev,
> > EXTCON_NONE,
> >  };
> >
> > +static struct usb_role_switch_desc renesas_usb3_role_switch_desc = {
> 
> You can constify that.

Thank you for the review! I'll modify this in v6 patch.

Best regards,
Yoshihiro Shimoda

> > +   .set = renesas_usb3_role_switch_set,
> > +   .get = renesas_usb3_role_switch_get,
> > +   .allow_userspace_control = true,
> > +};
> > +
> >  static int renesas_usb3_probe(struct platform_device *pdev)
> >  {
> > struct renesas_usb3 *usb3;
> 
> Thanks,
> 
> --
> heikki

RE: [PATCH v5] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Yoshihiro Shimoda]

Hi Andy,

Thank you for your review!

> From: Andy Shevchenko, Sent: Monday, May 28, 2018 9:47 PM
> 
> On Fri, May 25, 2018 at 10:12 AM, Yoshihiro Shimoda
>  wrote:
> 
> > -static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> 
> Wouldn't be better to choose another name for a new function?

I got it. I'll choose another name for a new function as 
"usb3_set_mode_by_role_sw".

> > +   struct renesas_usb3 *usb3 = container_of(work, struct renesas_usb3,
> > +role_work);
> 
> Matter of style, though I would rather put entire container_of() on
> the next line (see for the existing style in the module and use it).

I got it. I'll modify that.

> > +   /* This device_attach() might sleep */
> > +   if (device_attach(host) < 0)
> > +   dev_err(dev, "device_attach(usb3_port) failed\n");
> 
> can't be "usb3_port" part derived from the host variable somehow and
> to some extend?

Oops. I should describe "host" instead of "usb3_port".

> > +   usb3->role_sw = usb_role_switch_register(>dev,
> > +   _usb3_role_switch_desc);
> > +   if (!IS_ERR(usb3->role_sw)) {
> 
> > +   usb3->host_dev = usb_of_get_companion_dev(>dev);
> 
> Hmm... Can it possible return -EPROBE_DEFER? If so, would it be better
> to use other approach to handle it?

Does this "it" mean " usb_of_get_companion_dev()"? If so, it is not possible
to return -EPROBE_DEFER.
Or, " usb_role_switch_register()"? Also this function is not possible to
return -EPROBE_DEFER, IIUC.

> > +   if (IS_ERR_OR_NULL(usb3->host_dev)) {

So, I can just use "if (!usb3->host_dev) {" instead of above.

Best regards,
Yoshihiro Shimoda

> > +   /* If not found, this driver will not use a role sw 
> > */
> > +   usb_role_switch_unregister(usb3->role_sw);
> > +   usb3->role_sw = NULL;
> > +   }
> > +   } else {
> > +   usb3->role_sw = NULL;
> > +   }
> 
> 
> --
> With Best Regards,
> Andy Shevchenko

Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI

[Kuninori Morimoto]

Hi Geert

> > +_con {
> > +   remote-endpoint = <_dw_hdmi0_out>;
> > +};
> 
> I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
> Can we do that now (with stubs?), or does this have to wait until r8a77965 has
> received HDMI sound support?

HDMI sound doesn't use hdmi0_con.
You can do it now, thanks

Best regards
---
Kuninori Morimoto

Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties

[Dmitry Osipenko]

On 29.05.2018 02:48, Dmitry Osipenko wrote:
> inversion=true" if mask has form of 0x11000111, though this could be not

For clarity: I meant s/0x11000111/0xFF000FFF/.

Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties

[Dmitry Osipenko]

On 28.05.2018 16:15, Ville Syrjälä wrote:
> On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
>> Color keying is the action of replacing pixels matching a given color
>> (or range of colors) with transparent pixels in an overlay when
>> performing blitting. Depending on the hardware capabilities, the
>> matching pixel can either become fully transparent or gain adjustment
>> of the pixels component values.
>>
>> Color keying is found in a large number of devices whose capabilities
>> often differ, but they still have enough common features in range to
>> standardize color key properties. This commit adds nine generic DRM plane
>> properties related to the color keying to cover various HW capabilities.
>>
>> This patch is based on the initial work done by Laurent Pinchart, most of
>> credits for this patch goes to him.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/gpu/drm/drm_atomic.c |  36 ++
>>  drivers/gpu/drm/drm_blend.c  | 229 +++
>>  include/drm/drm_blend.h  |   3 +
>>  include/drm/drm_plane.h  |  77 
>>  4 files changed, 345 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 895741e9cd7d..5b808cb68654 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct 
>> drm_plane *plane,
>>  state->rotation = val;
>>  } else if (property == plane->zpos_property) {
>>  state->zpos = val;
>> +} else if (property == plane->colorkey.mode_property) {
>> +state->colorkey.mode = val;
>> +} else if (property == plane->colorkey.min_property) {
>> +state->colorkey.min = val;
>> +} else if (property == plane->colorkey.max_property) {
>> +state->colorkey.max = val;
>> +} else if (property == plane->colorkey.format_property) {
>> +state->colorkey.format = val;
>> +} else if (property == plane->colorkey.mask_property) {
>> +state->colorkey.mask = val;
>> +} else if (property == plane->colorkey.inverted_match_property) {
>> +state->colorkey.inverted_match = val;
>> +} else if (property == plane->colorkey.replacement_mask_property) {
>> +state->colorkey.replacement_mask = val;
>> +} else if (property == plane->colorkey.replacement_value_property) {
>> +state->colorkey.replacement_value = val;
>> +} else if (property == plane->colorkey.replacement_format_property) {
>> +state->colorkey.replacement_format = val;
>>  } else if (property == plane->color_encoding_property) {
>>  state->color_encoding = val;
>>  } else if (property == plane->color_range_property) {
>> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>>  *val = state->rotation;
>>  } else if (property == plane->zpos_property) {
>>  *val = state->zpos;
>> +} else if (property == plane->colorkey.mode_property) {
>> +*val = state->colorkey.mode;
>> +} else if (property == plane->colorkey.min_property) {
>> +*val = state->colorkey.min;
>> +} else if (property == plane->colorkey.max_property) {
>> +*val = state->colorkey.max;
>> +} else if (property == plane->colorkey.format_property) {
>> +*val = state->colorkey.format;
>> +} else if (property == plane->colorkey.mask_property) {
>> +*val = state->colorkey.mask;
>> +} else if (property == plane->colorkey.inverted_match_property) {
>> +*val = state->colorkey.inverted_match;
>> +} else if (property == plane->colorkey.replacement_mask_property) {
>> +*val = state->colorkey.replacement_mask;
>> +} else if (property == plane->colorkey.replacement_value_property) {
>> +*val = state->colorkey.replacement_value;
>> +} else if (property == plane->colorkey.replacement_format_property) {
>> +*val = state->colorkey.replacement_format;
>>  } else if (property == plane->color_encoding_property) {
>>  *val = state->color_encoding;
>>  } else if (property == plane->color_range_property) {
>> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
>> index a16a74d7e15e..05e5632ce375 100644
>> --- a/drivers/gpu/drm/drm_blend.c
>> +++ b/drivers/gpu/drm/drm_blend.c
>> @@ -107,6 +107,11 @@
>>   *  planes. Without this property the primary plane is always below the 
>> cursor
>>   *  plane, and ordering between all other planes is undefined.
>>   *
>> + * colorkey:
>> + *  Color keying is set up with drm_plane_create_colorkey_properties().
>> + *  It adds support for replacing a range of colors with a transparent
>> + *  color in the plane.
>> + *
>>   * Note that all the property extensions described here apply either to the
>>   * plane or the CRTC (e.g. for the background color, which 

[PATCH v2] media: rcar-vin: enable support for r8a77965

[Niklas Söderlund]

Add the SoC specific information for Renesas r8a77965.

Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 

---

* Changes since v1
- Fixed typo in variable name,
  s/_rcar_info_r8a77965_routes/rcar_info_r8a77965_routes/.
- Collected Laurents tag.
---
 drivers/media/platform/rcar-vin/rcar-core.c | 48 +
 1 file changed, 48 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index d3072e166a1ca24f..e6a010ee4ba1f671 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -974,6 +974,50 @@ static const struct rvin_info rcar_info_r8a7796 = {
.routes = rcar_info_r8a7796_routes,
 };
 
+static const struct rvin_group_route rcar_info_r8a77965_routes[] = {
+   { .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
+   { .csi = RVIN_CSI20, .channel = 0, .vin = 0, .mask = BIT(1) | BIT(4) },
+   { .csi = RVIN_CSI40, .channel = 1, .vin = 0, .mask = BIT(2) },
+   { .csi = RVIN_CSI20, .channel = 0, .vin = 1, .mask = BIT(0) },
+   { .csi = RVIN_CSI40, .channel = 1, .vin = 1, .mask = BIT(1) | BIT(3) },
+   { .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
+   { .csi = RVIN_CSI20, .channel = 1, .vin = 1, .mask = BIT(4) },
+   { .csi = RVIN_CSI20, .channel = 1, .vin = 2, .mask = BIT(0) },
+   { .csi = RVIN_CSI40, .channel = 0, .vin = 2, .mask = BIT(1) },
+   { .csi = RVIN_CSI20, .channel = 0, .vin = 2, .mask = BIT(2) },
+   { .csi = RVIN_CSI40, .channel = 2, .vin = 2, .mask = BIT(3) },
+   { .csi = RVIN_CSI20, .channel = 2, .vin = 2, .mask = BIT(4) },
+   { .csi = RVIN_CSI40, .channel = 1, .vin = 3, .mask = BIT(0) },
+   { .csi = RVIN_CSI20, .channel = 1, .vin = 3, .mask = BIT(1) | BIT(2) },
+   { .csi = RVIN_CSI40, .channel = 3, .vin = 3, .mask = BIT(3) },
+   { .csi = RVIN_CSI20, .channel = 3, .vin = 3, .mask = BIT(4) },
+   { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
+   { .csi = RVIN_CSI20, .channel = 0, .vin = 4, .mask = BIT(1) | BIT(4) },
+   { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
+   { .csi = RVIN_CSI20, .channel = 0, .vin = 5, .mask = BIT(0) },
+   { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
+   { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
+   { .csi = RVIN_CSI20, .channel = 1, .vin = 5, .mask = BIT(4) },
+   { .csi = RVIN_CSI20, .channel = 1, .vin = 6, .mask = BIT(0) },
+   { .csi = RVIN_CSI40, .channel = 0, .vin = 6, .mask = BIT(1) },
+   { .csi = RVIN_CSI20, .channel = 0, .vin = 6, .mask = BIT(2) },
+   { .csi = RVIN_CSI40, .channel = 2, .vin = 6, .mask = BIT(3) },
+   { .csi = RVIN_CSI20, .channel = 2, .vin = 6, .mask = BIT(4) },
+   { .csi = RVIN_CSI40, .channel = 1, .vin = 7, .mask = BIT(0) },
+   { .csi = RVIN_CSI20, .channel = 1, .vin = 7, .mask = BIT(1) | BIT(2) },
+   { .csi = RVIN_CSI40, .channel = 3, .vin = 7, .mask = BIT(3) },
+   { .csi = RVIN_CSI20, .channel = 3, .vin = 7, .mask = BIT(4) },
+   { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a77965 = {
+   .model = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+   .routes = rcar_info_r8a77965_routes,
+};
+
 static const struct rvin_group_route _rcar_info_r8a77970_routes[] = {
{ .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
{ .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
@@ -1030,6 +1074,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a7796",
.data = _info_r8a7796,
},
+   {
+   .compatible = "renesas,vin-r8a77965",
+   .data = _info_r8a77965,
+   },
{
.compatible = "renesas,vin-r8a77970",
.data = _info_r8a77970,
-- 
2.17.0

[PATCH v2] 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 written 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 outputting 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 

---

* Changes since v1
- Fix spelling in commit message pointed out by Sergei.
  s/writing/written/ and s/outputing/outputting/.
---
 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 v2] 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 
Reviewed-by: Rob Herring 

---

* Changes since v1.
- Fixed spelling reported by Sergei, s/then/than/.
- Collected Rob's tag.
---
 .../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..f8b50f8a3a0bd5d3 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 than 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

Re: [PATCH v3] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

Hi Eric,

On Mon, May 28, 2018 at 10:27 PM, Auger Eric  wrote:
> On 05/28/2018 05:26 PM, Geert Uytterhoeven wrote:
>> If a device is part of a PM Domain (e.g. power and/or clock domain), its
>> power state is managed using Runtime PM.  Without Runtime PM, the device
>> may not be powered up or clocked, causing subtle failures, crashes, or
>> system lock-ups when the device is accessed by the guest.
>>
>> Fix this by adding Runtime PM support, powering the device when the VFIO
>> device is opened by the guest.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> Reviewed-by: Simon Horman 
>> ---
>> v3:
>>   - Drop controversial note about unsafeness of exporting fine-grained
>> power management from host to guest,
> thanks ;-)
>
>>
>> v2:
>>   - Improve wording,
>>   - Add Reviewed-by.
>> ---
>>  drivers/vfio/platform/vfio_platform_common.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
>> b/drivers/vfio/platform/vfio_platform_common.c
>> index b60bb5326668498c..41f862f055054543 100644
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -233,6 +234,8 @@ static void vfio_platform_release(void *device_data)
>>   const char *extra_dbg = NULL;
>>   int ret;
>>
>> + pm_runtime_put(vdev->device);
>
>> +
>>   ret = vfio_platform_call_reset(vdev, _dbg);
> While reading the code again, the reset is using the HW. Don't you want
> to call the get() before.

Thanks, you're right, it's safer to do the reset here first...

>>   if (ret && vdev->reset_required) {
>>   dev_warn(vdev->device, "reset driver is required and 
>> reset call failed in release (%d) %s\n",
>> @@ -275,6 +278,10 @@ static int vfio_platform_open(void *device_data)
>>ret, extra_dbg ? extra_dbg : "");
>>   goto err_rst;
>>   }
>> +
>> + ret = pm_runtime_get_sync(vdev->device);

... and to do the reset here last.

Will fix and send v4.

>> + if (ret < 0)
>> + goto err_rst;
>>   }
>>
>>   vdev->refcnt++;
>> @@ -690,6 +697,7 @@ int vfio_platform_probe_common(struct 
>> vfio_platform_device *vdev,
>>
>>   mutex_init(>igate);
>>
>> + pm_runtime_enable(vdev->device);
>>   return 0;
>>
>>  put_iommu:
>> @@ -707,6 +715,7 @@ struct vfio_platform_device 
>> *vfio_platform_remove_common(struct device *dev)
>>   vdev = vfio_del_group_dev(dev);
>>
>>   if (vdev) {
>> + pm_runtime_disable(vdev->device);
>>   vfio_platform_put_reset(vdev);
>>   vfio_iommu_group_put(dev->iommu_group, dev);
>>   }

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 v3 0/2] Add R8A77980/Condor I2C support

[Sergei Shtylyov]

Sorry, "v3" shouldn't be there in the subject...

[PATCH 1/2] arm64: dts: renesas: r8a77980: add I2C support

[Sergei Shtylyov]

Define the generic R8A77980 parts of the I2C[0-5] device node.

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

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

---
 arch/arm64/boot/dts/renesas/r8a77980.dtsi |  111 ++
 1 file changed, 111 insertions(+)

Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -16,6 +16,15 @@
#address-cells = <2>;
#size-cells = <2>;
 
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   i2c5 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -135,6 +144,108 @@
#power-domain-cells = <1>;
};
 
+   i2c0: i2c@e650 {
+   compatible = "renesas,i2c-r8a77980",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe650 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 931>;
+   power-domains = < R8A77980_PD_ALWAYS_ON>;
+   resets = < 931>;
+   dmas = < 0x91>, < 0x90>,
+  < 0x91>, < 0x90>;
+   dma-names = "tx", "rx", "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@e6508000 {
+   compatible = "renesas,i2c-r8a77980",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe6508000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 930>;
+   power-domains = < R8A77980_PD_ALWAYS_ON>;
+   resets = < 930>;
+   dmas = < 0x93>, < 0x92>,
+  < 0x93>, < 0x92>;
+   dma-names = "tx", "rx", "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@e651 {
+   compatible = "renesas,i2c-r8a77980",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe651 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 929>;
+   power-domains = < R8A77980_PD_ALWAYS_ON>;
+   resets = < 929>;
+   dmas = < 0x95>, < 0x94>,
+  < 0x95>, < 0x94>;
+   dma-names = "tx", "rx", "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@e66d {
+   compatible = "renesas,i2c-r8a77980",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe66d 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 928>;
+   power-domains = < R8A77980_PD_ALWAYS_ON>;
+   resets = < 928>;
+   dmas = < 0x97>, < 0x96>,
+  < 0x97>, < 0x96>;
+   dma-names = "tx", "rx", "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c4: i2c@e66d8000 {
+   compatible = "renesas,i2c-r8a77980",
+"renesas,rcar-gen3-i2c";
+   reg = <0 0xe66d8000 0 0x40>;
+   interrupts = ;
+   clocks = < CPG_MOD 927>;
+   power-domains = < R8A77980_PD_ALWAYS_ON>;
+   resets = < 927>;
+   dmas = < 0x99>, < 0x98>,
+  < 0x99>, < 0x98>;
+   dma-names = "tx", "rx", "tx", "rx";
+   i2c-scl-internal-delay-ns = <6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c5: i2c@e66e {
+   compatible = "renesas,i2c-r8a77980",
+

[PATCH 2/2] arm64: dts: renesas: condor: add I2C0 support

[Sergei Shtylyov]

Define the Condor board dependent part of the I2C0 device node.

The I2C0 bus is populated by 2 ON Semiconductor PCA9654 I/O expanders
and Analog Devices  ADV7511W HDMI transmitter (but we're only describing
the former chips now).

Signed-off-by: Sergei Shtylyov 

---
 arch/arm64/boot/dts/renesas/r8a77980-condor.dts |   27 
 1 file changed, 27 insertions(+)

Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -80,6 +80,28 @@
clock-frequency = <32768>;
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   io_expander0: gpio@20 {
+   compatible = "onnn,pca9654";
+   reg = <0x20>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   io_expander1: gpio@21 {
+   compatible = "onnn,pca9654";
+   reg = <0x21>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-1 = <_pins_uhs>;
@@ -104,6 +126,11 @@
function = "canfd0";
};
 
+   i2c0_pins: i2c0 {
+   groups = "i2c0";
+   function = "i2c0";
+   };
+
mmc_pins: mmc {
groups = "mmc_data8", "mmc_ctrl", "mmc_ds";
function = "mmc";

[PATCH] i2c: rcar: document R8A77980 bindings

[Sergei Shtylyov]

R-Car V3H (R8A77980) SoC also has the R-Car gen3 compatible I2C controller,
so document the SoC  specific bindings.

Signed-off-by: Sergei Shtylyov 

---
The patch is against Wolfram Sang's 'linux.git' repo's 'i2c/for-next' branch
but I wouldn't mind if it was applied to the 'i2c/for-current' branch. :-)

 Documentation/devicetree/bindings/i2c/i2c-rcar.txt |1 +
 1 file changed, 1 insertion(+)

Index: linux/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
===
--- linux.orig/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ linux/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -15,6 +15,7 @@ Required properties:
"renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
"renesas,i2c-r8a77965" if the device is a part of a R8A77965 SoC.
"renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC.
+   "renesas,i2c-r8a77980" if the device is a part of a R8A77980 SoC.
"renesas,i2c-r8a77995" if the device is a part of a R8A77995 SoC.
"renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible

[PATCH v3 0/2] Add R8A77980/Condor I2C support

[Sergei Shtylyov]

Hello!

Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180528-v4.17-rc7' tag. We're adding the R8A77980 I2C nodes
and then describing 2 PCA9654 I/O expanders connected to the I2C0 bus on
the Condor board.

[1/2] arm64: dts: renesas: r8a77980: add I2C support
[2/2] arm64: dts: renesas: condor: add I2C0 support

WBR, Sergei

Re: [PATCH v3] vfio: platform: Fix using devices in PM Domains

[Auger Eric]

Hi Geert,

On 05/28/2018 05:26 PM, Geert Uytterhoeven wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM.  Without Runtime PM, the device
> may not be powered up or clocked, causing subtle failures, crashes, or
> system lock-ups when the device is accessed by the guest.
> 
> Fix this by adding Runtime PM support, powering the device when the VFIO
> device is opened by the guest.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 
> ---
> v3:
>   - Drop controversial note about unsafeness of exporting fine-grained
> power management from host to guest,
thanks ;-)

> 
> v2:
>   - Improve wording,
>   - Add Reviewed-by.
> ---
>  drivers/vfio/platform/vfio_platform_common.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..41f862f055054543 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -233,6 +234,8 @@ static void vfio_platform_release(void *device_data)
>   const char *extra_dbg = NULL;
>   int ret;
>  
> + pm_runtime_put(vdev->device);

> +
>   ret = vfio_platform_call_reset(vdev, _dbg);
While reading the code again, the reset is using the HW. Don't you want
to call the get() before.

Thanks

Eric
>   if (ret && vdev->reset_required) {
>   dev_warn(vdev->device, "reset driver is required and 
> reset call failed in release (%d) %s\n",
> @@ -275,6 +278,10 @@ static int vfio_platform_open(void *device_data)
>ret, extra_dbg ? extra_dbg : "");
>   goto err_rst;
>   }
> +
> + ret = pm_runtime_get_sync(vdev->device);
> + if (ret < 0)
> + goto err_rst;
>   }
>  
>   vdev->refcnt++;
> @@ -690,6 +697,7 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>  
>   mutex_init(>igate);
>  
> + pm_runtime_enable(vdev->device);
>   return 0;
>  
>  put_iommu:
> @@ -707,6 +715,7 @@ struct vfio_platform_device 
> *vfio_platform_remove_common(struct device *dev)
>   vdev = vfio_del_group_dev(dev);
>  
>   if (vdev) {
> + pm_runtime_disable(vdev->device);
>   vfio_platform_put_reset(vdev);
>   vfio_iommu_group_put(dev->iommu_group, dev);
>   }
> 

[PATCH v2] arm64: dts: salvator-x(s): Update I2C ch4 clock to 400kHz

[Wolfram Sang]

From: Takeshi Kihara 

Any of the following devices connected to I2C ch4 of the Salvator-X(S)
boards will operate at 400 kHz:

PCA9654, 9FGV0841, ADV7482WBBCZ, MAX9611, 5P49V5923, 5P49V6901A

This patch updates the clock frequency to 400 KHz.

Signed-off-by: Takeshi Kihara 
[wsa: squashed commits into one]
Signed-off-by: Wolfram Sang 
---

Changes since V1:
* squashed commits into single one

 arch/arm64/boot/dts/renesas/salvator-x.dtsi  | 2 ++
 arch/arm64/boot/dts/renesas/salvator-xs.dtsi | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-x.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
index 468868c8ed9f..2828482eba1c 100644
--- a/arch/arm64/boot/dts/renesas/salvator-x.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-x.dtsi
@@ -20,6 +20,8 @@
 };
 
  {
+   clock-frequency = <40>;
+
versaclock5: clock-generator@6a {
compatible = "idt,5p49v5923";
reg = <0x6a>;
diff --git a/arch/arm64/boot/dts/renesas/salvator-xs.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-xs.dtsi
index bf4d200fb546..1ac03b7564aa 100644
--- a/arch/arm64/boot/dts/renesas/salvator-xs.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-xs.dtsi
@@ -20,6 +20,8 @@
 };
 
  {
+   clock-frequency = <40>;
+
versaclock6: clock-generator@6a {
compatible = "idt,5p49v6901";
reg = <0x6a>;
-- 
2.11.0

[PATCH v2] arm64: dts: renesas: Add sdhi2_ds pin group to SDHI2 pinctrl groups

[Wolfram Sang]

From: Masaharu Hayakawa 

This patch adds definitions for configuration of the power-source,
drive-strength, etc... for the SD2_DS pin for Salvator-X(S) and ULCB
boards.

Signed-off-by: Masaharu Hayakawa 
Signed-off-by: Takeshi Kihara 
[wsa: fixed for ULCB boards, too]
Signed-off-by: Wolfram Sang 
---

Changes since V1:
* squashed commits into single one

 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 4 ++--
 arch/arm64/boot/dts/renesas/ulcb.dtsi| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 9256fbaaab7f..b3c0b6912af4 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -589,13 +589,13 @@
};
 
sdhi2_pins: sd2 {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <3300>;
};
 
sdhi2_pins_uhs: sd2_uhs {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
};
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi 
b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index 0edb16e6b372..702df9cbed52 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -330,13 +330,13 @@
};
 
sdhi2_pins: sd2 {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <3300>;
};
 
sdhi2_pins_uhs: sd2_uhs {
-   groups = "sdhi2_data8", "sdhi2_ctrl";
+   groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
function = "sdhi2";
power-source = <1800>;
};
-- 
2.11.0

[PATCH 3/5] arch: sh: kfr2r09: Use new renesas-ceu camera driver

[Jacopo Mondi]

Use the new renesas-ceu camera driver in kfr2r09 board file instead of
the soc_camera based sh_mobile_ceu_camera driver.

Get rid of soc_camera specific components, and move clk and gpio handling
away from board file, registering the clock source and the enable gpios
for driver consumption.

Memory for the CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

While at there update license to SPDX header and sort headers alphabetically.

No need to udapte the clock source names, as
commit c2f9b05fd5c1 ("media: arch: sh: ecovec: Use new renesas-ceu camera 
driver")
already updated it to the new ceu driver name for all SH7724 boards (possibly
breaking kfr2r09 before this commit).

Compile tested only.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-kfr2r09/setup.c | 217 +---
 1 file changed, 103 insertions(+), 114 deletions(-)

diff --git a/arch/sh/boards/mach-kfr2r09/setup.c 
b/arch/sh/boards/mach-kfr2r09/setup.c
index 6af..e59c577 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -1,41 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * KFR2R09 board support code
  *
  * Copyright (C) 2009 Magnus Damm
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
 #include 
-#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
+
+#include 
+
+#include 
 #include 
-#include 
-#include 
+
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
+/* set VIO_CKO clock to 25MHz */
+#define CEU_MCLK_FREQ  2500
+#define DRVCRB 0xA405018C
 
 static struct mtd_partition kfr2r09_nor_flash_partitions[] =
 {
@@ -230,8 +242,17 @@ static struct platform_device kfr2r09_usb0_gadget_device = 
{
.resource   = kfr2r09_usb0_gadget_resources,
 };
 
-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu_pdata = {
+   .num_subdevs= 1,
+   .subdevs = {
+   { /* [0] = rj54n1cb0c */
+   .flags  = 0,
+   .bus_width  = 8,
+   .bus_shift  = 0,
+   .i2c_adapter_id = 1,
+   .i2c_address= 0x50,
+   },
+   },
 };
 
 static struct resource kfr2r09_ceu_resources[] = {
@@ -246,109 +267,35 @@ static struct resource kfr2r09_ceu_resources[] = {
.end= evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };
 
 static struct platform_device kfr2r09_ceu_device = {
-   .name   = "sh_mobile_ceu",
+   .name   = "renesas-ceu",
.id = 0, /* "ceu0" clock */
.num_resources  = ARRAY_SIZE(kfr2r09_ceu_resources),
.resource   = kfr2r09_ceu_resources,
.dev= {
-   .platform_data  = _mobile_ceu_info,
+   .platform_data  = _pdata,
},
 };
 
-static struct i2c_board_info kfr2r09_i2c_camera = {
-   I2C_BOARD_INFO("rj54n1cb0c", 0x50),
-};
-
-static struct clk *camera_clk;
-
-/* set VIO_CKO clock to 25MHz */
-#define CEU_MCLK_FREQ 2500
-
-#define DRVCRB 0xA405018C
-static int camera_power(struct device *dev, int mode)
-{
-   int ret;
-
-   if (mode) {
-   long rate;
-
-   camera_clk = clk_get(NULL, "video_clk");
-   if (IS_ERR(camera_clk))
-   return PTR_ERR(camera_clk);
-
-   rate = clk_round_rate(camera_clk, CEU_MCLK_FREQ);
-   ret = clk_set_rate(camera_clk, rate);
-   if (ret < 0)
-   goto eclkrate;
-
-   /* set DRVCRB
-*
-* use 1.8 V for VccQ_VIO
-* use 2.85V for VccQ_SR
-*/
-   __raw_writew((__raw_readw(DRVCRB) & ~0x0003) | 0x0001, DRVCRB);
-
-   /* reset clear */
-   ret = gpio_request(GPIO_PTB4, NULL);
-   if (ret < 0)
-   goto eptb4;
-   ret = gpio_request(GPIO_PTB7, NULL);
-   if (ret < 0)
-   goto eptb7;
-

[PATCH 0/5] Remove sh_mobile_ceu_camera from arch/sh

[Jacopo Mondi]

Hello,
this series removes dependencies on the soc_camera based
sh_mobile_ceu_camera driver from 3 board files in arch/sh and from one
sensor driver used by one of those boards.

Hans, this means there are no more user of the soc_camera framework that I know
of in Linux, and I guess we can now plan of to remove that framework.

A note on the sensor driver: I haven't been able to find any documentation
for the SHARP RJ54N1CB0C sensor and so I inferred as much as possible from the
existing code. It seems to me that the sensor needs to power-up/enable gpios
(both active high) and I have registered them from the kfr2r09 board file,
assuming this was not a platform-specific design, but something the sensor
requires. As per the previous drivers ported away from soc_camera, I'm in
favour of moving them to staging if they do not match the quality expected
from a modern V4L2 sensor driver. Ie. framerate control is missing, and I
know this has been a blocker for other drivers in the past.

What I've done to three board files closely resembles what I done already for
Migo-R and Ecovec, and it listed in the single commit messages.

The only tough one is probably ap325rxa, which had an additional sensor
registered but controlled from i2c transaction of magic blobs from the board
file. I dare to remove that sensor registration completely as it seems to me
there is no diver for that at all in mainline.

Last, this patch is based on the media tree master branch, with Akinobu Mita's
patches on ov772x driver on top, which I strangely see only partially applied
to the media master tree [1]

Hans, as this is mostly media-related work, but mostly on SH architecture, I
would like to ask if these should go through you or SH tree.

All of that has only been compile tested. It's pretty hard to find this
platforms around and testing would be awesome if somebody happens to have
one of these.

Thanks
   j

[1] https://patchwork.linuxtv.org/patch/49318/
https://patchwork.linuxtv.org/patch/49317/
https://patchwork.linuxtv.org/patch/49312/

Jacopo Mondi (5):
  media: i2c: Copy rj54n1cb0c soc_camera sensor driver
  media: i2c: rj54n1: Remove soc_camera dependencies
  arch: sh: kfr2r09: Use new renesas-ceu camera driver
  arch: sh: ms7724se: Use new renesas-ceu camera driver
  arch: sh: ap325rxa: Use new renesas-ceu camera driver

 arch/sh/boards/mach-ap325rxa/setup.c   |  282 ++-
 arch/sh/boards/mach-kfr2r09/setup.c|  216 +++--
 arch/sh/boards/mach-se/7724/setup.c|  120 ++-
 arch/sh/kernel/cpu/sh4a/clock-sh7723.c |2 +-
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/rj54n1cb0c.c | 1437 
 7 files changed, 1710 insertions(+), 359 deletions(-)
 create mode 100644 drivers/media/i2c/rj54n1cb0c.c

--
2.7.4

[PATCH 1/5] media: i2c: Copy rj54n1cb0c soc_camera sensor driver

[Jacopo Mondi]

Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.

Signed-off-by: Jacopo Mondi 
---
 drivers/media/i2c/rj54n1cb0c.c | 1416 
 1 file changed, 1416 insertions(+)
 create mode 100644 drivers/media/i2c/rj54n1cb0c.c

diff --git a/drivers/media/i2c/rj54n1cb0c.c b/drivers/media/i2c/rj54n1cb0c.c
new file mode 100644
index 000..02398d0
--- /dev/null
+++ b/drivers/media/i2c/rj54n1cb0c.c
@@ -0,0 +1,1416 @@
+/*
+ * Driver for RJ54N1CB0C CMOS Image Sensor from Sharp
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RJ54N1_DEV_CODE0x0400
+#define RJ54N1_DEV_CODE2   0x0401
+#define RJ54N1_OUT_SEL 0x0403
+#define RJ54N1_XY_OUTPUT_SIZE_S_H  0x0404
+#define RJ54N1_X_OUTPUT_SIZE_S_L   0x0405
+#define RJ54N1_Y_OUTPUT_SIZE_S_L   0x0406
+#define RJ54N1_XY_OUTPUT_SIZE_P_H  0x0407
+#define RJ54N1_X_OUTPUT_SIZE_P_L   0x0408
+#define RJ54N1_Y_OUTPUT_SIZE_P_L   0x0409
+#define RJ54N1_LINE_LENGTH_PCK_S_H 0x040a
+#define RJ54N1_LINE_LENGTH_PCK_S_L 0x040b
+#define RJ54N1_LINE_LENGTH_PCK_P_H 0x040c
+#define RJ54N1_LINE_LENGTH_PCK_P_L 0x040d
+#define RJ54N1_RESIZE_N0x040e
+#define RJ54N1_RESIZE_N_STEP   0x040f
+#define RJ54N1_RESIZE_STEP 0x0410
+#define RJ54N1_RESIZE_HOLD_H   0x0411
+#define RJ54N1_RESIZE_HOLD_L   0x0412
+#define RJ54N1_H_OBEN_OFS  0x0413
+#define RJ54N1_V_OBEN_OFS  0x0414
+#define RJ54N1_RESIZE_CONTROL  0x0415
+#define RJ54N1_STILL_CONTROL   0x0417
+#define RJ54N1_INC_USE_SEL_H   0x0425
+#define RJ54N1_INC_USE_SEL_L   0x0426
+#define RJ54N1_MIRROR_STILL_MODE   0x0427
+#define RJ54N1_INIT_START  0x0428
+#define RJ54N1_SCALE_1_2_LEV   0x0429
+#define RJ54N1_SCALE_4_LEV 0x042a
+#define RJ54N1_Y_GAIN  0x04d8
+#define RJ54N1_APT_GAIN_UP 0x04fa
+#define RJ54N1_RA_SEL_UL   0x0530
+#define RJ54N1_BYTE_SWAP   0x0531
+#define RJ54N1_OUT_SIGPO   0x053b
+#define RJ54N1_WB_SEL_WEIGHT_I 0x054e
+#define RJ54N1_BIT8_WB 0x0569
+#define RJ54N1_HCAPS_WB0x056a
+#define RJ54N1_VCAPS_WB0x056b
+#define RJ54N1_HCAPE_WB0x056c
+#define RJ54N1_VCAPE_WB0x056d
+#define RJ54N1_EXPOSURE_CONTROL0x058c
+#define RJ54N1_FRAME_LENGTH_S_H0x0595
+#define RJ54N1_FRAME_LENGTH_S_L0x0596
+#define RJ54N1_FRAME_LENGTH_P_H0x0597
+#define RJ54N1_FRAME_LENGTH_P_L0x0598
+#define RJ54N1_PEAK_H  0x05b7
+#define RJ54N1_PEAK_50 0x05b8
+#define RJ54N1_PEAK_60 0x05b9
+#define RJ54N1_PEAK_DIFF   0x05ba
+#define RJ54N1_IOC 0x05ef
+#define RJ54N1_TG_BYPASS   0x0700
+#define RJ54N1_PLL_L   0x0701
+#define RJ54N1_PLL_N   0x0702
+#define RJ54N1_PLL_EN  0x0704
+#define RJ54N1_RATIO_TG0x0706
+#define RJ54N1_RATIO_T 0x0707
+#define RJ54N1_RATIO_R 0x0708
+#define RJ54N1_RAMP_TGCLK_EN   0x0709
+#define RJ54N1_OCLK_DSP0x0710
+#define RJ54N1_RATIO_OP0x0711
+#define RJ54N1_RATIO_O 0x0712
+#define RJ54N1_OCLK_SEL_EN 0x0713
+#define RJ54N1_CLK_RST 0x0717
+#define RJ54N1_RESET_STANDBY   0x0718
+#define RJ54N1_FWFLG   0x07fe
+
+#define E_EXCLK(1 << 7)
+#define SOFT_STDBY (1 << 4)
+#define SEN_RSTX   (1 << 2)
+#define TG_RSTX(1 << 1)
+#define DSP_RSTX   (1 << 0)
+
+#define RESIZE_HOLD_SEL(1 << 2)
+#define RESIZE_GO  (1 << 1)
+
+/*
+ * When cropping, the camera automatically centers the cropped region, there
+ * doesn't seem to be a way to specify an explicit location of the rectangle.
+ */
+#define RJ54N1_COLUMN_SKIP 0
+#define RJ54N1_ROW_SKIP0
+#define RJ54N1_MAX_WIDTH   1600
+#define RJ54N1_MAX_HEIGHT  1200
+
+#define PLL_L   

[PATCH 5/5] arch: sh: ap325rxa: Use new renesas-ceu camera driver

[Jacopo Mondi]

Use the new renesas-ceu camera driver in ap325rxa board file instead of
the soc_camera based sh_mobile_ceu_camera driver.

Get rid of soc_camera specific components, and register CEU0 with a single
video sensor (ov7725).

Memory for the CEU video buffers is now reserved with membocks APIs
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

The ap325rxa board file registers another camera (ncm03j) for which I found no
driver in mainline kernel version, and that was configured/probed by sending
i2c messages (of 'magic blobs) from the board file itself. I removed the
sensor registration from this new version as it used soc_camera components
that will be later removed.

While at there update license to SPDX header and sort headers alphabetically.

Compile tested only.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-ap325rxa/setup.c   | 282 +
 arch/sh/kernel/cpu/sh4a/clock-sh7723.c |   2 +-
 2 files changed, 80 insertions(+), 204 deletions(-)

diff --git a/arch/sh/boards/mach-ap325rxa/setup.c 
b/arch/sh/boards/mach-ap325rxa/setup.c
index de8393c..8f234d04 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -1,40 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Renesas - AP-325RXA
  * (Compatible with Algo System ., LTD. - AP-320A)
  *
  * Copyright (C) 2008 Renesas Solutions Corp.
  * Author : Yusuke Goda 
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
 
-#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
+#include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
-#include 
+
+#include 
 #include 
-#include 
-#include 
-#include 
+
 #include 
-#include 
-#include 
-#include 
-#include 
+
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
 
 /* Dummy supplies, where voltage doesn't matter */
 static struct regulator_consumer_supply dummy_supplies[] = {
@@ -253,150 +258,25 @@ static struct platform_device lcdc_device = {
},
 };
 
-static void camera_power(int val)
-{
-   gpio_set_value(GPIO_PTZ5, val); /* RST_CAM/RSTB */
-   mdelay(10);
-}
-
-#ifdef CONFIG_I2C
-/* support for the old ncm03j camera */
-static unsigned char camera_ncm03j_magic[] =
-{
-   0x87, 0x00, 0x88, 0x08, 0x89, 0x01, 0x8A, 0xE8,
-   0x1D, 0x00, 0x1E, 0x8A, 0x21, 0x00, 0x33, 0x36,
-   0x36, 0x60, 0x37, 0x08, 0x3B, 0x31, 0x44, 0x0F,
-   0x46, 0xF0, 0x4B, 0x28, 0x4C, 0x21, 0x4D, 0x55,
-   0x4E, 0x1B, 0x4F, 0xC7, 0x50, 0xFC, 0x51, 0x12,
-   0x58, 0x02, 0x66, 0xC0, 0x67, 0x46, 0x6B, 0xA0,
-   0x6C, 0x34, 0x7E, 0x25, 0x7F, 0x25, 0x8D, 0x0F,
-   0x92, 0x40, 0x93, 0x04, 0x94, 0x26, 0x95, 0x0A,
-   0x99, 0x03, 0x9A, 0xF0, 0x9B, 0x14, 0x9D, 0x7A,
-   0xC5, 0x02, 0xD6, 0x07, 0x59, 0x00, 0x5A, 0x1A,
-   0x5B, 0x2A, 0x5C, 0x37, 0x5D, 0x42, 0x5E, 0x56,
-   0xC8, 0x00, 0xC9, 0x1A, 0xCA, 0x2A, 0xCB, 0x37,
-   0xCC, 0x42, 0xCD, 0x56, 0xCE, 0x00, 0xCF, 0x1A,
-   0xD0, 0x2A, 0xD1, 0x37, 0xD2, 0x42, 0xD3, 0x56,
-   0x5F, 0x68, 0x60, 0x87, 0x61, 0xA3, 0x62, 0xBC,
-   0x63, 0xD4, 0x64, 0xEA, 0xD6, 0x0F,
-};
-
-static int camera_probe(void)
-{
-   struct i2c_adapter *a = i2c_get_adapter(0);
-   struct i2c_msg msg;
-   int ret;
-
-   if (!a)
-   return -ENODEV;
-
-   camera_power(1);
-   msg.addr = 0x6e;
-   msg.buf = camera_ncm03j_magic;
-   msg.len = 2;
-   msg.flags = 0;
-   ret = i2c_transfer(a, , 1);
-   camera_power(0);
-
-   return ret;
-}
-
-static int camera_set_capture(struct soc_camera_platform_info *info,
- int enable)
-{
-   struct i2c_adapter *a = i2c_get_adapter(0);
-   struct i2c_msg msg;
-   int ret = 0;
-   int i;
-
-   camera_power(0);
-   if (!enable)
-   return 0; /* no disable for now */
-
-   camera_power(1);
-   for (i = 0; i < ARRAY_SIZE(camera_ncm03j_magic); i += 2) {
-   u_int8_t buf[8];
-
-   msg.addr = 0x6e;
-   msg.buf = buf;
-   msg.len = 2;
-   msg.flags = 0;
-
-   buf[0] = camera_ncm03j_magic[i];
-   buf[1] = camera_ncm03j_magic[i + 1];
-
-   ret = (ret < 0) ? ret : i2c_transfer(a, , 1);
-   }
-
-   return ret;
-}
-
-static int ap325rxa_camera_add(struct soc_camera_device *icd);
-static void ap325rxa_camera_del(struct soc_camera_device *icd);
-
-static struct soc_camera_platform_info camera_info = {
-   .format_name = "UYVY",
- 

[PATCH 4/5] arch: sh: ms7724se: Use new renesas-ceu camera driver

[Jacopo Mondi]

Use the new renesas-ceu camera driver is ms7724se board file instead of
the soc_camera based sh_mobile_ceu_camera driver.

Get rid of soc_camera specific components, and register CEU0 and CEU1 with
no active video subdevices.

Memory for the CEU video buffers is now reserved with membocks APIs
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.

While at there update license to SPDX header and sort headers
alphabetically.

No need to udapte the clock source names, as
commit c2f9b05fd5c1 ("media: arch: sh: ecovec: Use new renesas-ceu camera 
driver")
already updated it to the new ceu driver name for all SH7724 boards
(possibly breaking ms7724se before this commit).

Compile tested only.

Signed-off-by: Jacopo Mondi 
---
 arch/sh/boards/mach-se/7724/setup.c | 120 
 1 file changed, 79 insertions(+), 41 deletions(-)

diff --git a/arch/sh/boards/mach-se/7724/setup.c 
b/arch/sh/boards/mach-se/7724/setup.c
index 2559525..fdbec22a 100644
--- a/arch/sh/boards/mach-se/7724/setup.c
+++ b/arch/sh/boards/mach-se/7724/setup.c
@@ -1,43 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * linux/arch/sh/boards/se/7724/setup.c
  *
  * Copyright (C) 2009 Renesas Solutions Corp.
  *
  * Kuninori Morimoto 
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
  */
+#include 
+#include 
+#include 
+#include 
 
-#include 
+#include 
+
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
-#include 
+#include 
 #include 
+#include 
 #include 
-#include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
+#include 
+#include 
 #include 
-#include 
-#include 
+
+#include 
+#include 
+
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+
+#include 
+
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu0_dma_membase;
+static phys_addr_t ceu1_dma_membase;
 
 /*
  * SWx1234 5678
@@ -216,8 +222,8 @@ static struct platform_device lcdc_device = {
 };
 
 /* CEU0 */
-static struct sh_mobile_ceu_info sh_mobile_ceu0_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu0_pdata = {
+   .num_subdevs = 0,
 };
 
 static struct resource ceu0_resources[] = {
@@ -231,24 +237,21 @@ static struct resource ceu0_resources[] = {
.start  = evt2irq(0x880),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };
 
 static struct platform_device ceu0_device = {
-   .name   = "sh_mobile_ceu",
-   .id = 0, /* "ceu0" clock */
+   .name   = "renesas-ceu",
+   .id = 0, /* "ceu.0" clock */
.num_resources  = ARRAY_SIZE(ceu0_resources),
.resource   = ceu0_resources,
.dev= {
-   .platform_data  = _mobile_ceu0_info,
+   .platform_data  = _pdata,
},
 };
 
 /* CEU1 */
-static struct sh_mobile_ceu_info sh_mobile_ceu1_info = {
-   .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu1_pdata = {
+   .num_subdevs = 0,
 };
 
 static struct resource ceu1_resources[] = {
@@ -262,18 +265,15 @@ static struct resource ceu1_resources[] = {
.start  = evt2irq(0x9e0),
.flags  = IORESOURCE_IRQ,
},
-   [2] = {
-   /* place holder for contiguous memory */
-   },
 };
 
 static struct platform_device ceu1_device = {
-   .name   = "sh_mobile_ceu",
-   .id = 1, /* "ceu1" clock */
+   .name   = "renesas-ceu",
+   .id = 1, /* "ceu.1" clock */
.num_resources  = ARRAY_SIZE(ceu1_resources),
.resource   = ceu1_resources,
.dev= {
-   .platform_data  = _mobile_ceu1_info,
+   .platform_data  = _pdata,
},
 };
 
@@ -574,13 +574,16 @@ static struct platform_device vou_device = {
},
 };
 
+static struct platform_device *ms7724se_ceu_devices[] __initdata = {
+   _device,
+   _device,
+};
+
 static struct platform_device *ms7724se_devices[] __initdata = {
_device,
_eth_device,
_device,
_flash_device,
-   _device,
-   _device,
_device,
_eth_device,
_usb0_host_device,
@@ -797,7 +800,6 @@ static int __init devices_setup(void)
gpio_request(GPIO_FN_VIO0_CLK, NULL);
gpio_request(GPIO_FN_VIO0_FLD, NULL);
gpio_request(GPIO_FN_VIO0_HD,  NULL);
-   platform_resource_setup_memory(_device, "ceu0", 4 << 20);
 
/* enable CEU1 */
gpio_request(GPIO_FN_VIO1_D7,  NULL);
@@ -812,7 +814,6 @@ static int 

[PATCH 2/5] media: i2c: rj54n1: Remove soc_camera dependencies

[Jacopo Mondi]

Remove soc_camera framework dependencies from rj54n1 sensor driver.
- Handle clock
- Handle GPIOs (named 'powerup' and 'enable')
- Register the async subdevice
- Remove g/s_mbus_config as they're deprecated.
- Adjust build system
- List the driver as maintained for 'Odd Fixes' as I don't have HW to test.

This commits does not remove the original soc_camera based driver.

Compiled tested only.

Signed-off-by: Jacopo Mondi 
---
 MAINTAINERS|   8 +++
 drivers/media/i2c/Kconfig  |  11 +++
 drivers/media/i2c/Makefile |   1 +
 drivers/media/i2c/rj54n1cb0c.c | 153 +++--
 4 files changed, 107 insertions(+), 66 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cbcd5ab..0dd7532 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12680,6 +12680,14 @@ W: 
http://www.ibm.com/developerworks/linux/linux390/
 S: Supported
 F: net/smc/
 
+SHARP RJ54N1CB0C SENSOR DRIVER
+M: Jacopo Mondi 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Odd fixes
+F: drivers/media/i2c/rj54n1cb0c.c
+F: include/media/i2c/rj54n1cb0c.h
+
 SH_VEU V4L2 MEM2MEM DRIVER
 L: linux-me...@vger.kernel.org
 S: Orphan
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b95b447..7b5a224 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -846,6 +846,17 @@ config VIDEO_NOON010PC30
 
 source "drivers/media/i2c/m5mols/Kconfig"
 
+config VIDEO_RJ54N1
+   tristate "Sharp RJ54N1CB0C sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   help
+ This is a V4L2 sensor-level driver for Sharp RJ54N1CB0C CMOS image
+ sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rj54n1.
+
 config VIDEO_S5K6AA
tristate "Samsung S5K6AAFX sensor support"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index ff6e291..3f9c1f7 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
 obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
 obj-$(CONFIG_VIDEO_SR030PC30)  += sr030pc30.o
 obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
+obj-$(CONFIG_VIDEO_RJ54N1) += rj54n1cb0c.o
 obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
 obj-$(CONFIG_VIDEO_S5K6A3) += s5k6a3.o
 obj-$(CONFIG_VIDEO_S5K4ECGX)   += s5k4ecgx.o
diff --git a/drivers/media/i2c/rj54n1cb0c.c b/drivers/media/i2c/rj54n1cb0c.c
index 02398d0..6ad998a 100644
--- a/drivers/media/i2c/rj54n1cb0c.c
+++ b/drivers/media/i2c/rj54n1cb0c.c
@@ -1,25 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Driver for RJ54N1CB0C CMOS Image Sensor from Sharp
  *
- * Copyright (C) 2009, Guennadi Liakhovetski 
+ * Copyright (C) 2018, Jacopo Mondi 
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
+ * Copyright (C) 2009, Guennadi Liakhovetski 
  */
 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 
 #include 
-#include 
-#include 
-#include 
+#include 
 #include 
+#include 
 
 #define RJ54N1_DEV_CODE0x0400
 #define RJ54N1_DEV_CODE2   0x0401
@@ -151,7 +151,9 @@ struct rj54n1_clock_div {
 struct rj54n1 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
-   struct v4l2_clk *clk;
+   struct clk *clk;
+   struct gpio_desc *pwup_gpio;
+   struct gpio_desc *enable_gpio;
struct rj54n1_clock_div clk_div;
const struct rj54n1_datafmt *fmt;
struct v4l2_rect rect;  /* Sensor window */
@@ -545,8 +547,7 @@ static int rj54n1_set_selection(struct v4l2_subdev *sd,
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct rj54n1 *rj54n1 = to_rj54n1(client);
const struct v4l2_rect *rect = >r;
-   int dummy = 0, output_w, output_h,
-   input_w = rect->width, input_h = rect->height;
+   int output_w, output_h, input_w = rect->width, input_h = rect->height;
int ret;
 
if (sel->which != V4L2_SUBDEV_FORMAT_ACTIVE ||
@@ -554,11 +555,8 @@ static int rj54n1_set_selection(struct v4l2_subdev *sd,
return -EINVAL;
 
/* arbitrary minimum width and height, edges unimportant */
-   soc_camera_limit_side(, _w,
-RJ54N1_COLUMN_SKIP, 8, RJ54N1_MAX_WIDTH);
-
-   soc_camera_limit_side(, _h,
-RJ54N1_ROW_SKIP, 8, RJ54N1_MAX_HEIGHT);
+   v4l_bound_align_image(_w, 8, RJ54N1_MAX_WIDTH, 0,
+ _h, 8, RJ54N1_MAX_HEIGHT, 0, 0);
 
output_w = (input_w * 1024 + rj54n1->resize / 2) / 

[PATCH v3] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

If a device is part of a PM Domain (e.g. power and/or clock domain), its
power state is managed using Runtime PM.  Without Runtime PM, the device
may not be powered up or clocked, causing subtle failures, crashes, or
system lock-ups when the device is accessed by the guest.

Fix this by adding Runtime PM support, powering the device when the VFIO
device is opened by the guest.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Simon Horman 
---
v3:
  - Drop controversial note about unsafeness of exporting fine-grained
power management from host to guest,

v2:
  - Improve wording,
  - Add Reviewed-by.
---
 drivers/vfio/platform/vfio_platform_common.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index b60bb5326668498c..41f862f055054543 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -233,6 +234,8 @@ static void vfio_platform_release(void *device_data)
const char *extra_dbg = NULL;
int ret;
 
+   pm_runtime_put(vdev->device);
+
ret = vfio_platform_call_reset(vdev, _dbg);
if (ret && vdev->reset_required) {
dev_warn(vdev->device, "reset driver is required and 
reset call failed in release (%d) %s\n",
@@ -275,6 +278,10 @@ static int vfio_platform_open(void *device_data)
 ret, extra_dbg ? extra_dbg : "");
goto err_rst;
}
+
+   ret = pm_runtime_get_sync(vdev->device);
+   if (ret < 0)
+   goto err_rst;
}
 
vdev->refcnt++;
@@ -690,6 +697,7 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
 
mutex_init(>igate);
 
+   pm_runtime_enable(vdev->device);
return 0;
 
 put_iommu:
@@ -707,6 +715,7 @@ struct vfio_platform_device 
*vfio_platform_remove_common(struct device *dev)
vdev = vfio_del_group_dev(dev);
 
if (vdev) {
+   pm_runtime_disable(vdev->device);
vfio_platform_put_reset(vdev);
vfio_iommu_group_put(dev->iommu_group, dev);
}
-- 
2.7.4

[PATCH] media: vsp1: Document vsp1_dl_body refcnt

[Kieran Bingham]

In commit 2d9445db0ee9 ("media: vsp1: Use reference counting for
bodies"), a new field was introduced to the vsp1_dl_body structure to
account for usage tracking of the body.

Document the newly added field in the kerneldoc.

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

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index d9b9cdd8fbe2..10a24bde2299 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -43,6 +43,7 @@ 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
+ * @refcnt: reference tracking for the body
  * @pool: pool to which this body belongs
  * @vsp1: the VSP1 device
  * @entries: array of entries
-- 
2.17.0

Re: [PATCH v2] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

Hi Eric,

On Mon, May 28, 2018 at 4:54 PM, Auger Eric  wrote:
> On 05/18/2018 12:55 PM, Geert Uytterhoeven wrote:
>> If a device is part of a PM Domain (e.g. power and/or clock domain), its
>> power state is managed using Runtime PM.  Without Runtime PM, the device
>> may not be powered up or clocked, causing subtle failures, crashes, or
>> system lock-ups when the device is accessed by the guest.
>>
>> Fix this by adding Runtime PM support, powering the device when the VFIO
>> device is opened by the guest.
>
> I fail to apply this on master branch?

It's against git://github.com/awilliam/linux-vfio.git#next.

>> Note that while more fine-grained power management could be implemented
>> on the guest side, if exported by the host, this would be inherently
>> unsafe, as abusing it may take down the whole system.
> I think I would prefer we get rid of the above paragraph.

OK, I will drop it. But you've been warned ;-)

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] vfio: platform: Fix using devices in PM Domains

[Auger Eric]

Hi Geert,

On 05/18/2018 12:55 PM, Geert Uytterhoeven wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM.  Without Runtime PM, the device
> may not be powered up or clocked, causing subtle failures, crashes, or
> system lock-ups when the device is accessed by the guest.
> 
> Fix this by adding Runtime PM support, powering the device when the VFIO
> device is opened by the guest.

I fail to apply this on master branch?
> 
> Note that while more fine-grained power management could be implemented
> on the guest side, if exported by the host, this would be inherently
> unsafe, as abusing it may take down the whole system.
I think I would prefer we get rid of the above paragraph.

Thanks

Eric
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 
> ---
> v2:
>   - Improve wording,
>   - Add Reviewed-by.
> ---
>  drivers/vfio/platform/vfio_platform_common.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..41f862f055054543 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -233,6 +234,8 @@ static void vfio_platform_release(void *device_data)
>   const char *extra_dbg = NULL;
>   int ret;
>  
> + pm_runtime_put(vdev->device);
> +
>   ret = vfio_platform_call_reset(vdev, _dbg);
>   if (ret && vdev->reset_required) {
>   dev_warn(vdev->device, "reset driver is required and 
> reset call failed in release (%d) %s\n",
> @@ -275,6 +278,10 @@ static int vfio_platform_open(void *device_data)
>ret, extra_dbg ? extra_dbg : "");
>   goto err_rst;
>   }
> +
> + ret = pm_runtime_get_sync(vdev->device);
> + if (ret < 0)
> + goto err_rst;
>   }
>  
>   vdev->refcnt++;
> @@ -690,6 +697,7 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>  
>   mutex_init(>igate);
>  
> + pm_runtime_enable(vdev->device);
>   return 0;
>  
>  put_iommu:
> @@ -707,6 +715,7 @@ struct vfio_platform_device 
> *vfio_platform_remove_common(struct device *dev)
>   vdev = vfio_del_group_dev(dev);
>  
>   if (vdev) {
> + pm_runtime_disable(vdev->device);
>   vfio_platform_put_reset(vdev);
>   vfio_iommu_group_put(dev->iommu_group, dev);
>   }
> 

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Simon Horman]

On Mon, May 28, 2018 at 12:45:32PM +0300, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Monday, 28 May 2018 12:39:17 EEST Simon Horman wrote:
> > On Fri, May 25, 2018 at 01:23:53PM +0300, Laurent Pinchart wrote:
> > > On Friday, 25 May 2018 13:13:20 EEST Simon Horman wrote:
> > >> On Thu, May 24, 2018 at 11:00:52AM +0300, Laurent Pinchart wrote:
> > >>> On Wednesday, 21 February 2018 18:39:25 EEST Simon Horman wrote:
> >  On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote:
> > > 
> > > [snip]
> > > 
> > > Laurent Pinchart (11):
> > >   dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
> > >   dt-bindings: display: renesas: Deprecate LVDS support in the DU
> > > bindings
> > >   drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
> > >   drm: rcar-du: Convert LVDS encoder code to bridge driver
> > >   ARM: dts: r8a7790: Convert to new LVDS DT bindings
> > >   ARM: dts: r8a7791: Convert to new LVDS DT bindings
> > >   ARM: dts: r8a7792: Convert to new DU DT bindings
> > >   ARM: dts: r8a7793: Convert to new LVDS DT bindings
> > >   ARM: dts: r8a7794: Convert to new DU DT bindings
> > >   arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
> > >   arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings
> >  
> >  I have marked the dts patches above as deferred as they depend
> >  on the driver changes not to cause a regression. Please repost them
> >  or otherwise ping me once the driver dependencies are present in an
> >  rc release.
> > >>> 
> > >>> The driver changes have made it to v4.17-rc1. Is it too late for v4.18
> > >>> ?
> > >> 
> > >> Unfortunately it is. Shall I apply them for v4.19?
> > > 
> > > Please do.
> > 
> > Hi Laurent,
> > 
> > I'm sorry to have to ask this, but in the light of Olof Johansson's recent
> > comments in ("Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18")
> > please consider squashing the DTS patches and reposting.
> 
> It's about time we stopped trying to game the kernel patch statistics :-)
> 
> Before I repost, has there been a consensus on the new rule ? And how are we 
> expected to proceed from now on ?

No, there has not been. And I think there needs to be.

Re: [PATCH v4 5/9] media: rcar-vin: Parse parallel input on Gen3

[Niklas Söderlund]

Hi Jacopo,

On 2018-05-25 13:50:08 +0200, Jacopo Mondi wrote:
> Hi Niklas,
>I might have another question before sending v5.
> 
> On Fri, May 25, 2018 at 12:29:44AM +0200, Niklas Söderlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > I really like what you did with this patch in v4.
> >
> > On 2018-05-25 00:02:15 +0200, Jacopo Mondi wrote:
> > > The rcar-vin driver so far had a mutually exclusive code path for
> > > handling parallel and CSI-2 video input subdevices, with only the CSI-2
> > > use case supporting media-controller. As we add support for parallel
> > > inputs to Gen3 media-controller compliant code path now parse both port@0
> > > and port@1, handling the media-controller use case in the parallel
> > > bound/unbind notifier operations.
> > >
> > > Signed-off-by: Jacopo Mondi 
> > >
> > > ---
> > > v3 -> v4:
> > > - Change the mc/parallel initialization order. Initialize mc first, then
> > >   parallel
> > > - As a consequence no need to delay parallel notifiers registration, the
> > >   media controller is set up already when parallel input got parsed,
> > >   this greatly simplify the group notifier complete callback.
> > > ---
> > >  drivers/media/platform/rcar-vin/rcar-core.c | 56 
> > > ++---
> > >  1 file changed, 35 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> > > b/drivers/media/platform/rcar-vin/rcar-core.c
> > > index a799684..29619c2 100644
> > > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > > @@ -399,6 +399,11 @@ static int rvin_parallel_subdevice_attach(struct 
> > > rvin_dev *vin,
> > >   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> > >   vin->parallel->sink_pad = ret < 0 ? 0 : ret;
> > >
> > > + if (vin->info->use_mc) {
> > > + vin->parallel->subdev = subdev;
> > > + return 0;
> > > + }
> > > +
> > >   /* Find compatible subdevices mbus format */
> > >   vin->mbus_code = 0;
> > >   code.index = 0;
> > > @@ -460,10 +465,12 @@ static int rvin_parallel_subdevice_attach(struct 
> > > rvin_dev *vin,
> > >  static void rvin_parallel_subdevice_detach(struct rvin_dev *vin)
> > >  {
> > >   rvin_v4l2_unregister(vin);
> > > - v4l2_ctrl_handler_free(>ctrl_handler);
> > > -
> > > - vin->vdev.ctrl_handler = NULL;
> > >   vin->parallel->subdev = NULL;
> > > +
> > > + if (!vin->info->use_mc) {
> > > + v4l2_ctrl_handler_free(>ctrl_handler);
> > > + vin->vdev.ctrl_handler = NULL;
> > > + }
> > >  }
> > >
> > >  static int rvin_parallel_notify_complete(struct v4l2_async_notifier 
> > > *notifier)
> > > @@ -552,18 +559,18 @@ static int rvin_parallel_parse_v4l2(struct device 
> > > *dev,
> > >   return 0;
> > >  }
> > >
> > > -static int rvin_parallel_graph_init(struct rvin_dev *vin)
> > > +static int rvin_parallel_init(struct rvin_dev *vin)
> > >  {
> > >   int ret;
> > >
> > > - ret = v4l2_async_notifier_parse_fwnode_endpoints(
> > > - vin->dev, >notifier,
> > > - sizeof(struct rvin_parallel_entity), rvin_parallel_parse_v4l2);
> > > + ret = v4l2_async_notifier_parse_fwnode_endpoints_by_port(
> > > + vin->dev, >notifier, sizeof(struct rvin_parallel_entity),
> > > + 0, rvin_parallel_parse_v4l2);
> > >   if (ret)
> > >   return ret;
> > >
> > >   if (!vin->parallel)
> > > - return -ENODEV;
> > > + return -ENOTCONN;
> >
> > I think you still should return -ENODEV here if !vin->info->use_mc to
> > preserve Gen2 which runs without media controller behavior. How about:
> >
> > return vin->info->use_mc ? -ENOTCONN : -ENODEV;
> >
> > >
> > >   vin_dbg(vin, "Found parallel subdevice %pOF\n",
> > >   to_of_node(vin->parallel->asd.match.fwnode));
> > > @@ -784,14 +791,8 @@ static int rvin_mc_init(struct rvin_dev *vin)
> > >  {
> > >   int ret;
> > >
> > > - vin->pad.flags = MEDIA_PAD_FL_SINK;
> > > - ret = media_entity_pads_init(>vdev.entity, 1, >pad);
> > > - if (ret)
> > > - return ret;
> > > -
> > > - ret = rvin_group_get(vin);
> > > - if (ret)
> > > - return ret;
> > > + if (!vin->info->use_mc)
> > > + return 0;
> > >
> > >   ret = rvin_mc_parse_of_graph(vin);
> > >   if (ret)
> > > @@ -1074,11 +1075,24 @@ static int rcar_vin_probe(struct platform_device 
> > > *pdev)
> > >   return ret;
> > >
> > >   platform_set_drvdata(pdev, vin);
> > > - if (vin->info->use_mc)
> > > - ret = rvin_mc_init(vin);
> > > - else
> > > - ret = rvin_parallel_graph_init(vin);
> > > - if (ret < 0)
> > > +
> > > + if (vin->info->use_mc) {
> > > + vin->pad.flags = MEDIA_PAD_FL_SINK;
> > > + ret = media_entity_pads_init(>vdev.entity, 1, >pad);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = rvin_group_get(vin);
> > > + if (ret)
> > > + return ret;
> > > + }
> >
> > I don't see why you need to move the media 

[PATCH/RFC] arm64: dts: renesas: salvator-common: Add HSCIF1 device support

[Geert Uytterhoeven]

From: Hiromitsu Yamasaki 

This patch adds the pin control for HSCIF1, and supports connection with
the Debug Serial-1 (CN26) on Salvator boards.

SCIF1 and HSCI1 are sharing the pin connected to the Debug Serial-1
(CN26) on Salvator boards, and it is necessary to use it by exclusion.

As for the default of this DeviceTree, SCIF1 is connected.

Signed-off-by: Hiromitsu Yamasaki 
Signed-off-by: Takeshi Kihara 
[geert: Add missing "uart-has-rtscts"]
Signed-off-by: Geert Uytterhoeven 
---
This depends on "arm64: dts: renesas: r8a77965: Add all HSCIF nodes",
due to the  reference.

This doesn't really change anything, but serves as an example and
documentation.

Questions:
  1. Do we want to have such examples/documentation?

  2. Should we make HSCIF1 the default? IMHO, HSCIF is superior to SCIF.
 Both are served by the same driver, so increased kernel size is not
 a counter-argument.
 For comparison: r8a7790-lager.dts uses SCIFA1 instead of SCIF1 for
 the debug serial (not for the serial console, due to earlycon and
 U-Boot compatibility).

 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 9256fbaaab7f3297..976fda67e202f054 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -341,6 +341,15 @@
clock-frequency = <32768>;
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   uart-has-rtscts;
+   /* Please use exclusively to the scif1 node */
+   /* status = "okay"; */
+};
+
  {
dr_mode = "otg";
status = "okay";
@@ -546,6 +555,11 @@
function = "du";
};
 
+   hscif1_pins: hscif1 {
+   groups = "hscif1_data_a", "hscif1_ctrl_a";
+   function = "hscif1";
+   };
+
i2c2_pins: i2c2 {
groups = "i2c2_a";
function = "i2c2";
@@ -711,6 +725,7 @@
pinctrl-names = "default";
 
uart-has-rtscts;
+   /* Please use exclusively to the hscif1 node */
status = "okay";
 };
 
-- 
2.7.4

[PATCH] arm64: dts: renesas: r8a77965: Add all HSCIF nodes

[Geert Uytterhoeven]

From: Takeshi Kihara 

Based on a similar patch of the R8A7796 device tree
by Ulrich Hecht .

Signed-off-by: Takeshi Kihara 
Signed-off-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 88 +++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index fad98ba6742e220b..e3180b7574d6cffa 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -451,6 +451,94 @@
status = "disabled";
};
 
+   hscif0: serial@e654 {
+   compatible = "renesas,hscif-r8a77965",
+"renesas,rcar-gen3-hscif",
+"renesas,hscif";
+   reg = <0 0xe654 0 0x60>;
+   interrupts = ;
+   clocks = < CPG_MOD 520>,
+< CPG_CORE R8A77965_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x31>, < 0x30>,
+  < 0x31>, < 0x30>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 520>;
+   status = "disabled";
+   };
+
+   hscif1: serial@e655 {
+   compatible = "renesas,hscif-r8a77965",
+"renesas,rcar-gen3-hscif",
+"renesas,hscif";
+   reg = <0 0xe655 0 0x60>;
+   interrupts = ;
+   clocks = < CPG_MOD 519>,
+< CPG_CORE R8A77965_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x33>, < 0x32>,
+  < 0x33>, < 0x32>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 519>;
+   status = "disabled";
+   };
+
+   hscif2: serial@e656 {
+   compatible = "renesas,hscif-r8a77965",
+"renesas,rcar-gen3-hscif",
+"renesas,hscif";
+   reg = <0 0xe656 0 0x60>;
+   interrupts = ;
+   clocks = < CPG_MOD 518>,
+< CPG_CORE R8A77965_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x35>, < 0x34>,
+  < 0x35>, < 0x34>;
+   dma-names = "tx", "rx", "tx", "rx";
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 518>;
+   status = "disabled";
+   };
+
+   hscif3: serial@e66a {
+   compatible = "renesas,hscif-r8a77965",
+"renesas,rcar-gen3-hscif",
+"renesas,hscif";
+   reg = <0 0xe66a 0 0x60>;
+   interrupts = ;
+   clocks = < CPG_MOD 517>,
+< CPG_CORE R8A77965_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x37>, < 0x36>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 517>;
+   status = "disabled";
+   };
+
+   hscif4: serial@e66b {
+   compatible = "renesas,hscif-r8a77965",
+"renesas,rcar-gen3-hscif",
+"renesas,hscif";
+   reg = <0 0xe66b 0 0x60>;
+   interrupts = ;
+   clocks = < CPG_MOD 516>,
+< CPG_CORE R8A77965_CLK_S3D1>,
+<_clk>;
+   clock-names = "fck", "brg_int", "scif_clk";
+   dmas = < 0x39>, < 0x38>;
+   dma-names = "tx", "rx";
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 516>;
+   status = "disabled";
+   };
+
hsusb: usb@e659 {
  

[PATCH] arm64: dts: renesas: r8a77965: Use r8a77965-cpg-mssr binding definitions

[Geert Uytterhoeven]

Replace the hardcoded clock indices by R8A77965_CLK_* symbols.

Signed-off-by: Geert Uytterhoeven 
---
Commit 7ce36da900c0a2ff ("clk: renesas: cpg-mssr: Add support for R-Car
M3-N") providing the definitions is in v4.17-rc1.

 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 486aecacb22abcf2..fad98ba6742e220b 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -732,7 +732,7 @@
reg = <0 0xe6e6 0 64>;
interrupts = ;
clocks = < CPG_MOD 207>,
-< CPG_CORE 20>,
+< CPG_CORE R8A77965_CLK_S3D1>,
 <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x51>, < 0x50>,
@@ -749,7 +749,7 @@
reg = <0 0xe6e68000 0 64>;
interrupts = ;
clocks = < CPG_MOD 206>,
-< CPG_CORE 20>,
+< CPG_CORE R8A77965_CLK_S3D1>,
 <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x53>, < 0x52>,
@@ -766,7 +766,7 @@
reg = <0 0xe6e88000 0 64>;
interrupts = ;
clocks = < CPG_MOD 310>,
-< CPG_CORE 20>,
+< CPG_CORE R8A77965_CLK_S3D1>,
 <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
power-domains = < R8A77965_PD_ALWAYS_ON>;
@@ -780,7 +780,7 @@
reg = <0 0xe6c5 0 64>;
interrupts = ;
clocks = < CPG_MOD 204>,
-< CPG_CORE 20>,
+< CPG_CORE R8A77965_CLK_S3D1>,
 <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x57>, < 0x56>;
@@ -796,7 +796,7 @@
reg = <0 0xe6c4 0 64>;
interrupts = ;
clocks = < CPG_MOD 203>,
-< CPG_CORE 20>,
+< CPG_CORE R8A77965_CLK_S3D1>,
 <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x59>, < 0x58>;
@@ -812,7 +812,7 @@
reg = <0 0xe6f3 0 64>;
interrupts = ;
clocks = < CPG_MOD 202>,
-< CPG_CORE 20>,
+< CPG_CORE R8A77965_CLK_S3D1>,
 <_clk>;
clock-names = "fck", "brg_int", "scif_clk";
dmas = < 0x5b>, < 0x5a>,
-- 
2.7.4

Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties

[Ville Syrjälä]

On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent or gain adjustment
> of the pixels component values.
> 
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds nine generic DRM plane
> properties related to the color keying to cover various HW capabilities.
> 
> This patch is based on the initial work done by Laurent Pinchart, most of
> credits for this patch goes to him.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/drm_atomic.c |  36 ++
>  drivers/gpu/drm/drm_blend.c  | 229 +++
>  include/drm/drm_blend.h  |   3 +
>  include/drm/drm_plane.h  |  77 
>  4 files changed, 345 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..5b808cb68654 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct 
> drm_plane *plane,
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
>   state->zpos = val;
> + } else if (property == plane->colorkey.mode_property) {
> + state->colorkey.mode = val;
> + } else if (property == plane->colorkey.min_property) {
> + state->colorkey.min = val;
> + } else if (property == plane->colorkey.max_property) {
> + state->colorkey.max = val;
> + } else if (property == plane->colorkey.format_property) {
> + state->colorkey.format = val;
> + } else if (property == plane->colorkey.mask_property) {
> + state->colorkey.mask = val;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + state->colorkey.inverted_match = val;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + state->colorkey.replacement_mask = val;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + state->colorkey.replacement_value = val;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + state->colorkey.replacement_format = val;
>   } else if (property == plane->color_encoding_property) {
>   state->color_encoding = val;
>   } else if (property == plane->color_range_property) {
> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
>   *val = state->zpos;
> + } else if (property == plane->colorkey.mode_property) {
> + *val = state->colorkey.mode;
> + } else if (property == plane->colorkey.min_property) {
> + *val = state->colorkey.min;
> + } else if (property == plane->colorkey.max_property) {
> + *val = state->colorkey.max;
> + } else if (property == plane->colorkey.format_property) {
> + *val = state->colorkey.format;
> + } else if (property == plane->colorkey.mask_property) {
> + *val = state->colorkey.mask;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + *val = state->colorkey.inverted_match;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + *val = state->colorkey.replacement_mask;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + *val = state->colorkey.replacement_value;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + *val = state->colorkey.replacement_format;
>   } else if (property == plane->color_encoding_property) {
>   *val = state->color_encoding;
>   } else if (property == plane->color_range_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d7e15e..05e5632ce375 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,11 @@
>   *   planes. Without this property the primary plane is always below the 
> cursor
>   *   plane, and ordering between all other planes is undefined.
>   *
> + * colorkey:
> + *   Color keying is set up with drm_plane_create_colorkey_properties().
> + *   It adds support for replacing a range of colors with a transparent
> + *   color in the plane.
> + *
>   * Note that all the property extensions described here apply either to the
>   * plane or the CRTC (e.g. for the background color, which currently is not
>   * exposed and assumed to be black).
> @@ -448,3 

Re: [PATCH] arm64: dts: r8a77965: Add Watchdog Timer controller node using RCLK Watchdog Timer

[Geert Uytterhoeven]

Hi Kaneko-san,

(after adding more coffee)

The summary prefix should be "arm64: dts: renesas: r8a77965:"

On Mon, May 28, 2018 at 11:32 AM, Geert Uytterhoeven
 wrote:
> On Wed, May 23, 2018 at 2:36 PM, Yoshihiro Kaneko  
> wrote:
>> From: Takeshi Kihara 
>>
>> Add a device node for the Watchdog Timer (WDT) controller on the Renesas
>> R-Car M3N (R8A77965) SoC.

M3-N

>> Based on a similar patch of the R8A7796 device tree
>> by Geert Uytterhoeven .
>>
>> Signed-off-by: Takeshi Kihara 
>> Signed-off-by: Yoshihiro Kaneko 
>
> Reviewed-by: Geert Uytterhoeven 
> Tested-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 v5] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Heikki Krogerus]

On Fri, May 25, 2018 at 04:12:56PM +0900, Yoshihiro Shimoda wrote:
> @@ -2573,6 +2635,12 @@ static void renesas_usb3_init_ram(struct renesas_usb3 
> *usb3, struct device *dev,
>   EXTCON_NONE,
>  };
>  
> +static struct usb_role_switch_desc renesas_usb3_role_switch_desc = {

You can constify that.

> + .set = renesas_usb3_role_switch_set,
> + .get = renesas_usb3_role_switch_get,
> + .allow_userspace_control = true,
> +};
> +
>  static int renesas_usb3_probe(struct platform_device *pdev)
>  {
>   struct renesas_usb3 *usb3;

Thanks,

-- 
heikki

[PATCH] pinctrl: sh-pfc: r8a77965: Add HSCIF pins, groups, and functions

[Geert Uytterhoeven]

From: Takeshi Kihara 

This patch adds HSCIF{0,1,2,3,4} pins, groups and functions to
the R8A77965 SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Geert Uytterhoeven 
---
To be queued in sh-pfc-for-v4.19.

 drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 333 ++
 1 file changed, 333 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index d2bbee6563813919..cfd7de67e3e34b6e 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -1758,6 +1758,263 @@ static const unsigned int du_disp_mux[] = {
DU_DISP_MARK,
 };
 
+/* - HSCIF0 - 
*/
+static const unsigned int hscif0_data_pins[] = {
+   /* RX, TX */
+   RCAR_GP_PIN(5, 13), RCAR_GP_PIN(5, 14),
+};
+
+static const unsigned int hscif0_data_mux[] = {
+   HRX0_MARK, HTX0_MARK,
+};
+
+static const unsigned int hscif0_clk_pins[] = {
+   /* SCK */
+   RCAR_GP_PIN(5, 12),
+};
+
+static const unsigned int hscif0_clk_mux[] = {
+   HSCK0_MARK,
+};
+
+static const unsigned int hscif0_ctrl_pins[] = {
+   /* RTS, CTS */
+   RCAR_GP_PIN(5, 16), RCAR_GP_PIN(5, 15),
+};
+
+static const unsigned int hscif0_ctrl_mux[] = {
+   HRTS0_N_MARK, HCTS0_N_MARK,
+};
+
+/* - HSCIF1 - 
*/
+static const unsigned int hscif1_data_a_pins[] = {
+   /* RX, TX */
+   RCAR_GP_PIN(5, 5), RCAR_GP_PIN(5, 6),
+};
+
+static const unsigned int hscif1_data_a_mux[] = {
+   HRX1_A_MARK, HTX1_A_MARK,
+};
+
+static const unsigned int hscif1_clk_a_pins[] = {
+   /* SCK */
+   RCAR_GP_PIN(6, 21),
+};
+
+static const unsigned int hscif1_clk_a_mux[] = {
+   HSCK1_A_MARK,
+};
+
+static const unsigned int hscif1_ctrl_a_pins[] = {
+   /* RTS, CTS */
+   RCAR_GP_PIN(5, 8), RCAR_GP_PIN(5, 7),
+};
+
+static const unsigned int hscif1_ctrl_a_mux[] = {
+   HRTS1_N_A_MARK, HCTS1_N_A_MARK,
+};
+
+static const unsigned int hscif1_data_b_pins[] = {
+   /* RX, TX */
+   RCAR_GP_PIN(5, 1), RCAR_GP_PIN(5, 2),
+};
+
+static const unsigned int hscif1_data_b_mux[] = {
+   HRX1_B_MARK, HTX1_B_MARK,
+};
+
+static const unsigned int hscif1_clk_b_pins[] = {
+   /* SCK */
+   RCAR_GP_PIN(5, 0),
+};
+
+static const unsigned int hscif1_clk_b_mux[] = {
+   HSCK1_B_MARK,
+};
+
+static const unsigned int hscif1_ctrl_b_pins[] = {
+   /* RTS, CTS */
+   RCAR_GP_PIN(5, 4), RCAR_GP_PIN(5, 3),
+};
+
+static const unsigned int hscif1_ctrl_b_mux[] = {
+   HRTS1_N_B_MARK, HCTS1_N_B_MARK,
+};
+
+/* - HSCIF2 - 
*/
+static const unsigned int hscif2_data_a_pins[] = {
+   /* RX, TX */
+   RCAR_GP_PIN(6, 8), RCAR_GP_PIN(6, 9),
+};
+
+static const unsigned int hscif2_data_a_mux[] = {
+   HRX2_A_MARK, HTX2_A_MARK,
+};
+
+static const unsigned int hscif2_clk_a_pins[] = {
+   /* SCK */
+   RCAR_GP_PIN(6, 10),
+};
+
+static const unsigned int hscif2_clk_a_mux[] = {
+   HSCK2_A_MARK,
+};
+
+static const unsigned int hscif2_ctrl_a_pins[] = {
+   /* RTS, CTS */
+   RCAR_GP_PIN(6, 7), RCAR_GP_PIN(6, 6),
+};
+
+static const unsigned int hscif2_ctrl_a_mux[] = {
+   HRTS2_N_A_MARK, HCTS2_N_A_MARK,
+};
+
+static const unsigned int hscif2_data_b_pins[] = {
+   /* RX, TX */
+   RCAR_GP_PIN(6, 17), RCAR_GP_PIN(6, 18),
+};
+
+static const unsigned int hscif2_data_b_mux[] = {
+   HRX2_B_MARK, HTX2_B_MARK,
+};
+
+static const unsigned int hscif2_clk_b_pins[] = {
+   /* SCK */
+   RCAR_GP_PIN(6, 21),
+};
+
+static const unsigned int hscif2_clk_b_mux[] = {
+   HSCK2_B_MARK,
+};
+
+static const unsigned int hscif2_ctrl_b_pins[] = {
+   /* RTS, CTS */
+   RCAR_GP_PIN(6, 20), RCAR_GP_PIN(6, 19),
+};
+
+static const unsigned int hscif2_ctrl_b_mux[] = {
+   HRTS2_N_B_MARK, HCTS2_N_B_MARK,
+};
+
+static const unsigned int hscif2_data_c_pins[] = {
+   /* RX, TX */
+   RCAR_GP_PIN(6, 25), RCAR_GP_PIN(6, 26),
+};
+
+static const unsigned int hscif2_data_c_mux[] = {
+   HRX2_C_MARK, HTX2_C_MARK,
+};
+
+static const unsigned int hscif2_clk_c_pins[] = {
+   /* SCK */
+   RCAR_GP_PIN(6, 24),
+};
+
+static const unsigned int hscif2_clk_c_mux[] = {
+   HSCK2_C_MARK,
+};
+
+static const unsigned int hscif2_ctrl_c_pins[] = {
+   /* RTS, CTS */
+   RCAR_GP_PIN(6, 28), RCAR_GP_PIN(6, 27),
+};
+
+static const unsigned int hscif2_ctrl_c_mux[] = {
+   HRTS2_N_C_MARK, HCTS2_N_C_MARK,
+};
+
+/* - HSCIF3 - 
*/
+static const unsigned int hscif3_data_a_pins[] = {
+   /* RX, TX */
+   RCAR_GP_PIN(1, 23), RCAR_GP_PIN(1, 24),
+};
+
+static const unsigned int hscif3_data_a_mux[] = {
+   HRX3_A_MARK, HTX3_A_MARK,

Re: [PATCH v5] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Andy Shevchenko]

On Fri, May 25, 2018 at 10:12 AM, Yoshihiro Shimoda
 wrote:

> -static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)

Wouldn't be better to choose another name for a new function?

> +   struct renesas_usb3 *usb3 = container_of(work, struct renesas_usb3,
> +role_work);

Matter of style, though I would rather put entire container_of() on
the next line (see for the existing style in the module and use it).

> +   /* This device_attach() might sleep */
> +   if (device_attach(host) < 0)
> +   dev_err(dev, "device_attach(usb3_port) failed\n");

can't be "usb3_port" part derived from the host variable somehow and
to some extend?

> +   usb3->role_sw = usb_role_switch_register(>dev,
> +   _usb3_role_switch_desc);
> +   if (!IS_ERR(usb3->role_sw)) {

> +   usb3->host_dev = usb_of_get_companion_dev(>dev);

Hmm... Can it possible return -EPROBE_DEFER? If so, would it be better
to use other approach to handle it?

> +   if (IS_ERR_OR_NULL(usb3->host_dev)) {
> +   /* If not found, this driver will not use a role sw */
> +   usb_role_switch_unregister(usb3->role_sw);
> +   usb3->role_sw = NULL;
> +   }
> +   } else {
> +   usb3->role_sw = NULL;
> +   }


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 2/4] mmc: core: more fine-grained hooks for HS400 tuning

[Simon Horman]

On Tue, May 22, 2018 at 04:32:09PM +0200, Ulf Hansson wrote:
> On 18 April 2018 at 11:56, Simon Horman  wrote:
> > This adds two new HS400 tuning operations:
> > * prepare_hs400_tuning_downgrade
> > * complete_hs400_tuning
> >
> > These supplement the existing HS400 operation:
> > * prepare_hs400_tuning
> >
> > This is motivated by a requirement of Renesas SDHI for the following:
> > 1. Disabling SCC before selecting to HS if selection of HS400 has occurred.
> >This can be done in an implementation of prepare_hs400_tuning_downgrade
> > 2. Updating registers after switching to HS400
> >This can be done in an implementation of complete_hs400_tuning
> >
> > After this patch the call sequence is as follows:
> >
> > * Initial tuning
> >   i. prepare_hs400_tuning
> >   2. Tuning procedure
> >   3. Select HS400
> >   4. complete_hs400_tuning
> >
> > * Retune
> >   1. prepare_hs400_tuning_downgrade
> >   2. Select HS200
> >   3. prepare_hs400_tuning
> >   4. Tuning procedure
> >   5. Select HS400
> >   6. complete_hs400_tuning
> >
> > If prepare_hs400_tuning or complete_hs400_tuning are not implemented they
> > are not called. And if neither are called the procedure is the same as
> > before this patch.
> >
> > Design consideration: In the case of Renesas SDHI it is likely that
> > prepare_hs400_tuning_downgrade and prepare_hs400_tuning could be combined
> > if the latter was called before selecting HS200 during tuning. When I say
> > likely, I believe it matches my understanding of the hardware. However, I
> > did not test this as I am entirely unsure if moving the
> > prepare_hs400_tuning call would work for other hardware that uses this
> > operation and I am in no position to test such hardware.
> >
> > Signed-off-by: Simon Horman 
> > ---
> > v4
> > * New patch
> > ---
> >  drivers/mmc/core/host.c  | 13 -
> >  drivers/mmc/core/mmc.c   | 19 ++-
> >  include/linux/mmc/host.h | 26 +-
> >  3 files changed, 51 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> > index 64b03d6eaf18..5e60df7ca11f 100644
> > --- a/drivers/mmc/core/host.c
> > +++ b/drivers/mmc/core/host.c
> > @@ -138,6 +138,10 @@ int mmc_retune(struct mmc_host *host)
> > host->doing_retune = 1;
> >
> > if (host->ios.timing == MMC_TIMING_MMC_HS400) {
> > +   if (host->ops->prepare_hs400_tuning_downgrade)
> > +   host->ops->prepare_hs400_tuning_downgrade(host,
> > + 
> > >ios);
> > +
> 
> Quite a long lame for the callback, perhaps "hs400_downgrade" is sufficient?

I struggled with the names (more than any other aspect of the patch). So I
decided to go for something very descriptive in the hope you would suggest
better names. Thanks for doing so!

> Moreover, I suggest you move this new code snippet into
> mmc_hs400_to_hs200() instead.

Thanks, I also wondered about that. I think it makes a lot of sense.
And although I haven't prototyped that I believe it should work quite
nicely.

> 
> > err = mmc_hs400_to_hs200(host->card);
> > if (err)
> > goto out;
> > @@ -152,8 +156,15 @@ int mmc_retune(struct mmc_host *host)
> > if (err)
> > goto out;
> >
> > -   if (return_to_hs400)
> > +   if (return_to_hs400) {
> > err = mmc_hs200_to_hs400(host->card);
> > +   if (err)
> > +   goto out;
> > +
> > +   if (host->ops->complete_hs400_tuning)
> > +   host->ops->complete_hs400_tuning(host, >ios);
> 
> Perhaps rename callback to "hs400_complete"?

Will do.

> And, please move this new code into mmc_select_hs400() (which is
> called from mmc_hs200_to_hs400()), as I think it better belongs there.

Thanks, I will see about doing so.

> > +   }
> > +
> >  out:
> > host->doing_retune = 0;
> >
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index 099b327e10ca..a108a1a3e27f 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -1508,22 +1508,31 @@ static int mmc_select_timing(struct mmc_card *card)
> >  static int mmc_hs200_tuning(struct mmc_card *card)
> >  {
> > struct mmc_host *host = card->host;
> > +   bool run_hs400_ops;
> > int err;
> >
> > +   run_hs400_ops = card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
> > +   host->ios.bus_width == MMC_BUS_WIDTH_8;
> > +
> > /*
> >  * Timing should be adjusted to the HS400 target
> >  * operation frequency for tuning process
> >  */
> > -   if (card->mmc_avail_type & EXT_CSD_CARD_TYPE_HS400 &&
> > -   host->ios.bus_width == MMC_BUS_WIDTH_8)
> > -   if (host->ops->prepare_hs400_tuning)
> > -   

Re: [PATCH 13/15] arm: dts: r8a7743: Add missing OPP properties for CPUs

[Viresh Kumar]

On 28-05-18, 11:23, Simon Horman wrote:
> [Cc Biju Das]
> 
> On Fri, May 25, 2018 at 04:01:59PM +0530, Viresh Kumar wrote:
> > The OPP properties, like "operating-points", should either be present
> > for all the CPUs of a cluster or none. If these are present only for a
> > subset of CPUs of a cluster then things will start falling apart as soon
> > as the CPUs are brought online in a different order. For example, this
> > will happen because the operating system looks for such properties in
> > the CPU node it is trying to bring up, so that it can create an OPP
> > table.
> > 
> > Add such missing properties.
> > 
> > Fix other missing property (clock latency) as well to make it all
> > work.
> > 
> > Signed-off-by: Viresh Kumar 
> 
> Thanks, this looks good to me and it looks like it should have:
> 
> Fixes: 0417814ea140 ("ARM: dts: r8a7743: Add OPP table for frequency scaling")

Sure.

Will you be picking this patch directly and send it part of your pull
request ? Maybe add Fixes tag then only ?

-- 
viresh

Re: [PATCH 13/15] arm: dts: r8a7743: Add missing OPP properties for CPUs

[Simon Horman]

On Mon, May 28, 2018 at 04:28:31PM +0530, Viresh Kumar wrote:
> On 28-05-18, 11:23, Simon Horman wrote:
> > [Cc Biju Das]
> > 
> > On Fri, May 25, 2018 at 04:01:59PM +0530, Viresh Kumar wrote:
> > > The OPP properties, like "operating-points", should either be present
> > > for all the CPUs of a cluster or none. If these are present only for a
> > > subset of CPUs of a cluster then things will start falling apart as soon
> > > as the CPUs are brought online in a different order. For example, this
> > > will happen because the operating system looks for such properties in
> > > the CPU node it is trying to bring up, so that it can create an OPP
> > > table.
> > > 
> > > Add such missing properties.
> > > 
> > > Fix other missing property (clock latency) as well to make it all
> > > work.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > 
> > Thanks, this looks good to me and it looks like it should have:
> > 
> > Fixes: 0417814ea140 ("ARM: dts: r8a7743: Add OPP table for frequency 
> > scaling")
> 
> Sure.
> 
> Will you be picking this patch directly and send it part of your pull
> request ? Maybe add Fixes tag then only ?

Yes, that is my plan. I can handle adding the Fixes tag.
But I'll wait to see if Bjiu has an feedback first.

Re: [PATCH 3/6] ravb: remove custom .set_link_ksettings from ethtool ops

[Vladimir Zapolskiy]

Hello Sergei,

On 05/26/2018 10:50 PM, Sergei Shtylyov wrote:
> On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote:
> 
>> The change replaces a custom implementation of .set_link_ksettings
>> callback with a shared phy_ethtool_set_link_ksettings(), this fixes
>> sleep in atomic context bug, which is encountered every time when link
>> settings are changed by ethtool.
> 
>Seeing it now...
> 
>> Now duplex mode setting is enforced in ravb_adjust_link() only, also
>> now TX/RX is disabled when link is put down or modifications to E-MAC
>> registers ECMR and GECMR are expected for both cases of checked and
>> ignored link status pin state from E-MAC interrupt handler.
>>
>> Signed-off-by: Vladimir Zapolskiy 
>> ---
>>  drivers/net/ethernet/renesas/ravb_main.c | 58 
>> +---
>>  1 file changed, 15 insertions(+), 43 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
>> b/drivers/net/ethernet/renesas/ravb_main.c
>> index 3d91caa44176..0d811c02ff34 100644
>> --- a/drivers/net/ethernet/renesas/ravb_main.c
>> +++ b/drivers/net/ethernet/renesas/ravb_main.c
>> @@ -980,6 +980,13 @@ static void ravb_adjust_link(struct net_device *ndev)
>>  struct ravb_private *priv = netdev_priv(ndev);
>>  struct phy_device *phydev = ndev->phydev;
>>  bool new_state = false;
>> +unsigned long flags;
>> +
>> +spin_lock_irqsave(>lock, flags);
>> +
>> +/* Disable TX and RX right over here, if E-MAC change is ignored */
>> +if (priv->no_avb_link)
>> +ravb_rcv_snd_disable(ndev);
>>  
>>  if (phydev->link) {
>>  if (phydev->duplex != priv->duplex) {
>> @@ -997,18 +1004,21 @@ static void ravb_adjust_link(struct net_device *ndev)
>>  ravb_modify(ndev, ECMR, ECMR_TXF, 0);
>>  new_state = true;
>>  priv->link = phydev->link;
>> -if (priv->no_avb_link)
>> -ravb_rcv_snd_enable(ndev);
>>  }
>>  } else if (priv->link) {
>>  new_state = true;
>>  priv->link = 0;
>>  priv->speed = 0;
>>  priv->duplex = -1;
>> -if (priv->no_avb_link)
>> -ravb_rcv_snd_disable(ndev);
>>  }
>>  
>> +/* Enable TX and RX right over here, if E-MAC change is ignored */
>> +if (priv->no_avb_link && phydev->link)
>> +ravb_rcv_snd_enable(ndev);
>> +
>> +mmiowb();
>> +spin_unlock_irqrestore(>lock, flags);
>> +
> 
>I like this part. :-)
> 

A weight off my mind :) And I hope that this change will remain the less
questionable one, other ones from the series are trivial.

Anyway I hope it is understandable that this part of the change can not
be simply extracted from the rest one below, otherwise there'll be bugs of
another type intorduced.

>>  if (new_state && netif_msg_link(priv))
>>  phy_print_status(phydev);
>>  }
>> @@ -1096,44 +1106,6 @@ static int ravb_phy_start(struct net_device *ndev)
>>  return 0;
>>  }
>>  
>> -static int ravb_set_link_ksettings(struct net_device *ndev,
>> -   const struct ethtool_link_ksettings *cmd)
>> -{
>> -struct ravb_private *priv = netdev_priv(ndev);
>> -unsigned long flags;
>> -int error;
>> -
>> -if (!ndev->phydev)
>> -return -ENODEV;
>> -
>> -spin_lock_irqsave(>lock, flags);
>> -
>> -/* Disable TX and RX */
>> -ravb_rcv_snd_disable(ndev);
>> -
>> -error = phy_ethtool_ksettings_set(ndev->phydev, cmd);
>> -if (error)
>> -goto error_exit;
>> -
>> -if (cmd->base.duplex == DUPLEX_FULL)
>> -priv->duplex = 1;
>> -else
>> -priv->duplex = 0;
>> -
>> -ravb_set_duplex(ndev);
>> -
>> -error_exit:
>> -mdelay(1);
>> -
>> -/* Enable TX and RX */
>> -ravb_rcv_snd_enable(ndev);
>> -
>> -mmiowb();
>> -spin_unlock_irqrestore(>lock, flags);
>> -
>> -return error;
>> -}
>> -
> 
>But this part is clearly lumping it all together... 

Please elaborate.

> 
> [...]
>> @@ -1357,7 +1329,7 @@ static const struct ethtool_ops ravb_ethtool_ops = {
>>  .set_ringparam  = ravb_set_ringparam,
>>  .get_ts_info= ravb_get_ts_info,
>>  .get_link_ksettings = phy_ethtool_get_link_ksettings,
>> -.set_link_ksettings = ravb_set_link_ksettings,
>> +.set_link_ksettings = phy_ethtool_set_link_ksettings,
> 
>Should have been a part of the final patch in the fix/enhancement chain...

Please elaborate.

Do you mean that firstly I have to make erroneous ravb_set_link_ksettings()
to look similar to phy_ethtool_set_link_ksettings() and then remove it?

As I see it in the current context (removal of ravb_set_duplex() call and
so on), the problem with this approach is that the actual fix change will
be done on top of a number of enchancement changes, thus it contradicts to
the accepted 

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hi Simon,

On Monday, 28 May 2018 12:39:17 EEST Simon Horman wrote:
> On Fri, May 25, 2018 at 01:23:53PM +0300, Laurent Pinchart wrote:
> > On Friday, 25 May 2018 13:13:20 EEST Simon Horman wrote:
> >> On Thu, May 24, 2018 at 11:00:52AM +0300, Laurent Pinchart wrote:
> >>> On Wednesday, 21 February 2018 18:39:25 EEST Simon Horman wrote:
>  On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote:
> > 
> > [snip]
> > 
> > Laurent Pinchart (11):
> >   dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
> >   dt-bindings: display: renesas: Deprecate LVDS support in the DU
> > bindings
> >   drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
> >   drm: rcar-du: Convert LVDS encoder code to bridge driver
> >   ARM: dts: r8a7790: Convert to new LVDS DT bindings
> >   ARM: dts: r8a7791: Convert to new LVDS DT bindings
> >   ARM: dts: r8a7792: Convert to new DU DT bindings
> >   ARM: dts: r8a7793: Convert to new LVDS DT bindings
> >   ARM: dts: r8a7794: Convert to new DU DT bindings
> >   arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
> >   arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings
>  
>  I have marked the dts patches above as deferred as they depend
>  on the driver changes not to cause a regression. Please repost them
>  or otherwise ping me once the driver dependencies are present in an
>  rc release.
> >>> 
> >>> The driver changes have made it to v4.17-rc1. Is it too late for v4.18
> >>> ?
> >> 
> >> Unfortunately it is. Shall I apply them for v4.19?
> > 
> > Please do.
> 
> Hi Laurent,
> 
> I'm sorry to have to ask this, but in the light of Olof Johansson's recent
> comments in ("Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18")
> please consider squashing the DTS patches and reposting.

It's about time we stopped trying to game the kernel patch statistics :-)

Before I repost, has there been a consensus on the new rule ? And how are we 
expected to proceed from now on ?

-- 
Regards,

Laurent Pinchart

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Simon Horman]

On Fri, May 25, 2018 at 01:23:53PM +0300, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Friday, 25 May 2018 13:13:20 EEST Simon Horman wrote:
> > On Thu, May 24, 2018 at 11:00:52AM +0300, Laurent Pinchart wrote:
> > > On Wednesday, 21 February 2018 18:39:25 EEST Simon Horman wrote:
> > >> On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote:
> 
> [snip]
> 
> > >>> Laurent Pinchart (11):
> > >>>   dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
> > >>>   dt-bindings: display: renesas: Deprecate LVDS support in the DU
> > >>> bindings
> > >>>   drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
> > >>>   drm: rcar-du: Convert LVDS encoder code to bridge driver
> > >>>   ARM: dts: r8a7790: Convert to new LVDS DT bindings
> > >>>   ARM: dts: r8a7791: Convert to new LVDS DT bindings
> > >>>   ARM: dts: r8a7792: Convert to new DU DT bindings
> > >>>   ARM: dts: r8a7793: Convert to new LVDS DT bindings
> > >>>   ARM: dts: r8a7794: Convert to new DU DT bindings
> > >>>   arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
> > >>>   arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings
> > >> 
> > >> I have marked the dts patches above as deferred as they depend
> > >> on the driver changes not to cause a regression. Please repost them
> > >> or otherwise ping me once the driver dependencies are present in an rc
> > >> release.
> > > 
> > > The driver changes have made it to v4.17-rc1. Is it too late for v4.18 ?
> > 
> > Unfortunately it is. Shall I apply them for v4.19?
> 
> Please do.

Hi Laurent,

I'm sorry to have to ask this, but in the light of Olof Johansson's recent
comments in ("Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18")
please consider squashing the DTS patches and reposting.

Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT

[Simon Horman]

On Mon, May 28, 2018 at 10:54:57AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Mon, May 28, 2018 at 10:41 AM, Simon Horman  wrote:
> > On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> >> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> >> > On Wed, May 23, 2018 at 12:01 AM, Marek Vasut  
> >> > wrote:
> >> >> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >> >>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut  
> >> >>> wrote:
> >>  Drop the MTD partitioning from DT, since it does not describe HW
> >>  and to give way to a more flexible kernel command line partition
> >>  passing.
> >> 
> >>  To retain the original partitioning, assure you have enabled
> >>  CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >>  following to your kernel command line:
> >> 
> >>    mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >> >>>
> >> >>> I think the "@0" can be dropped, as it's optional?
> >> >>> 4m?
> >> >>
> >> >> My take on this is that the loader is actually at offset 0x0 of the MTD
> >> >> device and we explicitly state that in the mtdparts to anchor the first
> >> >> partition within the MTD device and all the other partitions are at
> >> >> offset +(sum of the sizes of all partitions listed before the current
> >> >> one) relative to that first partition.
> >> >
> >> > Where is this explicitly states for the first partition?
> >> >
> >> >> Removing the @0 feels fragile at best and it seems to depend on the
> >> >> current behavior of the code.
> >> >
> >> > Better, it also depends on the documented behavior:
> >> >
> >> > Documentation/admin-guide/kernel-parameters.txt refers to
> >> > drivers/mtd/cmdlinepart.c, which states:
> >> >
> >> >  *   := standard linux memsize
> >> >  *  if omitted the part will immediately follow the previous 
> >> > part
> >> >  *  or 0 if the first part
> >> >
> >> > None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> >> > help text, or in a defconfig bundled with the kernel, use @0 for the 
> >> > first
> >> > partition.
> >>
> >> I think this is exceptionally fragile and dangerous to depend on this,
> >> but so be it.
> >
> > Could you respin with this change?
> >
> > I would also like to ask for another change, in light of recent
> > feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> > Updates for v4.18").
> >
> > Please consolidate the dts patches into a single patch?
> 
> I think it's better to keep them split, as each commit description mentions
> what needs to be passed on the kernel command line for the corresponding
> board.
> 
> Combining it in a single patch makes it much harder to extract this 
> information.
> Unless you're fine with a list:
> 
>koelsch: ...
>wheat: mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)

Lets try a list.

Re: [PATCH] PCI: rcar: Clean up PHY init on failure

[Simon Horman]

On Fri, May 25, 2018 at 09:27:42PM +0200, Geert Uytterhoeven wrote:
> CC Sergei
> 
> On Fri, May 25, 2018 at 8:33 PM, Marek Vasut  wrote:
> > If the Gen3 PHY fails to power up, the code does not undo the
> > initialization caused by phy_init(). Add the missing failure
> > handling to the rcar_pcie_phy_init_gen3() function.
> >
> > Signed-off-by: Marek Vasut 
> > Reported-by: Geert Uytterhoeven 
> > Cc: Geert Uytterhoeven 
> > Cc: Lorenzo Pieralisi 
> > Cc: Phil Edworthy 
> > Cc: Simon Horman 
> > Cc: Wolfram Sang 
> > Cc: linux-renesas-soc@vger.kernel.org
> > Fixes: 517ca93a7159 ("PCI: rcar: Add R-Car gen3 PHY support")
> 
> Reviewed-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

Re: [PATCH] arm64: dts: r8a77965: Add Watchdog Timer controller node using RCLK Watchdog Timer

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 2:36 PM, Yoshihiro Kaneko  wrote:
> From: Takeshi Kihara 
>
> Add a device node for the Watchdog Timer (WDT) controller on the Renesas
> R-Car M3N (R8A77965) SoC.
>
> Based on a similar patch of the R8A7796 device tree
> by Geert Uytterhoeven .
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Kaneko 

Reviewed-by: Geert Uytterhoeven 
Tested-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 2/2] arm64: dts: ulcb: Add sdhi2_ds pin group to SDHI2 pinctrl groups

[Simon Horman]

On Fri, May 25, 2018 at 05:05:18PM +0200, Wolfram Sang wrote:
> This patch adds definitions for configuration of the power-source,
> drive-strength, etc... for the SD2_DS pin. Based on a similar patch for
> Salvator boards by Masaharu Hayakawa and Takeshi Kihara.
> 
> Signed-off-by: Wolfram Sang 

Hi Wolfram,

Given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas ARM64
Based SoC DT Updates for v4.18") please consider squashing this
series into a single patch and reposting.

Re: [PATCH 0/2] arm: dts: salvator-x(s): increase I2C ch4 bus speed

[Simon Horman]

On Fri, May 25, 2018 at 01:05:40PM +0200, Wolfram Sang wrote:
> Patches taken from the BSP. I did some testing by accessing the chips 
> manually.
> I also checked the datasheets of the attached I2C clients which confirm this
> step up.

Hi Wolfram,

Given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas ARM64
Based SoC DT Updates for v4.18") please consider squashing this
series into a single patch and posting a v2.

Re: [PATCH 13/15] arm: dts: r8a7743: Add missing OPP properties for CPUs

[Simon Horman]

[Cc Biju Das]

On Fri, May 25, 2018 at 04:01:59PM +0530, Viresh Kumar wrote:
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
> 
> Add such missing properties.
> 
> Fix other missing property (clock latency) as well to make it all
> work.
> 
> Signed-off-by: Viresh Kumar 

Thanks, this looks good to me and it looks like it should have:

Fixes: 0417814ea140 ("ARM: dts: r8a7743: Add OPP table for frequency scaling")

Biju, as the author of the above patch could you take a look over this fix?

> ---
>  arch/arm/boot/dts/r8a7743.dtsi | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> index 142949d7066f..e4fb31c4f0ee 100644
> --- a/arch/arm/boot/dts/r8a7743.dtsi
> +++ b/arch/arm/boot/dts/r8a7743.dtsi
> @@ -98,8 +98,17 @@
>   reg = <1>;
>   clock-frequency = <15>;
>   clocks = < CPG_CORE R8A7743_CLK_Z>;
> + clock-latency = <30>; /* 300 us */
>   power-domains = < R8A7743_PD_CA15_CPU1>;
>   next-level-cache = <_CA15>;
> +
> + /* kHz - uV - OPPs unknown yet */
> + operating-points = <150 100>,
> +<1312500 100>,
> +<1125000 100>,
> +< 937500 100>,
> +< 75 100>,
> +< 375000 100>;
>   };
>  
>   L2_CA15: cache-controller-0 {
> -- 
> 2.15.0.194.g9af6a3dea062
> 

Re: [PATCH v7 3/5] ARM: dts: Renesas R9A06G032 base device tree file

[Simon Horman]

On Fri, May 25, 2018 at 11:27:46AM +0200, Geert Uytterhoeven wrote:
> Hi Michel,
> 
> On Thu, May 24, 2018 at 11:28 AM, Michel Pollet
>  wrote:
> > This adds the Renesas R9A06G032 bare bone support.
> >
> > This currently only handles generic parts (gic, architected timer)
> > and a UART.
> >
> > Signed-off-by: Michel Pollet 
> 
> Thanks for your patch!
> 
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/r9a06g032.dtsi
> 
> > +   soc {
> > +   compatible = "simple-bus";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   interrupt-parent = <>;
> > +   ranges;
> > +
> > +   sysctrl: sysctrl@4000c000 {
> 
> system-controller@
> 
> > +   compatible = "renesas,r9a06g032-sysctrl";
> > +   reg = <0x4000c000 0x1000>;
> > +   status = "okay";
> > +   #clock-cells = <1>;
> > +   };
> 
> With the minor nit above resolved, and pending acceptance of the
> sysctrl bindings:
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks. I have marked this patch, and the following one, as deferred
pending acceptance of those bindings. Please repost or otherwise ping me
once that has happened.

Re: [PATCH] arm64: dts: r8a77965: Add Watchdog Timer controller node using RCLK Watchdog Timer

[Simon Horman]

On Wed, May 23, 2018 at 09:36:35PM +0900, Yoshihiro Kaneko wrote:
> From: Takeshi Kihara 
> 
> Add a device node for the Watchdog Timer (WDT) controller on the Renesas
> R-Car M3N (R8A77965) SoC.
> 
> Based on a similar patch of the R8A7796 device tree
> by Geert Uytterhoeven .
> 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Kaneko 

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

Reviewed-by: Simon Horman 

Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI

[Geert Uytterhoeven]

Hi Kieran, Morimoto-san,

On Fri, Apr 27, 2018 at 6:57 PM, Kieran Bingham
 wrote:
> The DU1 external dot clock is provided by the fixed frequency clock
> generator X21, while the DU0 and DU3 clocks are provided by the
> programmable Versaclock5 clock generator.
>
> Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board
> and hook it up to the HDMI connector.
>
> Based on patches from Takeshi Kihara 
>
> Signed-off-by: Kieran Bingham 
>
> ---
> v2:
>  - Remove LVDS clocks from DU node
>  - Merge DU Clocks and HDMI enablement
> ---
>  .../boot/dts/renesas/r8a77965-salvator-x.dts  | 28 +++
>  1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts 
> b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> index 75d890d91df9..340a3c72b65a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
> @@ -19,3 +19,31 @@
> reg = <0x0 0x4800 0x0 0x7800>;
> };
>  };
> +
> + {
> +   clocks = < CPG_MOD 724>,
> +< CPG_MOD 723>,
> +< CPG_MOD 721>,
> +< 1>,
> +<_clk>,
> +< 2>;
> +   clock-names = "du.0", "du.1", "du.3",
> + "dclkin.0", "dclkin.1", "dclkin.3";
> +};
> +
> + {
> +   status = "okay";
> +
> +   ports {
> +   port@1 {
> +   reg = <1>;
> +   rcar_dw_hdmi0_out: endpoint {
> +   remote-endpoint = <_con>;
> +   };
> +   };
> +   };
> +};
> +
> +_con {
> +   remote-endpoint = <_dw_hdmi0_out>;
> +};

I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
Can we do that now (with stubs?), or does this have to wait until r8a77965 has
received HDMI sound support?

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 00/03] arm64: dts: renesas: Add IPMMU device nodes

[Simon Horman]

On Mon, May 21, 2018 at 11:44:44PM +0900, Magnus Damm wrote:
> arm64: dts: renesas: Add IPMMU device nodes
> 
> [PATCH 01/03] arm64: dts: renesas: r8a77965: Add IPMMU devices nodes
> [PATCH 02/03] arm64: dts: renesas: r8a77980: Add IPMMU devices nodes
> [PATCH 03/03] arm64: dts: renesas: r8a77990: Add IPMMU devices nodes
> 
> This series adds IPMMU device nodes to R-Car M3-N, V3H and E3 SoCs.
> 
> The IPMMU DT binding changes are not yet merged upstream however they
> have been documented by the following patches:
> 
> [PATCH] iommu/ipmmu-vmsa: Document R-Car M3-N IPMMU DT bindings 
> [PATCH] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings

Hi Magnus,

Given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas ARM64
Based SoC DT Updates for v4.18") please consider squashing this
series into a single patch when posting v2.

Re: [PATCH v4 0/6] PCI: rcar: Failpath fixes

[Simon Horman]

On Fri, May 25, 2018 at 05:43:13PM +0100, Lorenzo Pieralisi wrote:
> On Thu, May 24, 2018 at 04:36:18PM +0200, Marek Vasut wrote:
> > Multiple minor failpath fixes for the R-Car PCIe driver.
> > 
> > V4: Sync up the version numbers
> > Rebase on top of Lorenzo's tree
> > Add new patch fixing bug in the PHY code
> > 
> > Marek Vasut (6):
> >   PCI: rcar: Pull bus clock enable/disable from
> > rcar_pcie_get_resources()
> >   PCI: rcar: Add missing irq_dispose_mapping() into failpath
> >   PCI: rcar: Teardown MSI setup if rcar_pcie_enable() fails
> >   PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
> >   PCI: rcar: Remove IRQ mappings in rcar_pcie_enable_msi failpath
> >   PCI: rcar: Shut the PHY down in failpath
> > 
> >  drivers/pci/host/pcie-rcar.c | 82 
> > +++-
> >  1 file changed, 66 insertions(+), 16 deletions(-)
> 
> Marek,
> 
> I have applied patches [1-5] to pci/rcar for v4.18, I could not
> apply patch 6 since it is missing Simon's ACK (please have a look
> at what I queued to check it is OK).

Sorry for the delay. You should have that now.

If not, for the entire series:

Acked-by: Simon Horman 


> 
> Bjorn will be merging the branch into -next shortly, I do not know if
> there is room for adding additional patches on top of it, as I mentioned
> on linux-pci I will be offline for two weeks so it is possible that
> what's in pci/rcar at present will be what gets into v4.18, apologies,
> that's all I can do.

Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT

[Geert Uytterhoeven]

Hi Simon,

On Mon, May 28, 2018 at 10:41 AM, Simon Horman  wrote:
> On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
>> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
>> > On Wed, May 23, 2018 at 12:01 AM, Marek Vasut  
>> > wrote:
>> >> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
>> >>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut  
>> >>> wrote:
>>  Drop the MTD partitioning from DT, since it does not describe HW
>>  and to give way to a more flexible kernel command line partition
>>  passing.
>> 
>>  To retain the original partitioning, assure you have enabled
>>  CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
>>  following to your kernel command line:
>> 
>>    mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
>> >>>
>> >>> I think the "@0" can be dropped, as it's optional?
>> >>> 4m?
>> >>
>> >> My take on this is that the loader is actually at offset 0x0 of the MTD
>> >> device and we explicitly state that in the mtdparts to anchor the first
>> >> partition within the MTD device and all the other partitions are at
>> >> offset +(sum of the sizes of all partitions listed before the current
>> >> one) relative to that first partition.
>> >
>> > Where is this explicitly states for the first partition?
>> >
>> >> Removing the @0 feels fragile at best and it seems to depend on the
>> >> current behavior of the code.
>> >
>> > Better, it also depends on the documented behavior:
>> >
>> > Documentation/admin-guide/kernel-parameters.txt refers to
>> > drivers/mtd/cmdlinepart.c, which states:
>> >
>> >  *   := standard linux memsize
>> >  *  if omitted the part will immediately follow the previous 
>> > part
>> >  *  or 0 if the first part
>> >
>> > None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
>> > help text, or in a defconfig bundled with the kernel, use @0 for the first
>> > partition.
>>
>> I think this is exceptionally fragile and dangerous to depend on this,
>> but so be it.
>
> Could you respin with this change?
>
> I would also like to ask for another change, in light of recent
> feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> Updates for v4.18").
>
> Please consolidate the dts patches into a single patch?

I think it's better to keep them split, as each commit description mentions
what needs to be passed on the kernel command line for the corresponding
board.

Combining it in a single patch makes it much harder to extract this information.
Unless you're fine with a list:

   koelsch: ...
   wheat: mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)

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 v4 5/6] PCI: rcar: Remove IRQ mappings in rcar_pcie_enable_msi failpath

[Simon Horman]

On Thu, May 24, 2018 at 04:36:23PM +0200, Marek Vasut wrote:
> The rcar_pcie_enable_msi() creates IRQ mappings using irq_create_mapping()
> before requesting the IRQs using devm_request_irq(). If devm_request_irq()
> fails for some reason, rcar_pcie_enable_msi() does not remove the mapping.
> 
> Pull out the code for disposing IRQ mappings from rcar_pcie_teardown_msi()
> into a separate function and call it from both rcar_pcie_teardown_msi()
> and rcar_pcie_enable_msi() failpath to remove the mappings correctly.
> 
> Signed-off-by: Marek Vasut 
> Reported-by: Geert Uytterhoeven 
> Cc: Geert Uytterhoeven 
> Cc: Lorenzo Pieralisi 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org

Acked-by: Simon Horman 

Re: [PATCH v4 4/6] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()

[Simon Horman]

On Thu, May 24, 2018 at 04:36:22PM +0200, Marek Vasut wrote:
> The data link active signal usually takes ~20 uSec to be asserted,
> poll the bit more often to avoid useless delays in this function.
> Use udelay() instead of usleep() for such a small delay as suggested
> by the timer documentation and because this will be used in atomic
> context later on when the suspend/resume patches land.
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Lorenzo Pieralisi 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org

Acked-by: Simon Horman 

Re: [PATCH v4 3/6] PCI: rcar: Teardown MSI setup if rcar_pcie_enable() fails

[Simon Horman]

On Thu, May 24, 2018 at 04:36:21PM +0200, Marek Vasut wrote:
> If the rcar_pcie_enable() fails and MSIs are enabled, the setup done in
> rcar_pcie_enable_msi() is never undone. Add a function to tear down the
> MSI setup by disabling the MSI handling in the PCIe block, deallocating
> the pages requested for the MSIs and zapping the IRQ mapping.
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Lorenzo Pieralisi 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org

Reviewed-by: Simon Horman 

Re: [PATCH v4 2/6] PCI: rcar: Add missing irq_dispose_mapping() into failpath

[Simon Horman]

On Thu, May 24, 2018 at 04:36:20PM +0200, Marek Vasut wrote:
> The rcar_pcie_get_resources() is another misnomer with a side effect.
> The function does not only get resources, but also maps MSI IRQs via
> irq_of_parse_and_map(). In case anything fails afterward, the IRQ
> mapping must be disposed through irq_dispose_mapping() which is not
> done.
> 
> This patch handles irq_of_parse_and_map() failures in by disposing
> of the mapping in rcar_pcie_get_resources() as well as in probe.
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Lorenzo Pieralisi 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org


Acked-by: Simon Horman 

Re: [PATCH v4 1/6] PCI: rcar: Pull bus clock enable/disable from rcar_pcie_get_resources()

[Simon Horman]

On Thu, May 24, 2018 at 04:36:19PM +0200, Marek Vasut wrote:
> The rcar_pcie_get_resources() is another misnomer with a side effect.
> The function does not only get resources, but also enables/disables bus
> clock. This is forgotten in the probe() function though and if anything
> in probe() fails after rcar_pcie_get_resources() is called, the bus
> clock are never disabled.
> 
> This patch pulls the clock handling out of the rcar_pcie_get_resources()
> and enables clock after all the resources were requested. Moreover, this
> patch also always disables the clock in case of failure.
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Lorenzo Pieralisi 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: No change
> V3: No change
> V4: Rebase on top of Lorenzo's pci/rcar, fix up the rebase breakage
> induced by patches therein


Acked-by: Simon Horman 

> ---
>  drivers/pci/host/pcie-rcar.c | 33 -
>  1 file changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 8d161563bce8..0879880f7975 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -946,32 +946,22 @@ static int rcar_pcie_get_resources(struct rcar_pcie 
> *pcie)
>   dev_err(dev, "cannot get pcie bus clock\n");
>   return PTR_ERR(pcie->bus_clk);
>   }
> - err = clk_prepare_enable(pcie->bus_clk);
> - if (err)
> - return err;
>  
>   i = irq_of_parse_and_map(dev->of_node, 0);
>   if (!i) {
>   dev_err(dev, "cannot get platform resources for msi 
> interrupt\n");
> - err = -ENOENT;
> - goto err_map_reg;
> + return -ENOENT;
>   }
>   pcie->msi.irq1 = i;
>  
>   i = irq_of_parse_and_map(dev->of_node, 1);
>   if (!i) {
>   dev_err(dev, "cannot get platform resources for msi 
> interrupt\n");
> - err = -ENOENT;
> - goto err_map_reg;
> + return -ENOENT;
>   }
>   pcie->msi.irq2 = i;
>  
>   return 0;
> -
> -err_map_reg:
> - clk_disable_unprepare(pcie->bus_clk);
> -
> - return err;
>  }
>  
>  static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie,
> @@ -1115,22 +1105,28 @@ static int rcar_pcie_probe(struct platform_device 
> *pdev)
>   goto err_pm_put;
>   }
>  
> + err = clk_prepare_enable(pcie->bus_clk);
> + if (err) {
> + dev_err(dev, "failed to enable bus clock: %d\n", err);
> + goto err_pm_put;
> + }
> +
>   err = rcar_pcie_parse_map_dma_ranges(pcie, dev->of_node);
>   if (err)
> - goto err_pm_put;
> + goto err_clk_disable;
>  
>   phy_init_fn = of_device_get_match_data(dev);
>   err = phy_init_fn(pcie);
>   if (err) {
>   dev_err(dev, "failed to init PCIe PHY\n");
> - goto err_pm_put;
> + goto err_clk_disable;
>   }
>  
>   /* Failure to get a link might just be that no cards are inserted */
>   if (rcar_pcie_hw_init(pcie)) {
>   dev_info(dev, "PCIe link down\n");
>   err = -ENODEV;
> - goto err_pm_put;
> + goto err_clk_disable;
>   }
>  
>   data = rcar_pci_read_reg(pcie, MACSR);
> @@ -1142,16 +1138,19 @@ static int rcar_pcie_probe(struct platform_device 
> *pdev)
>   dev_err(dev,
>   "failed to enable MSI support: %d\n",
>   err);
> - goto err_pm_put;
> + goto err_clk_disable;
>   }
>   }
>  
>   err = rcar_pcie_enable(pcie);
>   if (err)
> - goto err_pm_put;
> + goto err_clk_disable;
>  
>   return 0;
>  
> +err_clk_disable:
> + clk_disable_unprepare(pcie->bus_clk);
> +
>  err_pm_put:
>   pm_runtime_put(dev);
>  
> -- 
> 2.16.2
> 

Re: [PATCH v4 6/6] PCI: rcar: Shut the PHY down in failpath

[Simon Horman]

On Thu, May 24, 2018 at 04:36:24PM +0200, Marek Vasut wrote:
> If anything fails past phy_init_fn() and the system is a Gen3 with
> a PHY, the PHY will be left on and inited. This is caused by the
> phy_init_fn, which is in fact a pointer to rcar_pcie_phy_init_gen3()
> function, which starts the PHY, yet has no counterpart in the failpath.
> Add that counterpart.
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Lorenzo Pieralisi 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org
> Fixes: 517ca93a7159 ("PCI: rcar: Add R-Car gen3 PHY support")

Acked-by: Simon Horman 

> ---
> V4: New patch
> ---
>  drivers/pci/host/pcie-rcar.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 636c3c5095d2..695781934f0a 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1163,7 +1163,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>   if (rcar_pcie_hw_init(pcie)) {
>   dev_info(dev, "PCIe link down\n");
>   err = -ENODEV;
> - goto err_clk_disable;
> + goto err_phy_shutdown;
>   }
>  
>   data = rcar_pci_read_reg(pcie, MACSR);
> @@ -1175,7 +1175,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>   dev_err(dev,
>   "failed to enable MSI support: %d\n",
>   err);
> - goto err_clk_disable;
> + goto err_phy_shutdown;
>   }
>   }
>  
> @@ -1189,6 +1189,12 @@ static int rcar_pcie_probe(struct platform_device 
> *pdev)
>   if (IS_ENABLED(CONFIG_PCI_MSI))
>   rcar_pcie_teardown_msi(pcie);
>  
> +err_phy_shutdown:
> + if (pcie->phy) {
> + phy_power_off(pcie->phy);
> + phy_exit(pcie->phy);
> + }
> +
>  err_clk_disable:
>   clk_disable_unprepare(pcie->bus_clk);
>  
> -- 
> 2.16.2
> 

Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT

[Simon Horman]

On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> > Hi Marek,
> > 
> > On Wed, May 23, 2018 at 12:01 AM, Marek Vasut  wrote:
> >> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut  
> >>> wrote:
>  Drop the MTD partitioning from DT, since it does not describe HW
>  and to give way to a more flexible kernel command line partition
>  passing.
> 
>  To retain the original partitioning, assure you have enabled
>  CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
>  following to your kernel command line:
> 
>    mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >>>
> >>> I think the "@0" can be dropped, as it's optional?
> >>> 4m?
> >>
> >> My take on this is that the loader is actually at offset 0x0 of the MTD
> >> device and we explicitly state that in the mtdparts to anchor the first
> >> partition within the MTD device and all the other partitions are at
> >> offset +(sum of the sizes of all partitions listed before the current
> >> one) relative to that first partition.
> > 
> > Where is this explicitly states for the first partition?
> > 
> >> Removing the @0 feels fragile at best and it seems to depend on the
> >> current behavior of the code.
> > 
> > Better, it also depends on the documented behavior:
> > 
> > Documentation/admin-guide/kernel-parameters.txt refers to
> > drivers/mtd/cmdlinepart.c, which states:
> > 
> >  *   := standard linux memsize
> >  *  if omitted the part will immediately follow the previous 
> > part
> >  *  or 0 if the first part
> > 
> > None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> > help text, or in a defconfig bundled with the kernel, use @0 for the first
> > partition.
> 
> I think this is exceptionally fragile and dangerous to depend on this,
> but so be it.

Could you respin with this change?

I would also like to ask for another change, in light of recent
feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
Updates for v4.18").

Please consolidate the dts patches into a single patch?

I have applied the defconfig patch, so there is no need to repost that one.

Re: [PATCH 1/9] ARM: shmobile: defconfig: Enable MTD command line partition parsing

[Simon Horman]

On Tue, May 22, 2018 at 02:02:49PM +0200, Marek Vasut wrote:
> In preparation for removing MTD partitioning from the DTs and moving
> it over to kernel command line partition parsing, enable the support
> for kernel command line MTD partition parsing.
> 
> The argument for not having MTD partitions in the DT is the same as
> for not having hard drive partitions in DT, neither describes the
> hardware itself, so it shouldn't be in the DT. Furthermore, kernel
> command line MTD partition passing allows greater flexibility in
> case someone decided to repartition the flash, which is well in the
> realm of possibility with these systems.
> 
> Signed-off-by: Marek Vasut 

Thanks, applied.

Re: [PATCH] gpio: dwapb: Fix rework support for 1 interrupt per port A GPIO

[Linus Walleij]

On Fri, May 25, 2018 at 5:11 PM, Phil Edworthy
 wrote:

> Commit da069d5d2b814d9887989dcdb29fb0202eac8b38 ("gpio: dwapb: Rework
> support for 1 interrupt per port A GPIO"), was an incremental patch that
> was supposed to provide the delta between v5 and v6 patch set for
> adding support for 1 interupt per port A GPIO. v5 was applied, then some
> other feedback came afterwards.
>
> However, in my haste I managed to drop the changes made to dwapb_port_property
> struct. This patch includes those missing changes.
>
> Signed-off-by: Phil Edworthy 

Patch applied!

Yours,
Linus Walleij

Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18

[Simon Horman]

Hi Olof,

On Sat, May 26, 2018 at 02:14:20PM -0700, Olof Johansson wrote:
> Hi Simon,
> 
> On Fri, May 18, 2018 at 01:16:00PM +0200, Simon Horman wrote:
> > Hi Olof, Hi Kevin, Hi Arnd,
> > 
> > Please consider these Renesas ARM64 based SoC DT updates for v4.18.
> > 
> > 
> > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> > 
> >   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> > 
> > are available in the git repository at:
> > 
> >   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> > tags/renesas-arm64-dt-for-v4.18
> > 
> > for you to fetch changes up to 908001d778eba06ee1d832863d4e9a1e2cfd4746:
> > 
> >   arm64: dts: renesas: salvator-common: Add ADV7482 support (2018-05-18 
> > 11:52:03 +0200)
> 
> This pull request is really, really hard for us to digest. The tag
> description is very large, and it repeats several SoCs several times,
> making it hard to get an overview of what is in it. The verbosity of "
> says.." makes it harder on this size of a pull request as well.

I appologise that this pull-request has turned out to be hard to digest.

I think that one reason for this is that there are an unusally large number
of commits. It seems that the team has been a little more productive than
usual and I might have been better to send a smaller pull-request earlier
in the development cycle and then follow-up with a second batch. I'll try
to pay more attention to this aspect of things going forwards.

Regarding your specific comments:

* Repetition of SoCs. I do try to group things in a logical manner,
  but clearly I failed in this case. I'll try to make that a bit clearer
  in future.

* Verbosity: There as a request a few development cycles for me
  to include more information in the commit logs. It seems that
  I may have gone a bit too far. I'll try to find a better balance next
  time around.

* Patches for the same change split up for different SoCs/boards.
  Featurs broken out into incremental patches. And so on.

  This has been a long-standing practice for Renesas SoC development.
  We find that in general it aids review. It also works well
  with the way we develop patches. But I do see your point that
  it may be a little excessive - f.e. multiple patches for the same
  whitespace fixes. Again, we'll try to find a better balance.

> 
> For example:
> 
> > * Condor board with R-Car V3H (r8a77980) SoC
> >   - Enable eMMC
> > 
> > Sergei Shtylyov says "We're adding the R8A77980 MMC (SDHI)
> > device nodes and then enable eMMC support on the Condor board."
> 
> The "Enable eMMC" line is just fine here.
> 
> > 
> > Geert Uytterhoeven (11):
> >   arm64: dts: renesas: draak: Rename EtherAVB "mdc" pin group to "mdio"
> >   arm64: dts: renesas: salvator-common: Rename EtherAVB "mdc" pin group 
> > to "mdio"
> >   arm64: dts: renesas: ulcb: Rename EtherAVB "mdc" pin group to "mdio"
> 
> Why can't these be done in one commit?
> 
> >   arm64: dts: renesas: r8a7795: Correct whitespace
> >   arm64: dts: renesas: r8a7796: Correct whitespace
> >   arm64: dts: renesas: r8a77965: Correct whitespace
> 
> Do these really need to be three commits to fix some whitespace?
> 
> >   arm64: dts: renesas: ulcb: Add BD9571 PMIC
> >   arm64: dts: renesas: salvator-common: Add PMIC DDR Backup Power config
> >   arm64: dts: renesas: ulcb: Add PMIC DDR Backup Power config
> >   arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core
> >   arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node
> 
> Why can't these be done in the same commit?
> 
> > Kieran Bingham (7):
> >   arm64: dts: renesas: r8a77965: Add FCPF and FCPV instances
> >   arm64: dts: renesas: r8a77965: Add VSP instances
> >   arm64: dts: renesas: r8a77965: Populate the DU instance placeholder
> >   arm64: dts: renesas: r8a77965: Add HDMI encoder instance
> >   arm64: dts: renesas: r8a77965-salvator-x: Enable DU external clocks 
> > and HDMI
> >   arm64: dts: renesas: r8a77965-salvator-xs: Enable DU external clocks 
> > and HDMI
> 
> These two can probably be in one commit as well.
> 
> >   arm64: dts: renesas: salvator-common: Add ADV7482 support
> > 
> > Kuninori Morimoto (8):
> >   arm64: dts: renesas: r8a7795: add HDMI sound support
> >   arm64: dts: renesas: r8a7796: add HDMI sound support
> 
> ... starting to see a trend?
> 
> >   arm64: dts: renesas: salvator-common: use audio-graph-card for Sound
> >   arm64: dts: renesas: r8a7795-es1-salvator-x: enable HDMI sound
> >   arm64: dts: renesas: r8a7795-salvator-xs: enable HDMI sound
> >   arm64: dts: renesas: r8a7796-salvator-xs: enable HDMI sound
> >   arm64: dts: renesas: r8a7795-salvator-x: enable HDMI sound
> >   arm64: dts: renesas: r8a7796-salvator-x: enable HDMI sound
> 
> ... and more.
> 
> > 
> > Magnus Damm (5):
> >   arm64: dts: renesas: r8a77970: Update IPMMU DS1 bit