Re: [PATCH 02/03] arm64: dts: renesas: r8a77980: Add IPMMU devices nodes

[Magnus Damm]

Hi Simon,

On Tue, May 22, 2018 at 10:10 PM, Simon Horman  wrote:
> On Mon, May 21, 2018 at 11:45:01PM +0900, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Add IPMMU device nodes for the R-Car V3H SoC aka r8a77980.
>>
>> The r8a77980 IPMMU is quite similar to r8a77970 however VC0
>> has been added. The IMSSTR bit assignment has also been
>> reworked. Power domains are also quite different however the
>> the documentation is rather unclear about this topic.
>>
>> Until we know better VC0 gets assigned to R8A77980_PD_ALWAYS_ON.
>>
>> Signed-off-by: Magnus Damm 
>> ---
>>
>>  Developed on top of renesas-devel-20180518-v4.17-rc5
>>
>>  arch/arm64/boot/dts/renesas/r8a77980.dtsi |   49 
>> +
>>  1 file changed, 49 insertions(+)
>>
>> --- 0001/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> +++ work/arch/arm64/boot/dts/renesas/r8a77980.dtsi2018-05-21 
>> 22:31:52.460607110 +0900
>> @@ -387,6 +387,55 @@
>>   dma-channels = <16>;
>>   };
>>
>> + ipmmu_ds1: mmu@e774 {
>> + compatible = "renesas,ipmmu-r8a77980";
>> + reg = <0 0xe774 0 0x1000>;
>> + renesas,ipmmu-main = <_mm 0>;
>> + power-domains = < R8A77980_PD_ALWAYS_ON>;
>> + #iommu-cells = <1>;
>> + };
>> +
>> + ipmmu_ir: mmu@ff8b {
>> + compatible = "renesas,ipmmu-r8a77980";
>> + reg = <0 0xff8b 0 0x1000>;
>> + renesas,ipmmu-main = <_mm 3>;
>> + power-domains = < R8A77980_PD_A3IR>;
>> + #iommu-cells = <1>;
>> + };
>> +
>> + ipmmu_mm: mmu@e67b {
>> + compatible = "renesas,ipmmu-r8a77980";
>> + reg = <0 0xe67b 0 0x1000>;
>> + interrupts = ,
>> +  ;
>> + power-domains = < R8A77980_PD_ALWAYS_ON>;
>> + #iommu-cells = <1>;
>> + };
>> +
>> + ipmmu_rt: mmu@ffc8 {
>> + compatible = "renesas,ipmmu-r8a77980";
>> + reg = <0 0xffc8 0 0x1000>;
>> + renesas,ipmmu-main = <_mm 10>;
>> + power-domains = < R8A77980_PD_ALWAYS_ON>;
>> + #iommu-cells = <1>;
>> + };
>> +
>> + ipmmu_vc0: mmu@fe6b {
>> + compatible = "renesas,ipmmu-r8a77980";
>> + reg = <0 0xfe6b 0 0x1000>;
>> + renesas,ipmmu-main = <_mm 12>;
>> + power-domains = < R8A77980_PD_ALWAYS_ON>;
>> + #iommu-cells = <1>;
>> + };
>> +
>> + ipmmu_vi0: mmu@febd {
>> + compatible = "renesas,ipmmu-r8a77980";
>> + reg = <0 0xfebd 0 0x1000>;
>> + renesas,ipmmu-main = <_mm 14>;
>> + power-domains = < R8A77980_PD_ALWAYS_ON>;
>> + #iommu-cells = <1>;
>> + };
>> +
>
> nit: I believe the IPMMU nodes should go above the AVB rather than the
> MMC node to preserve the current node sorting order of:
>
> 1) bus address
> 2) IP block
> 3) alphabetical

Will reposition the IPMMU nodes in next version. Will also add vip0
and vip1 IPMMU nodes as described in the 1.0 data sheet.

Thanks,

/ magnus

Re: [PATCH v6 6/6] clk: renesas: Renesas RZ/N1 clock driver

[kbuild test robot]

Hi Michel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20180517]
[also build test WARNING on v4.17-rc6]
[cannot apply to robh/for-next renesas-drivers/clk-renesas renesas/devel 
v4.17-rc6 v4.17-rc5 v4.17-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Michel-Pollet/arm-Base-support-for-Renesas-RZN1D-DB-Board/20180524-052042
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/clk/renesas/rzn1-clocks.c:270:22: sparse: cast removes address space 
>> of expression
>> drivers/clk/renesas/rzn1-clocks.c:271:29: sparse: incorrect type in argument 
>> 1 (different address spaces) @@expected unsigned int [noderef] 
>> [usertype] *reg @@got eref] [usertype] *reg @@
   drivers/clk/renesas/rzn1-clocks.c:271:29:expected unsigned int [noderef] 
[usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:271:29:got unsigned int [usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:274:25: sparse: incorrect type in argument 
2 (different address spaces) @@expected unsigned int [noderef] [usertype] 
*reg @@got eref] [usertype] *reg @@
   drivers/clk/renesas/rzn1-clocks.c:274:25:expected unsigned int [noderef] 
[usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:274:25:got unsigned int [usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:281:22: sparse: cast removes address space 
of expression
   drivers/clk/renesas/rzn1-clocks.c:282:29: sparse: incorrect type in argument 
1 (different address spaces) @@expected unsigned int [noderef] [usertype] 
*reg @@got eref] [usertype] *reg @@
   drivers/clk/renesas/rzn1-clocks.c:282:29:expected unsigned int [noderef] 
[usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:282:29:got unsigned int [usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:430:22: sparse: cast removes address space 
of expression
   drivers/clk/renesas/rzn1-clocks.c:431:30: sparse: incorrect type in argument 
1 (different address spaces) @@expected unsigned int [noderef] [usertype] 
*reg @@got eref] [usertype] *reg @@
   drivers/clk/renesas/rzn1-clocks.c:431:30:expected unsigned int [noderef] 
[usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:431:30:got unsigned int [usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:516:22: sparse: cast removes address space 
of expression
   drivers/clk/renesas/rzn1-clocks.c:528:38: sparse: incorrect type in argument 
2 (different address spaces) @@expected unsigned int [noderef] [usertype] 
*reg @@got eref] [usertype] *reg @@
   drivers/clk/renesas/rzn1-clocks.c:528:38:expected unsigned int [noderef] 
[usertype] *reg
   drivers/clk/renesas/rzn1-clocks.c:528:38:got unsigned int [usertype] *reg

vim +270 drivers/clk/renesas/rzn1-clocks.c

   264  
   265  /* register/bit pairs are encoded as an uint16_t */
   266  static void clk_rdesc_set(
   267  struct rzn1_priv *clocks,
   268  uint16_t one, unsigned int on)
   269  {
 > 270  u32 *reg = ((u32 *)clocks->reg) + (one >> 5);
 > 271  u32 val = clk_readl(reg);
   272  
   273  val = (val & ~(1U << (one & 0x1f))) | ((!!on) << (one & 0x1f));
   274  clk_writel(val, reg);
   275  }
   276  

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

Re: [PATCH v6 5/6] ARM: dts: Renesas RZN1D-DB Board base file

[kbuild test robot]

Hi Michel,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20180517]
[also build test ERROR on v4.17-rc6]
[cannot apply to robh/for-next renesas-drivers/clk-renesas renesas/devel 
v4.17-rc6 v4.17-rc5 v4.17-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Michel-Pollet/arm-Base-support-for-Renesas-RZN1D-DB-Board/20180524-052042
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   In file included from arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts:11:0:
>> arch/arm/boot/dts/r9a06g032.dtsi:10:10: fatal error: 
>> dt-bindings/clock/rzn1-clock.h: No such file or directory
#include 
 ^~~~
   compilation terminated.

vim +10 arch/arm/boot/dts/r9a06g032.dtsi

f9ea3b52 Michel Pollet 2018-05-22 @10  #include 
f9ea3b52 Michel Pollet 2018-05-22  11  

:: The code at line 10 was first introduced by commit
:: f9ea3b52d31219bb2ad77f919417ed61fc779fcb ARM: dts: Renesas RZ/N1 SoC 
base device tree file

:: TO: Michel Pollet 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

Re: [PATCH v3 2/9] media: rcar-vin: Remove two empty lines

[Niklas Söderlund]

Hi Jacopo,

Thanks for your work.

On 2018-05-18 16:40:38 +0200, Jacopo Mondi wrote:
> Remove un-necessary empty lines.
> 
> Signed-off-by: Jacopo Mondi 

Acked-by: Niklas Söderlund 

> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index 6b80f98..1aadd90 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -707,11 +707,9 @@ static int rvin_mc_parse_of_endpoint(struct device *dev,
>   return -EINVAL;
>  
>   if (!of_device_is_available(to_of_node(asd->match.fwnode))) {
> -
>   vin_dbg(vin, "OF device %pOF disabled, ignoring\n",
>   to_of_node(asd->match.fwnode));
>   return -ENOTCONN;
> -
>   }
>  
>   if (vin->group->csi[vep->base.id].fwnode) {
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v3 1/9] media: rcar-vin: Rename 'digital' to 'parallel'

[Niklas Söderlund]

Hi Jacopo,

Thanks for your patch.

On 2018-05-18 16:40:37 +0200, Jacopo Mondi wrote:
> As the term 'digital' is used all over the rcar-vin code in place of
> 'parallel', rename all the occurrencies.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 72 
> ++---
>  drivers/media/platform/rcar-vin/rcar-dma.c  |  4 +-
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 12 ++---
>  drivers/media/platform/rcar-vin/rcar-vin.h  |  6 +--
>  4 files changed, 47 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index d3072e1..6b80f98 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -376,12 +376,12 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
> direction)
>  }
>  
>  /* 
> -
> - * Digital async notifier
> + * Parallel async notifier
>   */
>  
>  /* The vin lock should be held when calling the subdevice attach and detach 
> */
> -static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
> -  struct v4l2_subdev *subdev)
> +static int rvin_parallel_subdevice_attach(struct rvin_dev *vin,
> +   struct v4l2_subdev *subdev)
>  {
>   struct v4l2_subdev_mbus_code_enum code = {
>   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> @@ -392,15 +392,15 @@ static int rvin_digital_subdevice_attach(struct 
> rvin_dev *vin,
>   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
>   if (ret < 0)
>   return ret;
> - vin->digital->source_pad = ret;
> + vin->parallel->source_pad = ret;
>  
>   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> - vin->digital->sink_pad = ret < 0 ? 0 : ret;
> + vin->parallel->sink_pad = ret < 0 ? 0 : ret;
>  
>   /* Find compatible subdevices mbus format */
>   vin->mbus_code = 0;
>   code.index = 0;
> - code.pad = vin->digital->source_pad;
> + code.pad = vin->parallel->source_pad;
>   while (!vin->mbus_code &&
>  !v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
>   code.index++;
> @@ -450,21 +450,21 @@ static int rvin_digital_subdevice_attach(struct 
> rvin_dev *vin,
>  
>   vin->vdev.ctrl_handler = >ctrl_handler;
>  
> - vin->digital->subdev = subdev;
> + vin->parallel->subdev = subdev;
>  
>   return 0;
>  }
>  
> -static void rvin_digital_subdevice_detach(struct rvin_dev *vin)
> +static void rvin_parallel_subdevice_detach(struct rvin_dev *vin)
>  {
>   rvin_v4l2_unregister(vin);
>   v4l2_ctrl_handler_free(>ctrl_handler);
>  
>   vin->vdev.ctrl_handler = NULL;
> - vin->digital->subdev = NULL;
> + vin->parallel->subdev = NULL;
>  }
>  
> -static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
> +static int rvin_parallel_notify_complete(struct v4l2_async_notifier 
> *notifier)
>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>   int ret;
> @@ -478,28 +478,28 @@ static int rvin_digital_notify_complete(struct 
> v4l2_async_notifier *notifier)
>   return rvin_v4l2_register(vin);
>  }
>  
> -static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
> -struct v4l2_subdev *subdev,
> -struct v4l2_async_subdev *asd)
> +static void rvin_parallel_notify_unbind(struct v4l2_async_notifier *notifier,
> + struct v4l2_subdev *subdev,
> + struct v4l2_async_subdev *asd)

When I run my indentation script this indentation changes from spaces to 
all tabs. If possible I would like to keep that as I usually run it on 
these files before submitting any patches, but it's not a big deal.

Whit this fixed, thanks for clearing this up!

Acked-by: Niklas Söderlund 

>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>  
> - vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
> + vin_dbg(vin, "unbind parallel subdev %s\n", subdev->name);
>  
>   mutex_lock(>lock);
> - rvin_digital_subdevice_detach(vin);
> + rvin_parallel_subdevice_detach(vin);
>   mutex_unlock(>lock);
>  }
>  
> -static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
> -  struct v4l2_subdev *subdev,
> -  struct v4l2_async_subdev *asd)
> +static int rvin_parallel_notify_bound(struct v4l2_async_notifier *notifier,
> +   struct v4l2_subdev *subdev,
> +   struct v4l2_async_subdev *asd)
>  {
>   struct rvin_dev *vin = notifier_to_vin(notifier);
>   int ret;
>  
>   mutex_lock(>lock);
> - 

Re: [PATCH 1/4] PCI: rcar: Rename rcar_pcie_parse_request_of_pci_ranges()

[Bjorn Helgaas]

On Wed, May 23, 2018 at 07:05:06PM +0200, Marek Vasut wrote:
> On 05/23/2018 06:17 PM, Lorenzo Pieralisi wrote:
> > On Mon, May 21, 2018 at 03:11:20PM +0200, Marek Vasut wrote:
> >> The function name is just too confusing, rename it, no functional change.
> >> Rename the function to rcar_pcie_alloc_and_parse_pci_resource_list() as
> >> it's matching failpath function is pci_free_resource_list() so the names
> >> align much better and the new name also describes what the function does
> >> much better.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Geert Uytterhoeven 
> >> Cc: Phil Edworthy 
> >> Cc: Simon Horman 
> >> Cc: Wolfram Sang 
> >> Cc: linux-renesas-soc@vger.kernel.org
> >> ---
> >>  drivers/pci/host/pcie-rcar.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Can you rebase this series against my pci/rcar branch please ?
> > 
> > I will merge it then, thanks.
> 
> Where is that tree/branch located ?
> 
> It applies fine on current next 20180517, is there a problem ?

https://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/log/?h=pci/rcar

I don't think next 20180517 includes Lorenzo's pci/rcar branch, so
there might be conflicts.  I think Stephen is on vacation until next
week, so there isn't a newer -next tree yet.

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

[Rob Herring]

On Wed, May 23, 2018 at 2:38 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Wednesday, 23 May 2018 19:29:47 EEST Rob Herring wrote:
>> On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
>> > Describe the optional endpoint properties for endpoint nodes of port@0
>> > and port@1 of the R-Car VIN driver device tree bindings documentation.
>> >
>> > Signed-off-by: Jacopo Mondi 
>> > ---
>> >
>> >  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
>> >  1 file changed, 12 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > b/Documentation/devicetree/bindings/media/rcar_vin.txt index
>> > a19517e1..c53ce4e 100644
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on
>> > SoC.
>> >
>> >from external SoC pins described in video-interfaces.txt[1].
>> >Describing more then one endpoint in port 0 is invalid. Only VIN
>> >instances that are connected to external pins should have port 0.
>> >
>> > +
>> > +  - Optional properties for endpoint nodes of port@0:
>> > +- hsync-active: active state of the HSYNC signal, 0/1 for
>> > LOW/HIGH
>> > + respectively. Default is active high.
>> > +- vsync-active: active state of the VSYNC signal, 0/1 for
>> > LOW/HIGH
>> > + respectively. Default is active high.
>> > +
>> > +   If both HSYNC and VSYNC polarities are not specified, embedded
>> > +   synchronization is selected.
>>
>> No need to copy-n-paste from video-interfaces.txt. Just "see
>> video-interfaces.txt" for the description is fine.
>
> I would still explicitly list the properties that apply to this binding. I
> agree that there's no need to copy & paste the description of those properties
> though.

Yes, that's what I meant. List each property with "see
video-interfaces.txt" for the description of each.

Rob

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

[Laurent Pinchart]

Hi Rob,

On Wednesday, 23 May 2018 19:29:47 EEST Rob Herring wrote:
> On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
> > Describe the optional endpoint properties for endpoint nodes of port@0
> > and port@1 of the R-Car VIN driver device tree bindings documentation.
> > 
> > Signed-off-by: Jacopo Mondi 
> > ---
> > 
> >  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > b/Documentation/devicetree/bindings/media/rcar_vin.txt index
> > a19517e1..c53ce4e 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on
> > SoC.
> > 
> >from external SoC pins described in video-interfaces.txt[1].
> >Describing more then one endpoint in port 0 is invalid. Only VIN
> >instances that are connected to external pins should have port 0.
> > 
> > +
> > +  - Optional properties for endpoint nodes of port@0:
> > +- hsync-active: active state of the HSYNC signal, 0/1 for
> > LOW/HIGH
> > + respectively. Default is active high.
> > +- vsync-active: active state of the VSYNC signal, 0/1 for
> > LOW/HIGH
> > + respectively. Default is active high.
> > +
> > +   If both HSYNC and VSYNC polarities are not specified, embedded
> > +   synchronization is selected.
> 
> No need to copy-n-paste from video-interfaces.txt. Just "see
> video-interfaces.txt" for the description is fine.

I would still explicitly list the properties that apply to this binding. I 
agree that there's no need to copy & paste the description of those properties 
though.

> > +
> > 
> >  - port 1 - sub-nodes describing one or more endpoints connected to
> >  
> >the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> >use the following schema.
> > 
> > @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> > 
> >  - Endpoint 2 - sub-node describing the endpoint connected to
> >  CSI40
> >  - Endpoint 3 - sub-node describing the endpoint connected to
> >  CSI41
> > 
> > +  Endpoint nodes of port@1 do not support any optional endpoint
> > property. +
> > 
> >  Device node example for Gen2 platforms
> >  --
> > 
> > @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite
> > video input)> 
> >  vin1ep0: endpoint {
> >  
> >  remote-endpoint = <>;
> > 
> > -bus-width = <8>;
> > 
> >  };
> >  
> >  };
> >  
> >  };

