date:20180410

Hi Andy,

Thank you for the review!

> From: Andy Shevchenko, Sent: Tuesday, April 10, 2018 9:40 PM
> 
> On Tue, Apr 10, 2018 at 3:03 PM, Yoshihiro Shimoda
>  wrote:

> > +#include 
> > +#include 
> > +#include 
> 
> > +#include 
> 
> Do you need this one?

If using of_parse_phandle() is acceptable, I need linux/of_platform.h at least.

> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> > +static const struct of_device_id rcar_usb3_role_switch_of_match[] = {
> > +   { .compatible = "renesas,rcar-usb3-role-switch" },
> > +   { },
> 
> Better to remove comma at terminator line.

I got it. I will fix it in v2.

> > +};
> > +MODULE_DEVICE_TABLE(of, rcar_usb3_role_switch_of_match);
> 
> > +static int rcar_usb3_role_switch_probe(struct platform_device *pdev)
> > +{
> 
> > +   /* Avoid devm_request_mem_region() calling by 
> > devm_ioremap_resource() */
> 
> Redundant comment.

I will remove this comment.

> > +   host_node = of_parse_phandle(pdev->dev.of_node, "renesas,host", 0);
> > +   if (!host_node)
> > +   return -ENODEV;
> > +
> > +   pdev_host = of_find_device_by_node(host_node);
> > +   if (!pdev_host)
> > +   return -ENODEV;
> > +
> > +   of_node_put(host_node);
> 
> Isn't what Heikki tried to solve with graphs and stuff like that?

Heikki prepared "device connection" framework (devcon) [1] to get a device 
pointer.
However, IIUC, we need to improve the framework for device tree environment 
because:
 - The devcon needs each dev_name() through the endpoint array of struct 
device_connection.
 - Each dev_name() on device tree environment will be .,
   f.e. "ee02.usb". So, I don’t think adding such strings to a driver is a 
good way.

So, I wrote such a code by using existing APIs.
Should I improve the framework first somehow? Or, is my understanding incorrect?

[1] https://patchwork.kernel.org/patch/10297041/

> > +   dev_info(>dev, "probed\n");
> 
> Noise. (Hint: initcall_debug is a good command line option)

Thank you for the hint! I will remove the dev_info().

> > +}
> 
> > +#ifdef CONFIG_PM_SLEEP
> 
> Instead...
> 
> > +static int rcar_usb3_role_switch_suspend(struct device *dev)
> 
> ...use __maybe_unused annotation.
> 
> > +static int rcar_usb3_role_switch_resume(struct device *dev)
> 
> Ditto.

I will fix them in v2 patch.

> > +#endif
> 
> 
> > +static struct platform_driver rcar_usb3_role_switch_driver = {
> > +   .probe  = rcar_usb3_role_switch_probe,
> > +   .remove = rcar_usb3_role_switch_remove,
> > +   .driver = {
> > +   .name = "rcar_usb3_role_switch",
> > +   .pm = _usb3_role_switch_pm_ops,
> 
> > +   .of_match_table = 
> > of_match_ptr(rcar_usb3_role_switch_of_match),
> 
> Is it possible to have this driver w/o OF? Does it make sense in that case?
> Otherwise remove of_match_ptr() call and below modalias.

This driver depends on OF now. So, I will remove of_match_ptr() and 
MODULE_ALIAS().

Best regards,
Yoshihiro Shimoda

> > +   },
> > +};
> 
> > +MODULE_ALIAS("platform:rcar_usb3_role_switch");
> 
> --
> With Best Regards,
> Andy Shevchenko

[PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers

From: Wolfram Sang 

Intentionally missing i2c-riic here, Chris Brandt will add himself for
that one later.

Signed-off-by: Wolfram Sang 
---

Changes since v1:
* add EMEV2 and PINCTRL DEMUX drivers

 MAINTAINERS | 16 
 1 file changed, 16 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1fe9149fa062..e53d40028e03 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5906,6 +5906,11 @@ S:   Supported
 F: drivers/phy/
 F: include/linux/phy/
 
+GENERIC PINCTRL I2C DEMULTIPLEXER DRIVER
+M: Wolfram Sang 
+S: Supported
+F: drivers/i2c/muxes/i2c-demux-pinctrl.c
+
 GENERIC PM DOMAINS
 M: "Rafael J. Wysocki" 
 M: Kevin Hilman 
@@ -11884,6 +11889,11 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git c
 S: Supported
 F: drivers/clk/renesas/
 
+RENESAS EMEV2 I2C DRIVER
+M: Wolfram Sang 
+S: Supported
+F: drivers/i2c/busses/i2c-emev2.c
+
 RENESAS ETHERNET DRIVERS
 R: Sergei Shtylyov 
 L: net...@vger.kernel.org
@@ -11899,6 +11909,12 @@ L: linux-...@vger.kernel.org
 S: Supported
 F: drivers/iio/adc/rcar_gyro_adc.c
 
+RENESAS R-CAR I2C DRIVERS
+M: Wolfram Sang 
+S: Supported
+F: drivers/i2c/busses/i2c-rcar.c
+F: drivers/i2c/busses/i2c-sh_mobile.c
+
 RENESAS USB PHY DRIVER
 M: Yoshihiro Shimoda 
 L: linux-renesas-soc@vger.kernel.org
-- 
2.11.0

[PATCH v2 1/2] MAINTAINERS: remove me as maintainer for I2C host drivers

The number of I2C host controller drivers keeps increasing, and although
I had some success acquiring specific driver maintainers, my bandwidth
is by far not enough to act as a fallback for the rest of the drivers.
To reflect this status-quo in MAINTAINERS, add a seperate entry for I2C
host drivers, let the I2C list (= community) be the contact point, and
mark this section as "Odd fixes".

Signed-off-by: Wolfram Sang 
---

Changes since v1:
* explicitly state which files from include/linux I keep maintaining
* rename the new section to HOST DRIVERS instead of just DRIVERS
* explicitly state which subdirs belong to the HOST DRIVERS section

 MAINTAINERS | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 342895717506..1fe9149fa062 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6580,15 +6580,25 @@ W:  https://i2c.wiki.kernel.org/
 Q: https://patchwork.ozlabs.org/project/linux-i2c/list/
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
 S: Maintained
-F: Documentation/devicetree/bindings/i2c/
+F: Documentation/devicetree/bindings/i2c/i2c.txt
 F: Documentation/i2c/
-F: drivers/i2c/
-F: drivers/i2c/*/
+F: drivers/i2c/*
 F: include/linux/i2c.h
-F: include/linux/i2c-*.h
+F: include/linux/i2c-dev.h
+F: include/linux/i2c-smbus.h
 F: include/uapi/linux/i2c.h
 F: include/uapi/linux/i2c-*.h
 
+I2C SUBSYSTEM HOST DRIVERS
+L: linux-...@vger.kernel.org
+W: https://i2c.wiki.kernel.org/
+Q: https://patchwork.ozlabs.org/project/linux-i2c/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
+S: Odd Fixes
+F: Documentation/devicetree/bindings/i2c/
+F: drivers/i2c/algos/
+F: drivers/i2c/busses/
+
 I2C-TAOS-EVM DRIVER
 M: Jean Delvare 
 L: linux-...@vger.kernel.org
-- 
2.11.0

Re: [PATCH v2 3/4] arm64: dts: renesas: r8a77970: add LVDS support

2018-04-10 Thread Sergei Shtylyov

On 04/10/2018 03:13 PM, jacopo mondi wrote:

>>> From: Niklas Söderlund 
>>>
>>> Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
>>> the it to the LVDS output of the DU.
>>>
>>> Signed-off-by: Niklas Söderlund 
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Laurent Pinchart 
>>>
>>> ---
>>> v1 -> v2:
>>> - Rebased on the modified endpoint name and changed patch subject to
>>>   comply with other patches in the series from Sergei.
>>
>>Stop, what was wrong with my R8A77970 LVDS patch, reposted on the popular
>> demand? :-)
>>
> 
> Nothing wrong, I found out about your right now.
> I see a very small difference as
>  lvds@feb9 vs lvds-encoder@feb9

   Yes, I thought the latter was closer to a "generic" name that DT spec 
requires...

> You can add your signed-off-by ofc if you think that's the case.

   Didn't understand what you mean here...

> Thanks
>j

MBR, Sergei

Re: [PATCH] mtd: partitions: Handle add_mtd_device() failures gracefully

2018-04-10 Thread Steve deRosier

On Tue, Apr 10, 2018 at 7:47 AM, Geert Uytterhoeven
 wrote:
> Hi Marek,
>
> On Tue, Apr 10, 2018 at 4:37 PM, Marek Vasut  wrote:
>> On 04/10/2018 03:26 PM, Geert Uytterhoeven wrote:
>>> On Mon, Apr 9, 2018 at 11:59 PM, Marek Vasut  wrote:
 On 04/09/2018 02:25 PM, Geert Uytterhoeven wrote:
> Currently add_mtd_device() failures are plainly ignored, which may lead
> to kernel crashes later.
>>>
> Fix this by ignoring and freeing partitions that failed to add in
> add_mtd_partitions().  The same issue is present in mtd_add_partition(),
> so fix that as well.
>
> Signed-off-by: Geert Uytterhoeven 
> ---
> I don't know if it is worthwhile factoring out the common handling.
>
> Should allocate_partition() fail instead?  There's a comment saying
> "let's register it anyway to preserve ordering".
>>>
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
>>>
> @@ -746,7 +753,15 @@ int add_mtd_partitions(struct mtd_info *master,
>   list_add(>list, _partitions);
>   mutex_unlock(_partitions_mutex);
>
> - add_mtd_device(>mtd);
> + ret = add_mtd_device(>mtd);
> + if (ret) {
> + mutex_lock(_partitions_mutex);
> + list_del(>list);
> + mutex_unlock(_partitions_mutex);
> + free_partition(slave);
> + continue;
> + }

 Why is the partition even in the list in the first place ? Can we avoid
 adding it rather than adding and removing it ?
>>>
>>> Hence my question "Should allocate_partition() fail instead?".
>>> Note that if we go that route, it should be a "soft" failure, as we
>>> probably don't
>>> want to drop all other partitions on the device.
>> Is the number of partitions ie. in /proc/mtdparts an ABI ?
>
> I don't know.
>

I don't know if it's an ABI, but having consistent /dev/mtdX numbering
is important, even in the case of a failed partition.  Many scripts on
embedded systems are hard-coded to /dev/mtdX identifies with the
expectation that they can access a particular address region of flash.
I'm sure that's what the "let's register it anyway to preserve
ordering" comment was trying to get across. I've even seen weird
things in dts files where later entries specify earlier addresses in
order to leave the old /dev/mtdX numbering alone.

Obviously, a better user solution is to construct the mtdX number from
/proc/mtd based on filtering for the name field, but not everyone
does.

I'd be wary about doing any fix that disturbs the numbering as you'll
be disturbing users.  At a minum, a loud warning in the log.

That said - obviously fixing the kernel crash must happen.

- Steve

Re: [PATCH V5] PCI: rcar: Use runtime PM to control controller clock

On 04/10/2018 05:28 PM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

[...]

 The pairing looks as follows:

 .- rcar_pcie_parse_request_of_pci_ranges()
 |  (pm_runtime_enable is here)
 | .- pm_runtime_get_sync()
 | | .- rcar_pcie_get_resources()
>>>
>>> rcar_pcie_get_resources() is called  while the device is 
>>> runtime-enabled/resumed
>>
>> Because something may access the device, yes.
>>
 | | |
 | | '- pm_runtime_put()
 | '- pm_runtime_disable() + pci_free_resource_list()
>>>
>>> pci_free_resource_list() is called while the device is runtime-disabled.
>>
>> Because nothing will access the device.
>>
 '- pci_free_host_bridge()

 It looks symmetric to me ...
>>>
>>> rcar_pcie_get_resources() is called while the device is
>>> runtime-enabled/resumed,
>>> pci_free_resource_list() is called while the device is runtime-disabled.
>>
>> At this point, I think I'd rather see a diff of changes which you have
>> in mind rather than this endless discussion. Can you provide one against
>> this patch ?
> 
> My final comment:
> 
> If the steps during probing are A..Z, cleanup and removal should undo them
> in reverse order (Z..A), unless there's a very good reason not to do so.

I spent extra time going through the probe function and I just don't see
how it is not done in the exact reverse, I checked every single goto
statement in probe.

I noticed this though:

>>> rcar_pcie_get_resources() is called while the device is
>>> runtime-enabled/resumed,
>>> pci_free_resource_list() is called while the device is runtime-disabled.

rcar_pcie_get_resources() is NOT a pair function for
pci_free_resource_list() . rcar_pcie_parse_request_of_pci_ranges() is a
pair function for pci_free_resource_list().

rcar_pcie_parse_request_of_pci_ranges() calls
of_pci_get_host_bridge_resources() internally, so every single function
called after successful call of rcar_pcie_parse_request_of_pci_ranges()
must call pci_free_resource_list().

Both of_pci_get_host_bridge_resources() and pci_free_resource_list() are
called with runtime PM disabled.

The naming of the functions is confusing though.

-- 
Best regards,
Marek Vasut

[PATCH v2 1/2] vfio: platform: Fix reset module leak in error path

If the IOMMU group setup fails, the reset module is not released.

Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by 
default")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Eric Auger 
---
v2:
  - Add Reviewed-by.
---
 drivers/vfio/platform/vfio_platform_common.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 35469af87f88678e..b60bb5326668498c 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -680,18 +680,23 @@ int vfio_platform_probe_common(struct 
vfio_platform_device *vdev,
group = vfio_iommu_group_get(dev);
if (!group) {
pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put_reset;
}
 
ret = vfio_add_group_dev(dev, _platform_ops, vdev);
-   if (ret) {
-   vfio_iommu_group_put(group, dev);
-   return ret;
-   }
+   if (ret)
+   goto put_iommu;
 
mutex_init(>igate);
 
return 0;
+
+put_iommu:
+   vfio_iommu_group_put(group, dev);
+put_reset:
+   vfio_platform_put_reset(vdev);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(vfio_platform_probe_common);
 
-- 
2.7.4

[PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

Vfio-platform requires reset support, provided either by ACPI, or, on DT
platforms, by a device-specific reset driver matching against the
device's compatible value.

On many SoCs, devices are connected to an SoC-internal reset controller.
If the reset hierarchy is described in DT using "resets" properties,
such devices can be reset in a generic way through the reset controller
subsystem.  Hence add support for this, avoiding the need to write
device-specific reset drivers for each single device on affected SoCs.

Devices that do require a more complex reset procedure can still provide
a device-specific reset driver, as that takes precedence.

Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
becomes a no-op (as in: "No reset function found for device") if reset
controller support is disabled.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Don't store error values in vdev->reset_control,
  - Use of_reset_control_get_exclusive() instead of
__of_reset_control_get(),
  - Improve description.
---
 drivers/vfio/platform/vfio_platform_common.c  | 26 --
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index b60bb5326668498c..3c13327b2777f8ec 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 
@@ -112,11 +113,19 @@ static bool vfio_platform_has_reset(struct 
vfio_platform_device *vdev)
if (VFIO_PLATFORM_IS_ACPI(vdev))
return vfio_platform_acpi_has_reset(vdev);
 
-   return vdev->of_reset ? true : false;
+   if (vdev->of_reset)
+   return true;
+
+   if (vdev->reset_control)
+   return true;
+
+   return false;
 }
 
 static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
 {
+   struct reset_control *rstc;
+
if (VFIO_PLATFORM_IS_ACPI(vdev))
return vfio_platform_acpi_has_reset(vdev) ? 0 : -ENOENT;
 
@@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct 
vfio_platform_device *vdev)
vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>reset_module);
}
+   if (vdev->of_reset)
+   return 0;
+
+   rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
+   if (!IS_ERR(rstc)) {
+   vdev->reset_control = rstc;
+   return 0;
+   }
 
-   return vdev->of_reset ? 0 : -ENOENT;
+   return PTR_ERR(rstc);
 }
 
 static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
@@ -138,6 +155,8 @@ static void vfio_platform_put_reset(struct 
vfio_platform_device *vdev)
 
if (vdev->of_reset)
module_put(vdev->reset_module);
+
+   reset_control_put(vdev->reset_control);
 }
 
 static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
@@ -217,6 +236,9 @@ static int vfio_platform_call_reset(struct 
vfio_platform_device *vdev,
} else if (vdev->of_reset) {
dev_info(vdev->device, "reset\n");
return vdev->of_reset(vdev);
+   } else if (vdev->reset_control) {
+   dev_info(vdev->device, "reset\n");
+   return reset_control_reset(vdev->reset_control);
}
 
dev_warn(vdev->device, "no reset function found!\n");
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -60,6 +60,7 @@ struct vfio_platform_device {
const char  *compat;
const char  *acpihid;
struct module   *reset_module;
+   struct reset_control*reset_control;
struct device   *device;
 
/*
-- 
2.7.4

[PATCH v2 0/2] vfio: platform: Improve reset support

Hi all,

This patch series improves reset support for vfio-platform:
  - The first patch fixes a bug I ran into while working on this.
  - The second patch implements generic DT reset controller support, for
devices that are connected to an SoC-internal reset controller and
can be reset in a generic way.  This avoids having to write/change a
vfio-specific reset driver for each and every device to be
passed-through to a guest.

Changes compared to v1:
  - Add Reviewed-by,
  - Don't store error values in vdev->reset_control,
  - Use of_reset_control_get_exclusive() instead of
__of_reset_control_get(),
  - Improve description.

This has been tested on R-Car H3/Salvator-XS by exporting a GPIO module
to a QEMU+KWM guest: the GPIO module is reset before QEMU opens the vfio
device, and reset again after QEMU has released it, as can be witnessed
by the LEDs connected to the GPIOs.

Thanks!

Geert Uytterhoeven (2):
  vfio: platform: Fix reset module leak in error path
  vfio: platform: Add generic DT reset controller support

 drivers/vfio/platform/vfio_platform_common.c  | 41 ++-
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 35 insertions(+), 7 deletions(-)

-- 
2.7.4

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] PCI: rcar: Use runtime PM to control controller clock

Hi Marek,

On Tue, Apr 10, 2018 at 5:25 PM, Marek Vasut  wrote:
> On 04/10/2018 04:42 PM, Geert Uytterhoeven wrote:
>> On Tue, Apr 10, 2018 at 4:31 PM, Marek Vasut  wrote:
>>> On 04/09/2018 02:26 PM, Simon Horman wrote:
 On Mon, Apr 09, 2018 at 01:47:38PM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 9, 2018 at 1:41 PM, Simon Horman  wrote:
>> On Mon, Apr 09, 2018 at 10:20:05AM +0200, Marek Vasut wrote:
>>> On 04/09/2018 10:07 AM, Geert Uytterhoeven wrote:
 On Sun, Apr 8, 2018 at 3:09 PM, Marek Vasut  
 wrote:
> From: Dien Pham 
>
> The controller clock can be switched off during suspend/resume,
> let runtime PM take care of that.
>
> Signed-off-by: Dien Pham 
> Signed-off-by: Hien Dang 
> 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
> To: linux-...@vger.kernel.org
> ---
> V2: - Reorder the fail path in rcar_pcie_probe() to cater for the
>   reordering of function calls in probe
> - Dispose of fail_clk in rcar_pcie_get_resources()
> V3: - Fix up the failpath in probe function
> V4: - Rebase on recent linux-next
> V5: - Do not call pci_free_resource_list(>resources) if
>   rcar_pcie_parse_request_of_pci_ranges() fails, since that
>   functiona calls pci_free_resource_list() already.

 Thanks for the update!

> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c

> @@ -1124,22 +,22 @@ static int rcar_pcie_probe(struct 
> platform_device *pdev)
> if (err)
> goto err_free_bridge;
>
> +   pm_runtime_enable(pcie->dev);
> +   err = pm_runtime_get_sync(pcie->dev);
> +   if (err < 0) {
> +   dev_err(pcie->dev, "pm_runtime_get_sync failed\n");
> +   goto err_pm_disable;
> +   }
> +

 As you moved the pm_runtime setup up...

> err = rcar_pcie_get_resources(pcie);
> if (err < 0) {
> dev_err(dev, "failed to request resources: %d\n", 
> err);
> -   goto err_free_resource_list;
> +   goto err_pm_put;
> }
>
> err = rcar_pcie_parse_map_dma_ranges(pcie, dev->of_node);
> if (err)
> -   goto err_free_resource_list;
> -
> -   pm_runtime_enable(dev);
> -   err = pm_runtime_get_sync(dev);
> -   if (err < 0) {
> -   dev_err(dev, "pm_runtime_get_sync failed\n");
> -   goto err_pm_disable;
> -   }
> +   goto err_pm_put;
>
> /* Failure to get a link might just be that no cards are 
> inserted */
> hw_init_fn = of_device_get_match_data(dev);
> @@ -1174,9 +1161,8 @@ static int rcar_pcie_probe(struct 
> platform_device *pdev)
>
>  err_pm_disable:
> pm_runtime_disable(dev);

 ... shouldn't it be moved down here, for symmetry?
>>>
>>> I am reasonably certain the failpath should be correct now. Did I still
>>> miss something ?
>>
>> It looks correct to me too. Geert are Marek and I missing something?
>
> Probably it will still work fine, but after this patch, Runtime PM is 
> enabled
> early, and disabled early, which is not symmetrical.
>
> I like symmetry ;-)

 Understood. I think that is reasonable.
 Marek, would you care to respin?
