[PATCH v3 00/06] clocksource: sh_cmt: DT binding rework V3

[PATCH v3 00/06] clocksource: sh_cmt: DT binding rework V3

[Magnus Damm]

clocksource: sh_cmt: DT binding rework V3

[PATCH v3 01/06] devicetree: bindings: Remove sh7372 CMT binding
[PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
[PATCH v3 03/06] devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings
[PATCH v3 04/06] devicetree: bindings: Deprecate property, update example
[PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings
[PATCH v3 06/06] devicetree: bindings: Remove deprecated properties

Here are 6 patches that update the CMT DT bindings. All patches have
acks and are ready to be picked up and merged. Other changes such
as driver modification and SoC DTS bits depend on this series.

In short, this series reworks the CMT DT bindings to deal with the following:
- R-Car Gen2 CMT0 and CMT1 hardware instances are not identical
- The property renesas,channels-mask is not enough to describe the difference
- DT should describe the hardware, not the software implementation
- Not all documented DT bindings are actually used

Without these patches the binding "renesas,cmt-48-gen2" is used for both
CMT0 and CMT1 on R-Car Gen2 SoCs. CMT0 and CMT1 are currently seen by the
Linux device driver as compatible hardware, and the device-specific property
"renesas,channels-mask" is used to point out some of the hardware configuration
differences. Since the driver is not feature complete only some differences are
described and when diving into the data sheet we can see that:

1) CMT0 is not 48-bit at all, instead it only supports 32-bit counters.
2) Some channels of CMT1 are 48-bit, some 32-bit.
3) A couple of CMT1 channels have even more features.

It turns out that none of the above differences are described in our current
DT files. And since we use the same compat string for CMT0 and CMT1 the driver
itself cannot enable features specific only to CMT1 without first updating
the DTS. So this series is ground work for future feature patches.

It seems that we have two choices if we want to support CMT1 features:
A) Keep existing DT bindings, add more properties for CMT1
B) Rework the compatible strings and keep configuration in the driver

Judging by above it seems that DT update is inevitable. In my mind it is
rather painful to update the DT so I'd like to minimize the number of
updates and let the majority of the changes only happen in the driver.
And since we should really describe hardware in DT but driver features tend
to be implemented incrementally then B) seems like a good fit to me.

I wouldn't mind going with A) but to be honest I must say that the existing
compat string "renesas,cmt-48-gen2" is just too confusing with "48"
(when CMT0 is 32bit-only) and also "gen2" (used without product line R-Car).

Because of that I've gone with B) and reworked the bindings to separate
CMT0 from CMT1 and keep channel configuration in the device driver.

While at it I've deprecated "renesas,channels-mask" and the old DT compat
strings. Per-SoC compat strings have also been reworked, but are not left
around documented as deprecated since they were never used by the driver.

V3 patch series drops everything but DT binding documentation patches
and also adds acks from Rob Herring. Actual patches are unchanged.

Many thanks to Geert, Laurent and Rob for their feedback!

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (For patch 1-3)
Acked-by: Rob Herring <robh@kernel.org>
---

 Written against renesas-drivers-2016-02-09-v4.5-rc3

 Documentation/devicetree/bindings/timer/renesas,cmt.txt |   85 ++++++---------
 1 file changed, 38 insertions(+), 47 deletions(-)

[PATCH v3 01/06] devicetree: bindings: Remove sh7372 CMT binding

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Remove the sh7372 CMT compat string to reduce maintenance burden.

It should be fine to break DT compatibility because:
1) The sh7372 SoC support has been removed from upstream
2) The sh7372 CMT DT binding was never part of upstream DTS
3) The CMT driver never matches on the sh7372 binding

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---

 Changes since V2:
 - Added Acked-by from Rob
 - Removed Tested-by tag from DT binding patch - duh!

 Changes since V1:
 - Removed all references to sh7372
 - Added Acked-by and Tested-by from Geert
 - Added Acked-by from Laurent

 Documentation/devicetree/bindings/timer/renesas,cmt.txt |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

--- 0001/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt	2015-09-17 17:22:52.420513000 +0900
@@ -14,32 +14,26 @@ Required Properties:
   - compatible: must contain one or more of the following:
     - "renesas,cmt-32-r8a7740" for the r8a7740 32-bit CMT
 		(CMT0)
-    - "renesas,cmt-32-sh7372" for the sh7372 32-bit CMT
-		(CMT0)
     - "renesas,cmt-32-sh73a0" for the sh73a0 32-bit CMT
 		(CMT0)
     - "renesas,cmt-32" for all 32-bit CMT without fast clock support
-		(CMT0 on sh7372, sh73a0 and r8a7740)
+		(CMT0 on sh73a0 and r8a7740)
 		This is a fallback for the above renesas,cmt-32-* entries.
 
     - "renesas,cmt-32-fast-r8a7740" for the r8a7740 32-bit CMT with fast
 		clock support (CMT[234])
-    - "renesas,cmt-32-fast-sh7372" for the sh7372 32-bit CMT with fast
-		clock support (CMT[234])
     - "renesas,cmt-32-fast-sh73a0" for the sh73A0 32-bit CMT with fast
 		clock support (CMT[234])
     - "renesas,cmt-32-fast" for all 32-bit CMT with fast clock support
-		(CMT[234] on sh7372, sh73a0 and r8a7740)
+		(CMT[234] on sh73a0 and r8a7740)
 		This is a fallback for the above renesas,cmt-32-fast-* entries.
 