-- 
Regards,

Laurent Pinchart

Re: [PATCH] iommu/ipmmu-vmsa: Document R-Car V3H and E3 IPMMU DT bindings

[Rob Herring]

On Mon, May 21, 2018 at 11:41:33PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Update the IPMMU DT binding documentation to include the compat strings
> for the IPMMU devices included in the R-Car V3H and E3 SoCs.
> 
> Signed-off-by: Magnus Damm 
> ---
> 
>  Developed on top of renesas-drivers-2018-05-15-v4.17-rc5
> 
>  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH 1/4] PCI: rcar: Rename rcar_pcie_parse_request_of_pci_ranges()

[Marek Vasut]

On 05/23/2018 06:17 PM, Lorenzo Pieralisi wrote:
> On Mon, May 21, 2018 at 03:11:20PM +0200, Marek Vasut wrote:
>> The function name is just too confusing, rename it, no functional change.
>> Rename the function to rcar_pcie_alloc_and_parse_pci_resource_list() as
>> it's matching failpath function is pci_free_resource_list() so the names
>> align much better and the new name also describes what the function does
>> much better.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Geert Uytterhoeven 
>> Cc: Phil Edworthy 
>> Cc: Simon Horman 
>> Cc: Wolfram Sang 
>> Cc: linux-renesas-soc@vger.kernel.org
>> ---
>>  drivers/pci/host/pcie-rcar.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Can you rebase this series against my pci/rcar branch please ?
> 
> I will merge it then, thanks.

Where is that tree/branch located ?

It applies fine on current next 20180517, is there a problem ?

-- 
Best regards,
Marek Vasut

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

[Rob Herring]

On Thu, May 17, 2018 at 01:32:12AM +0200, Niklas Söderlund wrote:
> The style for referring to ports and endpoint are wrong. Refer to them
> using lowercase and a unit address, port@x and endpoint@x.
> 
> Signed-off-by: Niklas Söderlund 
> Reported-by: Geert Uytterhoeven 
> ---
>  .../devicetree/bindings/media/rcar_vin.txt| 20 +--
>  1 file changed, 10 insertions(+), 10 deletions(-)

Reviewed-by: Rob Herring 

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

[Rob Herring]

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

This doesn't match the common property's definition which AIUI is for 
the data lines' polarity. You need a new property. Perhaps a common one.

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

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

[Rob Herring]

On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
> 
> Thanks for your work.
> 
> On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > driver and only confuse users. Remove them in all Gen2 SoC that used
> > them.
> > 
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  arch/arm/boot/dts/r8a7790-lager.dts   | 3 ---
> >  arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> >  arch/arm/boot/dts/r8a7791-porter.dts  | 1 -
> >  arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
> >  arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> >  arch/arm/boot/dts/r8a7794-silk.dts| 1 -
> >  6 files changed, 12 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> > b/arch/arm/boot/dts/r8a7790-lager.dts
> > index 063fdb6..b56b309 100644
> > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > @@ -873,10 +873,8 @@
> > port {
> > vin0ep2: endpoint {
> > remote-endpoint = <_out>;
> > -   bus-width = <24>;
> 
> I can't really make up my mind if this is a good thing or not. Device 
> tree describes the hardware and not what the drivers make use of. And 
> the fact is that this bus is 24 bits wide. So I'm not sure we should 
> remove these properties. But I would love to hear what others think 
> about this.

IMO, this property should only be present when all the pins are not 
connected. And by "all", I mean the minimum of what each end of the 
graph can support.

Rob

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

[Rob Herring]

On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
> Describe the optional endpoint properties for endpoint nodes of port@0
> and port@1 of the R-Car VIN driver device tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1..c53ce4e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>from external SoC pins described in video-interfaces.txt[1].
>Describing more then one endpoint in port 0 is invalid. Only VIN
>instances that are connected to external pins should have port 0.
> +
> +  - Optional properties for endpoint nodes of port@0:
> +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> +   respectively. Default is active high.
> +
> + If both HSYNC and VSYNC polarities are not specified, embedded
> + synchronization is selected.

No need to copy-n-paste from video-interfaces.txt. Just "see 
video-interfaces.txt" for the description is fine.

> +
>  - port 1 - sub-nodes describing one or more endpoints connected to
>the VIN from local SoC CSI-2 receivers. The endpoint numbers must
>use the following schema.
> @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
>  - Endpoint 2 - sub-node describing the endpoint connected to CSI40
>  - Endpoint 3 - sub-node describing the endpoint connected to CSI41
> 
> +  Endpoint nodes of port@1 do not support any optional endpoint property.
> +
>  Device node example for Gen2 platforms
>  --
> 
> @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite 
> video input)
> 
>  vin1ep0: endpoint {
>  remote-endpoint = <>;
> -bus-width = <8>;
>  };
>  };
>  };
> --
> 2.7.4
> 

Re: [PATCH V2] mfd: dt: Add bindings for DA9063L

[Rob Herring]

On Wed, May 23, 2018 at 02:21:40PM +0200, Marek Vasut wrote:
> Add device tree bindings for the Dialog DA9063L. This is a
> variant of the DA9063 chip with smaller package, with less
> LDO regulators and without RTC block. The other properties
> of the chip are the same, including the content of the chip
> ID register.
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Lee Jones 
> Cc: Rob Herring 
> Cc: Steve Twiss 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Merge the DA9063/DA9063L regulator lists and mark DA9063-only
> regulators in that single list
> ---
>  Documentation/devicetree/bindings/mfd/da9063.txt | 32 
> +---
>  1 file changed, 17 insertions(+), 15 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH 1/4] PCI: rcar: Rename rcar_pcie_parse_request_of_pci_ranges()

[Lorenzo Pieralisi]

On Mon, May 21, 2018 at 03:11:20PM +0200, Marek Vasut wrote:
> The function name is just too confusing, rename it, no functional change.
> Rename the function to rcar_pcie_alloc_and_parse_pci_resource_list() as
> it's matching failpath function is pci_free_resource_list() so the names
> align much better and the new name also describes what the function does
> much better.
> 
> Signed-off-by: Marek Vasut 
> Cc: Geert Uytterhoeven 
> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Wolfram Sang 
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  drivers/pci/host/pcie-rcar.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Can you rebase this series against my pci/rcar branch please ?

I will merge it then, thanks.

Lorenzo

> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index e403c5206b24..dbc80e457f95 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1051,7 +1051,7 @@ static const struct of_device_id rcar_pcie_of_match[] = 
> {
>   {},
>  };
>  
> -static int rcar_pcie_parse_request_of_pci_ranges(struct rcar_pcie *pci)
> +static int rcar_pcie_alloc_and_parse_pci_resource_list(struct rcar_pcie *pci)
>  {
>   int err;
>   struct device *dev = pci->dev;
> @@ -1108,7 +1108,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>  
>   INIT_LIST_HEAD(>resources);
>  
> - err = rcar_pcie_parse_request_of_pci_ranges(pcie);
> + err = rcar_pcie_alloc_and_parse_pci_resource_list(pcie);
>   if (err)
>   goto err_free_bridge;
>  
> -- 
> 2.16.2
> 

Re: [PATCH v6 3/6] dt-bindings: clock: renesas,rzn1-clocks: document RZ/N1 clock driver

[Rob Herring]

On Wed, May 23, 2018 at 1:52 AM, M P  wrote:
> Hi Rob,
>
> On Tue, 22 May 2018 at 17:09, Rob Herring  wrote:
>
>> On Tue, May 22, 2018 at 11:01:23AM +0100, Michel Pollet wrote:
>> > The Renesas RZ/N1 Family (Part #R9A06G0xx) requires a driver
>> > to provide the SoC clock infrastructure for Linux.
>> >
>> > This documents the driver bindings.
>> >
>> > Signed-off-by: Michel Pollet 
>> > ---
>> >  .../bindings/clock/renesas,rzn1-clocks.txt | 44
> ++
>> >  1 file changed, 44 insertions(+)
>> >  create mode 100644
> Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> >
>> > diff --git
> a/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > new file mode 100644
>> > index 000..0c41137
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/clock/renesas,rzn1-clocks.txt
>> > @@ -0,0 +1,44 @@
>> > +* Renesas RZ/N1 Clock Driver
>> > +
>> > +This driver provides the clock infrastructure used by all the other
> drivers.
>
>> Bindings document h/w not drivers.
>
>> > +
>> > +One of the 'special' feature of this infrastructure is that Linux
> doesn't
>
>> Bindings are not just for Linux.
>
>> > +necessary 'own' all the clocks on the SoC, some other OS runs on
>> > +the Cortex-M3 core and that OS can access and claim it's own clocks.
>
>> How is this relevant to the binding?
>
> Well you just said it, if the binding is not just for linux, it's probably
> a good idea to mention it somewhere since I can promise you it's *not*
> documented in the hardware manual. Whatever this binding is for, it's
> relevant to point out it is different from the other clock drivers in the
> same directory... ?

That's not an uncommon issue (sometimes it's secure world that owns
the clocks, not even a different processor). I'm just not sure what I
do with this information. It doesn't tell me which clocks are owned by
the M3 or not.

>> > +
>> > +Required Properties:
>> > +
>> > +  - compatible: Must be
>> > +- "renesas,r9a06g032-clocks" for the RZ/N1D
>> > +and "renesas,rzn1-clocks" as a fallback.
>
>> Is "clocks" how the chip reference manual refers to this block?
>
> No, the block is called 'sysctrl' and has tons of other stuff in there.
> I've tried multiple times to get a 'sysctrl' driver in the previous
> versions of the patch, in various shape or form, and I can't because I'd be
> supposed to 'document' binding for stuff that has no code, no purpose, no
> testing, and have all wildly different topics. So, after some more
> lengthily discussion with Geert, we've decided to make the 'primary'
> feature of that block (clocks) as a driver, and see from there onward.

If you are referring to Geert's reply on v4, then this is not how I
interpreted it. I understood it as make the clock driver bind to the
sysctrl node and the clock driver can register other functions like
reset. Then later if you need multiple drivers, you can make an MFD
driver that binds to the sysctrl node and creates child devices to
bind sub-drivers (like clocks) to. But the DT doesn't change in the
process wrt clocks.

You don't have to have a driver for everything, but the binding should
be as complete as possible and done in an extendable way. The way you
have done it now is not. I can already see that at some point you will
want to break things and do something like this:

{
  compatible = "renesas,r9a06g032-sysctrl";
  ...
  {
compatible = "renesas,r9a06g032-clocks";
...
  };
};

Which is likely wrong because there's no need to have a child node
like that. The parent node can be the clock provider (and any other
provider). There are cases when child nodes do make sense, but we need
a more complete binding to make that decision. Evolving it one feature
at a time doesn't work.

Rob

Re: [PATCH/RFC v4 2/4] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Rob Herring]

On Wed, May 23, 2018 at 1:52 AM, Yoshihiro Shimoda
 wrote:
> Hi Rob,
>
> Thank you for the review!
>
>> From: Rob Herring, Sent: Wednesday, May 23, 2018 2:13 AM
>>
>> On Tue, May 22, 2018 at 09:01:07PM +0900, Yoshihiro Shimoda wrote:
>> > This patch adds role switch support for R-Car SoCs into the USB 3.0
>> > peripheral driver. 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 now. 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.
>> >
>> > Signed-off-by: Yoshihiro Shimoda 
>> > ---
>> >  .../devicetree/bindings/usb/renesas_usb3.txt   | 15 
>>
>> Please split bindings to a separate patch.
>
> Oops. I got it.
>
>> >  drivers/usb/gadget/udc/Kconfig |  1 +
>> >  drivers/usb/gadget/udc/renesas_usb3.c  | 82 
>> > ++
>> >  3 files changed, 98 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > index 2c071bb5..f6105aa 100644
>> > --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
>> > @@ -19,6 +19,9 @@ Required properties:
>> >  Optional properties:
>> >- phys: phandle + phy specifier pair
>> >- phy-names: must be "usb"
>> > +  - The connection to a usb3.0 host node needs by using OF graph bindings 
>> > for
>> > +usb role switch.
>> > +   - port@0 = USB3.0 host port.
>>
>> On the host side, this might conflict with the USB connector binding.
>>
>> I would either make sure this can work with the connector binding by
>> having 2 endpoints on the HS or SS port or just use the 'companion'
>> property defined in usb-generic.txt.
>
> I don't understand the first one now... This means the renesas_usb3 should 
> follow
> USB connector binding and have 2 endpoints for the usb role switch to avoid
> the conflict like below?
>  - port1@0: Super Speed (SS), present in SS capable connectors (from 
> usb-connector.txt).
>  - port1@1: USB3.0 host port.

I'm confused, SS and USB3.0 are the same essentially. It would be:

port@1/endpoint@0: SS host port
port@1/endpoint@1: SS device port

> About the 'companion' in usb-generic.txt, the property intends to be used for 
> EHCI or host side
> like the commit log [1]. If there is accept to use 'companion' for this 
> patch, I think it will
> be simple to achieve this role switch feature. However, in last month, I 
> submitted a similar patch [2]
> that has "renesas,host" property, but I got reply from Andy [3] and Heikki 
> [4]. So, I'm
> trying to improve the device connection framework [5] now.

I think this case is rare enough that we don't need a general solution
using OF graph, so I'm fine with a simple, single property to link the
2 nodes. Either reusing "companion" or "renesas,host" is fine by me.

Rob

>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/usb/generic.txt?h=v4.17-rc6=5095cb89c62acc78b4cfaeb9a4072979d010510a
>
> [2]
> https://www.spinics.net/lists/linux-usb/msg167773.html
>
> [3]
> https://www.spinics.net/lists/linux-usb/msg167780.html
>
> [4]
> https://www.spinics.net/lists/linux-usb/msg167806.html
>
> [5]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/device_connection.rst
>
> Best regards,
> Yoshihiro Shimoda
>
>> Rob

[PATCH] arm64: defconfig: Enable BD9571MWV regulator

[Geert Uytterhoeven]

From: Dien Pham 

The BD9571 PMIC is present on the Renesas Salvator-X(S) and R-Car
Starter Kit Premier/Pro development boards.

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

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 3a9096bebc74b288..8e430fce8dc97dee 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -363,6 +363,7 @@ CONFIG_MESON_WATCHDOG=m
 CONFIG_RENESAS_WDT=y
 CONFIG_UNIPHIER_WATCHDOG=y
 CONFIG_BCM2835_WDT=y
+CONFIG_MFD_BD9571MWV=y
 CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=y
@@ -375,6 +376,7 @@ CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_SEC_CORE=y
 CONFIG_REGULATOR_AXP20X=y
+CONFIG_REGULATOR_BD9571MWV=y
 CONFIG_REGULATOR_FAN53555=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
-- 
2.7.4

[git pull] pinctrl: sh-pfc: Updates for v4.18 (take two)

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit 73dacc3403436fc246258c0933e35b6e809640ac:

  pinctrl: sh-pfc: Add r8a77470 PFC support (2018-05-16 13:32:15 +0200)