>>>
>>> I am looking into the driver, but I fail to see what Geert is trying to
>>> make me change here.
>>>
>>> The pairing looks as follows:
>>>
>>> .- rcar_pcie_parse_request_of_pci_ranges()
>>> |  (pm_runtime_enable is here)
>>> | .- pm_runtime_get_sync()
>>> | | .- rcar_pcie_get_resources()
>>
>> rcar_pcie_get_resources() is called  while the device is 
>> runtime-enabled/resumed
>
> Because something may access the device, yes.
>
>>> | | |
>>> | | '- pm_runtime_put()
>>> | '- pm_runtime_disable() + pci_free_resource_list()
>>
>> pci_free_resource_list() is called while the device is runtime-disabled.
>
> Because nothing will access the device.
>
>>> '- pci_free_host_bridge()
>>>
>>> It looks

Re: [PATCH V5] PCI: rcar: Use runtime PM to control controller clock

On 04/10/2018 04:42 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Tue, Apr 10, 2018 at 4:31 PM, Marek Vasut  wrote:
>> On 04/09/2018 02:26 PM, Simon Horman wrote:
>>> On Mon, Apr 09, 2018 at 01:47:38PM +0200, Geert Uytterhoeven wrote:
 On Mon, Apr 9, 2018 at 1:41 PM, Simon Horman  wrote:
> On Mon, Apr 09, 2018 at 10:20:05AM +0200, Marek Vasut wrote:
>> On 04/09/2018 10:07 AM, Geert Uytterhoeven wrote:
>>> On Sun, Apr 8, 2018 at 3:09 PM, Marek Vasut  
>>> wrote:
 From: Dien Pham 

 The controller clock can be switched off during suspend/resume,
 let runtime PM take care of that.

 Signed-off-by: Dien Pham 
 Signed-off-by: Hien Dang 
 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
 To: linux-...@vger.kernel.org
 ---
 V2: - Reorder the fail path in rcar_pcie_probe() to cater for the
   reordering of function calls in probe
 - Dispose of fail_clk in rcar_pcie_get_resources()
 V3: - Fix up the failpath in probe function
 V4: - Rebase on recent linux-next
 V5: - Do not call pci_free_resource_list(>resources) if
   rcar_pcie_parse_request_of_pci_ranges() fails, since that
   functiona calls pci_free_resource_list() already.
>>>
>>> Thanks for the update!
>>>
 --- a/drivers/pci/host/pcie-rcar.c
 +++ b/drivers/pci/host/pcie-rcar.c
>>>
 @@ -1124,22 +,22 @@ static int rcar_pcie_probe(struct 
 platform_device *pdev)
 if (err)
 goto err_free_bridge;

 +   pm_runtime_enable(pcie->dev);
 +   err = pm_runtime_get_sync(pcie->dev);
 +   if (err < 0) {
 +   dev_err(pcie->dev, "pm_runtime_get_sync failed\n");
 +   goto err_pm_disable;
 +   }
 +
>>>
>>> As you moved the pm_runtime setup up...
>>>
 err = rcar_pcie_get_resources(pcie);
 if (err < 0) {
 dev_err(dev, "failed to request resources: %d\n", err);
 -   goto err_free_resource_list;
 +   goto err_pm_put;
 }

 err = rcar_pcie_parse_map_dma_ranges(pcie, dev->of_node);
 if (err)
 -   goto err_free_resource_list;
 -
 -   pm_runtime_enable(dev);
 -   err = pm_runtime_get_sync(dev);
 -   if (err < 0) {
 -   dev_err(dev, "pm_runtime_get_sync failed\n");
 -   goto err_pm_disable;
 -   }
 +   goto err_pm_put;

 /* Failure to get a link might just be that no cards are 
 inserted */
 hw_init_fn = of_device_get_match_data(dev);
 @@ -1174,9 +1161,8 @@ static int rcar_pcie_probe(struct 
 platform_device *pdev)

  err_pm_disable:
 pm_runtime_disable(dev);
>>>
>>> ... shouldn't it be moved down here, for symmetry?
>>
>> I am reasonably certain the failpath should be correct now. Did I still
>> miss something ?
>
> It looks correct to me too. Geert are Marek and I missing something?

 Probably it will still work fine, but after this patch, Runtime PM is 
 enabled
 early, and disabled early, which is not symmetrical.

 I like symmetry ;-)
>>>
>>> Understood. I think that is reasonable.
>>> Marek, would you care to respin?
>>
>> I am looking into the driver, but I fail to see what Geert is trying to
>> make me change here.
>>
>> The pairing looks as follows:
>>
>> .- rcar_pcie_parse_request_of_pci_ranges()
>> |  (pm_runtime_enable is here)
>> | .- pm_runtime_get_sync()
>> | | .- rcar_pcie_get_resources()
> 
> rcar_pcie_get_resources() is called  while the device is 
> runtime-enabled/resumed

Because something may access the device, yes.

>> | | |
>> | | '- pm_runtime_put()
>> | '- pm_runtime_disable() + pci_free_resource_list()
> 
> pci_free_resource_list() is called while the device is runtime-disabled.

Because nothing will access the device.

>> '- pci_free_host_bridge()
>>
>> It looks symmetric to me ...
> 
> rcar_pcie_get_resources() is called while the device is
> runtime-enabled/resumed,
> pci_free_resource_list() is called while the device is runtime-disabled.

At this point, I think I'd

RE: [PATCH] gpio: dwapb: Add support for 32 interrupts

2018-04-10 Thread Phil Edworthy

Hi Geert,

On 10 April 2018 15:29 Geert Uytterhoeven wrote:
> On Tue, Apr 10, 2018 at 4:23 PM, Phil Edworthy wrote:
> > On 10 April 2018 07:24 Phil Edworthy wrote:
> >> On 09 April 2018 20:20 Rob Herring wrote:
> >> > On Wed, Mar 28, 2018 at 03:22:30PM +0100, Phil Edworthy wrote:
> > [...]
> >> > > +- interrupt-mask : a 32-bit bit mask that specifies which
> >> > > +interrupts in the list
> >> > > +  of interrupts is valid, bit is 1 for a valid irq.
> >> >
> >> > This is not a standard property and would need a vendor prefix.
> >> > However,
> >> I'd
> >> > prefer you just skip any not connected interrupts with an invalid
> >> > interrupt number. Then the GPIO number is the index into "interrupts".
> >> Makes sense, I'll rework it to do this.
> > Err, what would an invalid interrupt number be?
> > If I use -1, I get a DT parsing error and 0 is certainly valid. If the
> > number is larger than the valid interrupt range I get errors during probe.
> 
> Perhaps using interrupts-extended instead of interrupts?
> 
> E.g.
> 
> interrupts-extended = < 5 1>, <0>, < 1 0>;

Thanks for the pointer, I'll have a look.
Phil

Re: [PATCH] mtd: partitions: Handle add_mtd_device() failures gracefully

Hi Marek,

On Tue, Apr 10, 2018 at 4:37 PM, Marek Vasut  wrote:
> On 04/10/2018 03:26 PM, Geert Uytterhoeven wrote:
>> On Mon, Apr 9, 2018 at 11:59 PM, Marek Vasut  wrote:
>>> On 04/09/2018 02:25 PM, Geert Uytterhoeven wrote:
 Currently add_mtd_device() failures are plainly ignored, which may lead
 to kernel crashes later.
>>
 Fix this by ignoring and freeing partitions that failed to add in
 add_mtd_partitions().  The same issue is present in mtd_add_partition(),
 so fix that as well.

 Signed-off-by: Geert Uytterhoeven 
 ---
 I don't know if it is worthwhile factoring out the common handling.

 Should allocate_partition() fail instead?  There's a comment saying
 "let's register it anyway to preserve ordering".
>>
 --- a/drivers/mtd/mtdpart.c
 +++ b/drivers/mtd/mtdpart.c
>>
 @@ -746,7 +753,15 @@ int add_mtd_partitions(struct mtd_info *master,
   list_add(>list, _partitions);
   mutex_unlock(_partitions_mutex);

 - add_mtd_device(>mtd);
 + ret = add_mtd_device(>mtd);
 + if (ret) {
 + mutex_lock(_partitions_mutex);
 + list_del(>list);
 + mutex_unlock(_partitions_mutex);
 + free_partition(slave);
 + continue;
 + }
>>>
>>> Why is the partition even in the list in the first place ? Can we avoid
>>> adding it rather than adding and removing it ?
>>
>> Hence my question "Should allocate_partition() fail instead?".
>> Note that if we go that route, it should be a "soft" failure, as we
>> probably don't
>> want to drop all other partitions on the device.
> Is the number of partitions ie. in /proc/mtdparts an ABI ?

I don't know.

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] PCI: rcar: Use runtime PM to control controller clock

Hi Marek,

On Tue, Apr 10, 2018 at 4:31 PM, Marek Vasut  wrote:
> On 04/09/2018 02:26 PM, Simon Horman wrote:
>> On Mon, Apr 09, 2018 at 01:47:38PM +0200, Geert Uytterhoeven wrote:
>>> On Mon, Apr 9, 2018 at 1:41 PM, Simon Horman  wrote:
 On Mon, Apr 09, 2018 at 10:20:05AM +0200, Marek Vasut wrote:
> On 04/09/2018 10:07 AM, Geert Uytterhoeven wrote:
>> On Sun, Apr 8, 2018 at 3:09 PM, Marek Vasut  
>> wrote:
>>> From: Dien Pham 
>>>
>>> The controller clock can be switched off during suspend/resume,
>>> let runtime PM take care of that.
>>>
>>> Signed-off-by: Dien Pham 
>>> Signed-off-by: Hien Dang 
>>> 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
>>> To: linux-...@vger.kernel.org
>>> ---
>>> V2: - Reorder the fail path in rcar_pcie_probe() to cater for the
>>>   reordering of function calls in probe
>>> - Dispose of fail_clk in rcar_pcie_get_resources()
>>> V3: - Fix up the failpath in probe function
>>> V4: - Rebase on recent linux-next
>>> V5: - Do not call pci_free_resource_list(>resources) if
>>>   rcar_pcie_parse_request_of_pci_ranges() fails, since that
>>>   functiona calls pci_free_resource_list() already.
>>
>> Thanks for the update!
>>
>>> --- a/drivers/pci/host/pcie-rcar.c
>>> +++ b/drivers/pci/host/pcie-rcar.c
>>
>>> @@ -1124,22 +,22 @@ static int rcar_pcie_probe(struct 
>>> platform_device *pdev)
>>> if (err)
>>> goto err_free_bridge;
>>>
>>> +   pm_runtime_enable(pcie->dev);
>>> +   err = pm_runtime_get_sync(pcie->dev);
>>> +   if (err < 0) {
>>> +   dev_err(pcie->dev, "pm_runtime_get_sync failed\n");
>>> +   goto err_pm_disable;
>>> +   }
>>> +
>>
>> As you moved the pm_runtime setup up...
>>
>>> err = rcar_pcie_get_resources(pcie);
>>> if (err < 0) {
>>> dev_err(dev, "failed to request resources: %d\n", err);
>>> -   goto err_free_resource_list;
>>> +   goto err_pm_put;
>>> }
>>>
>>> err = rcar_pcie_parse_map_dma_ranges(pcie, dev->of_node);
>>> if (err)
>>> -   goto err_free_resource_list;
>>> -
>>> -   pm_runtime_enable(dev);
>>> -   err = pm_runtime_get_sync(dev);
>>> -   if (err < 0) {
>>> -   dev_err(dev, "pm_runtime_get_sync failed\n");
>>> -   goto err_pm_disable;
>>> -   }
>>> +   goto err_pm_put;
>>>
>>> /* Failure to get a link might just be that no cards are 
>>> inserted */
>>> hw_init_fn = of_device_get_match_data(dev);
>>> @@ -1174,9 +1161,8 @@ static int rcar_pcie_probe(struct platform_device 
>>> *pdev)
>>>
>>>  err_pm_disable:
>>> pm_runtime_disable(dev);
>>
>> ... shouldn't it be moved down here, for symmetry?
>
> I am reasonably certain the failpath should be correct now. Did I still
> miss something ?

 It looks correct to me too. Geert are Marek and I missing something?
>>>
>>> Probably it will still work fine, but after this patch, Runtime PM is 
>>> enabled
>>> early, and disabled early, which is not symmetrical.
>>>
>>> I like symmetry ;-)
>>
>> Understood. I think that is reasonable.
>> Marek, would you care to respin?
>
> I am looking into the driver, but I fail to see what Geert is trying to
> make me change here.
>
> The pairing looks as follows:
>
> .- rcar_pcie_parse_request_of_pci_ranges()
> |  (pm_runtime_enable is here)
> | .- pm_runtime_get_sync()
> | | .- rcar_pcie_get_resources()

rcar_pcie_get_resources() is called  while the device is runtime-enabled/resumed

> | | |
> | | '- pm_runtime_put()
> | '- pm_runtime_disable() + pci_free_resource_list()

pci_free_resource_list() is called while the device is runtime-disabled.

> '- pci_free_host_bridge()
>
> It looks symmetric to me ...

rcar_pcie_get_resources() is called while the device is
runtime-enabled/resumed,
pci_free_resource_list() is called while the device is runtime-disabled.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] mtd: partitions: Handle add_mtd_device() failures gracefully