-    - "renesas,cmt-48-sh7372" for the sh7372 48-bit CMT
-		(CMT1)
     - "renesas,cmt-48-sh73a0" for the sh73A0 48-bit CMT
 		(CMT1)
     - "renesas,cmt-48-r8a7740" for the r8a7740 48-bit CMT
 		(CMT1)
     - "renesas,cmt-48" for all non-second generation 48-bit CMT
-		(CMT1 on sh7372, sh73a0 and r8a7740)
+		(CMT1 on sh73a0 and r8a7740)
 		This is a fallback for the above renesas,cmt-48-* entries.
 
     - "renesas,cmt-48-r8a73a4" for the r8a73a4 48-bit CMT

Re: [PATCH v3 01/06] devicetree: bindings: Remove sh7372 CMT binding

[Simon Horman]

On Tue, Feb 16, 2016 at 04:17:31PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Remove the sh7372 CMT compat string to reduce maintenance burden.
> 
> It should be fine to break DT compatibility because:
> 1) The sh7372 SoC support has been removed from upstream
> 2) The sh7372 CMT DT binding was never part of upstream DTS
> 3) The CMT driver never matches on the sh7372 binding

A trifecta!

> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Rob Herring <robh@kernel.org>

I'd like to join this Ack-party!

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Re: [PATCH v3 01/06] devicetree: bindings: Remove sh7372 CMT binding

[Simon Horman]

On Tue, Feb 16, 2016 at 04:17:31PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> 
> Remove the sh7372 CMT compat string to reduce maintenance burden.
> 
> It should be fine to break DT compatibility because:
> 1) The sh7372 SoC support has been removed from upstream
> 2) The sh7372 CMT DT binding was never part of upstream DTS
> 3) The CMT driver never matches on the sh7372 binding

A trifecta!

> 
> Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> Acked-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> Acked-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

I'd like to join this Ack-party!

Acked-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Add documentation for new separate CMT0 and CMT1 DT compatible strings
for R-Car Gen2. These compat strings allow us to enable CMT1-specific
features in the driver. The old compat strings will be deprecated in
the not so distant future.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---

 Changes since V2:
 - Added Acked-by from Rob
 - Removed Tested-by tag from DT binding patch - duh!

 Changes since V1:
 - Added Acked-by and Tested-by from Geert
 - Added Acked-by from Laurent

 Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
 1 file changed, 3 insertions(+)

--- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt	2015-09-17 17:26:57.440513000 +0900
@@ -36,6 +36,9 @@ Required Properties:
 		(CMT1 on sh73a0 and r8a7740)
 		This is a fallback for the above renesas,cmt-48-* entries.
 
+    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
+    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
+
     - "renesas,cmt-48-r8a73a4" for the r8a73a4 48-bit CMT
 		(CMT[01])
     - "renesas,cmt-48-r8a7790" for the r8a7790 48-bit CMT

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Geert Uytterhoeven]

On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Add documentation for new separate CMT0 and CMT1 DT compatible strings
> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
> features in the driver. The old compat strings will be deprecated in
> the not so distant future.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>
>  Changes since V2:
>  - Added Acked-by from Rob
>  - Removed Tested-by tag from DT binding patch - duh!
>
>  Changes since V1:
>  - Added Acked-by and Tested-by from Geert
>  - Added Acked-by from Laurent
>
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
>  1 file changed, 3 insertions(+)
>
> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt        2015-09-17 17:26:57.440513000 +0900
> @@ -36,6 +36,9 @@ Required Properties:
>                 (CMT1 on sh73a0 and r8a7740)
>                 This is a fallback for the above renesas,cmt-48-* entries.
>
> +    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
> +    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.

(advancing a few months always means more comments ;-)

I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

Hi Geert,

On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> From: Magnus Damm <damm+renesas@opensource.se>
>>
>> Add documentation for new separate CMT0 and CMT1 DT compatible strings
>> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
>> features in the driver. The old compat strings will be deprecated in
>> the not so distant future.
>>
>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>>
>>  Changes since V2:
>>  - Added Acked-by from Rob
>>  - Removed Tested-by tag from DT binding patch - duh!
>>
>>  Changes since V1:
>>  - Added Acked-by and Tested-by from Geert
>>  - Added Acked-by from Laurent
>>
>>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
>>  1 file changed, 3 insertions(+)
>>
>> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt        2015-09-17 17:26:57.440513000 +0900
>> @@ -36,6 +36,9 @@ Required Properties:
>>                 (CMT1 on sh73a0 and r8a7740)
>>                 This is a fallback for the above renesas,cmt-48-* entries.
>>
>> +    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
>> +    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
>
> (advancing a few months always means more comments ;-)

Indeed!

> I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?

I have no strong feelings one way or the other, but I agree that
aiming to make things more consistent must be good.

Your proposal makes the fallback match with what we do for a bunch
other devices on R-Car Gen2 like:
"rcar-gen2-cpg-clocks"
"rcar-gen2-scif"
But we also seem to have:
"pci-rcar-gen2"

On R-Car Gen3 we seem to have the following per-SoC compat strings:
"dmac-r8a7795"
"etheravb-r8a7795"
"gpio-r8a7795"
"scif-r8a7795"
But we also have:
"r8a7795-cpg-mssr"

My only feeling is that it looks a tad odd if we follow
"<vendor>,<family-generation>-<device>" for fallback strings but
"<vendor>,<device>-<part-number>" for the per-soc binding. Why not
using the same order? Maybe this is specified in some document
somewhere?