are available in the git repository at:

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

for you to fetch changes up to db701f4bea09a0f9925e262753444e848c33af89:

  pinctrl: sh-pfc: rcar-gen3: Fix grammar in static pin comments (2018-05-23 
14:43:49 +0200)


pinctrl: sh-pfc: Updates for v4.18 (take two)

  - Add support for the new R-Car E3 SoC,
  - Add I2C pin groups on R-Car M3-N,
  - Small fixes and cleanups.

Thanks for pulling!


Geert Uytterhoeven (1):
  pinctrl: sh-pfc: rcar-gen3: Fix grammar in static pin comments

Niklas Söderlund (1):
  pinctrl: sh-pfc: r8a77965: Add I2C pin support

Takeshi Kihara (6):
  pinctrl: sh-pfc: Add PORT_GP_11 helper macro
  pinctrl: sh-pfc: Initial R8A77990 PFC support
  pinctrl: sh-pfc: r8a77990: Add bias pinconf support
  pinctrl: sh-pfc: r8a77990: Add SCIF pins, groups and functions
  pinctrl: sh-pfc: r8a77990: Add I2C{1,2,4,5,6,7} pins, groups and functions
  pinctrl: sh-pfc: r8a77990: Add EthernetAVB pins, groups and functions

 .../bindings/pinctrl/renesas,pfc-pinctrl.txt   |1 +
 drivers/pinctrl/sh-pfc/Kconfig |5 +
 drivers/pinctrl/sh-pfc/Makefile|1 +
 drivers/pinctrl/sh-pfc/core.c  |6 +
 drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c   |6 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c   |6 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7796.c   |6 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77965.c  |   83 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77990.c  | 2695 
 drivers/pinctrl/sh-pfc/sh_pfc.h|9 +-
 10 files changed, 2804 insertions(+), 14 deletions(-)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77990.c

Gr{oetje,eeting}s,

Geert

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

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

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

[Yoshihiro Kaneko]

From: Takeshi Kihara 

Add a device node for the Watchdog Timer (WDT) controller on the Renesas
R-Car M3N (R8A77965) SoC.

Based on a similar patch of the R8A7796 device tree
by Geert Uytterhoeven .

Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Kaneko 
---

This patch is based on the devel branch of Simon Horman's renesas tree.

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

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 486aeca..fb7100f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -139,8 +139,13 @@
ranges;
 
wdt0: watchdog@e602 {
+   compatible = "renesas,r8a77965-wdt",
+"renesas,rcar-gen3-wdt";
reg = <0 0xe602 0 0x0c>;
-   /* placeholder */
+   clocks = < CPG_MOD 402>;
+   power-domains = < R8A77965_PD_ALWAYS_ON>;
+   resets = < 402>;
+   status = "disabled";
};
 
gpio0: gpio@e605 {
-- 
1.9.1

Re: [PATCH V2] mfd: dt: Add bindings for DA9063L

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 2:21 PM, Marek Vasut  wrote:
> Add device tree bindings for the Dialog DA9063L. This is a
> variant of the DA9063 chip with smaller package, with less
> LDO regulators and without RTC block. The other properties
> of the chip are the same, including the content of the chip
> ID register.
>
> Signed-off-by: Marek Vasut 

(again)
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Marek Vasut]

On 05/23/2018 01:55 PM, Geert Uytterhoeven wrote:
> On Wed, May 23, 2018 at 1:42 PM, Marek Vasut  wrote:
>> The model number stored in the struct da9063 is the same for all
>> variants of the da9063 since it is the chip ID, which is always
>> the same. Replace that with a separate identifier instead, which
>> allows us to discern the DA9063 variants by setting the type
>> based on either DT match or otherwise.
>>
>> Signed-off-by: Marek Vasut 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
>> --- a/drivers/mfd/da9063-i2c.c
>> +++ b/drivers/mfd/da9063-i2c.c
>> @@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>> i2c_set_clientdata(i2c, da9063);
>> da9063->dev = >dev;
>> da9063->chip_irq = i2c->irq;
>> +   da9063->type = (enum da9063_type)id->driver_data;
> 
> Nit: I think this cast (from unsigned long) is not needed.

Dropped

-- 
Best regards,
Marek Vasut

Re: [PATCH] mfd: dt: Add bindings for DA9063L

[Marek Vasut]

On 05/23/2018 02:08 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Wed, May 23, 2018 at 1:26 PM, Marek Vasut  wrote:
>> Add device tree bindings for the Dialog DA9063L. This is a
>> variant of the DA9063 chip with smaller package, with less
>> LDO regulators and without RTC block. The other properties
>> of the chip are the same, including the content of the chip
>> ID register.
>>
>> Signed-off-by: Marek Vasut 
> 
> Thanks for your patch!
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> Minor nit below.
> 
>> --- a/Documentation/devicetree/bindings/mfd/da9063.txt
>> +++ b/Documentation/devicetree/bindings/mfd/da9063.txt
> 
>> @@ -6,14 +6,14 @@ Device   Supply NamesDescription
>>  --   ---
>>  da9063-regulator:   : LDOs & BUCKs
>>  da9063-onkey:   : On Key
>> -da9063-rtc  :   : Real-Time Clock
>> +da9063-rtc  :   : Real-Time Clock (DA9063 only)
>>  da9063-watchdog :   : Watchdog
>>
>>  ==
>>
>>  Required properties:
>>
>> -- compatible : Should be "dlg,da9063"
>> +- compatible : Should be "dlg,da9063" or "dlg,da9063l"
>>  - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
>>modified to match the chip's OTP settings).
>>  - interrupt-parent : Specifies the reference to the interrupt controller for
>> @@ -23,8 +23,8 @@ Required properties:
>>
>>  Sub-nodes:
>>
>> -- regulators : This node defines the settings for the LDOs and BUCKs. The
>> -  DA9063 regulators are bound using their names listed below:
>> +- regulators : This node defines the settings for the LDOs and BUCKs.
>> +  The DA9063 regulators are bound using their names listed below:
>>
>>  bcore1: BUCK CORE1
>>  bcore2: BUCK CORE2
>> @@ -44,13 +44,28 @@ Sub-nodes:
>>  ldo10 : LDO_10
>>  ldo11 : LDO_11
>>
>> +  The DA9063L regulators are bound using their names listed below:
>> +
>> +bcore1: BUCK CORE1
>> +bcore2: BUCK CORE2
>> +bpro  : BUCK PRO
>> +bmem  : BUCK MEM
>> +bio   : BUCK IO
>> +bperi : BUCK PERI
>> +ldo3  : LDO_3
>> +ldo7  : LDO_7
>> +ldo8  : LDO_8
>> +ldo9  : LDO_9
>> +ldo11 : LDO_11
>> +
> 
> As an alternative to having two lists, perhaps you can use a table, or
> mark entries "(DA9063 only)", like you did for da9063-rtc above?
> That makes it easier to see the differences.

Let's try that in V2

-- 
Best regards,
Marek Vasut

[PATCH V2] mfd: dt: Add bindings for DA9063L

[Marek Vasut]

Add device tree bindings for the Dialog DA9063L. This is a
variant of the DA9063 chip with smaller package, with less
LDO regulators and without RTC block. The other properties
of the chip are the same, including the content of the chip
ID register.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
Cc: Rob Herring 
Cc: Steve Twiss 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
V2: Merge the DA9063/DA9063L regulator lists and mark DA9063-only
regulators in that single list
---
 Documentation/devicetree/bindings/mfd/da9063.txt | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt 
b/Documentation/devicetree/bindings/mfd/da9063.txt
index 05b21bcb8543..443e68286957 100644
--- a/Documentation/devicetree/bindings/mfd/da9063.txt
+++ b/Documentation/devicetree/bindings/mfd/da9063.txt
@@ -1,4 +1,4 @@
-* Dialog DA9063 Power Management Integrated Circuit (PMIC)
+* Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC)
 
 DA9093 consists of a large and varied group of sub-devices (I2C Only):
 
@@ -6,14 +6,14 @@ Device   Supply NamesDescription
 --   ---
 da9063-regulator:   : LDOs & BUCKs
 da9063-onkey:   : On Key
-da9063-rtc  :   : Real-Time Clock
+da9063-rtc  :   : Real-Time Clock (DA9063 only)
 da9063-watchdog :   : Watchdog
 
 ==
 
 Required properties:
 
-- compatible : Should be "dlg,da9063"
+- compatible : Should be "dlg,da9063" or "dlg,da9063l"
 - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
   modified to match the chip's OTP settings).
 - interrupt-parent : Specifies the reference to the interrupt controller for
@@ -23,8 +23,8 @@ Required properties:
 
 Sub-nodes:
 
-- regulators : This node defines the settings for the LDOs and BUCKs. The
-  DA9063 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+  The DA9063(L) regulators are bound using their names listed below:
 
 bcore1: BUCK CORE1
 bcore2: BUCK CORE2
@@ -32,16 +32,16 @@ Sub-nodes:
 bmem  : BUCK MEM
 bio   : BUCK IO
 bperi : BUCK PERI
-ldo1  : LDO_1
-ldo2  : LDO_2
+ldo1  : LDO_1  (DA9063 only)
+ldo2  : LDO_2  (DA9063 only)
 ldo3  : LDO_3
-ldo4  : LDO_4
-ldo5  : LDO_5
-ldo6  : LDO_6
+ldo4  : LDO_4  (DA9063 only)
+ldo5  : LDO_5  (DA9063 only)
+ldo6  : LDO_6  (DA9063 only)
 ldo7  : LDO_7
 ldo8  : LDO_8
 ldo9  : LDO_9
-ldo10 : LDO_10
+ldo10 : LDO_10 (DA9063 only)
 ldo11 : LDO_11
 
   The component follows the standard regulator framework and the bindings
@@ -49,8 +49,9 @@ Sub-nodes:
   Documentation/devicetree/bindings/regulator/regulator.txt
 
 - rtc : This node defines settings for the Real-Time Clock associated with
-  the DA9063. There are currently no entries in this binding, however
-  compatible = "dlg,da9063-rtc" should be added if a node is created.
+  the DA9063 only. The RTC is not present in DA9063L. There are currently
+  no entries in this binding, however compatible = "dlg,da9063-rtc" should
+  be added if a node is created.
 
 - onkey : This node defines the OnKey settings for controlling the key
   functionality of the device. The node should contain the compatible property
@@ -65,8 +66,9 @@ Sub-nodes:
 and KEY_SLEEP.
 
 - watchdog : This node defines settings for the Watchdog timer associated
-  with the DA9063. There are currently no entries in this binding, however
-  compatible = "dlg,da9063-watchdog" should be added if a node is created.
+  with the DA9063 and DA9063L. There are currently no entries in this
+  binding, however compatible = "dlg,da9063-watchdog" should be added
+  if a node is created.
 
 
 Example:
-- 
2.16.2

Re: [PATCH] mfd: dt: Add bindings for DA9063L

[Geert Uytterhoeven]

Hi Marek,

On Wed, May 23, 2018 at 1:26 PM, Marek Vasut  wrote:
> Add device tree bindings for the Dialog DA9063L. This is a
> variant of the DA9063 chip with smaller package, with less
> LDO regulators and without RTC block. The other properties
> of the chip are the same, including the content of the chip
> ID register.
>
> Signed-off-by: Marek Vasut 

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven 

Minor nit below.

> --- a/Documentation/devicetree/bindings/mfd/da9063.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9063.txt

> @@ -6,14 +6,14 @@ Device   Supply NamesDescription
>  --   ---
>  da9063-regulator:   : LDOs & BUCKs
>  da9063-onkey:   : On Key
> -da9063-rtc  :   : Real-Time Clock
> +da9063-rtc  :   : Real-Time Clock (DA9063 only)
>  da9063-watchdog :   : Watchdog
>
>  ==
>
>  Required properties:
>
> -- compatible : Should be "dlg,da9063"
> +- compatible : Should be "dlg,da9063" or "dlg,da9063l"
>  - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
>modified to match the chip's OTP settings).
>  - interrupt-parent : Specifies the reference to the interrupt controller for
> @@ -23,8 +23,8 @@ Required properties:
>
>  Sub-nodes:
>
> -- regulators : This node defines the settings for the LDOs and BUCKs. The
> -  DA9063 regulators are bound using their names listed below:
> +- regulators : This node defines the settings for the LDOs and BUCKs.
> +  The DA9063 regulators are bound using their names listed below:
>
>  bcore1: BUCK CORE1
>  bcore2: BUCK CORE2
> @@ -44,13 +44,28 @@ Sub-nodes:
>  ldo10 : LDO_10
>  ldo11 : LDO_11
>
> +  The DA9063L regulators are bound using their names listed below:
> +
> +bcore1: BUCK CORE1
> +bcore2: BUCK CORE2
> +bpro  : BUCK PRO
> +bmem  : BUCK MEM
> +bio   : BUCK IO
> +bperi : BUCK PERI
> +ldo3  : LDO_3
> +ldo7  : LDO_7
> +ldo8  : LDO_8
> +ldo9  : LDO_9
> +ldo11 : LDO_11
> +

As an alternative to having two lists, perhaps you can use a table, or
mark entries "(DA9063 only)", like you did for da9063-rtc above?
That makes it easier to see the differences.

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 6/6] mfd: da9063: Add DA9063L support

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut  wrote:
> Add support for DA9063L, which is a reduced variant of the DA9063
> with less regulators and without RTC.
>
> Signed-off-by: Marek Vasut 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut  wrote:
> Move the LDOs present only on DA9063 at the end of the list, so that
> the DA9063L can simply indicate less LDOs and still share the list of
> regulators with DA9063.
>
> Signed-off-by: Marek Vasut 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut  wrote:
> The DA9063L does not contain RTC block, unlike the full DA9063.
> Do not allow binding RTC driver on this variant of the chip.
>
> Signed-off-by: Marek Vasut 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/6] mfd: da9063: Add DA9063L type

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut  wrote:
> Add type for DA9063L, which is a reduced variant of the DA9063
> without RTC block and with less regulators.
>
> Signed-off-by: Marek Vasut 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut  wrote:
> The model number stored in the struct da9063 is the same for all
> variants of the da9063 since it is the chip ID, which is always
> the same. Replace that with a separate identifier instead, which
> allows us to discern the DA9063 variants by setting the type
> based on either DT match or otherwise.
>
> Signed-off-by: Marek Vasut 

Reviewed-by: Geert Uytterhoeven 

> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
> i2c_set_clientdata(i2c, da9063);
> da9063->dev = >dev;
> da9063->chip_irq = i2c->irq;
> +   da9063->type = (enum da9063_type)id->driver_data;

Nit: I think this cast (from unsigned long) is not needed.

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] ARM: dts: porter: Add missing PMIC nodes

[Marek Vasut]

On 05/23/2018 01:52 PM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

> On Wed, May 23, 2018 at 1:43 PM, Marek Vasut  wrote:
>> Add PMIC nodes to Porter and connect CPU DVFS supply. There is
>> one DA9063L and one DA9210 on Porter, the only difference from
>> the other boards is that DA9063L is at I2C address 0x5a rather
>> than 0x58 .
> 
> Ah, so porter needs the regulator quirk, too.

Most of the boards do in fact, they just miss the regulator nodes.
Silk to from what I can test locally.

>> Signed-off-by: Marek Vasut 
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file

[M P]

Hi Geert,

On Wed, 23 May 2018 at 12:18, Geert Uytterhoeven 
wrote:

> Hi Michel,

> On Wed, May 23, 2018 at 11:20 AM, M P  wrote:
> > On Wed, 23 May 2018 at 10:12, Geert Uytterhoeven 
> > wrote:
> >> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
> >>  wrote:
> >> > +   #address-cells = <1>;
> >> > +   #size-cells = <1>;
> >> > +
> >> > +   cpus {
> >> > +   #address-cells = <1>;
> >> > +   #size-cells = <0>;
> >> > +   clocks = < RZN1_DIV_CA7>;
> >
> >> I think the clocks property should be moved to the individual CPU
nodes.
> >
> > Ah, I had a look around, and I found some instances that are in the cpu
> > sub-node, and others that are not -- it seems that having it in the cpu
> > sub-node would implies it's core specific... here if that clock is
changed
> > both cores would change speed...

> Assumed the driver code knows to look in the parent node, which I doubt
> the cpufreq code does.

> > Either way, it's not used by the kernel in any way at the moment -- I
had
> > hoped cpufreq or something would claim it, but it's not the case.

> I guess you have to add your main SoC compatible value to the whitelist
> in drivers/cpufreq/cpufreq-dt-platdev.c first.

Most excellent tip here -- I'll add a further patch to enable this, after
this series eventually gets merged...

Cheers,
Michel

Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut  wrote:
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value
> of chip ID register of DA9063L though, so drop the enum as all the
> DA9063 "models" share the same chip ID and thus the distinction will
> have to be made using DT or otherwise.
>
> Signed-off-by: Marek Vasut 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] ARM: dts: porter: Add missing PMIC nodes

