Re: [PATCH] gpiolib: Avoid calling chip->request() for unused gpios
On Tue, Aug 7, 2018 at 9:21 AM Biju Das wrote: > Add a check for unused gpios to avoid chip->request() call to client > driver for unused gpios. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Patch applied with Geert's ACK. Yours, Linus Walleij
Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board
Hello Engeniu, On Fri, Aug 10, 2018 at 03:48:44PM +0200, Eugeniu Rosca wrote: > Hi again Jacopo, > > On Mon, Aug 06, 2018 at 12:40:02AM +0200, Eugeniu Rosca wrote: > > Hi Jacopo, > > > > Thanks for your comments. Please, find my replies below. > > > > On Sun, Aug 05, 2018 at 10:15:43AM +0200, jacopo mondi wrote: > > > Helle Eugeniu, > > > > > > On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote: > > > > In harmony with ATF and U-Boot outputs [1] and [2], the new board is > > > > based on M3-N revision ES1.1 and the amount of memory present on SiP > > > > is 2GiB, contiguously addressed. > > > > > > Not sure why the amount of installed system memory is relevant for > > > this commit.. > > > > To be honest, I don't know precisely what's encoded in the board string > > (particularly the one documented in this commit RTP0RC77965SKBX010SA00). > > > > The only thing unmistakenly present there is the SoC model 77965 (i.e. > > M3-N), but I am quite clueless about the rest. > > > > What I can say for sure is that the end-user experience of a R-Car Gen3 > > reference board clearly depends on below parameters: > > - [A] SoC (model, revision) including SRAM and on-chip peripherals > > - [B] DRAM (amount, linear/2ch/4ch split) > > - [C] Hyperflash (amount) > > - [D] board's PCB (revision) > > - [E] board's off-chip peripherals (model, revision) > > > > I don't know how many of these parameters are embedded in the board > > string, but since you are suggesting that RAM amount is not (IOW > > Renesas will potentially release several RTP0RC77965SKBX010SA00 > > boards with different amounts of memory), I will happily update > > the commit description. > > Since I found two H3-ES2.0 Starter Kit samples with different amount of > RAM (4 vs 8 GiB) each having a unique board id [1], I take this as > evidence that Renesas encodes the amount of RAM in the board id. > Therefore, I will not change the description of this patch in v2, > unless you comment/NAK. Thank you. > Thanks for digging into this, feel free to ignore my comment. > [1] https://patchwork.kernel.org/patch/10555957/#22169325 > > Best regards, > Eugeniu. signature.asc Description: PGP signature
Re: [PATCH] arm64: dts: renesas: r8a77980: add CSI2/VIN support
On 08/09/2018 04:08 PM, Simon Horman wrote:
>> Describe the CSI2 and VIN (and their interconnections) in the R8A77980
>> device tree.
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> This patch is against the 'renesas-devel-20180802v2-v4.18-rc7' branch of
>> Simon Horman's 'renesas.git' repo.
>>
>> The R8A77980 CSI2/VIN DT binding updates have been posted earlier today...
>>
>> arch/arm64/boot/dts/renesas/r8a77980.dtsi | 374
>> ++
>> 1 file changed, 374 insertions(+)
>>
>> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> ===
>> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
>> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
[...]
>> @@ -769,6 +1065,84 @@
>> resets = < 603>;
>> };
>>
>> +csi40: csi2@feaa {
>> +compatible = "renesas,r8a77980-csi2";
>> +reg = <0 0xfeaa 0 0x1>;
>> +interrupts = ;
>> +clocks = < CPG_MOD 716>;
>> +power-domains = < R8A77980_PD_ALWAYS_ON>;
>> +resets = < 716>;
>> +status = "disabled";
>> +
>> +ports {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +port@1 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +reg = <1>;
>> +
>> +csi40vin0: endpoint@0 {
>> +reg = <0>;
>> +remote-endpoint = <>;
>> +};
>> +csi40vin1: endpoint@1 {
>> +reg = <1>;
>> +remote-endpoint = <>;
>> +};
>> +csi40vin2: endpoint@2 {
>> +reg = <2>;
>> +remote-endpoint = <>;
>> +};
>> +csi40vin3: endpoint@3 {
>> +reg = <3>;
>> +remote-endpoint = <>;
>> +};
>> +};
>> +};
>> +};
>> +
>> +csi41: csi2@feab {
>> +compatible = "renesas,r8a77980-csi2";
>> +reg = <0 0xfeab 0 0x1>;
>> +interrupts = ;
>
> The use of GIC_SPI 246 for both csi40 and csi41 seems suspicious.
> Is this intentional?
No, must be copy/paste artefact... Sorry about that, it should be 241
instead.
>> +clocks = < CPG_MOD 716>;
>
> Should this clock be 715 rather than 716?
Yes, sure.
I'm seeing this patch merged despite your remarks. Please either fix it up or
pull it out!
[...]
MBR, Sergei
Re: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support
On Fri, Aug 10, 2018 at 5:13 AM Simon Horman wrote: > > On Fri, Aug 10, 2018 at 07:37:18AM +, Biju Das wrote: > > Hi Rob, > > > > > Subject: Re: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support > > > > > > Hi, this is an automated email from Rob's (experimental) review bot. I > > > found > > > a couple of common problems with your patch. Please see below. > > > > Do I need to send another patch? The mail says " Rob's (experimental) > > review bot". Previously for RZ/G1C upstreaming I have submitted the > > patches in similar fashion. Is anything changed? > > Yes, indeed. > > At one point I was enforcing such a split but as it did not seem to be a > universal practice I stopped doing so. I'd like some clear guidance from > Rob if he'd like this split to occur going forwards. I've generally not asked for either of these on 1 (or few) line changes or if I had no other comments on the patch. But for automated checking I'm not going to try to make that distinction. So, still up to whomever applies them. BTW, I'm adding the splitting patches check to checkpatch.pl too. Rob
Re: [PATCH v2 4/5] clk: renesas: Add r8a774a1 CPG Core Clock Definitions
On Fri, Aug 10, 2018 at 1:35 AM Biju Das wrote: > > Hi Rob, > > > > Subject: Re: [PATCH v2 4/5] clk: renesas: Add r8a774a1 CPG Core Clock > > Definitions > > > > Hi, this is an automated email from Rob's (experimental) review bot. I found > > a couple of common problems with your patch. Please see below. > > Do I need to send another patch? The mail says " Rob's (experimental) review > bot". "experimental" in the sense it may not work right. Such as they all triggered spam filters. But I checked all these mails before they went out, so the comments are correct. > Previously for RZ/G1C upstreaming I have submitted the patches in similar > fashion. > Is anything changed? Yes, I'm tired of manually providing these comments. If there's no other comments though, then it is fine to apply as is. Rob
Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board
Hi again Jacopo, On Mon, Aug 06, 2018 at 12:40:02AM +0200, Eugeniu Rosca wrote: > Hi Jacopo, > > Thanks for your comments. Please, find my replies below. > > On Sun, Aug 05, 2018 at 10:15:43AM +0200, jacopo mondi wrote: > > Helle Eugeniu, > > > > On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote: > > > In harmony with ATF and U-Boot outputs [1] and [2], the new board is > > > based on M3-N revision ES1.1 and the amount of memory present on SiP > > > is 2GiB, contiguously addressed. > > > > Not sure why the amount of installed system memory is relevant for > > this commit.. > > To be honest, I don't know precisely what's encoded in the board string > (particularly the one documented in this commit RTP0RC77965SKBX010SA00). > > The only thing unmistakenly present there is the SoC model 77965 (i.e. > M3-N), but I am quite clueless about the rest. > > What I can say for sure is that the end-user experience of a R-Car Gen3 > reference board clearly depends on below parameters: > - [A] SoC (model, revision) including SRAM and on-chip peripherals > - [B] DRAM (amount, linear/2ch/4ch split) > - [C] Hyperflash (amount) > - [D] board's PCB (revision) > - [E] board's off-chip peripherals (model, revision) > > I don't know how many of these parameters are embedded in the board > string, but since you are suggesting that RAM amount is not (IOW > Renesas will potentially release several RTP0RC77965SKBX010SA00 > boards with different amounts of memory), I will happily update > the commit description. Since I found two H3-ES2.0 Starter Kit samples with different amount of RAM (4 vs 8 GiB) each having a unique board id [1], I take this as evidence that Renesas encodes the amount of RAM in the board id. Therefore, I will not change the description of this patch in v2, unless you comment/NAK. Thank you. [1] https://patchwork.kernel.org/patch/10555957/#22169325 Best regards, Eugeniu.
RE: [PATCH v3 5/5] ARM: dts: iwg23s-sbc: Add pinctl support for EtherAVB
Hello Simon, Thanks for the feedback. > Subject: Re: [PATCH v3 5/5] ARM: dts: iwg23s-sbc: Add pinctl support for > EtherAVB > > On Tue, Aug 07, 2018 at 08:57:06AM +0100, Biju Das wrote: > > Adding pinctrl support for EtherAVB interface. > > > > Signed-off-by: Biju Das > > Reviewed-by: Fabrizio Castro > > Reviewed-by: Geert Uytterhoeven > > --- > > V1-->V2 > > * No change > > V2-->V3 > > * No change > > Depend onthe below patch > >https://patchwork.kernel.org/patch/10546801/ > > What is the effect of applying this patch without that dependency present? No build dependency. Only driver probe will fail during run time. [0.838091] ravb: probe of e680.ethernet failed with error -22 Regards, Biju Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH 01/14] arm64: dts: renesas: Cut redundant in *-ulcb*.dts
Hi Simon, Laurent, On Fri, Aug 10, 2018 at 01:22:49PM +0200, Simon Horman wrote: > On Mon, Aug 06, 2018 at 01:35:08PM +0300, Laurent Pinchart wrote: [snip] > > The naming convention is roughly -.dts. For instance, in > > r8a7795- > > h3ulcb.dts, the SoC is R8A7795 and the board "H3 ULCB". With the proposed > > rename we would break that convention. > > > > However, the name ULCB itself (which stands for Ultra Low Cost Board) might > > already not follow the naming convention, as the boards are officially > > called > > R-Car Starter Kit (Pro and Premier). The V3M and V3H "low-cost" boards > > reflect > > that properly, with their .dts files named r8a77970-v3msk.dts and r8a77970- > > v3hsk.dts respectively. > > > > I'm not opposed to simplifying the file names, but I think we should then > > decide on a simpler convention. In particular the H3/M3 and V3 .dts files > > should in my opinion follow the same convention. > > > > I'll now let others comment on this as I don't have such a strong opinion > > on > > this topic. > > At this point I'd prefer to keep the current, albeit imperfect scheme, > and avoid churn. To be able to push a v2, I interpret this input as using below strings for the newly supported M3-N Starter Kit board: - r8a77965-m3nulcb.dts and r8a77965-m3nulcb-kf.dts for device tree sources - "renesas,m3nulcb" for compatible string - M3NULCB for board name in the shmobile.txt DT bindings I still think there is some redundancy in this naming scheme, but I can live with that. Thanks, Eugeniu.
Re: [PATCH] arm64: dts: renesas: salvator-common: adv748x: Override secondary addresses
Hi Simon,
On 10/08/18 13:01, Simon Horman wrote:
> On Tue, Aug 07, 2018 at 04:59:33PM +0100, Kieran Bingham wrote:
>> Ensure that the ADV748x device addresses do not conflict, and group them
>> together (visually in i2cdetect)
>
> Hi Kieran,
>
> could you help me out with some pointers on how to correlate this
> with the HW documentation?
Not easily :) - Except for the 'main' address (0x70), these are not
addresses documented by the datasheet. . The driver supports the DT providing the slave pages to
allocate. One day the I2C framework might allow us to 'request' an
unused page :D
I performed a scan on the Salvator-X, (i2cdetect -r -y 4) and identified
a region of unused I2C address space to allocate the 12 pages so that
they did not conflict.
In particular, the address <0x30> which is the default for the CBUS page
conflicts with the default address of the OV10635 used by the GMSL
cameras on the same bus, and so I needed to move that one.
To make the effects clear, (and the i2cdetect reporting more obvious) I
chose to reassign all of the movable pages so that it is clear they are
from the same device.
Rather annoyingly it's difficult to map a slave page back to it's driver
due to the fact that it gets registered as a 'dummy' driver, so keeping
the related addresses together is quite valuable.
As soon as I get some free cycles, I plan to look at being able to map
extra driver information to dummy I2C registrations to make it easier to
identify who owns the address :)
--
Regards
Kieran
>>
>> Signed-off-by: Kieran Bingham
>> ---
>> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> index 5cfb9b99de89..2eba743c5c3f 100644
>> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
>> @@ -414,7 +414,10 @@
>>
>> video-receiver@70 {
>> compatible = "adi,adv7482";
>> -reg = <0x70>;
>> +reg = <0x70 0x71 0x72 0x73 0x74 0x75
>> + 0x60 0x61 0x62 0x63 0x64 0x65>;
>> +reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater",
>> +"infoframe", "cbus", "cec", "sdp", "txa", "txb" ;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>> --
>> 2.17.1
>>
--
Regards
--
Kieran
Re: [PATCH v3 5/5] ARM: dts: iwg23s-sbc: Add pinctl support for EtherAVB
On Tue, Aug 07, 2018 at 08:57:06AM +0100, Biju Das wrote: > Adding pinctrl support for EtherAVB interface. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > Reviewed-by: Geert Uytterhoeven > --- > V1-->V2 > * No change > V2-->V3 > * No change > Depend onthe below patch >https://patchwork.kernel.org/patch/10546801/ What is the effect of applying this patch without that dependency present?
Re: [PATCH v3 4/5] ARM: dts: iwg23s-sbc: specify EtherAVB PHY IRQ
On Tue, Aug 07, 2018 at 08:57:05AM +0100, Biju Das wrote: > Specify EtherAVB PHY IRQ in the board specific device tree, now that we > have GPIO support. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > Reviewed-by: Geert Uytterhoeven Thanks, applied for v4.20.
Re: [PATCH v3 3/5] ARM: dts: r8a77470: Add GPIO support
On Tue, Aug 07, 2018 at 08:57:04AM +0100, Biju Das wrote: > Describe GPIO blocks in the R8A77470 device tree. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > Reviewed-by: Geert Uytterhoeven > --- > V2-->V3 > * Moved gpio-reserved-ranges property just below gpio-ranges Thanks, applied for v4.20.
Re: [PATCH] arm64: dts: renesas: salvator-common: adv748x: Override secondary addresses
On Tue, Aug 07, 2018 at 04:59:33PM +0100, Kieran Bingham wrote:
> Ensure that the ADV748x device addresses do not conflict, and group them
> together (visually in i2cdetect)
Hi Kieran,
could you help me out with some pointers on how to correlate this
with the HW documentation?
>
> Signed-off-by: Kieran Bingham
> ---
> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index 5cfb9b99de89..2eba743c5c3f 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -414,7 +414,10 @@
>
> video-receiver@70 {
> compatible = "adi,adv7482";
> - reg = <0x70>;
> + reg = <0x70 0x71 0x72 0x73 0x74 0x75
> +0x60 0x61 0x62 0x63 0x64 0x65>;
> + reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater",
> + "infoframe", "cbus", "cec", "sdp", "txa", "txb" ;
>
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.17.1
>
Re: [PATCH V2] ARM: dts: silk: Add DA9063 PMIC node
On Tue, Aug 07, 2018 at 10:16:16AM +0200, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Sat, Aug 4, 2018 at 6:38 PM Marek Vasut wrote:
> > Add DA9063 PMIC node to the I2C bus.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Geert Uytterhoeven
> > Cc: Kuninori Morimoto
> > Cc: Simon Horman
> > Cc: Wolfram Sang
> > Cc: linux-renesas-soc@vger.kernel.org
> > ---
> > V2: - Replace shmobile with dts since it's a DT patch in subject
> > - Connect the 9063_IRQ# line to GP3_31
> > - Since the DA9063 is connected to both i2c1 and i2c7, connect
> > it to i2c7, which is the dedicated dvfs i2c.
>
> Thanks for the update!
>
> > --- a/arch/arm/boot/dts/r8a7794-silk.dts
> > +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> > @@ -405,6 +405,23 @@
> > clock-frequency = <40>;
> > };
> >
> > + {
> > + status = "okay";
> > + clock-frequency = <10>;
> > +
> > + pmic@58 {
> > + compatible = "dlg,da9063";
> > + reg = <0x58>;
> > + interrupt-parent = <>;
> > + interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-controller;
> > +
> > + wdt {
> > + compatible = "dlg,da9063-watchdog";
> > + };
>
> Given Silk has the full da9063 (unlike the "L" version on Porter), shouldn't
> you add an rtc subnode?
>
> Oh, Silk also has the onkey pin wired, so perhaps you want to add an onkey
> subnode, too? Does that feature work?
>
> BTW, Stout also has the onkey wired, but lacks the onkey subnode.
>
> > + };
> > +};
> > +
>
> Nevertheless:
> Reviewed-by: Geert Uytterhoeven
Thanks, I have applied this patch for v4.20.
Marek,
please consider some follow-up patches to address the issues
raised by Geert.
Re: [PATCH 01/14] arm64: dts: renesas: Cut redundant in *-ulcb*.dts
On Mon, Aug 06, 2018 at 01:35:08PM +0300, Laurent Pinchart wrote: > Hello Eugeniu, > > Thank you for the patch. > > On Sunday, 5 August 2018 02:11:01 EEST Eugeniu Rosca wrote: > > Perform a 's/(h|m)3ulcb/ulcb/' substitution in below DTS filenames: > > - r8a7795-es1-h3ulcb.dts=> r8a7795-es1-ulcb.dts > > - r8a7795-es1-h3ulcb-kf.dts => r8a7795-es1-ulcb-kf.dts > > - r8a7795-h3ulcb.dts=> r8a7795-ulcb.dts > > - r8a7795-h3ulcb-kf.dts => r8a7795-ulcb-kf.dts > > - r8a7796-m3ulcb.dts=> r8a7796-ulcb.dts > > - r8a7796-m3ulcb-kf.dts => r8a7796-ulcb-kf.dts > > > > The background of this commit is M3-N ULCB (RTP0RC77965SKBX010SA00) > > bring-up, which (assuming no change in existing DTS name patterns) > > requires two new DTS files: > > - r8a77965-m3nulcb.dts > > - r8a77965-m3nulcb-kf.dts > > > > In all above examples: > > - "m3n" prefix is redundant, since r8a77965 denotes the M3-N SoC > > - "m3" prefix is redundant, since r8a7796 denotes the M3/M3-W SoC > > - "h3" prefix is redundant, since r8a7795 denotes the H3 SoC > > The naming convention is roughly -.dts. For instance, in r8a7795- > h3ulcb.dts, the SoC is R8A7795 and the board "H3 ULCB". With the proposed > rename we would break that convention. > > However, the name ULCB itself (which stands for Ultra Low Cost Board) might > already not follow the naming convention, as the boards are officially called > R-Car Starter Kit (Pro and Premier). The V3M and V3H "low-cost" boards > reflect > that properly, with their .dts files named r8a77970-v3msk.dts and r8a77970- > v3hsk.dts respectively. > > I'm not opposed to simplifying the file names, but I think we should then > decide on a simpler convention. In particular the H3/M3 and V3 .dts files > should in my opinion follow the same convention. > > I'll now let others comment on this as I don't have such a strong opinion on > this topic. At this point I'd prefer to keep the current, albeit imperfect scheme, and avoid churn.
Re: [PATCH v2 3/5] soc: renesas: rcar-rst: Add support for RZ/G2M
On Thu, Aug 09, 2018 at 01:12:04PM +0200, Simon Horman wrote: > On Thu, Aug 02, 2018 at 03:55:04PM +0100, Biju Das wrote: > > Signed-off-by: Biju Das > > Reviewed-by: Chris Paterson > > Reviewed-by: Geert Uytterhoeven > > --- > > V1-->V2 > > * No change > > Reviewed-by: Simon Horman Now applied for v4.20.
Re: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support
On Fri, Aug 10, 2018 at 07:37:18AM +, Biju Das wrote: > Hi Rob, > > > Subject: Re: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support > > > > Hi, this is an automated email from Rob's (experimental) review bot. I found > > a couple of common problems with your patch. Please see below. > > Do I need to send another patch? The mail says " Rob's (experimental) > review bot". Previously for RZ/G1C upstreaming I have submitted the > patches in similar fashion. Is anything changed? Yes, indeed. At one point I was enforcing such a split but as it did not seem to be a universal practice I stopped doing so. I'd like some clear guidance from Rob if he'd like this split to occur going forwards. As for this patch, I have applied it for v4.20. > > > On Thu, 2 Aug 2018 15:53:19 +0100, Biju Das wrote: > > > Add support for RZ/G2M (R8A774A1) SoC power areas to the R-Car SYSC > > > driver. > > > > > > Signed-off-by: Biju Das > > > Reviewed-by: Chris Paterson > > > Reviewed-by: Geert Uytterhoeven > > > > The preferred subject prefix is "dt-bindings: : ...". > > > > DT bindings (including binding headers) should be a separate patch. See > > Documentation/devicetree/bindings/submitting-patches.txt. > > Regards, > Biju > > > > > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, > Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered > No. 04586709. >
Re: [PATCH v2 1/5] dt-bindings: power: Add r8a774a1 SYSC power domain definitions
On Thu, Aug 09, 2018 at 01:07:59PM +0200, Simon Horman wrote: > On Thu, Aug 02, 2018 at 03:48:18PM +0100, Biju Das wrote: > > This patch adds power domain indices for RZ/G2M. > > > > Signed-off-by: Biju Das > > Reviewed-by: Chris Paterson > > Reviewed-by: Geert Uytterhoeven > > Reviewed-by: Simon Horman Now applied for v4.20.
RE: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support
Hi Rob, > Subject: Re: [PATCH v2 2/5] soc: renesas: rcar-sysc: Add r8a774a1 support > > Hi, this is an automated email from Rob's (experimental) review bot. I found > a couple of common problems with your patch. Please see below. Do I need to send another patch? The mail says " Rob's (experimental) review bot". Previously for RZ/G1C upstreaming I have submitted the patches in similar fashion. Is anything changed? > On Thu, 2 Aug 2018 15:53:19 +0100, Biju Das wrote: > > Add support for RZ/G2M (R8A774A1) SoC power areas to the R-Car SYSC > > driver. > > > > Signed-off-by: Biju Das > > Reviewed-by: Chris Paterson > > Reviewed-by: Geert Uytterhoeven > > The preferred subject prefix is "dt-bindings: : ...". > > DT bindings (including binding headers) should be a separate patch. See > Documentation/devicetree/bindings/submitting-patches.txt. Regards, Biju Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
RE: [PATCH v2 4/5] clk: renesas: Add r8a774a1 CPG Core Clock Definitions
Hi Rob,
> Subject: Re: [PATCH v2 4/5] clk: renesas: Add r8a774a1 CPG Core Clock
> Definitions
>
> Hi, this is an automated email from Rob's (experimental) review bot. I found
> a couple of common problems with your patch. Please see below.
Do I need to send another patch? The mail says " Rob's (experimental) review
bot".
Previously for RZ/G1C upstreaming I have submitted the patches in similar
fashion.
Is anything changed?
> On Thu, 2 Aug 2018 15:56:34 +0100, Biju Das wrote:
> > Add all RZ/G2M Clock Pulse Generator Core Clock Outputs, as listed in
> > Table 8.2b ("List of Clocks [RZ/G2M]") of the RZ/G2M Hardware User's
> > Manual.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Fabrizio Castro
> > Reviewed-by: Geert Uytterhoeven
>
> The preferred subject prefix is "dt-bindings: : ...".
Regards,
Biju
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