On 04/10/2018 03:26 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Mon, Apr 9, 2018 at 11:59 PM, Marek Vasut  wrote:
>> On 04/09/2018 02:25 PM, Geert Uytterhoeven wrote:
>>> Currently add_mtd_device() failures are plainly ignored, which may lead
>>> to kernel crashes later.
> 
>>> Fix this by ignoring and freeing partitions that failed to add in
>>> add_mtd_partitions().  The same issue is present in mtd_add_partition(),
>>> so fix that as well.
>>>
>>> Signed-off-by: Geert Uytterhoeven 
>>> ---
>>> I don't know if it is worthwhile factoring out the common handling.
>>>
>>> Should allocate_partition() fail instead?  There's a comment saying
>>> "let's register it anyway to preserve ordering".
> 
>>> --- a/drivers/mtd/mtdpart.c
>>> +++ b/drivers/mtd/mtdpart.c
> 
>>> @@ -746,7 +753,15 @@ int add_mtd_partitions(struct mtd_info *master,
>>>   list_add(>list, _partitions);
>>>   mutex_unlock(_partitions_mutex);
>>>
>>> - add_mtd_device(>mtd);
>>> + ret = add_mtd_device(>mtd);
>>> + if (ret) {
>>> + mutex_lock(_partitions_mutex);
>>> + list_del(>list);
>>> + mutex_unlock(_partitions_mutex);
>>> + free_partition(slave);
>>> + continue;
>>> + }
>>
>> Why is the partition even in the list in the first place ? Can we avoid
>> adding it rather than adding and removing it ?
> 
> Hence my question "Should allocate_partition() fail instead?".
> Note that if we go that route, it should be a "soft" failure, as we
> probably don't
> want to drop all other partitions on the device.
Is the number of partitions ie. in /proc/mtdparts an ABI ?

-- 
Best regards,
Marek Vasut

Re: [PATCH V5] PCI: rcar: Use runtime PM to control controller clock

On 04/09/2018 02:26 PM, Simon Horman wrote:
> On Mon, Apr 09, 2018 at 01:47:38PM +0200, Geert Uytterhoeven wrote:
>> Hi Simon, Marek,
>>
>> On Mon, Apr 9, 2018 at 1:41 PM, Simon Horman  wrote:
>>> On Mon, Apr 09, 2018 at 10:20:05AM +0200, Marek Vasut wrote:
 On 04/09/2018 10:07 AM, Geert Uytterhoeven wrote:
> On Sun, Apr 8, 2018 at 3:09 PM, Marek Vasut  wrote:
>> From: Dien Pham 
>>
>> The controller clock can be switched off during suspend/resume,
>> let runtime PM take care of that.
>>
>> Signed-off-by: Dien Pham 
>> Signed-off-by: Hien Dang 
>> 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
>> To: linux-...@vger.kernel.org
>> ---
>> V2: - Reorder the fail path in rcar_pcie_probe() to cater for the
>>   reordering of function calls in probe
>> - Dispose of fail_clk in rcar_pcie_get_resources()
>> V3: - Fix up the failpath in probe function
>> V4: - Rebase on recent linux-next
>> V5: - Do not call pci_free_resource_list(>resources) if
>>   rcar_pcie_parse_request_of_pci_ranges() fails, since that
>>   functiona calls pci_free_resource_list() already.
>
> Thanks for the update!
>
>> --- a/drivers/pci/host/pcie-rcar.c
>> +++ b/drivers/pci/host/pcie-rcar.c
>
>> @@ -1124,22 +,22 @@ static int rcar_pcie_probe(struct 
>> platform_device *pdev)
>> if (err)
>> goto err_free_bridge;
>>
>> +   pm_runtime_enable(pcie->dev);
>> +   err = pm_runtime_get_sync(pcie->dev);
>> +   if (err < 0) {
>> +   dev_err(pcie->dev, "pm_runtime_get_sync failed\n");
>> +   goto err_pm_disable;
>> +   }
>> +
>
> As you moved the pm_runtime setup up...
>
>> err = rcar_pcie_get_resources(pcie);
>> if (err < 0) {
>> dev_err(dev, "failed to request resources: %d\n", err);
>> -   goto err_free_resource_list;
>> +   goto err_pm_put;
>> }
>>
>> err = rcar_pcie_parse_map_dma_ranges(pcie, dev->of_node);
>> if (err)
>> -   goto err_free_resource_list;
>> -
>> -   pm_runtime_enable(dev);
>> -   err = pm_runtime_get_sync(dev);
>> -   if (err < 0) {
>> -   dev_err(dev, "pm_runtime_get_sync failed\n");
>> -   goto err_pm_disable;
>> -   }
>> +   goto err_pm_put;
>>
>> /* Failure to get a link might just be that no cards are 
>> inserted */
>> hw_init_fn = of_device_get_match_data(dev);
>> @@ -1174,9 +1161,8 @@ static int rcar_pcie_probe(struct platform_device 
>> *pdev)
>>
>>  err_pm_disable:
>> pm_runtime_disable(dev);
>
> ... shouldn't it be moved down here, for symmetry?

 I am reasonably certain the failpath should be correct now. Did I still
 miss something ?
>>>
>>> It looks correct to me too. Geert are Marek and I missing something?
>>
>> Probably it will still work fine, but after this patch, Runtime PM is enabled
>> early, and disabled early, which is not symmetrical.
>>
>> I like symmetry ;-)
> 
> Understood. I think that is reasonable.
> Marek, would you care to respin?

I am looking into the driver, but I fail to see what Geert is trying to
make me change here.

The pairing looks as follows:

.- rcar_pcie_parse_request_of_pci_ranges()
|  (pm_runtime_enable is here)
| .- pm_runtime_get_sync()
| | .- rcar_pcie_get_resources()
| | |
| | '- pm_runtime_put()
| '- pm_runtime_disable() + pci_free_resource_list()
'- pci_free_host_bridge()

It looks symmetric to me ...

-- 
Best regards,
Marek Vasut

Re: [PATCH] gpio: dwapb: Add support for 32 interrupts

Hi Phil,

On Tue, Apr 10, 2018 at 4:23 PM, Phil Edworthy
 wrote:
> On 10 April 2018 07:24 Phil Edworthy wrote:
>> On 09 April 2018 20:20 Rob Herring wrote:
>> > On Wed, Mar 28, 2018 at 03:22:30PM +0100, Phil Edworthy wrote:
> [...]
>> > > +- interrupt-mask : a 32-bit bit mask that specifies which interrupts
>> > > +in the list
>> > > +  of interrupts is valid, bit is 1 for a valid irq.
>> >
>> > This is not a standard property and would need a vendor prefix. However,
>> I'd
>> > prefer you just skip any not connected interrupts with an invalid interrupt
>> > number. Then the GPIO number is the index into "interrupts".
>> Makes sense, I'll rework it to do this.
> Err, what would an invalid interrupt number be?
> If I use -1, I get a DT parsing error and 0 is certainly valid. If the number 
> is
> larger than the valid interrupt range I get errors during probe.

Perhaps using interrupts-extended instead of interrupts?

E.g.

interrupts-extended = < 5 1>, <0>, < 1 0>;

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH] gpio: dwapb: Add support for 32 interrupts

2018-04-10 Thread Phil Edworthy

Hi Rob,

On 10 April 2018 07:24 Phil Edworthy wrote:
> On 09 April 2018 20:20 Rob Herring wrote:
> > On Wed, Mar 28, 2018 at 03:22:30PM +0100, Phil Edworthy wrote:
[...]
> > > +- interrupt-mask : a 32-bit bit mask that specifies which interrupts
> > > +in the list
> > > +  of interrupts is valid, bit is 1 for a valid irq.
> >
> > This is not a standard property and would need a vendor prefix. However,
> I'd
> > prefer you just skip any not connected interrupts with an invalid interrupt
> > number. Then the GPIO number is the index into "interrupts".
> Makes sense, I'll rework it to do this.
Err, what would an invalid interrupt number be?
If I use -1, I get a DT parsing error and 0 is certainly valid. If the number is
larger than the valid interrupt range I get errors during probe.

Thanks
Phil

[PATCH] MAINTAINERS: I'll maintain Renesas R-Car I2C host drivers

Signed-off-by: Wolfram Sang 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2f7ccdcf76f7..3bb87e65889c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11897,6 +11897,12 @@ L: linux-...@vger.kernel.org
 S: Supported
 F: drivers/iio/adc/rcar_gyro_adc.c
 
+RENESAS R-CAR I2C DRIVERS
+M: Wolfram Sang 
+S: Supported
+F: drivers/i2c/busses/i2c-rcar.c
+F: drivers/i2c/busses/i2c-sh_mobile.c
+
 RENESAS USB PHY DRIVER
 M: Yoshihiro Shimoda 
 L: linux-renesas-soc@vger.kernel.org
-- 
2.11.0

Re: [PATCH] phy: Renesas R-Car gen3 PCIe PHY driver

2018-04-10 Thread Rob Herring

On Wed, Apr 04, 2018 at 10:31:26PM +0300, Sergei Shtylyov wrote:
> This PHY is still mostly undocumented -- the only documented registers
> exist on R-Car V3H (R8A77980) SoC  where this PHY stays in a powered-down
> state after a reset and thus  we must power it on for PCIe to work...
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against the 'next' branch of Kishon's 'linux-phy.git' repo.
> 
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt |   32 ++

Separate patch please.

>  drivers/phy/renesas/Kconfig  |7 
>  drivers/phy/renesas/Makefile |1 
>  drivers/phy/renesas/phy-rcar-gen3-pcie.c |  158 
> +++
>  4 files changed, 198 insertions(+)
> 
> Index: linux-phy/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt
> ===
> --- /dev/null
> +++ linux-phy/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt
> @@ -0,0 +1,32 @@
> +* Renesas R-Car generation 3 PCIe PHY
> +
> +This file provides information on what the device node for the R-Car
> +generation 3 PCIe PHY contains.
> +
> +Required properties:
> +- compatible: "renesas,r8a77980-pcie-phy" if the device is a part of R8A77980
> +   SoC.
> +   "renesas,rcar-gen3-pcie-phy" for a generic R-Car Gen3 compatible
> +   device.
> +
> +   When compatible with the generic version, nodes must list the
> +   SoC-specific version corresponding to the platform first
> +   followed by the generic version.
> +
> +- reg: offset and length of the register block.
> +- clocks: clock phandle and specifier pair.
> +- power-domains: power domain phandle and specifier pair.
> +- resets: reset phandle and specifier pair.
> +- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
> +
> +Example (R-Car V3H):
> +
> + pcie-phy@e65d {
> + compatible = "renesas,r8a77980-pcie-phy",
> +  "renesas,rcar-gen3-pcie-phy";
> + reg = <0 0xe65d 0 0x8000>;
> + #phy-cells = <0>;
> + clocks = < CPG_MOD 319>;
> + power-domains = < 32>;
> + resets = < 319>;
> + };

Re: [PATCH v2 2/2] dt-bindings: pinctrl: sh-pfc: Document r8a77470 PFC support

2018-04-10 Thread Rob Herring

On Wed, Apr 04, 2018 at 04:22:57PM +0100, Biju Das wrote:
> Document PFC support for the R8A77470 SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> ---
> V1->V2:
> * Incorporated sergie's review comment.
> 
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring

RE: [PATCH] clk: renesas: rcar-gen2: Centralize quirks handling

2018-04-10 Thread Biju Das

Hi Geert,

Thanks for the patch.

> -Original Message-
> From: Geert Uytterhoeven [mailto:geert+rene...@glider.be]
> Sent: 10 April 2018 14:05
> To: Michael Turquette ; Stephen Boyd
> ; Biju Das 
> Cc: linux-renesas-soc@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Geert Uytterhoeven 
> Subject: [PATCH] clk: renesas: rcar-gen2: Centralize quirks handling
>
> Introduce centralized quirks handling like on R-Car Gen3, and convert the
> RZ/G1C SD clock table handling over to it.
>
> This makes it easier to add more quirks later, if/when needed.
>
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Biju Das 