[Geert Uytterhoeven]

Hi Marek,

On Wed, May 23, 2018 at 1:43 PM, Marek Vasut  wrote:
> Add PMIC nodes to Porter and connect CPU DVFS supply. There is
> one DA9063L and one DA9210 on Porter, the only difference from
> the other boards is that DA9063L is at I2C address 0x5a rather
> than 0x58 .

Ah, so porter needs the regulator quirk, too.

> Signed-off-by: Marek Vasut 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Mark Brown]

On Wed, May 23, 2018 at 01:42:30PM +0200, Marek Vasut wrote:
> Add support for DA9063L, which is a reduced variant of the DA9063
> with less regulators and without RTC.

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Mark Brown]

On Wed, May 23, 2018 at 01:42:26PM +0200, Marek Vasut wrote:
> The model number stored in the struct da9063 is the same for all
> variants of the da9063 since it is the chip ID, which is always
> the same. Replace that with a separate identifier instead, which

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

[Mark Brown]

On Wed, May 23, 2018 at 01:42:29PM +0200, Marek Vasut wrote:
> Move the LDOs present only on DA9063 at the end of the list, so that
> the DA9063L can simply indicate less LDOs and still share the list of
> regulators with DA9063.

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[Mark Brown]

On Wed, May 23, 2018 at 01:42:25PM +0200, Marek Vasut wrote:
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value
> of chip ID register of DA9063L though, so drop the enum as all the

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

[PATCH] ARM: dts: porter: Add missing PMIC nodes

[Marek Vasut]

Add PMIC nodes to Porter and connect CPU DVFS supply. There is
one DA9063L and one DA9210 on Porter, the only difference from
the other boards is that DA9063L is at I2C address 0x5a rather
than 0x58 .

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Kuninori Morimoto 
Cc: Simon Horman 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 arch/arm/boot/dts/r8a7791-porter.dts | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index a01101b49d99..5f77d73d7462 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -375,10 +375,43 @@
clock-frequency = <40>;
 };
 
+ {
+   status = "okay";
+   clock-frequency = <10>;
+
+   pmic@5a {
+   compatible = "dlg,da9063l";
+   reg = <0x5a>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+
+   wdt {
+   compatible = "dlg,da9063-watchdog";
+   };
+   };
+
+   vdd_dvfs: regulator@68 {
+   compatible = "dlg,da9210";
+   reg = <0x68>;
+   interrupt-parent = <>;
+   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
  {
status = "okay";
 };
 
+ {
+   cpu0-supply = <_dvfs>;
+};
+
 /* composite video input */
  {
status = "okay";
-- 
2.16.2

[PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

[Marek Vasut]

Move the LDOs present only on DA9063 at the end of the list, so that
the DA9063L can simply indicate less LDOs and still share the list of
regulators with DA9063.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
Cc: Mark Brown 
Cc: Steve Twiss 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/regulator/da9063-regulator.c | 76 +---
 1 file changed, 45 insertions(+), 31 deletions(-)

diff --git a/drivers/regulator/da9063-regulator.c 
b/drivers/regulator/da9063-regulator.c
index 9b5c28392ae6..92569bed24b9 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -529,6 +529,32 @@ static const struct da9063_regulator_info 
da9063_regulator_info[] = {
.ilimit = BFIELD(DA9063_REG_BUCK_ILIM_A,
 DA9063_BMEM_ILIM_MASK),
},
+   {
+   DA9063_LDO(DA9063, LDO3, 900, 20, 3440),
+   .suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO3_SEL),
+   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO3_LIM),
+   },
+   {
+   DA9063_LDO(DA9063, LDO7, 900, 50, 3600),
+   .suspend = BFIELD(DA9063_REG_LDO7_CONT, DA9063_VLDO7_SEL),
+   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO7_LIM),
+   },
+   {
+   DA9063_LDO(DA9063, LDO8, 900, 50, 3600),
+   .suspend = BFIELD(DA9063_REG_LDO8_CONT, DA9063_VLDO8_SEL),
+   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO8_LIM),
+   },
+   {
+   DA9063_LDO(DA9063, LDO9, 950, 50, 3600),
+   .suspend = BFIELD(DA9063_REG_LDO9_CONT, DA9063_VLDO9_SEL),
+   },
+   {
+   DA9063_LDO(DA9063, LDO11, 900, 50, 3600),
+   .suspend = BFIELD(DA9063_REG_LDO11_CONT, DA9063_VLDO11_SEL),
+   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO11_LIM),
+   },
+
+   /* The following LDOs are present only on DA9063, not on DA9063L */
{
DA9063_LDO(DA9063, LDO1, 600, 20, 1860),
.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO1_SEL),
@@ -537,11 +563,6 @@ static const struct da9063_regulator_info 
da9063_regulator_info[] = {
DA9063_LDO(DA9063, LDO2, 600, 20, 1860),
.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO2_SEL),
},
-   {
-   DA9063_LDO(DA9063, LDO3, 900, 20, 3440),
-   .suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO3_SEL),
-   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO3_LIM),
-   },
{
DA9063_LDO(DA9063, LDO4, 900, 20, 3440),
.suspend = BFIELD(DA9063_REG_DVC_2, DA9063_VLDO4_SEL),
@@ -555,29 +576,11 @@ static const struct da9063_regulator_info 
da9063_regulator_info[] = {
DA9063_LDO(DA9063, LDO6, 900, 50, 3600),
.suspend = BFIELD(DA9063_REG_LDO6_CONT, DA9063_VLDO6_SEL),
},
-   {
-   DA9063_LDO(DA9063, LDO7, 900, 50, 3600),
-   .suspend = BFIELD(DA9063_REG_LDO7_CONT, DA9063_VLDO7_SEL),
-   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO7_LIM),
-   },
-   {
-   DA9063_LDO(DA9063, LDO8, 900, 50, 3600),
-   .suspend = BFIELD(DA9063_REG_LDO8_CONT, DA9063_VLDO8_SEL),
-   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO8_LIM),
-   },
-   {
-   DA9063_LDO(DA9063, LDO9, 950, 50, 3600),
-   .suspend = BFIELD(DA9063_REG_LDO9_CONT, DA9063_VLDO9_SEL),
-   },
+
{
DA9063_LDO(DA9063, LDO10, 900, 50, 3600),
.suspend = BFIELD(DA9063_REG_LDO10_CONT, DA9063_VLDO10_SEL),
},
-   {
-   DA9063_LDO(DA9063, LDO11, 900, 50, 3600),
-   .suspend = BFIELD(DA9063_REG_LDO11_CONT, DA9063_VLDO11_SEL),
-   .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO11_LIM),
-   },
 };
 
 /* Link chip model with regulators info table */
@@ -587,6 +590,11 @@ static struct da9063_dev_model regulators_models[] = {
.n_regulators = ARRAY_SIZE(da9063_regulator_info),
.type = PMIC_TYPE_DA9063,
},
+   {
+   .regulator_info = da9063_regulator_info,
+   .n_regulators = ARRAY_SIZE(da9063_regulator_info) - 6,
+   .type = PMIC_TYPE_DA9063L,
+   },
{ }
 };
 
@@ -641,28 +649,34 @@ static struct of_regulator_match da9063_matches[] = {
[DA9063_ID_BPERI]= { .name = "bperi",   },
[DA9063_ID_BCORES_MERGED]= { .name = "bcores-merged"},
[DA9063_ID_BMEM_BIO_MERGED]  = { .name = "bmem-bio-merged", },
+   [DA9063_ID_LDO3] = { .name = "ldo3",},
+   

[PATCH 6/6] mfd: da9063: Add DA9063L support

[Marek Vasut]

Add support for DA9063L, which is a reduced variant of the DA9063
with less regulators and without RTC.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
Cc: Mark Brown 
Cc: Steve Twiss 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/mfd/da9063-i2c.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 5544ce8e3363..84bbd2bbcd2a 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config = {
 
 static const struct of_device_id da9063_dt_ids[] = {
{ .compatible = "dlg,da9063", },
+   { .compatible = "dlg,da9063l", },
{ }
 };
 MODULE_DEVICE_TABLE(of, da9063_dt_ids);
@@ -282,6 +283,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
 
 static const struct i2c_device_id da9063_i2c_id[] = {
{ "da9063", PMIC_TYPE_DA9063 },
+   { "da9063l", PMIC_TYPE_DA9063L },
{},
 };
 MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
-- 
2.16.2

[PATCH 2/6] mfd: da9063: Replace model with type

[Marek Vasut]

The model number stored in the struct da9063 is the same for all
variants of the da9063 since it is the chip ID, which is always
the same. Replace that with a separate identifier instead, which
allows us to discern the DA9063 variants by setting the type
based on either DT match or otherwise.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
Cc: Mark Brown 
Cc: Steve Twiss 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/mfd/da9063-core.c| 1 -
 drivers/mfd/da9063-i2c.c | 5 +++--
 drivers/regulator/da9063-regulator.c | 6 +++---
 include/linux/mfd/da9063/core.h  | 6 +-
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 00b3caee4e21..7360b76b4f72 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -215,7 +215,6 @@ int da9063_device_init(struct da9063 *da9063, unsigned int 
irq)
return -ENODEV;
}
 
-   da9063->model = model;
da9063->variant_code = variant_code;
 
ret = da9063_irq_init(da9063);
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 7f84030c8d53..5544ce8e3363 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -236,7 +236,7 @@ static const struct of_device_id da9063_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, da9063_dt_ids);
 static int da9063_i2c_probe(struct i2c_client *i2c,
-   const struct i2c_device_id *id)
+   const struct i2c_device_id *id)
 {
struct da9063 *da9063;
int ret;
@@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, da9063);
da9063->dev = >dev;
da9063->chip_irq = i2c->irq;
+   da9063->type = (enum da9063_type)id->driver_data;
 
if (da9063->variant_code == PMIC_DA9063_AD) {
da9063_regmap_config.rd_table = _ad_readable_table;
@@ -280,7 +281,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
 }
 
 static const struct i2c_device_id da9063_i2c_id[] = {
-   { "da9063", PMIC_CHIP_ID_DA9063 },
+   { "da9063", PMIC_TYPE_DA9063 },
{},
 };
 MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
diff --git a/drivers/regulator/da9063-regulator.c 
b/drivers/regulator/da9063-regulator.c
index 87c884ae0064..9b5c28392ae6 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -98,7 +98,7 @@ struct da9063_regulator_info {
 struct da9063_dev_model {
const struct da9063_regulator_info  *regulator_info;
unsignedn_regulators;
-   unsigneddev_model;
+   enum da9063_typetype;
 };
 
 /* Single regulator settings */
@@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
{
.regulator_info = da9063_regulator_info,
.n_regulators = ARRAY_SIZE(da9063_regulator_info),
-   .dev_model = PMIC_CHIP_ID_DA9063,
+   .type = PMIC_TYPE_DA9063,
},
{ }
 };
@@ -741,7 +741,7 @@ static int da9063_regulator_probe(struct platform_device 
*pdev)
 