I guess your take with "r8a7795-cpg-mssr" above is to follow the same
order as for the fallback case? This seems sane to me, and if so then
perhaps the per-soc compat strings for the CMT should also be updated?
Same for other devices too then, like the recently added
"dmac-r8a7795"?

Cheers,

/ magnus

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

Hi Geert,

On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
>>
>> Add documentation for new separate CMT0 and CMT1 DT compatible strings
>> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
>> features in the driver. The old compat strings will be deprecated in
>> the not so distant future.
>>
>> Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
>> Acked-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>> Acked-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>>
>>  Changes since V2:
>>  - Added Acked-by from Rob
>>  - Removed Tested-by tag from DT binding patch - duh!
>>
>>  Changes since V1:
>>  - Added Acked-by and Tested-by from Geert
>>  - Added Acked-by from Laurent
>>
>>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
>>  1 file changed, 3 insertions(+)
>>
>> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt        2015-09-17 17:26:57.440513000 +0900
>> @@ -36,6 +36,9 @@ Required Properties:
>>                 (CMT1 on sh73a0 and r8a7740)
>>                 This is a fallback for the above renesas,cmt-48-* entries.
>>
>> +    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
>> +    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
>
> (advancing a few months always means more comments ;-)

Indeed!

> I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?

I have no strong feelings one way or the other, but I agree that
aiming to make things more consistent must be good.

Your proposal makes the fallback match with what we do for a bunch
other devices on R-Car Gen2 like:
"rcar-gen2-cpg-clocks"
"rcar-gen2-scif"
But we also seem to have:
"pci-rcar-gen2"

On R-Car Gen3 we seem to have the following per-SoC compat strings:
"dmac-r8a7795"
"etheravb-r8a7795"
"gpio-r8a7795"
"scif-r8a7795"
But we also have:
"r8a7795-cpg-mssr"

My only feeling is that it looks a tad odd if we follow
"<vendor>,<family-generation>-<device>" for fallback strings but
"<vendor>,<device>-<part-number>" for the per-soc binding. Why not
using the same order? Maybe this is specified in some document
somewhere?

I guess your take with "r8a7795-cpg-mssr" above is to follow the same
order as for the fallback case? This seems sane to me, and if so then
perhaps the per-soc compat strings for the CMT should also be updated?
Same for other devices too then, like the recently added
"dmac-r8a7795"?

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Simon Horman]

On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
> Hi Geert,
> 
> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> >> From: Magnus Damm <damm+renesas@opensource.se>
> >>
> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
> >> features in the driver. The old compat strings will be deprecated in
> >> the not so distant future.
> >>
> >> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> >> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> Acked-by: Rob Herring <robh@kernel.org>
> >> ---
> >>
> >>  Changes since V2:
> >>  - Added Acked-by from Rob
> >>  - Removed Tested-by tag from DT binding patch - duh!
> >>
> >>  Changes since V1:
> >>  - Added Acked-by and Tested-by from Geert
> >>  - Added Acked-by from Laurent
> >>
> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt        2015-09-17 17:26:57.440513000 +0900
> >> @@ -36,6 +36,9 @@ Required Properties:
> >>                 (CMT1 on sh73a0 and r8a7740)
> >>                 This is a fallback for the above renesas,cmt-48-* entries.
> >>
> >> +    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
> >> +    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
> >
> > (advancing a few months always means more comments ;-)
> 
> Indeed!
> 
> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
> 
> I have no strong feelings one way or the other, but I agree that
> aiming to make things more consistent must be good.

FWIW, I agree with Geert's suggestion.
But I also think it is not particularly important.

> Your proposal makes the fallback match with what we do for a bunch
> other devices on R-Car Gen2 like:
> "rcar-gen2-cpg-clocks"
> "rcar-gen2-scif"
> But we also seem to have:
> "pci-rcar-gen2"

Bother, it looks like I got pci backwards :(

> On R-Car Gen3 we seem to have the following per-SoC compat strings:
> "dmac-r8a7795"
> "etheravb-r8a7795"
> "gpio-r8a7795"
> "scif-r8a7795"

I believe the above are to follow the existing pattern for
per-SoC compat strings in the same driver, which seems sane.

> But we also have:
> "r8a7795-cpg-mssr"
> 
> My only feeling is that it looks a tad odd if we follow
> "<vendor>,<family-generation>-<device>" for fallback strings but
> "<vendor>,<device>-<part-number>" for the per-soc binding. Why not
> using the same order? Maybe this is specified in some document
> somewhere?

I believe that the problem is a historical one. Perhaps when
we started adding bindings for our hardware there were no clear
guidelines. But regardless we ended up with a mix as you describe.

In the mean time guidelines have emerged and we (or at least I) have
agreed with the device tree people (probably Rob) to use the
<vendor>,<chip>-<device> format for new bindings. My reading is that
applies even if it results in fallback and non-fallback bindings for the
same driver have different orders. Some precedence for this can now be found
in renesas,rcar-dmac.txt.

I don't, however, think it applies where we add more soc-specific to a
driver that already has such bindings. Or new fallback bindings to a driver
that already has such bindings.

> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
> order as for the fallback case? This seems sane to me, and if so then
> perhaps the per-soc compat strings for the CMT should also be updated?
> Same for other devices too then, like the recently added
> "dmac-r8a7795"?

>From my point of view it would be nice to clean things up and
re-order all the bindings. But I think the drivers would
need to maintain compatibility with the old strings. And I wonder
if it is really worth the effort.

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Simon Horman]