> ---
> To be queued in clk-renesas-for-v4.18.
>
>  drivers/clk/renesas/rcar-gen2-cpg.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/renesas/rcar-gen2-cpg.c b/drivers/clk/renesas/rcar-
> gen2-cpg.c
> index 0c49f59d5074b1c4..daf88bc2cdae177b 100644
> --- a/drivers/clk/renesas/rcar-gen2-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen2-cpg.c
> @@ -261,9 +261,15 @@ static const struct clk_div_table
> cpg_sd01_div_table[] = {  static const struct rcar_gen2_cpg_pll_config
> *cpg_pll_config __initdata;  static unsigned int cpg_pll0_div __initdata;  
> static
> u32 cpg_mode __initdata;
> +static u32 cpg_quirks __initdata;
>
> -static const struct soc_device_attribute soc_r8a77470[] = {
> -{ .soc_id = "r8a77470" },
> +#define SD_SKIP_FIRSTBIT(0)/* Skip first clock in SD table
> */
> +
> +static const struct soc_device_attribute cpg_quirks_match[] __initconst = {
> +{
> +.soc_id = "r8a77470",
> +.data = (void *)SD_SKIP_FIRST,
> +},
>  { /* sentinel */ }
>  };
>
> @@ -333,7 +339,7 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct
> device *dev,
>
>  case CLK_TYPE_GEN2_SD0:
>  table = cpg_sd01_div_table;
> -if (soc_device_match(soc_r8a77470))
> +if (cpg_quirks & SD_SKIP_FIRST)
>  table++;
>
>  shift = 4;
> @@ -341,7 +347,7 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct
> device *dev,
>
>  case CLK_TYPE_GEN2_SD1:
>  table = cpg_sd01_div_table;
> -if (soc_device_match(soc_r8a77470))
> +if (cpg_quirks & SD_SKIP_FIRST)
>  table++;
>
>  shift = 0;
> @@ -372,9 +378,15 @@ struct clk * __init
> rcar_gen2_cpg_clk_register(struct device *dev,  int __init
> rcar_gen2_cpg_init(const struct rcar_gen2_cpg_pll_config *config,
>unsigned int pll0_div, u32 mode)  {
> +const struct soc_device_attribute *attr;
> +
>  cpg_pll_config = config;
>  cpg_pll0_div = pll0_div;
>  cpg_mode = mode;
> +attr = soc_device_match(cpg_quirks_match);
> +if (attr)
> +cpg_quirks = (uintptr_t)attr->data;
> +pr_debug("%s: mode = 0x%x quirks = 0x%x\n", __func__, mode,
> +cpg_quirks);
>
>  spin_lock_init(_lock);
>
> --
> 2.7.4




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

Re: [PATCH] clk: renesas: rcar-gen2: Centralize quirks handling

2018-04-10 Thread Niklas Söderlund

Hi Geert,

Thanks for your patch.

On 2018-04-10 15:04:58 +0200, Geert Uytterhoeven wrote:
> Introduce centralized quirks handling like on R-Car Gen3, and convert
> the RZ/G1C SD clock table handling over to it.
> 
> This makes it easier to add more quirks later, if/when needed.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Niklas Söderlund 

> ---
> To be queued in clk-renesas-for-v4.18.
> 
>  drivers/clk/renesas/rcar-gen2-cpg.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/renesas/rcar-gen2-cpg.c 
> b/drivers/clk/renesas/rcar-gen2-cpg.c
> index 0c49f59d5074b1c4..daf88bc2cdae177b 100644
> --- a/drivers/clk/renesas/rcar-gen2-cpg.c
> +++ b/drivers/clk/renesas/rcar-gen2-cpg.c
> @@ -261,9 +261,15 @@ static const struct clk_div_table cpg_sd01_div_table[] = 
> {
>  static const struct rcar_gen2_cpg_pll_config *cpg_pll_config __initdata;
>  static unsigned int cpg_pll0_div __initdata;
>  static u32 cpg_mode __initdata;
> +static u32 cpg_quirks __initdata;
>  
> -static const struct soc_device_attribute soc_r8a77470[] = {
> - { .soc_id = "r8a77470" },
> +#define SD_SKIP_FIRSTBIT(0)  /* Skip first clock in SD table 
> */
> +
> +static const struct soc_device_attribute cpg_quirks_match[] __initconst = {
> + {
> + .soc_id = "r8a77470",
> + .data = (void *)SD_SKIP_FIRST,
> + },
>   { /* sentinel */ }
>  };
>  
> @@ -333,7 +339,7 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct 
> device *dev,
>  
>   case CLK_TYPE_GEN2_SD0:
>   table = cpg_sd01_div_table;
> - if (soc_device_match(soc_r8a77470))
> + if (cpg_quirks & SD_SKIP_FIRST)
>   table++;
>  
>   shift = 4;
> @@ -341,7 +347,7 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct 
> device *dev,
>  
>   case CLK_TYPE_GEN2_SD1:
>   table = cpg_sd01_div_table;
> - if (soc_device_match(soc_r8a77470))
> + if (cpg_quirks & SD_SKIP_FIRST)
>   table++;
>  
>   shift = 0;
> @@ -372,9 +378,15 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct 
> device *dev,
>  int __init rcar_gen2_cpg_init(const struct rcar_gen2_cpg_pll_config *config,
> unsigned int pll0_div, u32 mode)
>  {
> + const struct soc_device_attribute *attr;
> +
>   cpg_pll_config = config;
>   cpg_pll0_div = pll0_div;
>   cpg_mode = mode;
> + attr = soc_device_match(cpg_quirks_match);
> + if (attr)
> + cpg_quirks = (uintptr_t)attr->data;
> + pr_debug("%s: mode = 0x%x quirks = 0x%x\n", __func__, mode, cpg_quirks);
>  
>   spin_lock_init(_lock);
>  
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH] mtd: partitions: Handle add_mtd_device() failures gracefully

Hi Marek,

On Mon, Apr 9, 2018 at 11:59 PM, Marek Vasut  wrote:
> On 04/09/2018 02:25 PM, Geert Uytterhoeven wrote:
>> Currently add_mtd_device() failures are plainly ignored, which may lead
>> to kernel crashes later.

>> Fix this by ignoring and freeing partitions that failed to add in
>> add_mtd_partitions().  The same issue is present in mtd_add_partition(),
>> so fix that as well.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>> I don't know if it is worthwhile factoring out the common handling.
>>
>> Should allocate_partition() fail instead?  There's a comment saying
>> "let's register it anyway to preserve ordering".

>> --- a/drivers/mtd/mtdpart.c
>> +++ b/drivers/mtd/mtdpart.c

>> @@ -746,7 +753,15 @@ int add_mtd_partitions(struct mtd_info *master,
>>   list_add(>list, _partitions);
>>   mutex_unlock(_partitions_mutex);
>>
>> - add_mtd_device(>mtd);
>> + ret = add_mtd_device(>mtd);
>> + if (ret) {
>> + mutex_lock(_partitions_mutex);
>> + list_del(>list);
>> + mutex_unlock(_partitions_mutex);
>> + free_partition(slave);
>> + continue;
>> + }
>
> Why is the partition even in the list in the first place ? Can we avoid
> adding it rather than adding and removing it ?

Hence my question "Should allocate_partition() fail instead?".
Note that if we go that route, it should be a "soft" failure, as we
probably don't
want to drop all other partitions on the device.

>>   mtd_add_partition_attrs(slave);
>>   if (parts[i].types)
>>   mtd_parse_part(slave, parts[i].types);
>>

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] clk: renesas: rcar-gen2: Centralize quirks handling

Introduce centralized quirks handling like on R-Car Gen3, and convert
the RZ/G1C SD clock table handling over to it.

This makes it easier to add more quirks later, if/when needed.

Signed-off-by: Geert Uytterhoeven 
---
To be queued in clk-renesas-for-v4.18.

 drivers/clk/renesas/rcar-gen2-cpg.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/renesas/rcar-gen2-cpg.c 
b/drivers/clk/renesas/rcar-gen2-cpg.c
index 0c49f59d5074b1c4..daf88bc2cdae177b 100644
--- a/drivers/clk/renesas/rcar-gen2-cpg.c
+++ b/drivers/clk/renesas/rcar-gen2-cpg.c
@@ -261,9 +261,15 @@ static const struct clk_div_table cpg_sd01_div_table[] = {
 static const struct rcar_gen2_cpg_pll_config *cpg_pll_config __initdata;
 static unsigned int cpg_pll0_div __initdata;
 static u32 cpg_mode __initdata;
+static u32 cpg_quirks __initdata;
 
-static const struct soc_device_attribute soc_r8a77470[] = {
-   { .soc_id = "r8a77470" },
+#define SD_SKIP_FIRST  BIT(0)  /* Skip first clock in SD table */
+
+static const struct soc_device_attribute cpg_quirks_match[] __initconst = {
+   {
+   .soc_id = "r8a77470",
+   .data = (void *)SD_SKIP_FIRST,
+   },
{ /* sentinel */ }
 };
 
@@ -333,7 +339,7 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct 
device *dev,
 
case CLK_TYPE_GEN2_SD0:
table = cpg_sd01_div_table;
-   if (soc_device_match(soc_r8a77470))
+   if (cpg_quirks & SD_SKIP_FIRST)
table++;
 
shift = 4;
@@ -341,7 +347,7 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct 
device *dev,
 
case CLK_TYPE_GEN2_SD1:
table = cpg_sd01_div_table;
-   if (soc_device_match(soc_r8a77470))
+   if (cpg_quirks & SD_SKIP_FIRST)
table++;
 
shift = 0;
@@ -372,9 +378,15 @@ struct clk * __init rcar_gen2_cpg_clk_register(struct 
device *dev,
 int __init rcar_gen2_cpg_init(const struct rcar_gen2_cpg_pll_config *config,
  unsigned int pll0_div, u32 mode)
 {
+   const struct soc_device_attribute *attr;
+
cpg_pll_config = config;
cpg_pll0_div = pll0_div;
cpg_mode = mode;
+   attr = soc_device_match(cpg_quirks_match);
+   if (attr)
+   cpg_quirks = (uintptr_t)attr->data;
+   pr_debug("%s: mode = 0x%x quirks = 0x%x\n", __func__, mode, cpg_quirks);
 
spin_lock_init(_lock);
 
-- 
2.7.4

[PATCH] extcon: int3496: use proper GPIO include

Since commit eca0f13c836a ("extcon: int3496: Ignore incorrect
IoRestriction for ID pin"), the driver doesn't use GPIOF_* flags
anymore. We can thus now drop the deprecated include file for GPIO and
use the new one.

Signed-off-by: Wolfram Sang 
---

Compile tested only.

@linusw: one more gone

 drivers/extcon/extcon-intel-int3496.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-intel-int3496.c 
b/drivers/extcon/extcon-intel-int3496.c
index acaccb128fc4..fd24debe58a3 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -20,7 +20,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.11.0

Re: [PATCH] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

2018-04-10 Thread Andy Shevchenko

On Tue, Apr 10, 2018 at 3:03 PM, Yoshihiro Shimoda
 wrote:
> This patch adds role switch support for R-Car SoCs. Some R-Car SoCs
> (e.g. R-Car H3) have USB 3.0 dual-role device controller which has
> the USB 3.0 xHCI host and Renesas USB 3.0 peripheral.
>
> Unfortunately, the mode change register contains the USB 3.0 peripheral
> controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
> manages this register. However, in peripheral mode, the host should
> stop. Also the host hardware needs to reinitialize its own registers
> when the mode changes from peripheral to host mode. Otherwise,
> the host cannot work correctly (e.g. detect a device as high-speed).
>
> To achieve this by a driver, this role switch driver manages
> the mode change register and attach/release the xhci-plat driver.
> The renesas_usb3 udc driver should call devm_of_platform_populate()
> to probe this driver.

> +#include 
> +#include 
> +#include 

> +#include 

Do you need this one?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

> +static const struct of_device_id rcar_usb3_role_switch_of_match[] = {
> +   { .compatible = "renesas,rcar-usb3-role-switch" },
> +   { },

Better to remove comma at terminator line.

> +};
> +MODULE_DEVICE_TABLE(of, rcar_usb3_role_switch_of_match);

> +static int rcar_usb3_role_switch_probe(struct platform_device *pdev)
> +{

> +   /* Avoid devm_request_mem_region() calling by devm_ioremap_resource() 
> */

Redundant comment.

> +   host_node = of_parse_phandle(pdev->dev.of_node, "renesas,host", 0);
> +   if (!host_node)
> +   return -ENODEV;
> +
> +   pdev_host = of_find_device_by_node(host_node);
> +   if (!pdev_host)
> +   return -ENODEV;
> +
> +   of_node_put(host_node);

Isn't what Heikki tried to solve with graphs and stuff like that?

> +   dev_info(>dev, "probed\n");

Noise. (Hint: initcall_debug is a good command line option)

> +}

> +#ifdef CONFIG_PM_SLEEP

Instead...

> +static int rcar_usb3_role_switch_suspend(struct device *dev)

...use __maybe_unused annotation.

> +static int rcar_usb3_role_switch_resume(struct device *dev)

Ditto.

> +#endif


> +static struct platform_driver rcar_usb3_role_switch_driver = {
> +   .probe  = rcar_usb3_role_switch_probe,
> +   .remove = rcar_usb3_role_switch_remove,
> +   .driver = {
> +   .name = "rcar_usb3_role_switch",
> +   .pm = _usb3_role_switch_pm_ops,

> +   .of_match_table = 
> of_match_ptr(rcar_usb3_role_switch_of_match),

Is it possible to have this driver w/o OF? Does it make sense in that case?
Otherwise remove of_match_ptr() call and below modalias.

> +   },
> +};

> +MODULE_ALIAS("platform:rcar_usb3_role_switch");

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 4/4] arm64: dts: renesas: eagle: Enable HDMI output

2018-04-10 Thread Laurent Pinchart

Hi Jacopo,

Thank you for the patch.

On Tuesday, 10 April 2018 13:54:06 EEST Jacopo Mondi wrote:
> Enable HDMI output on Renesas R-Car V3M Eagle board.
> 
> The HDMI output is enabled connecting the DU LVDS output to the
> transparent LVDS converter THC63LVD1024, and successively routing its
> RGB output to the ADV7511W HDMI encoder.
> 
> Signed-off-by: Niklas Söderlund 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Laurent Pinchart 
> [for THC63LVD1024: ]
> Reviewed-by: Andrzej Hajda 
> 
> ---
> v1 -> v2:
> - Squash patches [5/7], [6/7] and [7/7] of v1 in a single patch as
>   suggested by Laurent
> - Remove DU pinmuxing as it is used for DU parallel RGB output only used
>   by Eagle's display expander board not enabled by this series.
> ---
>  arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 93 +++
>  1 file changed, 93 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts index 3c5f598..1e2191d
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -31,6 +31,51 @@
>   /* first 128MB is reserved for secure area. */
>   reg = <0x0 0x4800 0x0 0x3800>;
>   };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_out: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> + d3p3: regulator-fixed {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + thc63lvd1024: lvds-decoder {

Nitpicking, no need for a label, you never reference it.

Apart from that, you can keep my Reviewed-by.

> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + thc63lvd1024_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + thc63lvd1024_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
>  };
> 
>   {
> @@ -68,6 +113,38 @@
>   gpio-controller;
>   #gpio-cells = <2>;
>   };
> +
> + hdmi@39 {
> + compatible = "adi,adv7511w";
> + reg = <0x39>;
> + interrupt-parent = <>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <_con_out>;
> + };
> + };
> + };
> + };
>  };
> 
>   {
> @@ -93,3 +170,19 @@
> 
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};

-- 
Regards,

Laurent Pinchart

[PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

The documentation was wrong, gpiod_get_direction() returns 0/1 instead
of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
("gpio: correct docs about return value of gpiod_get_direction"). Now,
fix this user (until a better, system-wide solution is in place).

Signed-off-by: Wolfram Sang 
Acked-by: Daniel Thompson 
---

Changes since V1:
* rebased to top-of-linus-tree
* added tag from Daniel, thanks!

Through which tree does this need to go?

 drivers/video/backlight/pwm_bl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1c2289ddd555..0fa7d2bd0e48 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
 
/*
 * If the GPIO is not known to be already configured as output, that
-* is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
-* change the direction to output and set the GPIO as active.
+* is, if gpiod_get_direction returns either 1 or -EINVAL, change the
+* direction to output and set the GPIO as active.
 * Do not force the GPIO to active when it was already output as it
 * could cause backlight flickering or we would enable the backlight too
 * early. Leave the decision of the initial backlight state for later.
 */
if (pb->enable_gpio &&
-   gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
+   gpiod_get_direction(pb->enable_gpio) != 0)
gpiod_direction_output(pb->enable_gpio, 1);
 
pb->power_supply = devm_regulator_get(>dev, "power");
-- 
2.11.0

[PATCH 2/2] usb: gadget: udc: renesas_usb3: add devm_of_platform_populate()

This patch adds devm_of_platform_populate() calling to populate
the rcar-usb3-role-switch driver.

For now, this renesas_usb3 driver doesn't use any APIs of
the usb role switch framework because the usb_role_switch_get()
API depends on the device_connection framework and this framework
is not good match on device tree environment. However, the select
USB_ROLE_SWITCH needs to enable the rcar-usb3-role-switch driver.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/Kconfig| 1 +
 drivers/usb/gadget/udc/renesas_usb3.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38..7e4a5dd 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -193,6 +193,7 @@ config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
depends on EXTCON && HAS_DMA
+   select USB_ROLE_SWITCH
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 59e1485..fd593b2 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -2639,6 +2639,12 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
if (ret < 0)
goto err_add_udc;
 
+   ret = devm_of_platform_populate(>dev);
+   if (ret < 0)
+   goto err_dev_create;
+
+   /* TODO: Get role switch and use usb_role_switch_{set,get}_role APIs */
+
if (of_property_read_bool(pdev->dev.of_node, "renesas,no-id"))
usb3->ignore_id = true;
 
-- 
1.9.1

[PATCH 1/2] usb: gadget: udc: renesas_usb3: add property "renesas,ignore-id"

This patch adds a new property to ignore the ID signal on a board.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/usb/renesas_usb3.txt |  2 ++
 drivers/usb/gadget/udc/renesas_usb3.c  | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
index 2c071bb..53949bd 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -19,6 +19,8 @@ Required properties:
 Optional properties:
   - phys: phandle + phy specifier pair
   - phy-names: must be "usb"
+  - renesas,ignore-id: when a board doesn't use ID pin, you can add this
+  property to ignore the ID state.
 
 Example of R-Car H3 ES1.x:
usb3_peri0: usb@ee02 {
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 409cde4..59e1485 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -350,6 +350,7 @@ struct renesas_usb3 {
bool extcon_host;   /* check id and set EXTCON_USB_HOST */
bool extcon_usb;/* check vbus and set EXTCON_USB */
bool forced_b_device;
+   bool ignore_id;
 };
 
 #define gadget_to_renesas_usb3(_gadget)\
@@ -645,6 +646,9 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
 
 static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
 {
+   if (usb3->ignore_id && !usb3->forced_b_device)
+   return;
+
if (host)
usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
else
@@ -675,6 +679,9 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
bool host, bool a_dev)
 
 static bool usb3_is_a_device(struct renesas_usb3 *usb3)
 {
+   if (usb3->ignore_id)
+   return false;
+
return !(usb3_read(usb3, USB3_USB_OTG_STA) & USB_OTG_IDMON);
 }
 
@@ -2632,6 +2639,9 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
if (ret < 0)
goto err_add_udc;
 
+   if (of_property_read_bool(pdev->dev.of_node, "renesas,no-id"))
+   usb3->ignore_id = true;
+
ret = device_create_file(>dev, _attr_role);
if (ret < 0)
goto err_dev_create;
-- 
1.9.1

[PATCH 0/2] usb: gadet: udc: renesas_usb3: add role switch for R-Car SoCs

This patch is based on the today's Linus master branch.
This patch uses the USB role switch framework to attach/detach USB 3.0
host driver when changes the role via the rcar usb switch driver [1]
and "usb_role" sysfs.

[1] https://patchwork.kernel.org/patch/10332865/

In the future, I will add using the USB role switch APIs to renesas_usb3
driver. But, for now, since the device connection framework is not good
for device tree environment (e.g. calling the API on a driver with
device name, but device names on device tree environment will be
.).

Yoshihiro Shimoda (2):
  usb: gadget: udc: renesas_usb3: add property "renesas,ignore-id"
  usb: gadget: udc: renesas_usb3: add devm_of_platform_populate()

 Documentation/devicetree/bindings/usb/renesas_usb3.txt |  2 ++
 drivers/usb/gadget/udc/Kconfig |  1 +
 drivers/usb/gadget/udc/renesas_usb3.c  | 16 
 3 files changed, 19 insertions(+)

-- 
1.9.1

Re: [PATCH v2 3/4] arm64: dts: renesas: r8a77970: add LVDS support

2018-04-10 Thread jacopo mondi

Hi Sergei,

On Tue, Apr 10, 2018 at 03:02:39PM +0300, Sergei Shtylyov wrote:
> On 04/10/2018 01:54 PM, Jacopo Mondi wrote:
>
> > From: Niklas Söderlund 
> >
> > Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
> > the it to the LVDS output of the DU.
> >
> > Signed-off-by: Niklas Söderlund 
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Laurent Pinchart 
> >
> > ---
> > v1 -> v2:
> > - Rebased on the modified endpoint name and changed patch subject to
> >   comply with other patches in the series from Sergei.
>
>Stop, what was wrong with my R8A77970 LVDS patch, reposted on the popular
> demand? :-)
>

Nothing wrong, I found out about your right now.
I see a very small difference as
 lvds@feb9 vs lvds-encoder@feb9

You can add your signed-off-by ofc if you think that's the case.

Thanks
   j

> MBR, Sergei


signature.asc
Description: PGP signature

[PATCH] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

This patch adds role switch support for R-Car SoCs. Some R-Car SoCs
(e.g. R-Car H3) have USB 3.0 dual-role device controller which has
the USB 3.0 xHCI host and Renesas USB 3.0 peripheral.

Unfortunately, the mode change register contains the USB 3.0 peripheral
controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
manages this register. However, in peripheral mode, the host should
stop. Also the host hardware needs to reinitialize its own registers
when the mode changes from peripheral to host mode. Otherwise,
the host cannot work correctly (e.g. detect a device as high-speed).

To achieve this by a driver, this role switch driver manages
the mode change register and attach/release the xhci-plat driver.
The renesas_usb3 udc driver should call devm_of_platform_populate()
to probe this driver.

Signed-off-by: Yoshihiro Shimoda 
---
 .../bindings/usb/renesas,rcar-usb3-role-sw.txt |  23 +++
 drivers/usb/roles/Kconfig  |  12 ++
 drivers/usb/roles/Makefile |   1 +
 drivers/usb/roles/rcar-usb3-role-switch.c  | 200 +
 4 files changed, 236 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
 create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c

diff --git 
a/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt 
b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
new file mode 100644
index 000..752bc16
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
@@ -0,0 +1,23 @@
+Renesas Electronics R-Car USB 3.0 role switch driver
+
+A renesas_usb3's node can contain this node.
+
+Required properties:
+ - compatible: Must contain "renesas,rcar-usb3-role-switch".
+ - renesas,host: phandle of the usb3.0 host.
+
+Example of R-Car H3 ES2.0:
+   usb3_peri0: usb@ee02 {
+   compatible = "renesas,r8a7795-usb3-peri",
+"renesas,rcar-gen3-usb3-peri";
+   reg = <0 0xee02 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 328>;
+
+   usb3-role-sw {
+   compatible = "renesas,rcar-usb3-role-switch";
+   renesas,host = <>;
+   };
+   };
diff --git a/drivers/usb/roles/Kconfig b/drivers/usb/roles/Kconfig
index f5a5e6f..8218035 100644
--- a/drivers/usb/roles/Kconfig
+++ b/drivers/usb/roles/Kconfig
@@ -11,4 +11,16 @@ config USB_ROLES_INTEL_XHCI
  To compile the driver as a module, choose M here: the module will
  be called intel-xhci-usb-role-switch.
 
+config USB_ROLES_RCAR_USB3
+   tristate "Renesas R-Car USB3.0 Role Switch"
+   depends on ARCH_RENESAS
+   help
+ Driver for the internal USB role switch for switching the USB data
+ lines between the xHCI host controller and the Renesas gadget
+ controller (by using renesas_usb3 driver) found on various Renesas
+ R-Car SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called rcar-usb3-role-switch.
+
 endif # USB_ROLE_SWITCH
diff --git a/drivers/usb/roles/Makefile b/drivers/usb/roles/Makefile
index e44b179..7ce3be3 100644
--- a/drivers/usb/roles/Makefile
+++ b/drivers/usb/roles/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_USB_ROLES_INTEL_XHCI) += intel-xhci-usb-role-switch.o
+obj-$(CONFIG_USB_ROLES_RCAR_USB3) += rcar-usb3-role-switch.o
diff --git a/drivers/usb/roles/rcar-usb3-role-switch.c 
b/drivers/usb/roles/rcar-usb3-role-switch.c
new file mode 100644
index 000..90648a1
--- /dev/null
+++ b/drivers/usb/roles/rcar-usb3-role-switch.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas R-Car USB 3.0 role switch driver
+ *
+ * Copyright (C) 2018  Renesas Electronics Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB3_DRD_CON   0x218
+#define DRD_CON_PERI_CON   BIT(24)
+
+struct rcar_usb3_role_switch {
+   struct usb_role_switch *role_sw;
+   struct usb_role_switch_desc *desc;
+   void __iomem *reg;
+   enum usb_role save_role;/* for suspend/resume */
+};
+
+static enum usb_role
+rcar_usb3_role_switch_get_mode(struct rcar_usb3_role_switch *rcar_sw)
+{
+   u32 val = readl(rcar_sw->reg + USB3_DRD_CON);
+
+   if (val & DRD_CON_PERI_CON)
+   return USB_ROLE_DEVICE;
+
+   return USB_ROLE_HOST;
+}
+
+static void
+rcar_usb3_role_switch_set_mode(struct rcar_usb3_role_switch *rcar_sw,
+  bool host)
+{
+   void __iomem *drd_con = rcar_sw->reg + USB3_DRD_CON;
+
+   if (host)
+   writel(readl(drd_con) & ~DRD_CON_PERI_CON, drd_con);
+   else
+   writel(readl(drd_con) | DRD_CON_PERI_CON,

Re: [PATCH v2 3/4] arm64: dts: renesas: r8a77970: add LVDS support

2018-04-10 Thread Sergei Shtylyov

On 04/10/2018 01:54 PM, Jacopo Mondi wrote:

> From: Niklas Söderlund 
> 
> Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
> the it to the LVDS output of the DU.
> 
> Signed-off-by: Niklas Söderlund 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Laurent Pinchart 
> 
> ---
> v1 -> v2:
> - Rebased on the modified endpoint name and changed patch subject to
>   comply with other patches in the series from Sergei.

   Stop, what was wrong with my R8A77970 LVDS patch, reposted on the popular
demand? :-)

MBR, Sergei

RE: RFC: RZ/N1 clock architecture...

Hi Geert,

On 10 April 2018 11:08, Geert wrote:
>
> Hi Michel,
>
> On Tue, Apr 10, 2018 at 11:56 AM, Michel Pollet
>  wrote:
> > In the current SDK for the RZ/N1, we made a clock architecture that is
> entirely device-tree based.
> > The clock hierarchy is quite complex and was machine generated from
> > design documents, and some exceptions and grouping were added to the
> 'main' family rzn1.dtsi...
> >
> > Apart from a few fixed-clock nodes, all of the other nodes are
> > 'special' and require a driver. All of these drivers are sub-drivers to a 
> > 'main'
> clock driver. That has been working for 2 years already.
> >
> > One extra note: we don't 'own' all of these clocks, part of the
> > clocks/dividers can be enable/disabled by the CM3 core.
> >
> > Now, For upstreaming, I'm going to have to change that, since already
> > the 'clock' bits are going to go under the MFD sysctrl node. However
> > I'm trying to figure out if we can still use our rzn1-clocks.dtsi in
> > some form, as well as my drivers, or so I have to convert it to a C table in
> some way.
> >
> > Also note that all the clock refer to SYSCTRL registers/bits using
> > constant names from a header file, not hex constants etc.
> >
> > I would appreciate any ideas/suggestions before I commit blindly to a
> path...
> >
> > Here is the main autogenerated clock file:
> > https://github.com/renesas-rz/rzn1_linux/blob/rzn1-stable/arch/arm/boo
> > t/dts/rzn1-clocks.dtsi Here's the extra clock{} node in the main
> > rzn1.dtsi
> > https://github.com/renesas-
> rz/rzn1_linux/blob/89d6c9be056a462b95d52172
> > 21d70d6e5c25dfc2/arch/arm/boot/dts/rzn1.dtsi#L70
>
> Describing the full clock hierarchy in DT is no longer recommended.
> The modern way is to have a single clock provider node in DT, and have the
> driver register all clocks.
>
> Compare e.g. the single clock-controller node in
> arch/arm/boot/dts/r8a7791.dtsi in v4.15 (used with the {r8a7791,renesas}-
> cpg-mssr.c driver, with the complex clocks node in v4.14, used with a lot of
> subdrivers, and requiring continuous maintenance.
>
> So I think you're best of creating (generating) a C table instead, and keep 
> the
> DT simple and obviously correct.

So, do I understand correctly that I could duplicate the tree as a C structure, 
and have my
'clock' driver instantiate all my sub drivers as a clock tree directly?

I looked into r8a7791's code, but your clock tree is 'flat' from what I see 
there, you don't have
the weird and fun clock dependencies we have. Nor any of the special cases we 
have; also,
you have a single clock driver in there it seems, so it is a pretty simple case 
where your
indexing method works...

So I can definitely have a C struct to instantiate the table, but mostly that C 
table will be
duplicating the device tree hierarchy completely, and I'll still need as many 
sub-drivers
as I already have... The only change is really that that table will be in a .c 
-- is that
exactly what you want?

Here are the current drivers I used.
https://github.com/renesas-rz/rzn1_linux/tree/rzn1-stable/drivers/clk/rzn1

There is:
+ renesas,rzn1-clock-group -- many drivers only support claiming a single 
clock; the
   clock-group driver allows me to group clocks together so they are enabled as 
ones
   -- that way I don't have to patch the drivers.
+ renesas,rzn1-clock-gate -- this one is more or less the same as yours. 
Enables/disable
   a clock. It's parent will provide the rate.
+ renesas,rzn1-clock-divider -- this one has a register with min,max, and an 
optional
   table of 'fixed' values if the range is not linear.
+ renesas,rzn1-clock-bitselect -- this one is fun, a single bit can change not 
only the
   parent clock of *several IPs at the same time* but also the gate they have 
to use...
+ renesas,rzn1-clock-dualgate -- this one works with the previous one, use gate 
0 or
   1 depending on one bit...

So, should I just jam all of these together with a struct hierarchy in a single 
driver, and
use an index? I don't have too much trouble with the table as I can generate it 
as well,
I'm just making sure it's what you want...

>
> Gr{oetje,eeting}s,
>
> Geert

Thanks!
Michel
PS: I didn't make the hardware :-)



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

RE: [PATCH v13 02/33] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2018-04-10 Thread Fabrizio Castro

Hello Niklas,

> Subject: Re: [PATCH v13 02/33] dt-bindings: media: rcar_vin: add device tree 
> support for r8a774[35]
>
> Hi Fabrizio,
>
> On 2018-04-10 09:55:29 +, Fabrizio Castro wrote:
> > Dear All,
> >
> > this patch was originally sent on the 16/11/2017, and reposted a few times, 
> > does anybody know who is supposed to take it?
>
> Hans have indicated he will take this a respin of this whole patch-set
> sometime next week.

fantastic, thanks a lot for the information.

Cheers,
Fab

>
> >
> > Thanks,
> > Fab
> >
> > > -Original Message-
> > > From: Niklas Söderlund [mailto:niklas.soderlund+rene...@ragnatech.se]
> > > Sent: 26 March 2018 22:44
> > > To: Laurent Pinchart ; Hans Verkuil 
> > > ; linux-me...@vger.kernel.org
> > > Cc: linux-renesas-soc@vger.kernel.org; TOMOHARU FUKAWA 
> > > ; Kieran Bingham
> > > ; Fabrizio Castro 
> > > 
> > > Subject: [PATCH v13 02/33] dt-bindings: media: rcar_vin: add device tree 
> > > support for r8a774[35]
> > >
> > > From: Fabrizio Castro 
> > >
> > > Add compatible strings for r8a7743 and r8a7745. No driver change
> > > is needed as "renesas,rcar-gen2-vin" will activate the right code.
> > > However, it is good practice to document compatible strings for the
> > > specific SoC as this allows SoC specific changes to the driver if
> > > needed, in addition to document SoC support and therefore allow
> > > checkpatch.pl to validate compatible string values.
> > >
> > > Signed-off-by: Fabrizio Castro 
> > > Reviewed-by: Biju Das 
> > > Reviewed-by: Simon Horman 
> > > Acked-by: Rob Herring 
> > > Reviewed-by: Geert Uytterhoeven 
> > > Acked-by: Niklas Söderlund 
> > > Reviewed-by: Laurent Pinchart 
> > > ---
> > >  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> > > b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > > index d99b6f5dee418056..4c76d82905c9d3b8 100644
> > > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > > @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves 
> > > and suppot one input
> > >  channel which can be either RGB, YUYV or BT656.
> > >
> > >   - compatible: Must be one or more of the following
> > > +   - "renesas,vin-r8a7743" for the R8A7743 device
> > > +   - "renesas,vin-r8a7745" for the R8A7745 device
> > > - "renesas,vin-r8a7778" for the R8A7778 device
> > > - "renesas,vin-r8a7779" for the R8A7779 device
> > > - "renesas,vin-r8a7790" for the R8A7790 device
> > > @@ -14,7 +16,8 @@ channel which can be either RGB, YUYV or BT656.
> > > - "renesas,vin-r8a7793" for the R8A7793 device
> > > - "renesas,vin-r8a7794" for the R8A7794 device
> > > - "renesas,vin-r8a7795" for the R8A7795 device
> > > -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> > > +   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> > > + device.
> > > - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> > >
> > > When compatible with the generic version nodes must list the
> > > --
> > > 2.16.2
> >
> >
> >
> >
> > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
> > Buckinghamshire, SL8 5FH, UK. Registered in England
> & Wales under Registered No. 04586709.
>
> --
> Regards,
> Niklas Söderlund



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

[PATCH v2 0/4] V3M-Eagle HDMI output enablement

Hello,
   this series enables HDMI display on V3M Eagle board.

The v2 of this series is based on Linus' master, as it already contains the
pull request for arm64 DT is merged already, and it includes enablement of
R8A77970 basic components such as PFC, GPIOs and I2c.

Compared to to v1 I have not included
[PATCH 1/7] arm64: dts: renesas: r8a77970: add FCPVD support
as Simon has already included this in his tree for v4.18.

Indivual patches contains the changelog, the biggest overall change is that
HDMI output enablement, previously split in 3 patches is now performed in a
single patch for arch/arm64/boot/dts/renesas/r8a77970-eagle.dts as suggested
by Laurent.

The series depends on THC63LVD1024 driver, currently submitted for inclusion
[PATCH v8 0/2]  drm: Add Thine THC63LVD1024 LVDS decoder bridge
currently available at:
git://jmondi.org/linux lvds-bridge/linus-master/v8

Thanks
  j

v1 -> v2:
- Add Laurent's reviewed by tags
- Fixup patch 5, 6 and 7 of v1
- Remove DU digital output pin muxing
- Update thc63lvd1024 to use the new bindings with mandatory power supply
- Minor fixes (changes are described individually in each patch)

Jacopo Mondi (1):
  arm64: dts: renesas: eagle: Enable HDMI output

Niklas Söderlund (1):
  arm64: dts: renesas: r8a77970: add LVDS support

Sergei Shtylyov (2):
  arm64: dts: renesas: r8a77970: add VSPD support
  arm64: dts: renesas: r8a77970: add DU support

 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 82 ++
 arch/arm64/boot/dts/renesas/r8a77970.dtsi  | 65 
 2 files changed, 147 insertions(+)

--
2.7.4

[PATCH v2 4/4] arm64: dts: renesas: eagle: Enable HDMI output

Enable HDMI output on Renesas R-Car V3M Eagle board.

The HDMI output is enabled connecting the DU LVDS output to the
transparent LVDS converter THC63LVD1024, and successively routing its
RGB output to the ADV7511W HDMI encoder.

Signed-off-by: Niklas Söderlund 
Signed-off-by: Jacopo Mondi 
Reviewed-by: Laurent Pinchart 
[for THC63LVD1024: ]
Reviewed-by: Andrzej Hajda 

---
v1 -> v2:
- Squash patches [5/7], [6/7] and [7/7] of v1 in a single patch as
  suggested by Laurent
- Remove DU pinmuxing as it is used for DU parallel RGB output only used
  by Eagle's display expander board not enabled by this series.
---
 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 93 ++
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts 
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index 3c5f598..1e2191d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -31,6 +31,51 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_out: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   d3p3: regulator-fixed {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   thc63lvd1024_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   thc63lvd1024_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
 };

  {
@@ -68,6 +113,38 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con_out>;
+   };
+   };
+   };
+   };
 };

  {
@@ -93,3 +170,19 @@

status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
--
2.7.4

[PATCH v2 1/4] arm64: dts: renesas: r8a77970: add VSPD support

From: Sergei Shtylyov 

Describe VSPD0 in the R8A77970 device tree; it will be used by DU in
the next patch...

Based on the original (and large) patch by Daisuke Matsushita
.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 

---

v1 -> v2:
- Extend the memory region to include V6_CLUTn_TBL* registers.
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 97c27ef..a3ef3bd 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -625,6 +625,16 @@
power-domains = < R8A77970_PD_ALWAYS_ON>;
resets = < 603>;
};
+
+   vspd0: vsp@fea2 {
+   compatible = "renesas,vsp2";
+   reg = <0 0xfea2 0 0x8000>;
+   interrupts = ;
+   clocks = < CPG_MOD 623>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 623>;
+   renesas,fcp = <>;
+   };
};
 
timer {
-- 
2.7.4

[PATCH v2 2/4] arm64: dts: renesas: r8a77970: add DU support

From: Sergei Shtylyov 

Define the generic R8A77970 part of the DU device node.

Based on the original (and large) patch by Daisuke Matsushita
.

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 

---
v1 -> v2:
- Rename the du_out_lvds endpoint to comply with the name used in other
  Renesas board DTS files
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index a3ef3bd..ae5797d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -635,6 +635,34 @@
resets = < 623>;
renesas,fcp = <>;
};
+
+   du: display@feb0 {
+   compatible = "renesas,du-r8a77970";
+   reg = <0 0xfeb0 0 0x8>;
+   interrupts = ;
+   clocks = < CPG_MOD 724>;
+   clock-names = "du.0";
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   vsps = <>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   du_out_rgb: endpoint {
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   du_out_lvds0: endpoint {
+   };
+   };
+   };
+   };
};
 
timer {
-- 
2.7.4

[PATCH v2 3/4] arm64: dts: renesas: r8a77970: add LVDS support

From: Niklas Söderlund 

Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
the it to the LVDS output of the DU.

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

---
v1 -> v2:
- Rebased on the modified endpoint name and changed patch subject to
  comply with other patches in the series from Sergei.
---
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index ae5797d..ae15355 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -659,6 +659,33 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a77970-lvds";
+   reg = <0 0xfeb9 0 0x14>;
+   clocks = < CPG_MOD 727>;
+   power-domains = < R8A77970_PD_ALWAYS_ON>;
+   resets = < 727>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
2.7.4

[PATCH v8 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

Hello,
  new version with last bits hopefully fixed.

The vcc supply is now mandatory, as suggested by Mark Brown, and the driver
requires it to be described in device tree.

The "OE" GPIO is now described by 'oe' again, as I wrongly interpreted Rob's
suggestions on v6.

A few minor grammar fixes in bindings and in driver as suggested by Laurent.

As per v7, Eagle disaply enablement based on this series, is sent separately.

Thanks
   j

v7 -> b8:
- Make 'vcc' supply mandatory
- Use 'oe' property name to describe "OE" pin
- Minor fixes as suggested by Laurent on bindings and driver

v6 -> v7:
- Use semi-standard names for powerdown and output enable GPIOs as suggested
  by Rob and Vladimir
- Use 'regulator_get()' not the optional version, and list only 'vcc' as
  requested supply
- Addressed Laurent's review comments and removed Eagle display enablement patch
  to be sent separately

v5 -> v6:
- Drop check for CONFIG_OF as it is a Kconfig dependency
- Add Niklas Reviewed-by tags
- List [3/3] depenencies below commit message to ease integration

v4 -> v5:
- Fix punctuation in bindings documentation
- Add small statement to bindings document to clarify the chip has no
  control bus
- Print regulator name in enable/disable routines error path
- Add Andrzej Reviewed-by tag

v3 -> v4:
- Rename permutations of "pdwn" to just "pdwn" everywhere in the series
- Improve power enable/disable routines as suggested by Andrzej and Sergei
- Change "pdwn" gpio initialization to use the logical output level
- Change Kconfig description

v2 -> v3:
- Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
-- Rework bindings to describe multiple input/output ports
-- Rename driver and remove "lvds-decoder" references
-- Rework Eagle DTS to use new bindings

v1 -> v2:
- Drop support for THC63LVD1024

Jacopo Mondi (2):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add thc63lvd1024 LVDS decoder driver

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  60 ++
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  | 206 +
 4 files changed, 273 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

--
2.7.4

[PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..0b23e70
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,60 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two LVDS input streams and up to two digital CMOS/TTL outputs.
+
+Single or dual operation mode, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
+  PPL and digital circuitry
+
+Optional properties:
+- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
+- oe-gpios: Output enable GPIO signal, pin name "OE". Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- port@0: First LVDS input port
+- port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- port@1: Second LVDS input port
+- port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   powerdown-gpios = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
--
2.7.4

[PATCH v8 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
---
 drivers/gpu/drm/bridge/Kconfig|   6 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c | 206 ++
 3 files changed, 213 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3aa65bd..42c9c2d 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -93,6 +93,12 @@ config DRM_SII9234
  It is an I2C driver, that detects connection of MHL bridge
  and starts encapsulation of HDMI signal.
 
+config DRM_THINE_THC63LVD1024
+   tristate "Thine THC63LVD1024 LVDS decoder bridge"
+   depends on OF
+   ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..aa1d650
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+enum thc63_ports {
+   THC63_LVDS_IN0,
+   THC63_LVDS_IN1,
+   THC63_RGB_OUT0,
+   THC63_RGB_OUT1,
+};
+
+struct thc63_dev {
+   struct device *dev;
+
+   struct regulator *vcc;
+
+   struct gpio_desc *pdwn;
+   struct gpio_desc *oe;
+
+   struct drm_bridge bridge;
+   struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+
+   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   int ret;
+
+   ret = regulator_enable(thc63->vcc);
+   if (ret) {
+   dev_err(thc63->dev,
+   "Failed to enable regulator \"vcc\": %d\n", ret);
+   return;
+   }
+
+   gpiod_set_value(thc63->pdwn, 0);
+   gpiod_set_value(thc63->oe, 1);
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   int ret;
+
+   gpiod_set_value(thc63->oe, 0);
+   gpiod_set_value(thc63->pdwn, 1);
+
+   ret = regulator_disable(thc63->vcc);
+   if (ret)
+   dev_err(thc63->dev,
+   "Failed to disable regulator \"vcc\": %d\n", ret);
+}
+
+static const struct drm_bridge_funcs thc63_bridge_func = {
+   .attach = thc63_attach,
+   .enable = thc63_enable,
+   .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+   struct device_node *thc63_out;
+   struct device_node *remote;
+
+   thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_RGB_OUT0, -1);
+   if (!thc63_out) {
+   dev_err(thc63->dev, "Missing endpoint in port@%u\n",
+   THC63_RGB_OUT0);
+   return -ENODEV;
+   }
+
+   remote = of_graph_get_remote_port_parent(thc63_out);
+   of_node_put(thc63_out);
+   if (!remote) {
+   dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
+   THC63_RGB_OUT0);
+   return -ENODEV;
+   }
+
+   if (!of_device_is_available(remote)) {
+   dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
+   THC63_RGB_OUT0);
+   of_node_put(remote);
+   return -ENODEV;
+   }
+
+   thc63->next = of_drm_find_bridge(remote);
+   if (!thc63->next) {
+   of_node_put(remote);
+   return -EPROBE_DEFER;
+   }
+
+   return 0;
+}

Re: [PATCH v13 02/33] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2018-04-10 Thread Niklas Söderlund

Hi Fabrizio,

On 2018-04-10 09:55:29 +, Fabrizio Castro wrote:
> Dear All,
> 
> this patch was originally sent on the 16/11/2017, and reposted a few times, 
> does anybody know who is supposed to take it?

Hans have indicated he will take this a respin of this whole patch-set 
sometime next week.

> 
> Thanks,
> Fab
> 
> > -Original Message-
> > From: Niklas Söderlund [mailto:niklas.soderlund+rene...@ragnatech.se]
> > Sent: 26 March 2018 22:44
> > To: Laurent Pinchart ; Hans Verkuil 
> > ; linux-me...@vger.kernel.org
> > Cc: linux-renesas-soc@vger.kernel.org; TOMOHARU FUKAWA 
> > ; Kieran Bingham
> > ; Fabrizio Castro 
> > 
> > Subject: [PATCH v13 02/33] dt-bindings: media: rcar_vin: add device tree 
> > support for r8a774[35]
> >
> > From: Fabrizio Castro 
> >
> > Add compatible strings for r8a7743 and r8a7745. No driver change
> > is needed as "renesas,rcar-gen2-vin" will activate the right code.
> > However, it is good practice to document compatible strings for the
> > specific SoC as this allows SoC specific changes to the driver if
> > needed, in addition to document SoC support and therefore allow
> > checkpatch.pl to validate compatible string values.
> >
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
> > Reviewed-by: Simon Horman 
> > Acked-by: Rob Herring 
> > Reviewed-by: Geert Uytterhoeven 
> > Acked-by: Niklas Söderlund 
> > Reviewed-by: Laurent Pinchart 
> > ---
> >  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> > b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index d99b6f5dee418056..4c76d82905c9d3b8 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves and 
> > suppot one input
> >  channel which can be either RGB, YUYV or BT656.
> >
> >   - compatible: Must be one or more of the following
> > +   - "renesas,vin-r8a7743" for the R8A7743 device
> > +   - "renesas,vin-r8a7745" for the R8A7745 device
> > - "renesas,vin-r8a7778" for the R8A7778 device
> > - "renesas,vin-r8a7779" for the R8A7779 device
> > - "renesas,vin-r8a7790" for the R8A7790 device
> > @@ -14,7 +16,8 @@ channel which can be either RGB, YUYV or BT656.
> > - "renesas,vin-r8a7793" for the R8A7793 device
> > - "renesas,vin-r8a7794" for the R8A7794 device
> > - "renesas,vin-r8a7795" for the R8A7795 device
> > -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> > +   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> > + device.
> > - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
> >
> > When compatible with the generic version nodes must list the
> > --
> > 2.16.2
> 
> 
> 
> 
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
> Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
> No. 04586709.

-- 
Regards,
Niklas Söderlund

Re: RFC: RZ/N1 clock architecture...

Hi Michel,

On Tue, Apr 10, 2018 at 11:56 AM, Michel Pollet
 wrote:
> In the current SDK for the RZ/N1, we made a clock architecture that is 
> entirely device-tree based.
> The clock hierarchy is quite complex and was machine generated from design 
> documents, and
> some exceptions and grouping were added to the 'main' family rzn1.dtsi...
>
> Apart from a few fixed-clock nodes, all of the other nodes are 'special' and 
> require a driver. All
> of these drivers are sub-drivers to a 'main' clock driver. That has been 
> working for 2 years already.
>
> One extra note: we don't 'own' all of these clocks, part of the 
> clocks/dividers can be
> enable/disabled by the CM3 core.
>
> Now, For upstreaming, I'm going to have to change that, since already the 
> 'clock' bits are going
> to go under the MFD sysctrl node. However I'm trying to figure out if we can 
> still use our
> rzn1-clocks.dtsi in some form, as well as my drivers, or so I have to convert 
> it to a C table in
> some way.
>
> Also note that all the clock refer to SYSCTRL registers/bits using constant 
> names from a header
> file, not hex constants etc.
>
> I would appreciate any ideas/suggestions before I commit blindly to a path...
>
> Here is the main autogenerated clock file:
> https://github.com/renesas-rz/rzn1_linux/blob/rzn1-stable/arch/arm/boot/dts/rzn1-clocks.dtsi
> Here's the extra clock{} node in the main rzn1.dtsi
> https://github.com/renesas-rz/rzn1_linux/blob/89d6c9be056a462b95d5217221d70d6e5c25dfc2/arch/arm/boot/dts/rzn1.dtsi#L70

Describing the full clock hierarchy in DT is no longer recommended.
The modern way is to have a single clock provider node in DT, and have the
driver register all clocks.

Compare e.g. the single clock-controller node in arch/arm/boot/dts/r8a7791.dtsi
in v4.15 (used with the {r8a7791,renesas}-cpg-mssr.c driver, with the complex
clocks node in v4.14, used with a lot of subdrivers, and requiring continuous
maintenance.

So I think you're best of creating (generating) a C table instead, and
keep the DT
simple and obviously correct.

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 v13 02/33] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2018-04-10 Thread Fabrizio Castro

Dear All,

this patch was originally sent on the 16/11/2017, and reposted a few times, 
does anybody know who is supposed to take it?

Thanks,
Fab

> -Original Message-
> From: Niklas Söderlund [mailto:niklas.soderlund+rene...@ragnatech.se]
> Sent: 26 March 2018 22:44
> To: Laurent Pinchart ; Hans Verkuil 
> ; linux-me...@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org; TOMOHARU FUKAWA 
> ; Kieran Bingham
> ; Fabrizio Castro 
> 
> Subject: [PATCH v13 02/33] dt-bindings: media: rcar_vin: add device tree 
> support for r8a774[35]
>
> From: Fabrizio Castro 
>
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> Reviewed-by: Simon Horman 
> Acked-by: Rob Herring 
> Reviewed-by: Geert Uytterhoeven 
> Acked-by: Niklas Söderlund 
> Reviewed-by: Laurent Pinchart 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index d99b6f5dee418056..4c76d82905c9d3b8 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves and 
> suppot one input
>  channel which can be either RGB, YUYV or BT656.
>
>   - compatible: Must be one or more of the following
> +   - "renesas,vin-r8a7743" for the R8A7743 device
> +   - "renesas,vin-r8a7745" for the R8A7745 device
> - "renesas,vin-r8a7778" for the R8A7778 device
> - "renesas,vin-r8a7779" for the R8A7779 device
> - "renesas,vin-r8a7790" for the R8A7790 device
> @@ -14,7 +16,8 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7793" for the R8A7793 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> +   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> + device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
>
> When compatible with the generic version nodes must list the
> --
> 2.16.2




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

RFC: RZ/N1 clock architecture...

Hi guys,

In the current SDK for the RZ/N1, we made a clock architecture that is entirely
device-tree based.
The clock hierarchy is quite complex and was machine generated from design
documents, and
some exceptions and grouping were added to the 'main' family rzn1.dtsi...

Apart from a few fixed-clock nodes, all of the other nodes are 'special' and
require a driver. All
of these drivers are sub-drivers to a 'main' clock driver. That has been
working for 2 years already.

One extra note: we don't 'own' all of these clocks, part of the clocks/dividers
can be
enable/disabled by the CM3 core.

Now, For upstreaming, I'm going to have to change that, since already the
'clock' bits are going
to go under the MFD sysctrl node. However I'm trying to figure out if we can
still use our
rzn1-clocks.dtsi in some form, as well as my drivers, or so I have to convert
it to a C table in
some way.

Also note that all the clock refer to SYSCTRL registers/bits using constant
names from a header
file, not hex constants etc.

I would appreciate any ideas/suggestions before I commit blindly to a path...

Here is the main autogenerated clock file:
https://github.com/renesas-rz/rzn1_linux/blob/rzn1-stable/arch/arm/boot/dts/rzn1-clocks.dtsi
Here's the extra clock{} node in the main rzn1.dtsi
https://github.com/renesas-rz/rzn1_linux/blob/89d6c9be056a462b95d5217221d70d6e5c25dfc2/arch/arm/boot/dts/rzn1.dtsi#L70

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

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

Hi Wolfram,

On Tue, Apr 10, 2018 at 11:38 AM, Wolfram Sang
 wrote:
> Early revisions of certain SoCs cannot do multiple DMA RX streams in
> parallel. To avoid data corruption, only allow one DMA RX channel and
> fall back to PIO, if needed.
>
> Signed-off-by: Wolfram Sang 
> Reviewed-by: Yoshihiro Shimoda 
> Tested-by: Nguyen Viet Dung 

Thanks for your patch!

> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c

>  static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
>  {
> -   if (!soc_device_match(gen3_soc_whitelist))
> +   const struct soc_device_attribute *soc = 
> soc_device_match(gen3_soc_whitelist);
> +
> +   if (!soc)
> return -ENODEV;
>
> +   if (soc->data)

This non-NULL check is not really needed.

> +   global_flags |= (unsigned long)soc->data;
> +
> return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
>  }

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH 4/4] usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udc

Hi Simon-san,

> From: Simon Horman, Sent: Tuesday, April 10, 2018 6:34 PM
> 
> On Tue, Apr 10, 2018 at 01:28:33AM +, Yoshihiro Shimoda wrote:
> > Hi Simon-san,
> >
> > > From: Simon Horman, Sent: Monday, April 9, 2018 8:58 PM
> > >
> > > On Mon, Apr 02, 2018 at 09:21:34PM +0900, Yoshihiro Shimoda wrote:
> > > > This patch fixes an issue that this driver cannot call phy_init()
> > > > if a gadget driver is alreadly loaded because usb_add_gadget_udc()
> > > > might call renesas_usb3_start() via .udc_start.
> > > >
> > > > Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for 
> > > > generic phy")
> > > > Cc:  # v4.15+
> > > > Signed-off-by: Yoshihiro Shimoda 
> > > > ---
> > > >  drivers/usb/gadget/udc/renesas_usb3.c | 16 
> > > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > >
> > > Reviewed-by: Simon Horman 
> > >
> > >
> > > Please see some suggestions for follow-up lower-priority patches below.
> >
> > Thank you for the review and suggestions!
> >
> > > >
> > > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > > index 738b734..671bac3 100644
> > > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > > @@ -2632,6 +2632,14 @@ static int renesas_usb3_probe(struct 
> > > > platform_device *pdev)
> > > > if (ret < 0)
> > > > goto err_alloc_prd;
> > > >
> > > > +   /*
> > > > +* This is an optional. So, if this driver cannot get a phy,
> > > > +* this driver will not handle a phy anymore.
> > > > +*/
> > >
> > > nit: s/an optional/optional/
> >
> > Oops. I will fix and submit v2 patches.
> >
> > > > +   usb3->phy = devm_phy_get(>dev, "usb");
> > > > +   if (IS_ERR(usb3->phy))
> > > > +   usb3->phy = NULL;
> > >
> > > I think this will unintentionally ignore errors other than the
> > > non-existence of the device, f.e. a memory allocation failure
> > > in devm_phy_get().
> > >
> > > So perhaps something like this, as per phy_optional_get(), would be 
> > > better?
> > >
> > >   usb3->phy = devm_phy_get(>dev, "usb");
> > >   if (IS_ERR(usb3->phy) && (PTR_ERR(usb3->phy) == -ENODEV))
> > >   usb3->phy = NULL;
> >
> > Thank you for the suggestion. I agree with you.
> > I think I should use devm_phy_optional_get() instead of dev_phy_get(), as 
> > you mentioned :)
> > So, I will fix the code by using devm_phy_optional_get() first, and then 
> > fix this.
> 
> Thanks, I agree that would be a good fix.
> 
> But perhaps it is better as a follow-up?