/* Find regulators set for particular device model */
for (model = regulators_models; model->regulator_info; model++) {
-   if (model->dev_model == da9063->model)
+   if (model->dev_model == da9063->type)
break;
}
if (!model->regulator_info) {
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index 664f650d0086..eb234582dcb2 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -31,6 +31,10 @@
 
 #define PMIC_CHIP_ID_DA90630x61
 
+enum da9063_type {
+   PMIC_TYPE_DA9063 = 0,
+};
+
 enum da9063_variant_codes {
PMIC_DA9063_AD = 0x3,
PMIC_DA9063_BB = 0x5,
@@ -76,7 +80,7 @@ enum da9063_irqs {
 struct da9063 {
/* Device */
struct device   *dev;
-   unsigned short  model;
+   enum da9063_type type;
unsigned char   variant_code;
unsigned intflags;
 
-- 
2.16.2

[PATCH 3/6] mfd: da9063: Add DA9063L type

[Marek Vasut]

Add type for DA9063L, which is a reduced variant of the DA9063
without RTC block and with less regulators.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
Cc: Mark Brown 
Cc: Steve Twiss 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 include/linux/mfd/da9063/core.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index eb234582dcb2..c3e917dd1860 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -33,6 +33,7 @@
 
 enum da9063_type {
PMIC_TYPE_DA9063 = 0,
+   PMIC_TYPE_DA9063L,
 };
 
 enum da9063_variant_codes {
-- 
2.16.2

[PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[Marek Vasut]

The PMIC_DA9063 is a complete misnomer, it denotes the value of the
DA9063 chip ID register, so rename it as such. It is also the value
of chip ID register of DA9063L though, so drop the enum as all the
DA9063 "models" share the same chip ID and thus the distinction will
have to be made using DT or otherwise.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
Cc: Mark Brown 
Cc: Steve Twiss 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/mfd/da9063-core.c| 2 +-
 drivers/mfd/da9063-i2c.c | 2 +-
 drivers/regulator/da9063-regulator.c | 2 +-
 include/linux/mfd/da9063/core.h  | 4 +---
 4 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 6c2870d4e754..00b3caee4e21 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -192,7 +192,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int 
irq)
dev_err(da9063->dev, "Cannot read chip model id.\n");
return -EIO;
}
-   if (model != PMIC_DA9063) {
+   if (model != PMIC_CHIP_ID_DA9063) {
dev_err(da9063->dev, "Invalid chip model id: 0x%02x\n", model);
return -ENODEV;
}
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 981805a2c521..7f84030c8d53 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -280,7 +280,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
 }
 
 static const struct i2c_device_id da9063_i2c_id[] = {
-   {"da9063", PMIC_DA9063},
+   { "da9063", PMIC_CHIP_ID_DA9063 },
{},
 };
 MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
diff --git a/drivers/regulator/da9063-regulator.c 
b/drivers/regulator/da9063-regulator.c
index 6a8f9cd69f52..87c884ae0064 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
{
.regulator_info = da9063_regulator_info,
.n_regulators = ARRAY_SIZE(da9063_regulator_info),
-   .dev_model = PMIC_DA9063,
+   .dev_model = PMIC_CHIP_ID_DA9063,
},
{ }
 };
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index f3ae65db4c86..664f650d0086 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -29,9 +29,7 @@
 #define DA9063_DRVNAME_RTC "da9063-rtc"
 #define DA9063_DRVNAME_VIBRATION   "da9063-vibration"
 
-enum da9063_models {
-   PMIC_DA9063 = 0x61,
-};
+#define PMIC_CHIP_ID_DA90630x61
 
 enum da9063_variant_codes {
PMIC_DA9063_AD = 0x3,
-- 
2.16.2

[PATCH] mfd: dt: Add bindings for DA9063L

[Marek Vasut]

Add device tree bindings for the Dialog DA9063L. This is a
variant of the DA9063 chip with smaller package, with less
LDO regulators and without RTC block. The other properties
of the chip are the same, including the content of the chip
ID register.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Lee Jones 
Cc: Rob Herring 
Cc: Steve Twiss 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 Documentation/devicetree/bindings/mfd/da9063.txt | 34 +---
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt 
b/Documentation/devicetree/bindings/mfd/da9063.txt
index 05b21bcb8543..a519cf0f5c8d 100644
--- a/Documentation/devicetree/bindings/mfd/da9063.txt
+++ b/Documentation/devicetree/bindings/mfd/da9063.txt
@@ -1,4 +1,4 @@
-* Dialog DA9063 Power Management Integrated Circuit (PMIC)
+* Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC)
 
 DA9093 consists of a large and varied group of sub-devices (I2C Only):
 
@@ -6,14 +6,14 @@ Device   Supply NamesDescription
 --   ---
 da9063-regulator:   : LDOs & BUCKs
 da9063-onkey:   : On Key
-da9063-rtc  :   : Real-Time Clock
+da9063-rtc  :   : Real-Time Clock (DA9063 only)
 da9063-watchdog :   : Watchdog
 
 ==
 
 Required properties:
 
-- compatible : Should be "dlg,da9063"
+- compatible : Should be "dlg,da9063" or "dlg,da9063l"
 - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
   modified to match the chip's OTP settings).
 - interrupt-parent : Specifies the reference to the interrupt controller for
@@ -23,8 +23,8 @@ Required properties:
 
 Sub-nodes:
 
-- regulators : This node defines the settings for the LDOs and BUCKs. The
-  DA9063 regulators are bound using their names listed below:
+- regulators : This node defines the settings for the LDOs and BUCKs.
+  The DA9063 regulators are bound using their names listed below:
 
 bcore1: BUCK CORE1
 bcore2: BUCK CORE2
@@ -44,13 +44,28 @@ Sub-nodes:
 ldo10 : LDO_10
 ldo11 : LDO_11
 
+  The DA9063L regulators are bound using their names listed below:
+
+bcore1: BUCK CORE1
+bcore2: BUCK CORE2
+bpro  : BUCK PRO
+bmem  : BUCK MEM
+bio   : BUCK IO
+bperi : BUCK PERI
+ldo3  : LDO_3
+ldo7  : LDO_7
+ldo8  : LDO_8
+ldo9  : LDO_9
+ldo11 : LDO_11
+
   The component follows the standard regulator framework and the bindings
   details of individual regulator device can be found in:
   Documentation/devicetree/bindings/regulator/regulator.txt
 
 - rtc : This node defines settings for the Real-Time Clock associated with
-  the DA9063. There are currently no entries in this binding, however
-  compatible = "dlg,da9063-rtc" should be added if a node is created.
+  the DA9063 only. The RTC is not present in DA9063L. There are currently
+  no entries in this binding, however compatible = "dlg,da9063-rtc" should
+  be added if a node is created.
 
 - onkey : This node defines the OnKey settings for controlling the key
   functionality of the device. The node should contain the compatible property
@@ -65,8 +80,9 @@ Sub-nodes:
 and KEY_SLEEP.
 
 - watchdog : This node defines settings for the Watchdog timer associated
-  with the DA9063. There are currently no entries in this binding, however
-  compatible = "dlg,da9063-watchdog" should be added if a node is created.
+  with the DA9063 and DA9063L. There are currently no entries in this
+  binding, however compatible = "dlg,da9063-watchdog" should be added
+  if a node is created.
 
 
 Example:
-- 
2.16.2

Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file

[Geert Uytterhoeven]

Hi Michel,

On Wed, May 23, 2018 at 11:20 AM, M P  wrote:
> On Wed, 23 May 2018 at 10:12, Geert Uytterhoeven 
> wrote:
>> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
>>  wrote:
>> > +   #address-cells = <1>;
>> > +   #size-cells = <1>;
>> > +
>> > +   cpus {
>> > +   #address-cells = <1>;
>> > +   #size-cells = <0>;
>> > +   clocks = < RZN1_DIV_CA7>;
>
>> I think the clocks property should be moved to the individual CPU nodes.
>
> Ah, I had a look around, and I found some instances that are in the cpu
> sub-node, and others that are not -- it seems that having it in the cpu
> sub-node would implies it's core specific... here if that clock is changed
> both cores would change speed...

Assumed the driver code knows to look in the parent node, which I doubt
the cpufreq code does.

> Either way, it's not used by the kernel in any way at the moment -- I had
> hoped cpufreq or something would claim it, but it's not the case.

I guess you have to add your main SoC compatible value to the whitelist
in drivers/cpufreq/cpufreq-dt-platdev.c first.

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] PCI: rcar: Teardown MSI setup if rcar_pcie_enable() fails

[Marek Vasut]

On 05/23/2018 08:18 AM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Tue, May 22, 2018 at 11:53 PM, Marek Vasut  wrote:
>> On 05/22/2018 08:36 PM, Geert Uytterhoeven wrote:
>>> On Mon, May 21, 2018 at 3:11 PM, Marek Vasut  wrote:
 --- a/drivers/pci/host/pcie-rcar.c
 +++ b/drivers/pci/host/pcie-rcar.c
 @@ -900,6 +900,28 @@ static int rcar_pcie_enable_msi(struct rcar_pcie 
 *pcie)
 return err;
  }

 +static void rcar_pcie_teardown_msi(struct rcar_pcie *pcie)
 +{
 +   struct rcar_msi *msi = >msi;
 +   int irq, i;
 +
 +   /* Disable all MSI interrupts */
 +   rcar_pci_write_reg(pcie, 0, PCIEMSIIER);
 +
 +   /* Disable address decoding of the MSI interrupt, MSIFE */
 +   rcar_pci_write_reg(pcie, 0, PCIEMSIALR);
 +
 +   free_pages(msi->pages, 0);
 +
 +   for (i = 0; i < INT_PCI_MSI_NR; i++) {
 +   irq = irq_find_mapping(msi->domain, i);
 +   if (irq > 0)
 +   irq_dispose_mapping(irq);
 +   }
>>>
>>> Note that similar calls to irq_dispose_mapping() should be added to the
>>> failure path of rcar_pcie_enable_msi(), too.
>>
>> There are no failures happening in rcar_pcie_enable_msi() after the
>> mapping is created, just memory writes, so no. Did I miss something there ?
> 
> In my copy, there are two calls to devm_request_irq(). If they fail, the
> IRQ domain is removed, but the mappings are never disposed of.

Ah, true, I'll pull out a bit of the rcar_pcie_teardown_msi and call it
in the failpath to remove the mapping. Thanks

-- 
Best regards,
Marek Vasut

Re: [PATCH] PCI: rcar: Remove IRQ mappings in rcar_pcie_enable_msi failpath

[Geert Uytterhoeven]

Hi Marek,

On Wed, May 23, 2018 at 12:52 PM, Marek Vasut  wrote:
> The rcar_pcie_enable_msi() creates IRQ mappings using irq_create_mapping()
> before requesting the IRQs using devm_request_irq(). If devm_request_irq()
> fails for some reason, rcar_pcie_enable_msi() does not remove the mapping.
>
> Pull out the code for disposing IRQ mappings from rcar_pcie_teardown_msi()
> into a separate function and call it from both rcar_pcie_teardown_msi()
> and rcar_pcie_enable_msi() failpath to remove the mappings correctly.
>
> Signed-off-by: Marek Vasut 
> Reported-by: Geert Uytterhoeven 

Thanks a lot!

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] PCI: rcar: Remove IRQ mappings in rcar_pcie_enable_msi failpath

[Marek Vasut]

The rcar_pcie_enable_msi() creates IRQ mappings using irq_create_mapping()
before requesting the IRQs using devm_request_irq(). If devm_request_irq()
fails for some reason, rcar_pcie_enable_msi() does not remove the mapping.

Pull out the code for disposing IRQ mappings from rcar_pcie_teardown_msi()
into a separate function and call it from both rcar_pcie_teardown_msi()
and rcar_pcie_enable_msi() failpath to remove the mappings correctly.

Signed-off-by: Marek Vasut 
Reported-by: Geert Uytterhoeven 
Cc: Geert Uytterhoeven 
Cc: Phil Edworthy 
Cc: Simon Horman 
Cc: Wolfram Sang 
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/pci/host/pcie-rcar.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 3aa6fe5f2d64..e738d65c22e9 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -843,6 +843,20 @@ static const struct irq_domain_ops msi_domain_ops = {
.map = rcar_msi_map,
 };
 
+static void rcar_pcie_unmap_msi(struct rcar_pcie *pcie)
+{
+   struct rcar_msi *msi = >msi;
+   int i, irq;
+
+   for (i = 0; i < INT_PCI_MSI_NR; i++) {
+   irq = irq_find_mapping(msi->domain, i);
+   if (irq > 0)
+   irq_dispose_mapping(irq);
+   }
+
+   irq_domain_remove(msi->domain);
+}
+
 static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
 {
struct device *dev = pcie->dev;
@@ -897,14 +911,13 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
return 0;
 
 err:
-   irq_domain_remove(msi->domain);
+   rcar_pcie_unmap_msi(pcie);
return err;
 }
 
 static void rcar_pcie_teardown_msi(struct rcar_pcie *pcie)
 {
struct rcar_msi *msi = >msi;
-   int irq, i;
 
/* Disable all MSI interrupts */
rcar_pci_write_reg(pcie, 0, PCIEMSIIER);
@@ -914,13 +927,7 @@ static void rcar_pcie_teardown_msi(struct rcar_pcie *pcie)
 
free_pages(msi->pages, 0);
 
-   for (i = 0; i < INT_PCI_MSI_NR; i++) {
-   irq = irq_find_mapping(msi->domain, i);
-   if (irq > 0)
-   irq_dispose_mapping(irq);
-   }
-
-   irq_domain_remove(msi->domain);
+   rcar_pcie_unmap_msi(pcie);
 }
 
 static int rcar_pcie_get_resources(struct rcar_pcie *pcie)
-- 
2.16.2

Re: [PATCH 15/61] gpu: drm: omapdrm: displays: simplify getting .drvdata

[Tomi Valkeinen]

On 19/04/18 17:05, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
> 
> Signed-off-by: Wolfram Sang 
> ---
> 
> Build tested only. buildbot is happy. Please apply individually.
> 
>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 18 ++
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> index 428de90fced1..8f8573a00e07 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> @@ -412,8 +412,7 @@ static const struct backlight_ops dsicm_bl_ops = {
>  static ssize_t dsicm_num_errors_show(struct device *dev,
>   struct device_attribute *attr, char *buf)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
>   struct omap_dss_device *in = ddata->in;
>   u8 errors = 0;
>   int r;
> @@ -444,8 +443,7 @@ static ssize_t dsicm_num_errors_show(struct device *dev,
>  static ssize_t dsicm_hw_revision_show(struct device *dev,
>   struct device_attribute *attr, char *buf)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
>   struct omap_dss_device *in = ddata->in;
>   u8 id1, id2, id3;
>   int r;
> @@ -476,8 +474,7 @@ static ssize_t dsicm_store_ulps(struct device *dev,
>   struct device_attribute *attr,
>   const char *buf, size_t count)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
>   struct omap_dss_device *in = ddata->in;
>   unsigned long t;
>   int r;
> @@ -511,8 +508,7 @@ static ssize_t dsicm_show_ulps(struct device *dev,
>   struct device_attribute *attr,
>   char *buf)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
>   unsigned int t;
>  
>   mutex_lock(>lock);
> @@ -526,8 +522,7 @@ static ssize_t dsicm_store_ulps_timeout(struct device 
> *dev,
>   struct device_attribute *attr,
>   const char *buf, size_t count)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
>   struct omap_dss_device *in = ddata->in;
>   unsigned long t;
>   int r;
> @@ -558,8 +553,7 @@ static ssize_t dsicm_show_ulps_timeout(struct device *dev,
>   struct device_attribute *attr,
>   char *buf)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
>   unsigned int t;
>  
>   mutex_lock(>lock);
> 

Thanks, I have picked this up.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[Linus Walleij]

On Wed, May 23, 2018 at 10:52 AM, Phil Edworthy
 wrote:

> Treat DT and ACPI the same as much as possible. Note that we can't use
> platform_get_irq() to get the DT interrupts as they are in the port
> sub-node and hence do not have an associated platform device.
>
> This also fixes a problem introduced with error checking when calling
> platform_get_irq().
>
> Signed-off-by: Phil Edworthy 

OK this patch applied!

Yours,
Linus Walleij

Re: [PATCH v6 1/6] dt-bindings: arm: Document the RZN1D-DB board

[Simon Horman]

On Wed, May 23, 2018 at 11:03:56AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
>  wrote:
> > This documents the RZ/N1 bindings for the RZN1D-DB board.
> >
> > Signed-off-by: Michel Pollet 
> > Reviewed-by: Rob Herring 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file

[M P]

Hi Geert,

On Wed, 23 May 2018 at 10:12, Geert Uytterhoeven 
wrote:

> Hi Michel,

> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
>  wrote:
> > 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 

> Thanks for your patch!


> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   cpus {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   clocks = < RZN1_DIV_CA7>;

> I think the clocks property should be moved to the individual CPU nodes.


Ah, I had a look around, and I found some instances that are in the cpu
sub-node, and others that are not -- it seems that having it in the cpu
sub-node would implies it's core specific... here if that clock is changed
both cores would change speed...
Either way, it's not used by the kernel in any way at the moment -- I had
hoped cpufreq or something would claim it, but it's not the case.

Thanks,
Michel

Re: [PATCH 2/2] arm64: dts: renesas: v3hsk: add GEther support

[Simon Horman]

On Tue, May 22, 2018 at 10:52:21AM +0200, Simon Horman wrote:
> On Fri, May 18, 2018 at 10:46:19PM +0300, Sergei Shtylyov wrote:
> > Define the V3H Starter Kit board dependent part of the GEther device node.
> > 
> > Based on the original (and large) patch by Vladimir Barinov.
> > 
> > Signed-off-by: Vladimir Barinov 
> > Signed-off-by: Sergei Shtylyov 
> 
> This looks fine but I will wait to see if there are other reviews before
> applying.
> 
> Reviewed-by: Simon Horman 

Applied.

RE: [PATCH] gpio: dwapb: Rework support for 1 interrupt per port A GPIO

[Phil Edworthy]

Hi Simon,

On 23 May 2018 10:12 Simon Horman wrote:
> On Wed, May 23, 2018 at 09:52:44AM +0100, Phil Edworthy wrote:
> > Treat DT and ACPI the same as much as possible. Note that we can't use
> > platform_get_irq() to get the DT interrupts as they are in the port
> > sub-node and hence do not have an associated platform device.
> >
> > This also fixes a problem introduced with error checking when calling
> > platform_get_irq().
> 
> What is the problem? In general I think fixes should be in separate patches.
The ACPI code would ignore errors returned by platform_get_irq(), instead
treating the error as an interrupt number.

Andy Shevchenko provided some late feedback to the v5 patch, but v5 was 
already applied by Linus W. This patch just has the incremental changes that
were made in v6 of the patch.

BR
Phil

> >
> > Signed-off-by: Phil Edworthy 
> > ---
> >  drivers/gpio/gpio-dwapb.c | 53
> > ---
> >  1 file changed, 22 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> > index 7dcd06b..15b4154 100644
> > --- a/drivers/gpio/gpio-dwapb.c
> > +++ b/drivers/gpio/gpio-dwapb.c
> > @@ -444,7 +444,7 @@ static void dwapb_configure_irqs(struct
> dwapb_gpio *gpio,
> > int i;
> >
> > for (i = 0; i < pp->ngpio; i++) {
> > -   if (pp->irq[i])
> > +   if (pp->irq[i] >= 0)
> > irq_set_chained_handler_and_data(pp-
> >irq[i],
> > dwapb_irq_handler, gpio);
> > }
> > @@ -562,7 +562,7 @@ dwapb_gpio_get_pdata(struct device *dev)
> > struct dwapb_platform_data *pdata;
> > struct dwapb_port_property *pp;
> > int nports;
> > -   int i;
> > +   int i, j;
> >
> > nports = device_get_child_node_count(dev);
> > if (nports == 0)
> > @@ -580,6 +580,8 @@ dwapb_gpio_get_pdata(struct device *dev)
> >
> > i = 0;
> > device_for_each_child_node(dev, fwnode)  {
> > +   struct device_node *np = NULL;
> > +
> > pp = >properties[i++];
> > pp->fwnode = fwnode;
> >
> > @@ -599,46 +601,35 @@ dwapb_gpio_get_pdata(struct device *dev)
> > pp->ngpio = 32;
> > }
> >
> > +   pp->irq_shared  = false;
> > +   pp->gpio_base   = -1;
> > +
> > /*
> >  * Only port A can provide interrupts in all configurations of
> >  * the IP.
> >  */
> > -   if (dev->of_node && pp->idx == 0 &&
> > -   fwnode_property_read_bool(fwnode,
> > - "interrupt-controller")) {
> > -   struct device_node *np = to_of_node(fwnode);
> > -   unsigned int j;
> > -
> > -   /*
> > -* The IP has configuration options to allow a single
> > -* combined interrupt or one per gpio. If one per
> gpio,
> > -* some might not be used.
> > -*/
> > -   for (j = 0; j < pp->ngpio; j++) {
> > -   int irq = of_irq_get(np, j);
> > -   if (irq < 0)
> > -   continue;
> > -
> > -   pp->irq[j] = irq;
> > -   pp->has_irq = true;
> > -   }
> > +   if (pp->idx != 0)
> > +   continue;
> >
> > -   if (!pp->has_irq)
> > -   dev_warn(dev, "no irq for port%d\n", pp-
> >idx);
> > +   if (dev->of_node && fwnode_property_read_bool(fwnode,
> > + "interrupt-controller")) {
> > +   np = to_of_node(fwnode);
> > }
> >
> > -   if (has_acpi_companion(dev) && pp->idx == 0) {
> > -   unsigned int j;
> > +   for (j = 0; j < pp->ngpio; j++) {
> > +   pp->irq[j] = -ENXIO;
> >
> > -   for (j = 0; j < pp->ngpio; j++) {
> > +   if (np)
> > +   pp->irq[j] = of_irq_get(np, j);
> > +   else if (has_acpi_companion(dev))
> > pp->irq[j] =
> platform_get_irq(to_platform_device(dev), j);
> > -   if (pp->irq[j])
> > -   pp->has_irq = true;
> > -   }
> > +
> > +   if (pp->irq[j] >= 0)
> > +   pp->has_irq = true;
> > }
> >
> > -   pp->irq_shared  = false;
> > -   pp->gpio_base   = -1;
> > +   if (!pp->has_irq)
> > +   dev_warn(dev, "no irq for port%d\n", pp->idx);
> > }
> >
> > return pdata;
> > --
> > 2.7.4
> >

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

[Simon Horman]

On Wed, May 23, 2018 at 12:05:30PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 5/23/2018 11:41 AM, Simon Horman wrote:
> 
> > > > > Define the generic R8A77980 part of the GEther device node.
> > > > > 
> > > > > Based on the original (and large) patch by Vladimir Barinov.
> > > > > 
> > > > > Signed-off-by: Vladimir Barinov 
> > > > > Signed-off-by: Sergei Shtylyov 
> > > > 
> > > > Thanks for your patch!
> > > > 
> > > > With the below addressed:
> > > > Reviewed-by: Geert Uytterhoeven 
> > > 
> > > Thanks!
> > > 
> > > > > --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > > > > +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> > > > > @@ -417,6 +417,17 @@
> > > > >  dma-channels = <16>;
> > > > >  };
> > > > > 
> > > > > +   gether: ethernet@e740 {
> > > > > +   compatible = "renesas,gether-r8a77980";
> > > > > +   reg = <0 0xe740 0 0x1000>;
> > > > > +   interrupts = ;
> > > > > +   clocks = < CPG_MOD 813>;
> > > > > +   power-domains = < R8A77980_PD_ALWAYS_ON>;
> > > > 
> > > > resets = < 813>;
> > > 
> > > As usual...
> > > 
> > > > 
> > > > > +   #address-cells = <1>;
> > > > > +   #size-cells = <0>;
> > > > > +   status = "disabled";
> > > > 
> > > > Any default phy-mode needed?
> > > 
> > > A default "phy-mode" IMO make sense when the MAC supports a single
> > > PHY interface mode. In this case, both RMII and RGMII are supported, so
> > > I coulsn't choose a default...
> > 
> > I would think making an arbitrary choice is better than no choice.
> > How does the driver behave in the absence of a default?
> 
>The board DT *must* assign some "phy-mode" -- it's a required prop.
>In this particular case, iff the mode is still unspecified, the driver
> will select the MII mode for the RMII_MII reg (which is a reserved value for
> this GEther)...

Thanks, if its required that boards provide this property then
this makes sense to me.

I have applied the patch after adding the resets property.
The result is as follows:

From: Sergei Shtylyov 
Subject: [PATCH] arm64: dts: renesas: r8a77980: add GEther support

Define the generic R8A77980 part of the GEther device node.

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

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Geert Uytterhoeven 
[simon: add resets property]
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a77980.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77980.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
index 6d2b61d83caf..c797db59ae18 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -417,6 +417,18 @@
dma-channels = <16>;
};
 
+   gether: ethernet@e740 {
+   compatible = "renesas,gether-r8a77980";
+   reg = <0 0xe740 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 813>;
+   power-domains = < R8A77980_PD_ALWAYS_ON>;
+   resets = < 813>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
mmc0: mmc@ee14 {
compatible = "renesas,sdhi-r8a77980",
 "renesas,rcar-gen3-sdhi";
-- 
2.11.0

Re: [PATCH] spi: sh-msiof: Fix setting SIRMDR1.SYNCAC to match SITMDR1.SYNCAC

[Simon Horman]

On Wed, May 23, 2018 at 11:02:04AM +0200, Geert Uytterhoeven wrote:
> According to section 59.2.4 MSIOF Receive Mode Register 1 (SIRMDR1) in
> the R-Car Gen3 datasheet Rev.1.00, the value of the SIRMDR1.SYNCAC bit
> must match the value of the SITMDR1.SYNCAC bit.  However,
> sh_msiof_spi_setup() changes only the latter.
> 
> Fix this by updating the SIRMDR1 register like the SITMDR1 register,
> taking into account register bits that exist in SITMDR1 only.
> 
> Reported-by: Renesas BSP team via Yoshihiro Shimoda 
> 
> Fixes: 7ff0b53c4051145d ("spi: sh-msiof: Avoid writing to registers from 
> spi_master.setup()")
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

> ---
>  drivers/spi/spi-sh-msiof.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
> index 244e841fc4bcfcc7..09c04c1b7d0b5a15 100644
> --- a/drivers/spi/spi-sh-msiof.c
> +++ b/drivers/spi/spi-sh-msiof.c
> @@ -567,14 +567,16 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
>  
>   /* Configure native chip select mode/polarity early */
>   clr = MDR1_SYNCMD_MASK;
> - set = MDR1_TRMD | TMDR1_PCON | MDR1_SYNCMD_SPI;
> + set = MDR1_SYNCMD_SPI;
>   if (spi->mode & SPI_CS_HIGH)
>   clr |= BIT(MDR1_SYNCAC_SHIFT);
>   else
>   set |= BIT(MDR1_SYNCAC_SHIFT);
>   pm_runtime_get_sync(>pdev->dev);
>   tmp = sh_msiof_read(p, TMDR1) & ~clr;
> - sh_msiof_write(p, TMDR1, tmp | set);
> + sh_msiof_write(p, TMDR1, tmp | set | MDR1_TRMD | TMDR1_PCON);
> + tmp = sh_msiof_read(p, RMDR1) & ~clr;
> + sh_msiof_write(p, RMDR1, tmp | set);
>   pm_runtime_put(>pdev->dev);
>   p->native_cs_high = spi->mode & SPI_CS_HIGH;
>   p->native_cs_inited = true;
> -- 
> 2.7.4
> 

Re: [PATCH v6 5/6] ARM: dts: Renesas RZN1D-DB Board base file

[Geert Uytterhoeven]

Hi Michel,

On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
 wrote:
> 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 

Thanks for your patch!

> --- /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";

Please drop the "renesas,rzn1".

With the above fixed:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

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

[Simon Horman]

On Wed, May 23, 2018 at 09:52:44AM +0100, Phil Edworthy wrote:
> Treat DT and ACPI the same as much as possible. Note that we can't use
> platform_get_irq() to get the DT interrupts as they are in the port
> sub-node and hence do not have an associated platform device.
> 
> This also fixes a problem introduced with error checking when calling
> platform_get_irq().

What is the problem? In general I think fixes should be in separate
patches.

> 
> Signed-off-by: Phil Edworthy 
> ---
>  drivers/gpio/gpio-dwapb.c | 53 
> ---
>  1 file changed, 22 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index 7dcd06b..15b4154 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -444,7 +444,7 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
>   int i;
>  
>   for (i = 0; i < pp->ngpio; i++) {
> - if (pp->irq[i])
> + if (pp->irq[i] >= 0)
>   irq_set_chained_handler_and_data(pp->irq[i],
>   dwapb_irq_handler, gpio);
>   }
> @@ -562,7 +562,7 @@ dwapb_gpio_get_pdata(struct device *dev)
>   struct dwapb_platform_data *pdata;
>   struct dwapb_port_property *pp;
>   int nports;
> - int i;
> + int i, j;
>  
>   nports = device_get_child_node_count(dev);
>   if (nports == 0)
> @@ -580,6 +580,8 @@ dwapb_gpio_get_pdata(struct device *dev)
>  
>   i = 0;
>   device_for_each_child_node(dev, fwnode)  {
> + struct device_node *np = NULL;
> +
>   pp = >properties[i++];
>   pp->fwnode = fwnode;
>  
> @@ -599,46 +601,35 @@ dwapb_gpio_get_pdata(struct device *dev)
>   pp->ngpio = 32;
>   }
>  
> + pp->irq_shared  = false;
> + pp->gpio_base   = -1;
> +
>   /*
>* Only port A can provide interrupts in all configurations of
>* the IP.
>*/
> - if (dev->of_node && pp->idx == 0 &&
> - fwnode_property_read_bool(fwnode,
> -   "interrupt-controller")) {
> - struct device_node *np = to_of_node(fwnode);
> - unsigned int j;
> -
> - /*
> -  * The IP has configuration options to allow a single
> -  * combined interrupt or one per gpio. If one per gpio,
> -  * some might not be used.
> -  */
> - for (j = 0; j < pp->ngpio; j++) {
> - int irq = of_irq_get(np, j);
> - if (irq < 0)
> - continue;
> -
> - pp->irq[j] = irq;
> - pp->has_irq = true;
> - }
> + if (pp->idx != 0)
> + continue;
>  
> - if (!pp->has_irq)
> - dev_warn(dev, "no irq for port%d\n", pp->idx);
> + if (dev->of_node && fwnode_property_read_bool(fwnode,
> +   "interrupt-controller")) {
> + np = to_of_node(fwnode);
>   }
>  
> - if (has_acpi_companion(dev) && pp->idx == 0) {
> - unsigned int j;
> + for (j = 0; j < pp->ngpio; j++) {
> + pp->irq[j] = -ENXIO;
>  
> - for (j = 0; j < pp->ngpio; j++) {
> + if (np)
> + pp->irq[j] = of_irq_get(np, j);
> + else if (has_acpi_companion(dev))
>   pp->irq[j] = 
> platform_get_irq(to_platform_device(dev), j);
> - if (pp->irq[j])
> - pp->has_irq = true;
> - }
> +
> + if (pp->irq[j] >= 0)
> + pp->has_irq = true;
>   }
>  
> - pp->irq_shared  = false;
> - pp->gpio_base   = -1;
> + if (!pp->has_irq)
> + dev_warn(dev, "no irq for port%d\n", pp->idx);
>   }
>  
>   return pdata;
> -- 
> 2.7.4
> 

Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file

[Geert Uytterhoeven]

Hi Michel,

On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
 wrote:
> 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 

Thanks for your patch!

> --- /dev/null
> +++ b/arch/arm/boot/dts/r9a06g032.dtsi
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + */
> +
> +#include 
> +#include 
> +
> +/ {
> +   compatible = "renesas,r9a06g032", "renesas,rzn1";

Please drop the "renesas,rzn1".


> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = < RZN1_DIV_CA7>;

I think the clocks property should be moved to the individual CPU nodes.

> +
> +   cpu@0 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <0>;
> +   };
> +
> +   cpu@1 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <1>;
> +   };
> +   };

The rest looks OK to me (pending acceptance of the clock bindings).

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 1/2] arm64: dts: r8a77995: Add MSIOF device nodes

[Wolfram Sang]

> > For the record: can you describe shortly which of these got tested with
> > what setup? I don't know the Draak, so I don't know what is exposed.
> 
> MSIOF2 is conveniently hooked up to a 1x4 pin header (CN41), no
> weird-ass Samtec connectors required. My testing covered sending some
> data using spidev_test and watching the output on an oscilloscope
> attached to MSIOF2_TXD (pin 3). Looks plausible.

Perfect, thanks!



signature.asc
Description: PGP signature

Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

[Simon Horman]

On Wed, May 23, 2018 at 11:37:47AM +0300, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Wednesday, 23 May 2018 11:33:26 EEST Simon Horman wrote:
> > On Tue, May 22, 2018 at 01:04:56PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 22, 2018 at 11:05 AM, Simon Horman  wrote:
> > >>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> > >>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> > >>> @@ -1,4 +1,4 @@
> > >>> -/* SPDX-License-Identifier: GPL-2.0 */
> > >>> +/* SPDX-License-Identifier: GPL-2.0+ */
> > >> 
> > >> While you are changing this line, I believe the correct format is
> > >> to use a '//' comment.
> > >> 
> > >> i.e.:
> > >> 
> > >> // SPDX-License-Identifier: GPL-2.0+
> > > 
> > > Not for C header files, only for C source files.
> > 
> > Wow!
> 
> Yes, it's a mess :-( The rationale is that the assembler doesn't support C++-
> style comments, so we need to use C-style comments in header files. We should 
> really have standardized usage of C-style comments everywhere, it makes no 
> sense to me.

I'm reading this email while standing on my head
and things make much more sense :)

Re: [PATCH v6 4/6] ARM: dts: Renesas RZ/N1 SoC base device tree file

[Simon Horman]

On Tue, May 22, 2018 at 11:01:24AM +0100, Michel Pollet wrote:
> 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 

I am marking this and the following patch as deferred
pending acceptance of the bindings it uses.

> ---
>  arch/arm/boot/dts/r9a06g032.dtsi | 86 
> 
>  1 file changed, 86 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..c7764c7
> --- /dev/null
> +++ b/arch/arm/boot/dts/r9a06g032.dtsi
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + */
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "renesas,r9a06g032", "renesas,rzn1";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = < RZN1_DIV_CA7>;
> +
> + 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;
> +
> + clock: clocks@4000c000 {
> + compatible = "renesas,r9a06g032-clocks",
> + "renesas,rzn1-clocks";
> + reg = <0x4000c000 0x1000>;
> + status = "okay";
> + #clock-cells = <1>;
> + };
> +
> + uart0: serial@4006 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x4006 0x400>;
> + interrupts = ;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = < RZN1_CLK_UART0>;
> + 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 =
> +  IRQ_TYPE_LEVEL_HIGH)>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,cortex-a7-timer",
> +  "arm,armv7-timer";
> + interrupt-parent = <>;
> + arm,cpu-registers-not-fw-configured;
> + always-on;
> + interrupts =
> +  IRQ_TYPE_LEVEL_LOW)>,
> +  IRQ_TYPE_LEVEL_LOW)>,
> +  IRQ_TYPE_LEVEL_LOW)>,
> +  IRQ_TYPE_LEVEL_LOW)>;
> + };
> +};
> -- 
> 2.7.4
> 

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