On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
> Hi Geert,
> 
> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> >>
> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
> >> features in the driver. The old compat strings will be deprecated in
> >> the not so distant future.
> >>
> >> Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> >> Acked-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> >> Acked-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> >> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> ---
> >>
> >>  Changes since V2:
> >>  - Added Acked-by from Rob
> >>  - Removed Tested-by tag from DT binding patch - duh!
> >>
> >>  Changes since V1:
> >>  - Added Acked-by and Tested-by from Geert
> >>  - Added Acked-by from Laurent
> >>
> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt        2015-09-17 17:26:57.440513000 +0900
> >> @@ -36,6 +36,9 @@ Required Properties:
> >>                 (CMT1 on sh73a0 and r8a7740)
> >>                 This is a fallback for the above renesas,cmt-48-* entries.
> >>
> >> +    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
> >> +    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
> >
> > (advancing a few months always means more comments ;-)
> 
> Indeed!
> 
> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
> 
> I have no strong feelings one way or the other, but I agree that
> aiming to make things more consistent must be good.

FWIW, I agree with Geert's suggestion.
But I also think it is not particularly important.

> Your proposal makes the fallback match with what we do for a bunch
> other devices on R-Car Gen2 like:
> "rcar-gen2-cpg-clocks"
> "rcar-gen2-scif"
> But we also seem to have:
> "pci-rcar-gen2"