Oops. Yes, I changed my mind after prepared the patch v2 and submitted v2.
I should have sent an email about this to you...
Anyway, thank you very much for reviewing the v2 patches!

Best regards,
Yoshihiro Shimoda

[PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

Early revisions of certain SoCs cannot do multiple DMA RX streams in
parallel. To avoid data corruption, only allow one DMA RX channel and
fall back to PIO, if needed.

Signed-off-by: Wolfram Sang 
Reviewed-by: Yoshihiro Shimoda 
Tested-by: Nguyen Viet Dung 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 8e0acd197c43..9c50d64cd10c 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -62,6 +63,17 @@
  *   need a custom accessor.
  */
 
+static unsigned long global_flags;
+/*
+ * Workaround for avoiding to use RX DMAC by multiple channels.
+ * On R-Car H3 ES1.* and M3-W ES1.0, when multiple SDHI channels use
+ * RX DMAC simultaneously, sometimes hundreds of bytes data are not
+ * stored into the system memory even if the DMAC interrupt happened.
+ * So, this driver then uses one RX DMAC channel only.
+ */
+#define SDHI_INTERNAL_DMAC_ONE_RX_ONLY 0
+#define SDHI_INTERNAL_DMAC_RX_IN_USE   1
+
 /* Definitions for sampling clocks */
 static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
{
@@ -126,6 +138,10 @@ renesas_sdhi_internal_dmac_abort_dma(struct tmio_mmc_host 
*host) {
renesas_sdhi_internal_dmac_dm_write(host, DM_CM_RST,
RST_RESERVED_BITS | val);
 
+
+   if (host->data && host->data->flags & MMC_DATA_READ)
+   clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
+
renesas_sdhi_internal_dmac_enable_dma(host, true);
 }
 
@@ -155,6 +171,9 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
dir = DMA_FROM_DEVICE;
+   if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
+   test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, 
_flags))
+   goto force_pio;
} else {
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
dir = DMA_TO_DEVICE;
@@ -208,6 +227,9 @@ static void 
renesas_sdhi_internal_dmac_complete_tasklet_fn(unsigned long arg)
renesas_sdhi_internal_dmac_enable_dma(host, false);
dma_unmap_sg(>pdev->dev, host->sg_ptr, host->sg_len, dir);
 
+   if (dir == DMA_FROM_DEVICE)
+   clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
+
tmio_mmc_do_data_irq(host);
 out:
spin_unlock_irq(>lock);
@@ -251,18 +273,25 @@ static const struct tmio_mmc_dma_ops 
renesas_sdhi_internal_dmac_dma_ops = {
  * implementation as others may use a different implementation.
  */
 static const struct soc_device_attribute gen3_soc_whitelist[] = {
-{ .soc_id = "r8a7795", .revision = "ES1.*" },
+{ .soc_id = "r8a7795", .revision = "ES1.*",
+ .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
 { .soc_id = "r8a7795", .revision = "ES2.0" },
-{ .soc_id = "r8a7796", .revision = "ES1.0" },
+{ .soc_id = "r8a7796", .revision = "ES1.0",
+ .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
 { .soc_id = "r8a77995", .revision = "ES1.0" },
 { /* sentinel */ }
 };
 
 static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
 {
-   if (!soc_device_match(gen3_soc_whitelist))
+   const struct soc_device_attribute *soc = 
soc_device_match(gen3_soc_whitelist);
+
+   if (!soc)
return -ENODEV;
 
+   if (soc->data)
+   global_flags |= (unsigned long)soc->data;
+
return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
 }
 
-- 
2.11.0

[PATCH 0/5] mmc: renesas_sdhi_internal_dmac: DMA handling fixes

Ulf,

I have collected the patches floating around for renesas_sdhi_internal_dmac
(also previously internal ones) and grouped them to avoid dependency issues. I
think it would be good to give Shimoda-san some time to look at the new patches
(2,3,5), too.

Regarding stable: I think patch 1 is clearly for stable. Patch 3 maybe, but it
needs patch 2 which is not. Not sure if it is worth the hazzle. Maybe
Shimoda-san has an opinion, too? Patches 4 & 5 are not for stable.

Changes since last time:
* patch 1: added tags, don't initialize static var to 0
* patches 2,3,5: new
* patch 4: added tags

Kind regards,

   Wolfram


Masaharu Hayakawa (1):
  mmc: renesas_sdhi: Fix alignment check of sg buffer

Niklas Söderlund (1):
  mmc: renesas_sdhi: use helpers to access struct scatterlist members

Wolfram Sang (3):
  mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs
  mmc: renesas_sdhi_internal_dmac: use more generic whitelisting
  mmc: renesas_sdhi_internal_dmac: remove superfluous WARN

 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 64 +++
 1 file changed, 46 insertions(+), 18 deletions(-)

-- 
2.11.0

[PATCH 2/5] mmc: renesas_sdhi: use helpers to access struct scatterlist members

From: Niklas Söderlund 

Instead of directly accessing the members of struct scatterlist use the
helpers mmc_get_dma_dir() and sg_dma_address() in
renesas_sdhi_internal_dmac_start_dma(). Based on previous work by
Masaharu Hayakawa.

Signed-off-by: Niklas Söderlund 
[rebased to mmc/next]
Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 9c50d64cd10c..6c2f3ae01de9 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -158,7 +158,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
 {
struct scatterlist *sg = host->sg_ptr;
u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
-   enum dma_data_direction dir;
int ret;
 
/* This DMAC cannot handle if sg_len is not 1 */
@@ -170,16 +169,15 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
 
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
-   dir = DMA_FROM_DEVICE;
if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, 
_flags))
goto force_pio;
} else {
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
-   dir = DMA_TO_DEVICE;
}
 
-   ret = dma_map_sg(>pdev->dev, sg, host->sg_len, dir);
+   ret = dma_map_sg(>pdev->dev, sg, host->sg_len,
+mmc_get_dma_dir(data));
if (ret == 0)
goto force_pio;
 
@@ -189,7 +187,7 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
renesas_sdhi_internal_dmac_dm_write(host, DM_CM_DTRAN_MODE,
dtran_mode);
renesas_sdhi_internal_dmac_dm_write(host, DM_DTRAN_ADDR,
-   sg->dma_address);
+   sg_dma_address(sg));
 
return;
 
-- 
2.11.0

[PATCH 3/5] mmc: renesas_sdhi: Fix alignment check of sg buffer

From: Masaharu Hayakawa 

Sometimes sg->offset is not used for buffer addresses allocated by
dma_map_sg(), so alignment checks should be done on the allocated buffer
addresses. Delete the alignment check for sg->offset that is done before
dma_map_sg(). Instead, it performs the alignment check for
sg->dma_address after dma_map_sg().

Signed-off-by: Masaharu Hayakawa 
[Niklas: broke this commit in two and tidied small style issue]
Signed-off-by: Niklas Söderlund 
[rebased to mmc/next]
Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 6c2f3ae01de9..32b8be4c0b81 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -158,14 +158,20 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
 {
struct scatterlist *sg = host->sg_ptr;
u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
-   int ret;
 
/* This DMAC cannot handle if sg_len is not 1 */
WARN_ON(host->sg_len > 1);
 
+   if (!dma_map_sg(>pdev->dev, sg, host->sg_len,
+   mmc_get_dma_dir(data)))
+   goto force_pio;
+
/* This DMAC cannot handle if buffer is not 8-bytes alignment */
-   if (!IS_ALIGNED(sg->offset, 8))
+   if (!IS_ALIGNED(sg_dma_address(sg), 8)) {
+   dma_unmap_sg(>pdev->dev, sg, host->sg_len,
+mmc_get_dma_dir(data));
goto force_pio;
+   }
 
if (data->flags & MMC_DATA_READ) {
dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
@@ -176,11 +182,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
}
 
-   ret = dma_map_sg(>pdev->dev, sg, host->sg_len,
-mmc_get_dma_dir(data));
-   if (ret == 0)
-   goto force_pio;
-
renesas_sdhi_internal_dmac_enable_dma(host, true);
 
/* set dma parameters */
-- 
2.11.0

[PATCH 5/5] mmc: renesas_sdhi_internal_dmac: remove superfluous WARN

The WARN can never trigger because we limited the max_seg number in
renesas_sdhi_of_data already. Remove it and update the comment.

Signed-off-by: Wolfram Sang 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 06b4e0004ca4..9be1780d9970 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -91,7 +91,7 @@ static const struct renesas_sdhi_of_data 
of_rcar_gen3_compatible = {
.scc_offset = 0x1000,
.taps   = rcar_gen3_scc_taps,
.taps_num   = ARRAY_SIZE(rcar_gen3_scc_taps),
-   /* Gen3 SDHI DMAC can handle 0x blk count, but seg = 1 */
+   /* DMAC can handle 0x blk count but only 1 segment */
.max_blk_count  = 0x,
.max_segs   = 1,
 };
@@ -159,9 +159,6 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
*host,
struct scatterlist *sg = host->sg_ptr;
u32 dtran_mode = DTRAN_MODE_BUS_WID_TH | DTRAN_MODE_ADDR_MODE;
 
-   /* This DMAC cannot handle if sg_len is not 1 */
-   WARN_ON(host->sg_len > 1);
-
if (!dma_map_sg(>pdev->dev, sg, host->sg_len,
mmc_get_dma_dir(data)))
goto force_pio;
-- 
2.11.0

[PATCH 4/5] mmc: renesas_sdhi_internal_dmac: use more generic whitelisting

Whitelisting every ES version does not scale. So, we whitelist whole
SoCs independent of ES version. If we need specific handling for an ES
version, we put it to the front, so it will be matched first.

Signed-off-by: Wolfram Sang 
Reviewed-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
Tested-by: Nguyen Viet Dung 
---
 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 32b8be4c0b81..06b4e0004ca4 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -272,12 +272,15 @@ static const struct tmio_mmc_dma_ops 
renesas_sdhi_internal_dmac_dma_ops = {
  * implementation as others may use a different implementation.
  */
 static const struct soc_device_attribute gen3_soc_whitelist[] = {
+   /* specific ones */
 { .soc_id = "r8a7795", .revision = "ES1.*",
  .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
-{ .soc_id = "r8a7795", .revision = "ES2.0" },
 { .soc_id = "r8a7796", .revision = "ES1.0",
  .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
-{ .soc_id = "r8a77995", .revision = "ES1.0" },
+   /* generic ones */
+{ .soc_id = "r8a7795" },
+{ .soc_id = "r8a7796" },
+{ .soc_id = "r8a77995" },
 { /* sentinel */ }
 };
 
-- 
2.11.0

RE: [PATCH v2 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

2018-04-10 Thread Fabrizio Castro

Good morning gentlemen,

I am very sorry to bother you again, but it seems this patch has no master. Is 
anybody willing to take it?

Thanks,
Fab

> -Original Message-
> From: Fabrizio Castro [mailto:fabrizio.cas...@bp.renesas.com]
> Sent: 18 December 2017 17:39
> To: Rob Herring ; Mark Rutland 
> Cc: Fabrizio Castro ; Daniel Lezcano 
> ; Thomas Gleixner
> ; devicet...@vger.kernel.org; Simon Horman 
> ; Geert Uytterhoeven
> ; Chris Paterson ; Biju 
> Das ; linux-renesas-
> s...@vger.kernel.org
> Subject: [PATCH v2 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] 
> CMT support
>
> Document SoC specific compatible strings for r8a7743 and r8a7745.
> No driver change is needed as the fallback strings will activate
> the right code.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Rob Herring 
> Reviewed-by: Simon Horman 
> ---
> v1->v2:
> * "R-Car Gen2 or RZ/G1." -> "R-Car Gen2 and RZ/G1."
> * "all the R-Car" -> "R-Car"
>
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
> b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> index d740989..b40add2 100644
> --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> @@ -22,6 +22,10 @@ Required Properties:
>
>  - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
>  - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
> +- "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743.
> +- "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743.
> +- "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745.
> +- "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745.
>  - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790.
>  - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790.
>  - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791.
> @@ -31,10 +35,12 @@ Required Properties:
>  - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794.
>  - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794.
>
> -- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car 
> Gen2.
> -- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car 
> Gen2.
> -These are fallbacks for r8a73a4 and all the R-Car Gen2
> -entrieslisted above.
> +- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2
> +and RZ/G1.
> +- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2
> +and RZ/G1.
> +These are fallbacks for r8a73a4, R-Car Gen2 and RZ/G1 entries
> +listed above.
>
>- reg: base address and length of the registers block for the timer module.
>- interrupts: interrupt-specifier for the timer, one per channel.
> --
> 2.7.4




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

Re: [PATCH v2 5/6] usb: gadget: udc: renesas_usb3: should fail if devm_phy_get() returns error

On Tue, Apr 10, 2018 at 02:38:53PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver ignores errors other than
> the non-existence of the device, f.e. a memory allocation failure
> in devm_phy_get(). So, this patch replaces devm_phy_get() with
> devm_phy_optional_get().
> 
> Reported-by: Simon Horman 
> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic 
> phy")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 233bc04..0e70163 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2636,9 +2636,11 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>* This is optional. So, if this driver cannot get a phy,
>* this driver will not handle a phy anymore.
>*/
> - usb3->phy = devm_phy_get(>dev, "usb");
> - if (IS_ERR(usb3->phy))
> - usb3->phy = NULL;
> + usb3->phy = devm_phy_optional_get(>dev, "usb");
> + if (IS_ERR(usb3->phy)) {
> + ret = PTR_ERR(usb3->phy);
> + goto err_add_udc;
> + }
>  
>   pm_runtime_enable(>dev);
>   ret = usb_add_gadget_udc(>dev, >gadget);
> -- 
> 1.9.1
>

Re: [PATCH v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that reconnection is possible to fail
> because unexpected state handling happens by the irqs. To fix the issue,
> the driver disables the controller's irqs when disconnected.
> 
> Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> USB3.0 peripheral controller")
> Cc:  # v4.5+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
> 
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 0e70163..5caf78b 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 *usb3)
>   usb3_usb2_pullup(usb3, 0);
>   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
>   usb3_reset_epc(usb3);
> + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);
> + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> + usb3_init_epc_registers(usb3);
>  
>   if (usb3->driver)
>   usb3->driver->disconnect(>gadget);
> -- 
> 1.9.1
>

Re: [PATCH 4/4] usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udc

On Tue, Apr 10, 2018 at 01:28:33AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> > From: Simon Horman, Sent: Monday, April 9, 2018 8:58 PM
> > 
> > On Mon, Apr 02, 2018 at 09:21:34PM +0900, Yoshihiro Shimoda wrote:
> > > This patch fixes an issue that this driver cannot call phy_init()
> > > if a gadget driver is alreadly loaded because usb_add_gadget_udc()
> > > might call renesas_usb3_start() via .udc_start.
> > >
> > > Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for 
> > > generic phy")
> > > Cc:  # v4.15+
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  drivers/usb/gadget/udc/renesas_usb3.c | 16 
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > Reviewed-by: Simon Horman 
> > 
> > 
> > Please see some suggestions for follow-up lower-priority patches below.
> 
> Thank you for the review and suggestions!
> 
> > >
> > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > index 738b734..671bac3 100644
> > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > @@ -2632,6 +2632,14 @@ static int renesas_usb3_probe(struct 
> > > platform_device *pdev)
> > >   if (ret < 0)
> > >   goto err_alloc_prd;
> > >
> > > + /*
> > > +  * This is an optional. So, if this driver cannot get a phy,
> > > +  * this driver will not handle a phy anymore.
> > > +  */
> > 
> > nit: s/an optional/optional/
> 
> Oops. I will fix and submit v2 patches.
> 
> > > + usb3->phy = devm_phy_get(>dev, "usb");
> > > + if (IS_ERR(usb3->phy))
> > > + usb3->phy = NULL;
> > 
> > I think this will unintentionally ignore errors other than the
> > non-existence of the device, f.e. a memory allocation failure
> > in devm_phy_get().
> > 
> > So perhaps something like this, as per phy_optional_get(), would be better?
> > 
> > usb3->phy = devm_phy_get(>dev, "usb");
> > if (IS_ERR(usb3->phy) && (PTR_ERR(usb3->phy) == -ENODEV))
> > usb3->phy = NULL;
> 
> Thank you for the suggestion. I agree with you.
> I think I should use devm_phy_optional_get() instead of dev_phy_get(), as you 
> mentioned :)
> So, I will fix the code by using devm_phy_optional_get() first, and then fix 
> this.

Thanks, I agree that would be a good fix.

But perhaps it is better as a follow-up?

Re: [PATCH] phy: Renesas R-Car gen3 PCIe PHY driver

On Mon, Apr 09, 2018 at 06:57:11PM +0300, Sergei Shtylyov wrote:
> On 04/09/2018 12:46 PM, Geert Uytterhoeven wrote:
> 
> >> This PHY is still mostly undocumented -- the only documented registers
> >> exist on R-Car V3H (R8A77980) SoC  where this PHY stays in a powered-down
> >> state after a reset and thus  we must power it on for PCIe to work...
> > 
> > Bogus spaces slipping in again?
> 
>Yes, I should have worked in the type-setting. :-)
> 
> >> Signed-off-by: Sergei Shtylyov 
> > 
> >> --- /dev/null
> >> +++ linux-phy/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt
> >> @@ -0,0 +1,32 @@
> [...]
> >> +Example (R-Car V3H):
> >> +
> >> +   pcie-phy@e65d {
> >> +   compatible = "renesas,r8a77980-pcie-phy",
> >> +"renesas,rcar-gen3-pcie-phy";
> > 
> > Is the R8A77980 PCIe PHY compatible with the generic version, given it needs
> > to be powered up explicitly?
> 
>I assumed it's upwardly compatible. However, given the lack of information,
> it might not be...

If we are not sure I'd rather assume that it is not upwardly compatible.
Because falling back to something that doesn't work does not seem at all
useful to me.

...

[PATCH v4 8/8] reset: Renesas RZ/N1 reboot driver

The Renesas RZ/N1 Family (Part #R9A06G0xx) needs a small driver
to reboot the Cortex-A7 cores. This driver is a sub driver of
the sysctrl MFD.

Signed-off-by: Michel Pollet 
---
 drivers/power/reset/Kconfig   |   7 +++
 drivers/power/reset/Makefile  |   1 +
 drivers/power/reset/rzn1-reboot.c | 105 ++
 3 files changed, 113 insertions(+)
 create mode 100644 drivers/power/reset/rzn1-reboot.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index df58fc8..1416d88 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -144,6 +144,13 @@ config POWER_RESET_RESTART
  Instead they restart, and u-boot holds the SoC until the
  user presses a key. u-boot then boots into Linux.
 
+config POWER_RESET_RZN1
+   bool "Renesas RZ/N1 reboot driver"
+   depends on ARCH_RZN1
+   help
+ This driver allows rebooting the CA7 cores of the
+ Renesas RZ/N1 Family of SoC (Part # R9A06G0xx).
+
 config POWER_RESET_ST
bool "ST restart driver"
depends on ARCH_STI
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 7778c74..bad9702 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
 obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
 obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
 obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
+obj-$(CONFIG_POWER_RESET_RZN1) += rzn1-reboot.o
 obj-$(CONFIG_POWER_RESET_ST) += st-poweroff.o
 obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
 obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
diff --git a/drivers/power/reset/rzn1-reboot.c 
b/drivers/power/reset/rzn1-reboot.c
new file mode 100644
index 000..29b568c
--- /dev/null
+++ b/drivers/power/reset/rzn1-reboot.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RZ/N1 reboot driver
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet , 
+ * Derived from zx-reboot.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Definitions from the SDK rzn1-sysctrl.h autogenerated file */
+#define RZN1_SYSCTRL_REG_RSTEN 0x120
+#define RZN1_SYSCTRL_REG_RSTEN_MRESET_EN   0
+#define RZN1_SYSCTRL_REG_RSTEN_WDA7RST_EN  1
+#define RZN1_SYSCTRL_REG_RSTEN_WDA7RST_EN_MASK 0x6
+#define RZN1_SYSCTRL_REG_RSTEN_WDM3RST_EN  3
+#define RZN1_SYSCTRL_REG_RSTEN_CM3LOCKUPRST_EN 4
+#define RZN1_SYSCTRL_REG_RSTEN_CM3SYSRESET_EN  5
+#define RZN1_SYSCTRL_REG_RSTEN_SWRST_EN6
+#define RZN1_SYSCTRL_REG_RSTCTRL   0x198
+#define RZN1_SYSCTRL_REG_RSTCTRL_WDA7RST_REQ   1
+#define RZN1_SYSCTRL_REG_RSTCTRL_WDA7RST_REQ_MASK  0x6
+#define RZN1_SYSCTRL_REG_RSTCTRL_WDM3RST_REQ   3
+#define RZN1_SYSCTRL_REG_RSTCTRL_CM3LOCKUPRST_REQ  4
+#define RZN1_SYSCTRL_REG_RSTCTRL_CM3SYSRESET_REQ   5
+#define RZN1_SYSCTRL_REG_RSTCTRL_SWRST_REQ 6
+
+static struct regmap *sysctrl;
+
+static int rzn1_reboot_handler(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+   regmap_write_bits(sysctrl,
+   RZN1_SYSCTRL_REG_RSTEN,
+   BIT(RZN1_SYSCTRL_REG_RSTEN_SWRST_EN) |
+   BIT(RZN1_SYSCTRL_REG_RSTEN_MRESET_EN),
+   BIT(RZN1_SYSCTRL_REG_RSTEN_SWRST_EN) |
+   BIT(RZN1_SYSCTRL_REG_RSTEN_MRESET_EN));
+   regmap_write_bits(sysctrl,
+   RZN1_SYSCTRL_REG_RSTCTRL,
+   BIT(RZN1_SYSCTRL_REG_RSTCTRL_SWRST_REQ),
+   BIT(RZN1_SYSCTRL_REG_RSTCTRL_SWRST_REQ));
+
+   mdelay(50);
+   pr_emerg("Unable to restart system\n");
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block rzn1_reboot_nb = {
+   .notifier_call = rzn1_reboot_handler,
+   .priority = 128,
+};
+
+static int rzn1_reboot_probe(struct platform_device *pdev)
+{
+   int err;
+   struct device *parent;
+
+   parent = pdev->dev.parent;
+   if (!parent || !parent->of_node) {
+   dev_err(>dev, "couldn't find sysctrl node\n");
+   return -ENODEV;
+   }
+   sysctrl = syscon_node_to_regmap(parent->of_node);
+   if (IS_ERR(sysctrl)) {
+   dev_err(>dev, "couldn't find find regmap\n");
+   return PTR_ERR(sysctrl);
+   }
+   err = register_restart_handler(_reboot_nb);
+   if (err) {
+   dev_err(>dev, "register restart handler failed(err=%d)\n",
+   err);
+   }
+
+   return err;
+}
+
+static const struct of_device_id rzn1_reboot_of_match[] = {
+   { .compatible =

[PATCH v4 2/8] arm: shmobile: Add the RZ/N1D (R9A06G032) to the shmobile Kconfig

Add the RZ/N1D SoC to the reset of the Renesas SoC Collection.

Signed-off-by: Michel Pollet 
---
 arch/arm/mach-shmobile/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 221fbcb..a80c0ed 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -110,6 +110,10 @@ config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
select ARCH_RCAR_GEN2
 
+config ARCH_R9A06G032
+   bool "RZ/N1D (R9A06G032)"
+   select ARCH_RZN1
+
 config ARCH_RZN1
bool "RZ/N1 (R9A06G0xx) Family"
select ARM_AMBA
-- 
2.7.4

[PATCH v4 3/8] dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node

The Renesas RZ/N1 Family (Part #R9A06G0xx) has a multi-function
system controller. This documents the node used to encapsulate
it's sub drivers.

Signed-off-by: Michel Pollet 
---
 .../bindings/mfd/renesas,rzn1-sysctrl.txt  | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt

diff --git a/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt 
b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
new file mode 100644
index 000..9897f8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
@@ -0,0 +1,23 @@
+DT bindings for the Renesas RZ/N1 System Controller
+
+== System Controller Node ==
+
+The system controller node currently only hosts a single sub-node to handle
+the rebooting of the CPU. Eventually it will host the clock driver, SMP
+start handler, watchdog etc.
+
+See renesas,rzn1-reboot.txt for further details.
+
+Bindings:
++ Required:
+   compatible = "renesas,r9a06g032-sysctrl",
+   "renesas,rzn1-sysctrl",
+   "syscon", "simple-mfd";
+
+Example:
+   sysctrl: sysctrl@4000c000 {
+   compatible = "renesas,r9a06g032-sysctrl",
+   "renesas,rzn1-sysctrl",
+   "syscon", "simple-mfd";
+   reg = <0x4000c000 0x1000>;
+   };
-- 
2.7.4

[PATCH v4 4/8] dt-bindings: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver

The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
as part of the sysctrl MFD to handle rebooting the CA7 cores.
This documents the driver bindings.

Signed-off-by: Michel Pollet 
---
 .../bindings/power/renesas,rzn1-reboot.txt | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt

diff --git a/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt 
b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
new file mode 100644
index 000..8516ab0
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
@@ -0,0 +1,23 @@
+DT bindings for the Renesas RZ/N1 Reboot Driver
+
+== Reboot Driver Node ==
+
+The reboot driver is always a subnode of the system controller node, see
+renesas,rzn1-sysctrl.txt for details.
+
+Bindings:
++ Required:
+   compatible = "renesas,r9a06g032-reboot", "renesas,rzn1-reboot";
+
+Example:
+   sysctrl: sysctrl@4000c000 {
+   compatible = "renesas,r9a06g032-sysctrl",
+   "renesas,rzn1-sysctrl",
+   "syscon", "simple-mfd";
+   reg = <0x4000c000 0x1000>;
+
+   reboot {
+   compatible = "renesas,r9a06g032-reboot",
+   "renesas,rzn1-reboot";
+   };
+   };
-- 
2.7.4

[PATCH v4 7/8] ARM: dts: Renesas RZN1D-DB Board base file

This adds a base device tree file for the RZN1-DB board, with only the
basic support allowing the system to boot to a prompt. Only one UART is
used, with only a single CPU running.

Signed-off-by: Michel Pollet 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts | 29 +
 2 files changed, 30 insertions(+)
 create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e24249..53c9bf4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -806,6 +806,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
r8a7794-silk.dtb \
+   r9a06g032-rzn1d400-db.dtb \
sh73a0-kzm9g.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
diff --git a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts 
b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
new file mode 100644
index 000..5fc2c40
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the RZN1D-DB Board
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+/dts-v1/;
+
+#include "r9a06g032.dtsi"
+
+/ {
+   model = "RZN1D-DB Board";
+   compatible = "renesas,rzn1d400-db",
+   "renesas,r9a06g032", "renesas,rzn1";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = 
+   };
+};
+
+ {
+   status = "okay";
+};
-- 
2.7.4

[PATCH v4 6/8] ARM: dts: Renesas RZ/N1 SoC base device tree file

This adds the Renesas RZ/N1D (Part #R9A06G032) SoC bare
bone support.

This currently only handles generic parts (gic, architected timer)
and a UART.
For simplicity sake, this also relies on the bootloader to set the
pinctrl and clocks.

Signed-off-by: Michel Pollet 
---
 arch/arm/boot/dts/r9a06g032.dtsi | 94 
 1 file changed, 94 insertions(+)
 create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi

diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
new file mode 100644
index 000..7d84b38
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+#include 
+
+/ {
+   compatible = "renesas,r9a06g032", "renesas,rzn1";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   clkuarts: clkuarts {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <47619047>;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <1>;
+   };
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <>;
+   ranges;
+
+   sysctrl: sysctrl@4000c000 {
+   compatible = "renesas,r9a06g032-sysctrl",
+   "renesas,rzn1-sysctrl",
+   "syscon", "simple-mfd";
+   reg = <0x4000c000 0x1000>;
+
+   reboot {
+   compatible = "renesas,r9a06g032-reboot",
+   "renesas,rzn1-reboot";
+   };
+   };
+
+   uart0: serial@4006 {
+   compatible = "snps,dw-apb-uart";
+   reg = <0x4006 0x400>;
+   interrupts = ;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   clocks = <>;
+   clock-names = "baudclk";
+   status = "disabled";
+   };
+
+   gic: gic@44101000 {
+   compatible = "arm,cortex-a7-gic", "arm,gic-400";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   reg = <0x44101000 0x1000>, /* Distributer */
+ <0x44102000 0x2000>, /* CPU interface */
+ <0x44104000 0x2000>, /* Virt interface control */
+ <0x44106000 0x2000>; /* Virt CPU interface */
+   interrupts =
+   ;
+   };
+   };
+
+   timer {
+   compatible = "arm,cortex-a7-timer",
+"arm,armv7-timer";
+   interrupt-parent = <>;
+   arm,cpu-registers-not-fw-configured;
+   always-on;
+   interrupts =
+   ,
+   ,
+   ,
+   ;
+   };
+};
-- 
2.7.4

[PATCH v4 5/8] dt-bindings: arm: Document the RZN1D-DB board

This documents the RZ/N1 bindings for the RZN1D-DB board.

Signed-off-by: Michel Pollet 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index d3d1df9..024caf7 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -47,7 +47,8 @@ SoCs:
 compatible = "renesas,r8a77980"
   - R-Car D3 (R8A77995)
 compatible = "renesas,r8a77995"
-
+  - RZ/N1D (R9A06G032)
+compatible = "renesas,r9a06g032", "renesas,rzn1"
 
 Boards:
 
@@ -104,6 +105,8 @@ Boards:
 compatible = "renesas,porter", "renesas,r8a7791"
   - RSKRZA1 (YR0K77210C000BE)
 compatible = "renesas,rskrza1", "renesas,r7s72100"
+  - RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package)
+compatible = "renesas,rzn1d400-db", "renesas,r9a06g032", "renesas,rzn1"
   - Salvator-X (RTP0RC7795SIPB0010S)
 compatible = "renesas,salvator-x", "renesas,r8a7795"
   - Salvator-X (RTP0RC7796SIPB0011S)
-- 
2.7.4

[PATCH v4 1/8] arm: shmobile: Add the RZ/N1 arch to the shmobile Kconfig

Add the RZ/N1 Family (Part #R9A06G0xx) ARCH config to the rest of
the Renesas SoC collection.

Signed-off-by: Michel Pollet 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/mach-shmobile/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 280e731..221fbcb 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -110,6 +110,11 @@ config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
select ARCH_RCAR_GEN2
 
+config ARCH_RZN1
+   bool "RZ/N1 (R9A06G0xx) Family"
+   select ARM_AMBA
+   select CPU_V7
+
 config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
-- 
2.7.4

[PATCH v4 0/8] arm: Base support for Renesas RZN1D-DB Board

This series adds the plain basic support for booting a bare
kernel on the RZ/N1D-DB Board. It's been trimmed to the strict
minimum as a 'base', further patches that will add the
rest of the support, pinctrl, clock architecture and quite
a few others.

Thanks for the comments on the previous versions!

v4:
 + Fixes for suggestions by Simon Horman
 + Fixes for suggestions by Jacopo Mondi
 + Fixes for suggestions by Geert Uytterhoeven
 + Renamed the r9a06g0xx.dtsi file, given up on trying to get a family
   common file in, so dropped potential RZ/N1S support and now only
   focus on RZ/N1D for this patchset.
 + Added 'always-on' to the architected timer node, because it is.
 + Added ARCH_R9A06G032, to match others patterns like RCAR
 + Sorted the .dts files, added empty lines as required.
 + Fixed patch prefixes to match git-log for bindings
 + Merged board .dts & Makefile changes together
 + Rebased on next-20180410
v3:
 + Fixes for suggestions by Geert Uytterhoeven
 + Removed SoC Specific renesas,r9a06g032-xxx, as it's not needed for now.
 + Kept renesas,rzn1 as a family/generic for this family.
 + Fixed a couple of the commit messages.
 + Added Geert's Reviewed-By where appropriate.
v2:
 + Fixes for suggestions by Simon Horman
 + Fixes for suggestions by Rob Herring
 + Fixes for suggestions by Geert Uytterhoeven
 + Removed the mach file
 + Added a MFD base for the sysctrl block
 + Added a regmap based sub driver for the reboot handler
 + Renamed the files to match shmobile conventions
 + Adapted the compatible= strings to reflect 'family' vs 'part'
   distinction.
 + Removed the sysctrl.h file entirelly.
 + Fixed every warnings from the DTC compiler on W=12 mode.
 + Split the device-tree patches from the code.

Michel Pollet (8):
  arm: shmobile: Add the RZ/N1 arch to the shmobile Kconfig
  arm: shmobile: Add the RZ/N1D (R9A06G032) to the shmobile Kconfig
  dt-bindings: mfd: renesas,rzn1-sysctrl: document RZ/N1 sysctrl node
  dt-bindings: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver
  dt-bindings: arm: Document the RZN1D-DB board
  ARM: dts: Renesas RZ/N1 SoC base device tree file
  ARM: dts: Renesas RZN1D-DB Board base file
  reset: Renesas RZ/N1 reboot driver

 Documentation/devicetree/bindings/arm/shmobile.txt |   5 +-
 .../bindings/mfd/renesas,rzn1-sysctrl.txt  |  23 +
 .../bindings/power/renesas,rzn1-reboot.txt |  23 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts|  29 ++
 arch/arm/boot/dts/r9a06g032.dtsi   |  94 ++
 arch/arm/mach-shmobile/Kconfig |   9 ++
 drivers/power/reset/Kconfig|   7 ++
 drivers/power/reset/Makefile   |   1 +
 drivers/power/reset/rzn1-reboot.c  | 105 +
 10 files changed, 296 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/mfd/renesas,rzn1-sysctrl.txt
 create mode 100644 
Documentation/devicetree/bindings/power/renesas,rzn1-reboot.txt
 create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
 create mode 100644 arch/arm/boot/dts/r9a06g032.dtsi
 create mode 100644 drivers/power/reset/rzn1-reboot.c

-- 
2.7.4

Re: [PATCH] base: dma-mapping: Postpone cpu addr translation on mmap()

2018-04-10 Thread jacopo mondi

Hi Christoph,

On Mon, Apr 09, 2018 at 10:52:51AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 09, 2018 at 06:59:08PM +0200, Jacopo Mondi wrote:
> > I'm still a bit puzzled on what happens if dma_mmap_from_dev_coherent() 
> > fails.
> > Does a dma_mmap_from_dev_coherent() failure guarantee anyhow that the
> > successive virt_to_page() isn't problematic as it is today?
> > Or is it the
> > if (off < count && user_count <= (count - off))
> > check that makes the translation safe?
>
> It doesn't.  I think one major issue is that we should not simply fall
> to dma_common_mmap if no method is required, but need every instance of
> dma_map_ops to explicitly opt into an mmap method that is known to work.

I see.. this patch thus just postpones the problem...

>
> >  #ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
> > unsigned long user_count = vma_pages(vma);
> > unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > -   unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
> > unsigned long off = vma->vm_pgoff;
> > +   unsigned long pfn;
> >
> > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> >
> > @@ -235,6 +235,7 @@ int dma_common_mmap(struct device *dev, struct 
> > vm_area_struct *vma,
> > return ret;
> >
> > if (off < count && user_count <= (count - off)) {
> > +   pfn = page_to_pfn(virt_to_page(cpu_addr));
> > ret = remap_pfn_range(vma, vma->vm_start,
> >   pfn + off,
> >   user_count << PAGE_SHIFT,
>
> Why not:
>
>   ret = remap_pfn_range(vma, vma->vm_start,
>   page_to_pfn(virt_to_page(cpu_addr)) + off,
>
> and save the temp variable?

Sure, it's better... Should I send a v2 or considering your above
comment this patch is just a mitigation and should be ditched in
favour of a proper solution (which requires a much more considerable amount
of work though)?

Thanks
   j


signature.asc
Description: PGP signature

RE: [PATCH v3 2/8] DT: reset: renesas,rzn1-reboot: document RZ/N1 reboot driver