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

Commit Message

Magnus Damm Feb. 16, 2016, 7:17 a.m. UTC

From: Magnus Damm <[e-mail]>

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 <[e-mail]>
Acked-by: Geert Uytterhoeven <[e-mail]>
Acked-by: Laurent Pinchart <[e-mail]>
Acked-by: Rob Herring <[e-mail]>
---

 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(+)

Comments

Geert Uytterhoeven Feb. 16, 2016, 1:11 p.m. UTC | #1

On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <[e-mail]> wrote:
> From: Magnus Damm <[e-mail]>
>
> 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 <[e-mail]>
> Acked-by: Geert Uytterhoeven <[e-mail]>
> Acked-by: Laurent Pinchart <[e-mail]>
> Acked-by: Rob Herring <[e-mail]>
> ---
>
>  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 -- [e-mail]

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

Magnus Damm Feb. 17, 2016, 2:33 a.m. UTC | #2

Hi Geert,

On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
<[e-mail]> wrote:
> On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <[e-mail]> wrote:
>> From: Magnus Damm <[e-mail]>
>>
>> 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 <[e-mail]>
>> Acked-by: Geert Uytterhoeven <[e-mail]>
>> Acked-by: Laurent Pinchart <[e-mail]>
>> Acked-by: Rob Herring <[e-mail]>
>> ---
>>
>>  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

Simon Horman Feb. 17, 2016, 6:28 a.m. UTC | #3

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
> <[e-mail]> wrote:
> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <[e-mail]> wrote:
> >> From: Magnus Damm <[e-mail]>
> >>
> >> 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 <[e-mail]>
> >> Acked-by: Geert Uytterhoeven <[e-mail]>
> >> Acked-by: Laurent Pinchart <[e-mail]>
> >> Acked-by: Rob Herring <[e-mail]>
> >> ---
> >>
> >>  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.

Magnus Damm Feb. 17, 2016, 6:45 a.m. UTC | #4

Hi Simon,

On Wed, Feb 17, 2016 at 3:28 PM, Simon Horman <[e-mail]> 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
>> <[e-mail]> wrote:
>> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <[e-mail]> wrote:
>> >> From: Magnus Damm <[e-mail]>
>> >>
>> >> 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 <[e-mail]>
>> >> Acked-by: Geert Uytterhoeven <[e-mail]>
>> >> Acked-by: Laurent Pinchart <[e-mail]>
>> >> Acked-by: Rob Herring <[e-mail]>
>> >> ---
>> >>
>> >>  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

Simon Horman Feb. 17, 2016, 12:08 p.m. UTC | #5

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 <[e-mail]> 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
> >> <[e-mail]> wrote:
> >> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm <[e-mail]> wrote:
> >> >> From: Magnus Damm <[e-mail]>
> >> >>
> >> >> 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 <[e-mail]>
> >> >> Acked-by: Geert Uytterhoeven <[e-mail]>
> >> >> Acked-by: Laurent Pinchart <[e-mail]>
> >> >> Acked-by: Rob Herring <[e-mail]>
> >> >> ---
> >> >>
> >> >>  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.

Magnus Damm Feb. 24, 2016, 4:19 a.m. UTC | #6

Hi Simon,

On Wed, Feb 17, 2016 at 9:08 PM, Simon Horman <[e-mail]> 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

Simon Horman Feb. 24, 2016, 5:10 a.m. UTC | #7

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 <[e-mail]> 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

--- 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