[Sergei Shtylyov]

Hello!

On 5/23/2018 11:41 AM, Simon Horman wrote:


Define the generic R8A77980 part of the GEther device node.

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

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


Thanks for your patch!

With the below addressed:
Reviewed-by: Geert Uytterhoeven 


Thanks!


--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -417,6 +417,17 @@
 dma-channels = <16>;
 };

+   gether: ethernet@e740 {
+   compatible = "renesas,gether-r8a77980";
+   reg = <0 0xe740 0 0x1000>;
+   interrupts = ;
+   clocks = < CPG_MOD 813>;
+   power-domains = < R8A77980_PD_ALWAYS_ON>;


resets = < 813>;


As usual...




+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";


Any default phy-mode needed?


A default "phy-mode" IMO make sense when the MAC supports a single
PHY interface mode. In this case, both RMII and RGMII are supported, so
I coulsn't choose a default...


I would think making an arbitrary choice is better than no choice.
How does the driver behave in the absence of a default?


   The board DT *must* assign some "phy-mode" -- it's a required prop.
   In this particular case, iff the mode is still unspecified, the driver 
will select the MII mode for the RMII_MII reg (which is a reserved value for 
this GEther)...


[...]

MBR, Sergei

Re: [PATCH v6 1/6] dt-bindings: arm: Document the RZN1D-DB board

[Geert Uytterhoeven]

On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
 wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
>
> Signed-off-by: Michel Pollet 
> Reviewed-by: Rob Herring 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] spi: sh-msiof: Fix setting SIRMDR1.SYNCAC to match SITMDR1.SYNCAC

[Geert Uytterhoeven]

According to section 59.2.4 MSIOF Receive Mode Register 1 (SIRMDR1) in
the R-Car Gen3 datasheet Rev.1.00, the value of the SIRMDR1.SYNCAC bit
must match the value of the SITMDR1.SYNCAC bit.  However,
sh_msiof_spi_setup() changes only the latter.

Fix this by updating the SIRMDR1 register like the SITMDR1 register,
taking into account register bits that exist in SITMDR1 only.

Reported-by: Renesas BSP team via Yoshihiro Shimoda 