Bother, it looks like I got pci backwards :(

> On R-Car Gen3 we seem to have the following per-SoC compat strings:
> "dmac-r8a7795"
> "etheravb-r8a7795"
> "gpio-r8a7795"
> "scif-r8a7795"

I believe the above are to follow the existing pattern for
per-SoC compat strings in the same driver, which seems sane.

> But we also have:
> "r8a7795-cpg-mssr"
> 
> My only feeling is that it looks a tad odd if we follow
> "<vendor>,<family-generation>-<device>" for fallback strings but
> "<vendor>,<device>-<part-number>" for the per-soc binding. Why not
> using the same order? Maybe this is specified in some document
> somewhere?

I believe that the problem is a historical one. Perhaps when
we started adding bindings for our hardware there were no clear
guidelines. But regardless we ended up with a mix as you describe.

In the mean time guidelines have emerged and we (or at least I) have
agreed with the device tree people (probably Rob) to use the
<vendor>,<chip>-<device> format for new bindings. My reading is that
applies even if it results in fallback and non-fallback bindings for the
same driver have different orders. Some precedence for this can now be found
in renesas,rcar-dmac.txt.

I don't, however, think it applies where we add more soc-specific to a
driver that already has such bindings. Or new fallback bindings to a driver
that already has such bindings.

> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
> order as for the fallback case? This seems sane to me, and if so then
> perhaps the per-soc compat strings for the CMT should also be updated?
> Same for other devices too then, like the recently added
> "dmac-r8a7795"?

>From my point of view it would be nice to clean things up and
re-order all the bindings. But I think the drivers would
need to maintain compatibility with the old strings. And I wonder
if it is really worth the effort.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

Hi Simon,

On Wed, Feb 17, 2016 at 3:28 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
>> Hi Geert,
>>
>> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> >> From: Magnus Damm <damm+renesas@opensource.se>
>> >>
>> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
>> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
>> >> features in the driver. The old compat strings will be deprecated in
>> >> the not so distant future.
>> >>
>> >> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>> >> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> >> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> >> Acked-by: Rob Herring <robh@kernel.org>
>> >> ---
>> >>
>> >>  Changes since V2:
>> >>  - Added Acked-by from Rob
>> >>  - Removed Tested-by tag from DT binding patch - duh!
>> >>
>> >>  Changes since V1:
>> >>  - Added Acked-by and Tested-by from Geert
>> >>  - Added Acked-by from Laurent
>> >>
>> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt        2015-09-17 17:26:57.440513000 +0900
>> >> @@ -36,6 +36,9 @@ Required Properties:
>> >>                 (CMT1 on sh73a0 and r8a7740)
>> >>                 This is a fallback for the above renesas,cmt-48-* entries.
>> >>
>> >> +    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
>> >> +    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
>> >
>> > (advancing a few months always means more comments ;-)
>>
>> Indeed!
>>
>> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
>>
>> I have no strong feelings one way or the other, but I agree that
>> aiming to make things more consistent must be good.
>
> FWIW, I agree with Geert's suggestion.
> But I also think it is not particularly important.
>
>> Your proposal makes the fallback match with what we do for a bunch
>> other devices on R-Car Gen2 like:
>> "rcar-gen2-cpg-clocks"
>> "rcar-gen2-scif"
>> But we also seem to have:
>> "pci-rcar-gen2"
>
> Bother, it looks like I got pci backwards :(
>
>> On R-Car Gen3 we seem to have the following per-SoC compat strings:
>> "dmac-r8a7795"
>> "etheravb-r8a7795"
>> "gpio-r8a7795"
>> "scif-r8a7795"
>
> I believe the above are to follow the existing pattern for
> per-SoC compat strings in the same driver, which seems sane.
>
>> But we also have:
>> "r8a7795-cpg-mssr"
>>
>> My only feeling is that it looks a tad odd if we follow
>> "<vendor>,<family-generation>-<device>" for fallback strings but
>> "<vendor>,<device>-<part-number>" for the per-soc binding. Why not
>> using the same order? Maybe this is specified in some document
>> somewhere?
>
> I believe that the problem is a historical one. Perhaps when
> we started adding bindings for our hardware there were no clear
> guidelines. But regardless we ended up with a mix as you describe.

Right, that seems to be the way things have happened.

> In the mean time guidelines have emerged and we (or at least I) have
> agreed with the device tree people (probably Rob) to use the
> <vendor>,<chip>-<device> format for new bindings. My reading is that
> applies even if it results in fallback and non-fallback bindings for the
> same driver have different orders. Some precedence for this can now be found
> in renesas,rcar-dmac.txt.

Some sort of agreed format sounds good.

Your proposal of <vendor>,<chip>-<device> sounds good to me.

I'm however slightly more confused by seeing that your example
renesas,rcar-dmac.txt included in renesas-drivers-2016-02-16-v4.5-rc4
does not match the proposed format:

$ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
- compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback.
        - "renesas,dmac-r8a7790" (R-Car H2)
        - "renesas,dmac-r8a7791" (R-Car M2-W)
        - "renesas,dmac-r8a7792" (R-Car V2H)
        - "renesas,dmac-r8a7793" (R-Car M2-N)
        - "renesas,dmac-r8a7794" (R-Car E2)
        - "renesas,dmac-r8a7795" (R-Car H3)
        compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
        compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
$

> I don't, however, think it applies where we add more soc-specific to a
> driver that already has such bindings. Or new fallback bindings to a driver
> that already has such bindings.

Right, but for rcar-dmac.c there is no matching on per-SoC strings in
the driver so I guess we can pick anything we want?

$ grep "renesas," drivers/dma/sh/rcar-dmac.c
    { .compatible = "renesas,rcar-dmac", },
$

>> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
>> order as for the fallback case? This seems sane to me, and if so then
>> perhaps the per-soc compat strings for the CMT should also be updated?
>> Same for other devices too then, like the recently added
>> "dmac-r8a7795"?
>
> From my point of view it would be nice to clean things up and
> re-order all the bindings. But I think the drivers would
> need to maintain compatibility with the old strings. And I wonder
> if it is really worth the effort.

No need to rework existing stuff IMO. However once we rework DT
bindings (CMT) or add new ones (SYS-DMAC) then we have a good
opportunity to clean things up.

Thanks,

/ magnus

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Simon Horman]

On Wed, Feb 17, 2016 at 03:45:19PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Feb 17, 2016 at 3:28 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
> >> Hi Geert,
> >>
> >> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> >> >> From: Magnus Damm <damm+renesas@opensource.se>
> >> >>
> >> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
> >> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
> >> >> features in the driver. The old compat strings will be deprecated in
> >> >> the not so distant future.
> >> >>
> >> >> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> >> >> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> >> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> >> Acked-by: Rob Herring <robh@kernel.org>
> >> >> ---
> >> >>
> >> >>  Changes since V2:
> >> >>  - Added Acked-by from Rob
> >> >>  - Removed Tested-by tag from DT binding patch - duh!
> >> >>
> >> >>  Changes since V1:
> >> >>  - Added Acked-by and Tested-by from Geert
> >> >>  - Added Acked-by from Laurent
> >> >>
> >> >>  Documentation/devicetree/bindings/timer/renesas,cmt.txt |    3 +++
> >> >>  1 file changed, 3 insertions(+)
> >> >>
> >> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> >> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt        2015-09-17 17:26:57.440513000 +0900
> >> >> @@ -36,6 +36,9 @@ Required Properties:
> >> >>                 (CMT1 on sh73a0 and r8a7740)
> >> >>                 This is a fallback for the above renesas,cmt-48-* entries.
> >> >>
> >> >> +    - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
> >> >> +    - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
> >> >
> >> > (advancing a few months always means more comments ;-)
> >>
> >> Indeed!
> >>
> >> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
> >>
> >> I have no strong feelings one way or the other, but I agree that
> >> aiming to make things more consistent must be good.
> >
> > FWIW, I agree with Geert's suggestion.
> > But I also think it is not particularly important.
> >
> >> Your proposal makes the fallback match with what we do for a bunch
> >> other devices on R-Car Gen2 like:
> >> "rcar-gen2-cpg-clocks"
> >> "rcar-gen2-scif"
> >> But we also seem to have:
> >> "pci-rcar-gen2"
> >
> > Bother, it looks like I got pci backwards :(
> >
> >> On R-Car Gen3 we seem to have the following per-SoC compat strings:
> >> "dmac-r8a7795"
> >> "etheravb-r8a7795"
> >> "gpio-r8a7795"
> >> "scif-r8a7795"
> >
> > I believe the above are to follow the existing pattern for
> > per-SoC compat strings in the same driver, which seems sane.
> >
> >> But we also have:
> >> "r8a7795-cpg-mssr"
> >>
> >> My only feeling is that it looks a tad odd if we follow
> >> "<vendor>,<family-generation>-<device>" for fallback strings but
> >> "<vendor>,<device>-<part-number>" for the per-soc binding. Why not
> >> using the same order? Maybe this is specified in some document
> >> somewhere?
> >
> > I believe that the problem is a historical one. Perhaps when
> > we started adding bindings for our hardware there were no clear
> > guidelines. But regardless we ended up with a mix as you describe.
> 
> Right, that seems to be the way things have happened.
> 
> > In the mean time guidelines have emerged and we (or at least I) have
> > agreed with the device tree people (probably Rob) to use the
> > <vendor>,<chip>-<device> format for new bindings. My reading is that
> > applies even if it results in fallback and non-fallback bindings for the
> > same driver have different orders. Some precedence for this can now be found
> > in renesas,rcar-dmac.txt.
> 
> Some sort of agreed format sounds good.
> 
> Your proposal of <vendor>,<chip>-<device> sounds good to me.
> 
> I'm however slightly more confused by seeing that your example
> renesas,rcar-dmac.txt included in renesas-drivers-2016-02-16-v4.5-rc4
> does not match the proposed format:
> 
> $ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> - compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback.
>         - "renesas,dmac-r8a7790" (R-Car H2)
>         - "renesas,dmac-r8a7791" (R-Car M2-W)
>         - "renesas,dmac-r8a7792" (R-Car V2H)
>         - "renesas,dmac-r8a7793" (R-Car M2-N)
>         - "renesas,dmac-r8a7794" (R-Car E2)
>         - "renesas,dmac-r8a7795" (R-Car H3)
>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
> $

It looks like I have been making the mess worse :(

Possibly I prepared the patch in question, though recently,
before I was properly aware of the preferred order.

> > I don't, however, think it applies where we add more soc-specific to a
> > driver that already has such bindings. Or new fallback bindings to a driver
> > that already has such bindings.
> 
> Right, but for rcar-dmac.c there is no matching on per-SoC strings in
> the driver so I guess we can pick anything we want?
> 
> $ grep "renesas," drivers/dma/sh/rcar-dmac.c
>     { .compatible = "renesas,rcar-dmac", },
> $

Pretty much.

> >> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
> >> order as for the fallback case? This seems sane to me, and if so then
> >> perhaps the per-soc compat strings for the CMT should also be updated?
> >> Same for other devices too then, like the recently added
> >> "dmac-r8a7795"?
> >
> > From my point of view it would be nice to clean things up and
> > re-order all the bindings. But I think the drivers would
> > need to maintain compatibility with the old strings. And I wonder
> > if it is really worth the effort.
> 
> No need to rework existing stuff IMO. However once we rework DT
> bindings (CMT) or add new ones (SYS-DMAC) then we have a good
> opportunity to clean things up.

Understood. From my point of view that seems like an opportunity worth taking.

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

Hi Simon,

On Wed, Feb 17, 2016 at 9:08 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Feb 17, 2016 at 03:45:19PM +0900, Magnus Damm wrote:
>> $ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
>> - compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback.
>>         - "renesas,dmac-r8a7790" (R-Car H2)
>>         - "renesas,dmac-r8a7791" (R-Car M2-W)
>>         - "renesas,dmac-r8a7792" (R-Car V2H)
>>         - "renesas,dmac-r8a7793" (R-Car M2-N)
>>         - "renesas,dmac-r8a7794" (R-Car E2)
>>         - "renesas,dmac-r8a7795" (R-Car H3)
>>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
>>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
>> $
>
> It looks like I have been making the mess worse :(
>
> Possibly I prepared the patch in question, though recently,
> before I was properly aware of the preferred order.

No worries! The code above is at least consistent and matches the
common current case.

>> No need to rework existing stuff IMO. However once we rework DT
>> bindings (CMT) or add new ones (SYS-DMAC) then we have a good
>> opportunity to clean things up.
>
> Understood. From my point of view that seems like an opportunity worth taking.

So shall we leave the SYS-DMAC as-is or change things around? I
personally don't see the point in redoing things just to change order,
so keep as-is sounds good to me.

For the "fallback" CMT DT compat strings I think we should follow the
proposal from Geert and go with "renesas,rcar-gen2-cmt0". Regarding
the per-soc CMT DT compat strings my feeling is that we should follow
the same order as SYS-DMAC to keep things consistent.

Thanks,

/ magnus

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Magnus Damm]

Hi Simon,

On Wed, Feb 17, 2016 at 9:08 PM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> On Wed, Feb 17, 2016 at 03:45:19PM +0900, Magnus Damm wrote:
>> $ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
>> - compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback.
>>         - "renesas,dmac-r8a7790" (R-Car H2)
>>         - "renesas,dmac-r8a7791" (R-Car M2-W)
>>         - "renesas,dmac-r8a7792" (R-Car V2H)
>>         - "renesas,dmac-r8a7793" (R-Car M2-N)
>>         - "renesas,dmac-r8a7794" (R-Car E2)
>>         - "renesas,dmac-r8a7795" (R-Car H3)
>>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
>>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
>> $
>
> It looks like I have been making the mess worse :(
>
> Possibly I prepared the patch in question, though recently,
> before I was properly aware of the preferred order.

No worries! The code above is at least consistent and matches the
common current case.

>> No need to rework existing stuff IMO. However once we rework DT
>> bindings (CMT) or add new ones (SYS-DMAC) then we have a good
>> opportunity to clean things up.
>
> Understood. From my point of view that seems like an opportunity worth taking.

So shall we leave the SYS-DMAC as-is or change things around? I
personally don't see the point in redoing things just to change order,
so keep as-is sounds good to me.

For the "fallback" CMT DT compat strings I think we should follow the
proposal from Geert and go with "renesas,rcar-gen2-cmt0". Regarding
the per-soc CMT DT compat strings my feeling is that we should follow
the same order as SYS-DMAC to keep things consistent.

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings

[Simon Horman]

On Wed, Feb 24, 2016 at 01:19:25PM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Feb 17, 2016 at 9:08 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Feb 17, 2016 at 03:45:19PM +0900, Magnus Damm wrote:
> >> $ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> >> - compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback.
> >>         - "renesas,dmac-r8a7790" (R-Car H2)
> >>         - "renesas,dmac-r8a7791" (R-Car M2-W)
> >>         - "renesas,dmac-r8a7792" (R-Car V2H)
> >>         - "renesas,dmac-r8a7793" (R-Car M2-N)
> >>         - "renesas,dmac-r8a7794" (R-Car E2)
> >>         - "renesas,dmac-r8a7795" (R-Car H3)
> >>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
> >>         compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
> >> $
> >
> > It looks like I have been making the mess worse :(
> >
> > Possibly I prepared the patch in question, though recently,
> > before I was properly aware of the preferred order.
> 
> No worries! The code above is at least consistent and matches the
> common current case.
> 
> >> No need to rework existing stuff IMO. However once we rework DT
> >> bindings (CMT) or add new ones (SYS-DMAC) then we have a good
> >> opportunity to clean things up.
> >
> > Understood. From my point of view that seems like an opportunity worth taking.
> 
> So shall we leave the SYS-DMAC as-is or change things around? I
> personally don't see the point in redoing things just to change order,
> so keep as-is sounds good to me.
> 
> For the "fallback" CMT DT compat strings I think we should follow the
> proposal from Geert and go with "renesas,rcar-gen2-cmt0". Regarding
> the per-soc CMT DT compat strings my feeling is that we should follow
> the same order as SYS-DMAC to keep things consistent.

I would lean towards changing the order of the per-soc CMT DT compat
strings but I do not feel strongly about it.

As for the rest of your proposal above: I agree without reservation.

[PATCH v3 03/06] devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Update SoC-specific bindings for r8a73a4 and R-Car Gen2 CMT0 and CMT1.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---

 Changes since V2:
 - Added Acked-by from Rob
 - Removed Tested-by tag from DT binding patch - duh!

 Changes since V1:
 - Added Acked-by and Tested-by from Geert
 - Added Acked-by from Laurent

 Documentation/devicetree/bindings/timer/renesas,cmt.txt |   26 ++++++++-------
 1 file changed, 15 insertions(+), 11 deletions(-)

--- 0005/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt	2015-09-17 17:31:02.650513000 +0900
@@ -36,20 +36,24 @@ Required Properties:
 		(CMT1 on sh73a0 and r8a7740)
 		This is a fallback for the above renesas,cmt-48-* entries.
 
+    - "renesas,cmt0-r8a73a4" for the 32-bit CMT0 device included in r8a73a4.
+    - "renesas,cmt1-r8a73a4" for the 48-bit CMT1 device included in r8a73a4.
+    - "renesas,cmt0-r8a7790" for the 32-bit CMT0 device included in r8a7790.
+    - "renesas,cmt1-r8a7790" for the 48-bit CMT1 device included in r8a7790.
+    - "renesas,cmt0-r8a7791" for the 32-bit CMT0 device included in r8a7791.
+    - "renesas,cmt1-r8a7791" for the 48-bit CMT1 device included in r8a7791.
+    - "renesas,cmt0-r8a7793" for the 32-bit CMT0 device included in r8a7793.
+    - "renesas,cmt1-r8a7793" for the 48-bit CMT1 device included in r8a7793.
+    - "renesas,cmt0-r8a7794" for the 32-bit CMT0 device included in r8a7794.
+    - "renesas,cmt1-r8a7794" for the 48-bit CMT1 device included in r8a7794.
+
     - "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car Gen2.
     - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
+		These are fallbacks for r8a73a4 and all the R-Car Gen2
+		entries	listed above.
 
-    - "renesas,cmt-48-r8a73a4" for the r8a73a4 48-bit CMT
-		(CMT[01])
-    - "renesas,cmt-48-r8a7790" for the r8a7790 48-bit CMT
-		(CMT[01])
-    - "renesas,cmt-48-r8a7791" for the r8a7791 48-bit CMT
-		(CMT[01])
-    - "renesas,cmt-48-gen2" for all second generation 48-bit CMT
-		(CMT[01] on r8a73a4, r8a7790 and r8a7791)
-		This is a fallback for the renesas,cmt-48-r8a73a4,
-		renesas,cmt-48-r8a7790 and renesas,cmt-48-r8a7791 entries.
-
+    - "renesas,cmt-48-gen2" is <deprecated>, use "renesas,cmt[01]-*" instead.
+    
   - reg: base address and length of the registers block for the timer module.
   - interrupts: interrupt-specifier for the timer, one per channel.
   - clocks: a list of phandle + clock-specifier pairs, one for each entry

[PATCH v3 04/06] devicetree: bindings: Deprecate property, update example

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Deprecate "renesas,channels-mask" and update the r8a7790 CMT example.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---

 Changes since V2:
 - Added Acked-by from Rob
 - Removed Tested-by tag from DT binding patch - duh!

 Changes since V1:
 - Added Acked-by and Tested-by from Geert
 - Added Acked-by from Laurent

 Documentation/devicetree/bindings/timer/renesas,cmt.txt |   24 ++++++++++-----
 1 file changed, 17 insertions(+), 7 deletions(-)

--- 0009/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt	2015-09-17 17:39:47.080513000 +0900
@@ -60,21 +60,31 @@ Required Properties:
     in clock-names.
   - clock-names: must contain "fck" for the functional clock.
 
-  - renesas,channels-mask: bitmask of the available channels.
+  - renesas,channels-mask: <deprecated>, information kept in device driver.
 
 
-Example: R8A7790 (R-Car H2) CMT0 node
-
-	CMT0 on R8A7790 implements hardware channels 5 and 6 only and names
-	them channels 0 and 1 in the documentation.
+Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes
 
 	cmt0: timer@ffca0000 {
-		compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2";
+		compatible = "renesas,cmt0-r8a7790", "renesas,cmt0-rcar-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
 		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
 			     <0 142 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_CMT0>;
 		clock-names = "fck";
+	};
 
-		renesas,channels-mask = <0x60>;
+	cmt1: timer@e6130000 {
+		compatible = "renesas,cmt1-r8a7790", "renesas,cmt1-rcar-gen2";
+		reg = <0 0xe6130000 0 0x1004>;
+		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7790_CLK_CMT1>;
+		clock-names = "fck";
 	};

Re: [PATCH v3 04/06] devicetree: bindings: Deprecate property, update example

[Simon Horman]

On Tue, Feb 16, 2016 at 04:17:59PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Deprecate "renesas,channels-mask" and update the r8a7790 CMT example.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Rob Herring <robh@kernel.org>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

[PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

Remove the 32-bit CMT compat strings to reduce maintenance burden.

It should be fine to break DT compatibility because the 32-bit
32-bit CMT DT binding was never part of any upstream DTS file.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
---

 Changes since V2:
 - Added Acked-by from Rob
 - Added Acked-by from Geert

 Changes since V1:
 - New patch

 Documentation/devicetree/bindings/timer/renesas,cmt.txt |   16 ---------------
 1 file changed, 16 deletions(-)

--- 0008/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt	2015-09-17 18:04:35.060513000 +0900
@@ -12,22 +12,6 @@ datasheets.
 Required Properties:
 
   - compatible: must contain one or more of the following:
-    - "renesas,cmt-32-r8a7740" for the r8a7740 32-bit CMT
-		(CMT0)
-    - "renesas,cmt-32-sh73a0" for the sh73a0 32-bit CMT
-		(CMT0)
-    - "renesas,cmt-32" for all 32-bit CMT without fast clock support
-		(CMT0 on sh73a0 and r8a7740)
-		This is a fallback for the above renesas,cmt-32-* entries.
-
-    - "renesas,cmt-32-fast-r8a7740" for the r8a7740 32-bit CMT with fast
-		clock support (CMT[234])
-    - "renesas,cmt-32-fast-sh73a0" for the sh73A0 32-bit CMT with fast
-		clock support (CMT[234])
-    - "renesas,cmt-32-fast" for all 32-bit CMT with fast clock support
-		(CMT[234] on sh73a0 and r8a7740)
-		This is a fallback for the above renesas,cmt-32-fast-* entries.
-
     - "renesas,cmt-48-sh73a0" for the sh73A0 48-bit CMT
 		(CMT1)
     - "renesas,cmt-48-r8a7740" for the r8a7740 48-bit CMT

Re: [PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings

[Sergei Shtylyov]

Hello.

On 2/16/2016 10:18 AM, Magnus Damm wrote:

> From: Magnus Damm <damm+renesas@opensource.se>
>
> Remove the 32-bit CMT compat strings to reduce maintenance burden.
>
> It should be fine to break DT compatibility because the 32-bit
> 32-bit CMT DT binding was never part of any upstream DTS file.

    s/32-bit//. Once is enough. :-)

> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

[...]

MBR, Sergei

Re: [PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings

[Simon Horman]

On Tue, Feb 16, 2016 at 04:18:09PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Remove the 32-bit CMT compat strings to reduce maintenance burden.
> 
> It should be fine to break DT compatibility because the 32-bit
> 32-bit CMT DT binding was never part of any upstream DTS file.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

[PATCH v3 06/06] devicetree: bindings: Remove deprecated properties

[Magnus Damm]

From: Magnus Damm <damm+renesas@opensource.se>

The deprecated DT properties are part of the GIT history,
no need to keep them around any longer.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
---

 Changes since V2:
 - Added Acked-by from Rob
 - Fixed properties typo - Thanks Geert
 - Added Acked-by from Geert

 Changes since V1:
 - New patch

 Documentation/devicetree/bindings/timer/renesas,cmt.txt |    4 ----
 1 file changed, 4 deletions(-)

--- 0011/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt	2015-09-17 18:08:17.000513000 +0900
@@ -35,8 +35,6 @@ Required Properties:
     - "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car Gen2.
 		These are fallbacks for r8a73a4 and all the R-Car Gen2
 		entries	listed above.
-
-    - "renesas,cmt-48-gen2" is <deprecated>, use "renesas,cmt[01]-*" instead.
     
   - reg: base address and length of the registers block for the timer module.
   - interrupts: interrupt-specifier for the timer, one per channel.
@@ -44,8 +42,6 @@ Required Properties:
     in clock-names.
   - clock-names: must contain "fck" for the functional clock.
 
-  - renesas,channels-mask: <deprecated>, information kept in device driver.
-
 
 Example: R8A7790 (R-Car H2) CMT0 and CMT1 nodes
 

Re: [PATCH v3 06/06] devicetree: bindings: Remove deprecated properties

[Simon Horman]

On Tue, Feb 16, 2016 at 04:18:19PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> The deprecated DT properties are part of the GIT history,
> no need to keep them around any longer.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Acked-by: Simon Horman <horms+renesas@verge.net.au>

Re: [PATCH v3 06/06] devicetree: bindings: Remove deprecated properties

[Simon Horman]

On Tue, Feb 16, 2016 at 04:18:19PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> 
> The deprecated DT properties are part of the GIT history,
> no need to keep them around any longer.
> 
> Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>

Acked-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html