Fixes: 7ff0b53c4051145d ("spi: sh-msiof: Avoid writing to registers from 
spi_master.setup()")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/spi/spi-sh-msiof.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 244e841fc4bcfcc7..09c04c1b7d0b5a15 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -567,14 +567,16 @@ static int sh_msiof_spi_setup(struct spi_device *spi)
 
/* Configure native chip select mode/polarity early */
clr = MDR1_SYNCMD_MASK;
-   set = MDR1_TRMD | TMDR1_PCON | MDR1_SYNCMD_SPI;
+   set = MDR1_SYNCMD_SPI;
if (spi->mode & SPI_CS_HIGH)
clr |= BIT(MDR1_SYNCAC_SHIFT);
else
set |= BIT(MDR1_SYNCAC_SHIFT);
pm_runtime_get_sync(>pdev->dev);
tmp = sh_msiof_read(p, TMDR1) & ~clr;
-   sh_msiof_write(p, TMDR1, tmp | set);
+   sh_msiof_write(p, TMDR1, tmp | set | MDR1_TRMD | TMDR1_PCON);
+   tmp = sh_msiof_read(p, RMDR1) & ~clr;
+   sh_msiof_write(p, RMDR1, tmp | set);
pm_runtime_put(>pdev->dev);
p->native_cs_high = spi->mode & SPI_CS_HIGH;
p->native_cs_inited = true;
-- 
2.7.4

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

[Ulrich Hecht]

On Thu, May 17, 2018 at 9:56 AM, Wolfram Sang  wrote:
> On Wed, May 16, 2018 at 03:05:15PM +0200, Ulrich Hecht wrote:
>> From: Hiromitsu Yamasaki 
>>
>> This patch adds MSIOF device nodes for the R8A77995 SoC.
>>
>> Signed-off-by: Hiromitsu Yamasaki 
>> Signed-off-by: Takeshi Kihara 
>> [uli: remove unimplemented ref clock]
>> Signed-off-by: Ulrich Hecht 
>
> Thanks, Uli!
>
> For the record: can you describe shortly which of these got tested with
> what setup? I don't know the Draak, so I don't know what is exposed.

MSIOF2 is conveniently hooked up to a 1x4 pin header (CN41), no
weird-ass Samtec connectors required. My testing covered sending some
data using spidev_test and watching the output on an oscilloscope
attached to MSIOF2_TXD (pin 3). Looks plausible.

CU
Uli

Re: [PATCH v6 1/6] dt-bindings: arm: Document the RZN1D-DB board

[Simon Horman]

On Tue, May 22, 2018 at 11:01:21AM +0100, Michel Pollet wrote:
> This documents the RZ/N1 bindings for the RZN1D-DB board.
> 
> Signed-off-by: Michel Pollet 
> Reviewed-by: Rob Herring 

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

Reviewed-by: Simon Horman 

Re: [PATCH v2 2/2] i2c: mux: demux-pinctrl: add symlinks to the demux device in sysfs

[Wolfram Sang]

> > +   WARN(sysfs_create_link(>cur_adap.dev.kobj, >dev->kobj,
> > +  "demux_device"),
> > +"can't create symlink to mux device\n");
> > +   WARN(sysfs_create_link(>dev->kobj, >cur_adap.dev.kobj,
> > +  "channel-0"),
> > +"can't create symlink to channel 0\n");
> > +
> 
> Personally I'd rather not rely on side-effects from WARN statements,
> but perhaps thats just me.

It's a way to satisfy the __must_check from sysfs_create_link().



signature.asc
Description: PGP signature

[PATCH] gpio: dwapb: Rework support for 1 interrupt per port A GPIO

[Phil Edworthy]

Treat DT and ACPI the same as much as possible. Note that we can't use
platform_get_irq() to get the DT interrupts as they are in the port
sub-node and hence do not have an associated platform device.

This also fixes a problem introduced with error checking when calling
platform_get_irq().

Signed-off-by: Phil Edworthy 
---
 drivers/gpio/gpio-dwapb.c | 53 ---
 1 file changed, 22 insertions(+), 31 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 7dcd06b..15b4154 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -444,7 +444,7 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
int i;
 
for (i = 0; i < pp->ngpio; i++) {
-   if (pp->irq[i])
+   if (pp->irq[i] >= 0)
irq_set_chained_handler_and_data(pp->irq[i],
dwapb_irq_handler, gpio);
}
@@ -562,7 +562,7 @@ dwapb_gpio_get_pdata(struct device *dev)
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
-   int i;
+   int i, j;
 
nports = device_get_child_node_count(dev);
if (nports == 0)
@@ -580,6 +580,8 @@ dwapb_gpio_get_pdata(struct device *dev)
 
i = 0;
device_for_each_child_node(dev, fwnode)  {
+   struct device_node *np = NULL;
+
pp = >properties[i++];
pp->fwnode = fwnode;
 
@@ -599,46 +601,35 @@ dwapb_gpio_get_pdata(struct device *dev)
pp->ngpio = 32;
}
 
+   pp->irq_shared  = false;
+   pp->gpio_base   = -1;
+
/*
 * Only port A can provide interrupts in all configurations of
 * the IP.
 */
-   if (dev->of_node && pp->idx == 0 &&
-   fwnode_property_read_bool(fwnode,
- "interrupt-controller")) {
-   struct device_node *np = to_of_node(fwnode);
-   unsigned int j;
-
-   /*
-* The IP has configuration options to allow a single
-* combined interrupt or one per gpio. If one per gpio,
-* some might not be used.
-*/
-   for (j = 0; j < pp->ngpio; j++) {
-   int irq = of_irq_get(np, j);
-   if (irq < 0)
-   continue;
-
-   pp->irq[j] = irq;
-   pp->has_irq = true;
-   }
+   if (pp->idx != 0)
+   continue;
 
-   if (!pp->has_irq)
-   dev_warn(dev, "no irq for port%d\n", pp->idx);
+   if (dev->of_node && fwnode_property_read_bool(fwnode,
+ "interrupt-controller")) {
+   np = to_of_node(fwnode);
}
 
-   if (has_acpi_companion(dev) && pp->idx == 0) {
-   unsigned int j;
+   for (j = 0; j < pp->ngpio; j++) {
+   pp->irq[j] = -ENXIO;
 
-   for (j = 0; j < pp->ngpio; j++) {
+   if (np)
+   pp->irq[j] = of_irq_get(np, j);
+   else if (has_acpi_companion(dev))
pp->irq[j] = 
platform_get_irq(to_platform_device(dev), j);
-   if (pp->irq[j])
-   pp->has_irq = true;
-   }
+
+   if (pp->irq[j] >= 0)
+   pp->has_irq = true;
}
 
-   pp->irq_shared  = false;
-   pp->gpio_base   = -1;
+   if (!pp->has_irq)
+   dev_warn(dev, "no irq for port%d\n", pp->idx);
}
 
return pdata;
-- 
2.7.4

Re: [PATCH] media: dt-bindings: media: rcar_vin: add support for r8a77965

[Simon Horman]

On Sun, May 13, 2018 at 08:58:18PM +0200, Niklas Söderlund wrote:
> Signed-off-by: Niklas Söderlund 

Reviewed-by: Simon Horman 

> ---
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669eb35..c2c57dcf73f4851b 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -21,6 +21,7 @@ on Gen3 platforms to a CSI-2 receiver.
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> - "renesas,vin-r8a7796" for the R8A7796 device
> +   - "renesas,vin-r8a77965" for the R8A77965 device
> - "renesas,vin-r8a77970" for the R8A77970 device
> - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
>   device.
> -- 
> 2.17.0
> 

Re: [PATCH/RFC] ARM: dts: r8a7791: Move enable-method to CPU nodes

[Geert Uytterhoeven]

Hi Simon,

On Wed, May 23, 2018 at 10:37 AM, Simon Horman  wrote:
> On Tue, May 22, 2018 at 03:29:25PM +0200, Geert Uytterhoeven wrote:
>> According to Documentation/devicetree/bindings/arm/cpus.txt, the
>> "enable-method" property should be a property of the individual CPU
>> nodes, not of the parent "cpus" node.  However, on R-Car M2-W (and on
>> several other arm32 SoCs), the property is tied to the "cpus" node
>> instead.
>>
>> Secondary CPU bringup and CPU hot (un)plug work regardless, as
>> arm_dt_init_cpu_maps() falls back to looking in the "cpus" node.
>>
>> The cpuidle code does not have such a fallback, so it does not detect
>> the enable-method.  Note that cpuidle does not support the
>> "renesas,apmu" enable-method yet, so for now this does not make any
>> difference.
>
> Is the implication that if we keep the current binding for cpu nodes
> then at some point we will need to update the cpuidle binding?

If we keep the current binding for cpu nodes, we indeed have to update
(common) Documentation/devicetree/bindings/arm/cpus.txt.

In addition, if we want to add renesas,apmu-based cpuidle support later,
we will have to update the common cpuidle code to look in /cpus, too.

>> Signed-off-by: Geert Uytterhoeven 
>> ---
>> Arm64 and powerpc do not have such a fallback, but SH has, like arm32.
>>
>> This is marked RFC, as the alternative is to update the DT bindings to
>> keep the status quo.
>> ---
>>  arch/arm/boot/dts/r8a7791.dtsi | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
>> index d568bd22d6cbd855..b214cb8f52e47109 100644
>> --- a/arch/arm/boot/dts/r8a7791.dtsi
>> +++ b/arch/arm/boot/dts/r8a7791.dtsi
>> @@ -71,7 +71,6 @@
>>   cpus {
>>   #address-cells = <1>;
>>   #size-cells = <0>;
>> - enable-method = "renesas,apmu";
>>
>>   cpu0: cpu@0 {
>>   device_type = "cpu";
>> @@ -83,6 +82,7 @@
>>   clock-latency = <30>; /* 300 us */
>>   power-domains = < R8A7791_PD_CA15_CPU0>;
>>   next-level-cache = <_CA15>;
>> + enable-method = "renesas,apmu";
>>
>>   /* kHz - uV - OPPs unknown yet */
>>   operating-points = <150 100>,
>> @@ -101,6 +101,7 @@
>>   clocks = < CPG_CORE R8A7791_CLK_Z>;
>>   power-domains = < R8A7791_PD_CA15_CPU1>;
>>   next-level-cache = <_CA15>;
>> + enable-method = "renesas,apmu";
>>   };
>>
>>   L2_CA15: cache-controller-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 v2 1/2] i2c: mux: demux-pinctrl: use proper parent device for demux adapter

[Simon Horman]

On Mon, May 21, 2018 at 09:29:38AM +0200, Wolfram Sang wrote:
> Due to a typo, the wrong parent device was assigned to the newly created
> demuxing adapter device. It got connected to the demuxing platform
> device but not to the selected parent I2C adapter device. Fix it to get
> a proper parent-child relationship of the demuxed busses.
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

Re: [PATCH v2 2/2] i2c: mux: demux-pinctrl: add symlinks to the demux device in sysfs

[Simon Horman]

On Mon, May 21, 2018 at 09:29:39AM +0200, Wolfram Sang wrote:
> Similar to mux devices, create special symlinks to connect the demuxed
> bus with the demux device.
> 
> Signed-off-by: Wolfram Sang 

Nit below not withstanding:

Reviewed-by: Simon Horman 

> ---
> 
> Changes since v1:
> * check sysfs_create_link and print WARN if something fails
> 
>  drivers/i2c/muxes/i2c-demux-pinctrl.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c 
> b/drivers/i2c/muxes/i2c-demux-pinctrl.c
> index 035032e20327..13d1461703f3 100644
> --- a/drivers/i2c/muxes/i2c-demux-pinctrl.c
> +++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c
> @@ -116,6 +116,13 @@ static int i2c_demux_activate_master(struct 
> i2c_demux_pinctrl_priv *priv, u32 ne
>   if (ret < 0)
>   goto err_with_put;
>  
> + WARN(sysfs_create_link(>cur_adap.dev.kobj, >dev->kobj,
> +"demux_device"),
> +  "can't create symlink to mux device\n");
> + WARN(sysfs_create_link(>dev->kobj, >cur_adap.dev.kobj,
> +"channel-0"),
> +  "can't create symlink to channel 0\n");
> +

Personally I'd rather not rely on side-effects from WARN statements,
but perhaps thats just me.

>   return 0;
>  
>   err_with_put:
> @@ -135,6 +142,9 @@ static int i2c_demux_deactivate_master(struct 
> i2c_demux_pinctrl_priv *priv)
>   if (cur < 0)
>   return 0;
>  
> + sysfs_remove_link(>dev->kobj, "channel-0");
> + sysfs_remove_link(>cur_adap.dev.kobj, "demux_device");
> +
>   i2c_del_adapter(>cur_adap);
>   i2c_put_adapter(priv->chan[cur].parent_adap);
>  
> -- 
> 2.11.0
> 

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

[Phil Edworthy]

Hi Linus,

On 23 May 2018 09:29, Linus Walleij wrote:
> On Fri, May 11, 2018 at 10:31 AM, Phil Edworthy wrote:
> 
> > The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> > per GPIO in port A, but the driver currently only supports 1 interrupt.
> > See the DesignWare DW_apb_gpio Databook description of the
> > 'GPIO_INTR_IO' parameter.
> >
> > This change allows the driver to work with up to 32 interrupts, it
> > will get as many interrupts as specified in the DT 'interrupts' property.
> > It doesn't do anything clever with the different interrupts, it just
> > calls the same handler used for single interrupt hardware.
> >
> > Signed-off-by: Phil Edworthy 
> > Reviewed-by: Rob Herring 
> > Acked-by: Lee Jones 
> > ---
> > One point to mention is that I have made it possible for users to have
> > unconnected interrupts by specifying holes in the list of interrupts.
> > This is done by supporting the interrupts-extended DT prop.
> > However, I have no use for this and had to hack some test case for this.
> > Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
> >
> > v6:
> >  - Treat DT and ACPI the same as much as possible. Note that we can't use
> >platform_get_irq() to get the DT interrupts as they are in the port
> >sub-node and hence do not have an associated platform device.
> 
> I already applied this patch in some version, can you check what is in my
> devel branch and send incremental patches on top if something needs
> changing?
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-
> gpio.git/commit/?h=devel=e6ca26abd37606ba4864f20c85d3fe4a2173b93f
> 
> Sorry for not knowing by heart what was applied or when, it's just too much
> for me sometimes.
No problem, I'll send a patch with the incremental changes.

Thanks
Phil

Re: [PATCH v4 3/3] arm64: dts: renesas: r8a77995: add thermal device support

[Simon Horman]

On Sun, May 20, 2018 at 06:26:19PM +0900, Yoshihiro Kaneko wrote:
> Signed-off-by: Yoshihiro Kaneko 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

[Laurent Pinchart]

Hi Simon,

On Wednesday, 23 May 2018 11:33:26 EEST Simon Horman wrote:
> On Tue, May 22, 2018 at 01:04:56PM +0200, Geert Uytterhoeven wrote:
> > On Tue, May 22, 2018 at 11:05 AM, Simon Horman  wrote:
> >>> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> >>> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> >>> @@ -1,4 +1,4 @@
> >>> -/* SPDX-License-Identifier: GPL-2.0 */
> >>> +/* SPDX-License-Identifier: GPL-2.0+ */
> >> 
> >> While you are changing this line, I believe the correct format is
> >> to use a '//' comment.
> >> 
> >> i.e.:
> >> 
> >> // SPDX-License-Identifier: GPL-2.0+
> > 
> > Not for C header files, only for C source files.
> 
> Wow!

Yes, it's a mess :-( The rationale is that the assembler doesn't support C++-
style comments, so we need to use C-style comments in header files. We should 
really have standardized usage of C-style comments everywhere, it makes no 
sense to me.

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC] ARM: dts: r8a7791: Move enable-method to CPU nodes

[Simon Horman]

On Tue, May 22, 2018 at 03:29:25PM +0200, Geert Uytterhoeven wrote:
> According to Documentation/devicetree/bindings/arm/cpus.txt, the
> "enable-method" property should be a property of the individual CPU
> nodes, not of the parent "cpus" node.  However, on R-Car M2-W (and on
> several other arm32 SoCs), the property is tied to the "cpus" node
> instead.
> 
> Secondary CPU bringup and CPU hot (un)plug work regardless, as
> arm_dt_init_cpu_maps() falls back to looking in the "cpus" node.
> 
> The cpuidle code does not have such a fallback, so it does not detect
> the enable-method.  Note that cpuidle does not support the
> "renesas,apmu" enable-method yet, so for now this does not make any
> difference.

Is the implication that if we keep the current binding for cpu nodes
then at some point we will need to update the cpuidle binding?

> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Arm64 and powerpc do not have such a fallback, but SH has, like arm32.
> 
> This is marked RFC, as the alternative is to update the DT bindings to
> keep the status quo.
> ---
>  arch/arm/boot/dts/r8a7791.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
> index d568bd22d6cbd855..b214cb8f52e47109 100644
> --- a/arch/arm/boot/dts/r8a7791.dtsi
> +++ b/arch/arm/boot/dts/r8a7791.dtsi
> @@ -71,7 +71,6 @@
>   cpus {
>   #address-cells = <1>;
>   #size-cells = <0>;
> - enable-method = "renesas,apmu";
>  
>   cpu0: cpu@0 {
>   device_type = "cpu";
> @@ -83,6 +82,7 @@
>   clock-latency = <30>; /* 300 us */
>   power-domains = < R8A7791_PD_CA15_CPU0>;
>   next-level-cache = <_CA15>;
> + enable-method = "renesas,apmu";
>  
>   /* kHz - uV - OPPs unknown yet */
>   operating-points = <150 100>,
> @@ -101,6 +101,7 @@
>   clocks = < CPG_CORE R8A7791_CLK_Z>;
>   power-domains = < R8A7791_PD_CA15_CPU1>;
>   next-level-cache = <_CA15>;
> + enable-method = "renesas,apmu";
>   };
>  
>   L2_CA15: cache-controller-0 {
> -- 
> 2.7.4
> 

Re: [PATCH v2] v4l: vsp1: Fix vsp1_regs.h license header

[Simon Horman]

On Tue, May 22, 2018 at 01:04:56PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, May 22, 2018 at 11:05 AM, Simon Horman  wrote:
> >> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> >> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> >> @@ -1,4 +1,4 @@
> >> -/* SPDX-License-Identifier: GPL-2.0 */
> >> +/* SPDX-License-Identifier: GPL-2.0+ */
> >
> > While you are changing this line, I believe the correct format is
> > to use a '//' comment.
> >
> > i.e.:
> >
> > // SPDX-License-Identifier: GPL-2.0+
> 
> Not for C header files, only for C source files.

Wow!

Re: [PATCH] arm64: dts: renesas: r8a77980: add SMP support

[Simon Horman]

On Tue, May 22, 2018 at 11:49:36AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 22, 2018 at 10:54 AM, Simon Horman  wrote:
> > On Sat, May 19, 2018 at 08:38:13PM +0300, Sergei Shtylyov wrote:
> >> On 05/17/2018 11:23 PM, Geert Uytterhoeven wrote:
> >>
> >> >> Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the 
> >> >> interrupt
> >> >> delivery masks for the ARM GIC and Architectured Timer.
> >> >>
> >> >> Based on the original (and large) patch by Vladimir Barinov.
> >> >>
> >> >> Signed-off-by: Vladimir Barinov 
> >> >> Signed-off-by: Sergei Shtylyov 
> >> >
> >> > Thanks for your patch!
> >> >
> >> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> >> @@ -30,6 +30,36 @@
> >> >> enable-method = "psci";
> >> >> };
> >> >>
> >> >> +   a53_1: cpu@1 {
> >> >> +   device_type = "cpu";
> >> >> +   compatible = "arm,cortex-a53","arm,armv8";
> >> >
> >> > Please stop copying spaceless lists ;-)
> >>
> >>Oops! Simon, do I need to re-post?
> >
> > No, but Geert, are you otherwise ok with this patch?
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, I have applied the following:

From: Sergei Shtylyov 
Subject: [PATCH] arm64: dts: renesas: r8a77980: add SMP support

Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the interrupt
delivery masks for the ARM GIC and Architectured Timer.

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

Signed-off-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Geert Uytterhoeven 
[simon: corrected whitespace]
Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a77980.dtsi | 40 +++
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77980.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
index 4c40f9f0ebc9..6d2b61d83caf 100644
--- a/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -30,6 +30,36 @@
enable-method = "psci";
};
 
+   a53_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <1>;
+   clocks = < CPG_CORE R8A77980_CLK_Z2>;
+   power-domains = < R8A77980_PD_CA53_CPU1>;
+   next-level-cache = <_CA53>;
+   enable-method = "psci";
+   };
+
+   a53_2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <2>;
+   clocks = < CPG_CORE R8A77980_CLK_Z2>;
+   power-domains = < R8A77980_PD_CA53_CPU2>;
+   next-level-cache = <_CA53>;
+   enable-method = "psci";
+   };
+
+   a53_3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <3>;
+   clocks = < CPG_CORE R8A77980_CLK_Z2>;
+   power-domains = < R8A77980_PD_CA53_CPU3>;
+   next-level-cache = <_CA53>;
+   enable-method = "psci";
+   };
+
L2_CA53: cache-controller {
compatible = "cache";
power-domains = < R8A77980_PD_CA53_SCU>;
@@ -408,7 +438,7 @@
  <0x0 0xf102 0 0x2>,
  <0x0 0xf104 0 0x2>,
  <0x0 0xf106 0 0x2>;
-   interrupts = ;
clocks = < CPG_MOD 408>;
clock-names = "clk";
@@ -424,13 +454,13 @@
 
timer {
compatible = "arm,armv8-timer";
-   interrupts-extended = < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) |
+   interrupts-extended = < GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
   IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) |
+ < GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) |
   IRQ_TYPE_LEVEL_LOW)>,
- < GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) |
+ < GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
   IRQ_TYPE_LEVEL_LOW)>,
- < 

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

[Linus Walleij]

On Fri, May 11, 2018 at 10:31 AM, Phil Edworthy
 wrote:

> The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> per GPIO in port A, but the driver currently only supports 1 interrupt.
> See the DesignWare DW_apb_gpio Databook description of the
> 'GPIO_INTR_IO' parameter.
>
> This change allows the driver to work with up to 32 interrupts, it will
> get as many interrupts as specified in the DT 'interrupts' property.
> It doesn't do anything clever with the different interrupts, it just calls
> the same handler used for single interrupt hardware.
>
> Signed-off-by: Phil Edworthy 
> Reviewed-by: Rob Herring 
> Acked-by: Lee Jones 
> ---
> One point to mention is that I have made it possible for users to have
> unconnected interrupts by specifying holes in the list of interrupts. This is
> done by supporting the interrupts-extended DT prop.
> However, I have no use for this and had to hack some test case for this.
> Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
>
> v6:
>  - Treat DT and ACPI the same as much as possible. Note that we can't use
>platform_get_irq() to get the DT interrupts as they are in the port
>sub-node and hence do not have an associated platform device.

I already applied this patch in some version, can you check what is
in my devel branch and send incremental patches on top if
something needs changing?
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=devel=e6ca26abd37606ba4864f20c85d3fe4a2173b93f

Sorry for not knowing by heart what was applied or when, it's
just too much for me sometimes.

Yours,
Linus Walleij

Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file

[M P]

Morning Geert,

On Wed, 23 May 2018 at 08:26, Geert Uytterhoeven 
wrote:

> Hi Michel,

> On Wed, May 23, 2018 at 8:44 AM, M P  wrote:
> > On Tue, 22 May 2018 at 19:44, Geert Uytterhoeven 
> > wrote:
> >> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
> >>  wrote:
> >> > This adds the constants necessary to use the renesas,rzn1-clocks
driver.
> >> >
> >> > Signed-off-by: Michel Pollet 

> >> > --- /dev/null
> >> > +++ b/include/dt-bindings/clock/rzn1-clocks.h
> >
> >> Given this is part of the DT ABI, and there exist multiple different
RZ/N1
> >> SoCs (and there are probably planned more), I wouldn't call this header
> >> file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h".
> >
> > Actually, no, there already are two r906g03X devices that will work
> > perfectly fine with this driver. We had that discussion before, and you
> > insist and me removing mentions of the rzn1 everywhere, however, this
> > applies to *two* devices already, and I'm supposed to upstream support
for
> > them. I can't rename r9g06g032 because it is *inexact* that's why it's

> My worry is not that there are two r906g03X devices that will work fine
> with this driver, but that there will be other "rzn1" devices that will
not
> work with these bindings (the header file is part of the bindings).
> Besides, RZ/N1D and RZ/N1S (Which apparently differ in packaging only?
> Oh no, RZ/N1D (the larger package) has less QSPI channels than RZ/N1S
> (the smaller package)), there's also (at least) RZ/N1L.

> > called rzn1. So unless you let me call it r9a06g0xx-clocks.h (which i
know
> > you won't as per multiple previous discussions) this can't be called
> > r9a06g032 because it won't be fit for my purpose when I try to bring
back
> > the RZ/N1S into the picture.

> You can add r9a06g033-clocks.h when adding support for RZ/N1S.

So it is now acceptable to duplicate a huge amount of code, and constants
when in fact there differences are so minor they would require minimal
amount of code to take care of them? That just flies straight against my
30+ years of programming -- We're going to have twice the *identical* code,
twice the header, and completely incompatible device tree files -- I mean,
*right now* our rzn1.dtsi works *as is* on the 1D and 1S, we've got ONE
file to maintain, and you can switch your CPU board from 1D to 1S and your
'board file' can stay the same.

Wasn't it the idea of that stuff in the first place? Isn't it in the
customer/engineer interest to be able to cross grade from one
manufacturer's device *in the same series* to another without having to
duplicate his whole board file?

> > There are minor difference to clocking,

> Aha?

Sure, 1S doesn't' have DDR, 1D doesn't have the second QSPI. That's about
it (I lie, theres a few other bits I'm sure). It's not like it won't even
*work* or anything, the registers are there, the bit positions are there,
all is the same, I'm *sure* that's what the compatible="" thing were
supposed to be used for, isn't it? Heck, I'm pretty sure there's a register
in sysctrl, that tells me that anyway, so I wouldn't even have to have a
special compatible= -- I didn't do it since the driver is already so big.


> > I don't know if Renesas plans to release any more rzn1's in this series,
> > but my little finger tells me this isn't the case. But regardless of
what

> We thought the same thing when the first RZ member (RZ/A1H) showed up.
> Did we know this was not going to be the first SoC of a new RZ family, but
> the first SoC of the first subfamily (RZ/A) of the RZ family... And the
> various subfamilies bear not much similarity.

> > we plan, Marketing will screw it up.

> Correct. And to mitigate that, we have no other choice than to use the
real
> part numbers to differentiate. Once bitten, twice shy.

It's not mitigation from where I stand -- it's a gigantic kludge; To handle
one exception, you throw away the baby with the bathwater. From where I
sit, it's like having to a different screwdriver for the screws on the left
of a panel vs the right of the panel.

Sorry to come out as pretty miffed -- I've just spent weeks polishing up a
driver to make it more or less similar to what they were 10 years ago (whoo
look a platform file with a big table in it!), after throwing away all the
work I had done to make it all device-tree based and make the code as
agnostic as we could -- and now it turns out we need to make it even worse
by throwing away the fact it actually *does* work on two SoC -- and that
just because... because what, again?

What about *making up names* -- The 'family names' can/will change -- the
part numbers are *too limited in scope* -- why not just make up names? does
it matter as long as it's close to reality and are documented? I dunno,
"rzn1_18" or "rzn1_mk1" and so we have a way out when they release a new
one next year? It seems to be working fine for cars 

Re: [PATCH] dt-bindings: gpio: rcar: Add support for r8a77990

[Linus Walleij]

On Fri, May 11, 2018 at 5:13 AM, Yoshihiro Shimoda
 wrote:

> Add compatible string for R-Car E3 (r8a77990) in gpio-rcar.
>
> Signed-off-by: Yoshihiro Shimoda 

Quite uncontroversial so, patch applied with Simon's
ACK.

Yours,
Linus Walleij

Re: [PATCH v6 2/6] dt-bindings: Add the rzn1-clocks.h file

[M P]

On Tue, 22 May 2018 at 19:44, Geert Uytterhoeven 
wrote:

> Hi Michel,

> On Tue, May 22, 2018 at 12:01 PM, Michel Pollet
>  wrote:
> > This adds the constants necessary to use the renesas,rzn1-clocks driver.
> >
> > Signed-off-by: Michel Pollet 

> Thanks for your patch!

> > ---
> >  include/dt-bindings/clock/rzn1-clocks.h | 187

> >  1 file changed, 187 insertions(+)
> >  create mode 100644 include/dt-bindings/clock/rzn1-clocks.h
> >
> > diff --git a/include/dt-bindings/clock/rzn1-clocks.h
b/include/dt-bindings/clock/rzn1-clocks.h
> > new file mode 100644
> > index 000..8a73db2
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/rzn1-clocks.h

> Given this is part of the DT ABI, and there exist multiple different RZ/N1
> SoCs (and there are probably planned more), I wouldn't call this header
> file "rzn1-clocks.h", but e.g. "r9a06g032-clocks.h".

Actually, no, there already are two r906g03X devices that will work
perfectly fine with this driver. We had that discussion before, and you
insist and me removing mentions of the rzn1 everywhere, however, this
applies to *two* devices already, and I'm supposed to upstream support for
them. I can't rename r9g06g032 because it is *inexact* that's why it's
called rzn1. So unless you let me call it r9a06g0xx-clocks.h (which i know
you won't as per multiple previous discussions) this can't be called
r9a06g032 because it won't be fit for my purpose when I try to bring back
the RZ/N1S into the picture. There are minor difference to clocking,

I don't know if Renesas plans to release any more rzn1's in this series,
but my little finger tells me this isn't the case. But regardless of what
we plan, Marketing will screw it up.

Cheers,
Michel


> > @@ -0,0 +1,187 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * RZ/N1 clock IDs
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
> > + *
> > + * Michel Pollet , 
> > + * Derived from zx-reboot.c
> > + */
> > +
> > +#ifndef __DT_BINDINGS_RZN1_CLOCK_H__
> > +#define __DT_BINDINGS_RZN1_CLOCK_H__
> > +
> > +#define RZN1_CLKOUT0

> Similar for the RZN1 prefix.

> I'll look at the actual list of clocks later...

> 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 6/9] ARM: dts: wheat: Drop MTD partitioning from DT

[Geert Uytterhoeven]

Hi Marek,

On Wed, May 23, 2018 at 12:01 AM, Marek Vasut  wrote:
> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut  wrote:
>>> Drop the MTD partitioning from DT, since it does not describe HW
>>> and to give way to a more flexible kernel command line partition
>>> passing.
>>>
>>> To retain the original partitioning, assure you have enabled
>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
>>> following to your kernel command line:
>>>
>>>   mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
>>
>> I think the "@0" can be dropped, as it's optional?
>> 4m?
>
> My take on this is that the loader is actually at offset 0x0 of the MTD
> device and we explicitly state that in the mtdparts to anchor the first
> partition within the MTD device and all the other partitions are at
> offset +(sum of the sizes of all partitions listed before the current
> one) relative to that first partition.

Where is this explicitly states for the first partition?

> Removing the @0 feels fragile at best and it seems to depend on the
> current behavior of the code.

Better, it also depends on the documented behavior:

Documentation/admin-guide/kernel-parameters.txt refers to
drivers/mtd/cmdlinepart.c, which states:

 *   := standard linux memsize
 *  if omitted the part will immediately follow the previous part
 *  or 0 if the first part

None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
help text, or in a defconfig bundled with the kernel, use @0 for the first
partition.

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] PCI: rcar: Teardown MSI setup if rcar_pcie_enable() fails

[Geert Uytterhoeven]

Hi Marek,

On Tue, May 22, 2018 at 11:53 PM, Marek Vasut  wrote:
> On 05/22/2018 08:36 PM, Geert Uytterhoeven wrote:
>> On Mon, May 21, 2018 at 3:11 PM, Marek Vasut  wrote:
>>> --- a/drivers/pci/host/pcie-rcar.c
>>> +++ b/drivers/pci/host/pcie-rcar.c
>>> @@ -900,6 +900,28 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
>>> return err;
>>>  }
>>>
>>> +static void rcar_pcie_teardown_msi(struct rcar_pcie *pcie)
>>> +{
>>> +   struct rcar_msi *msi = >msi;
>>> +   int irq, i;
>>> +
>>> +   /* Disable all MSI interrupts */
>>> +   rcar_pci_write_reg(pcie, 0, PCIEMSIIER);
>>> +
>>> +   /* Disable address decoding of the MSI interrupt, MSIFE */
>>> +   rcar_pci_write_reg(pcie, 0, PCIEMSIALR);
>>> +
>>> +   free_pages(msi->pages, 0);
>>> +
>>> +   for (i = 0; i < INT_PCI_MSI_NR; i++) {
>>> +   irq = irq_find_mapping(msi->domain, i);
>>> +   if (irq > 0)
>>> +   irq_dispose_mapping(irq);
>>> +   }
>>
>> Note that similar calls to irq_dispose_mapping() should be added to the
>> failure path of rcar_pcie_enable_msi(), too.
>
> There are no failures happening in rcar_pcie_enable_msi() after the
> mapping is created, just memory writes, so no. Did I miss something there ?

In my copy, there are two calls to devm_request_irq(). If they fail, the
IRQ domain is removed, but the mappings are never disposed of.

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