Re: [PATCH v2 0/2] PCI: rcar-pcie: Fix memory leak

[Bjorn Helgaas]

On Fri, Aug 04, 2017 at 12:32:53PM +0900, Harunobu Kurokawa wrote:
> When no PCIe card is inserted, there is a memory leak as
> pci_free_resource_list is not called before returning.
> 
> v2:
>  separate the patch to two files.
> 
> Harunobu Kurokawa (1):
>   PCI: rcar-pcie: Fix memory leak when no PCIe card is inserted
> 
> Lorenzo Pieralisi (1):
>   PCI: rcar: Fix error exit path
> 
>  drivers/pci/host/pcie-rcar.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Waiting for Simon's ack...

Re: [PATCH v4 00/06] clocksource: sh_cmt: DT binding rework V4

[Geert Uytterhoeven]

Hi Daniel, Magnus,

On Thu, Aug 10, 2017 at 12:56 PM, Daniel Lezcano
 wrote:
> On 10/08/2017 11:01, Geert Uytterhoeven wrote:
>> On Tue, Jul 11, 2017 at 1:56 PM, Simon Horman  wrote:
>>> On Thu, Nov 24, 2016 at 11:58:43AM +0100, Simon Horman wrote:
 On Mon, Mar 14, 2016 at 11:23:42PM +0900, Magnus Damm wrote:
> clocksource: sh_cmt: DT binding rework V4
>
> [PATCH v4 01/06] devicetree: bindings: Remove sh7372 CMT binding
> [PATCH v4 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
> [PATCH v4 03/06] devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings
> [PATCH v4 04/06] devicetree: bindings: Deprecate property, update example
> [PATCH v4 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings
> [PATCH v4 06/06] devicetree: bindings: Remove deprecated properties
>
> Here is the latest and hopefully final take on updating the CMT DT
> bindings for R-Car Gen2. In total there are 6 patches that have acks
> and are ready to be picked up and merged. Other earlier posted changes
> such as driver modification and SoC DTS bits depend on this series.

 I am wondering what the state of this work is.
 I see only one minor review comment for this series.
 It would be great to see it merged.
>>>
>>> Ping
>>
>> Recently, at +1800m, I realized that if we want to continue this work, we
>> better do it soon, so it can be included in the big R-Car Gen2 flag day
>> requiring APMU, CPG/MSSR, ICRAM, RST, and SYSC being described in DT.
>
> Applied.

Thank you.

Of course, before we can convert existing DT source files to the new bindings,
we need support for the new bindings in the sh_cmt driver.

Magnus: what is the status of that? Where can we find the latest code?

Thanks again!

Gr{oetje,eeting}s,

Geert

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

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

Re: [RFC PATCH 0/3] watchdog: renesas_wdt: use standard clock handling

[Guenter Roeck]

On Mon, Aug 14, 2017 at 05:47:28PM +0200, Wolfram Sang wrote:
> On Mon, Aug 14, 2017 at 08:32:30AM -0700, Guenter Roeck wrote:
> > On Wed, Jul 26, 2017 at 11:54:36PM +0200, Wolfram Sang wrote:
> > > As mentioned in a response to a previous patch, clock handling for Renesas
> > > R-Car is done via RuntimePM. Patch 1 implements that consequently. Patch 2
> > > is a cleanup then possible and patch 3 is a trivial copyright update.
> > > 
> > > This is RFC because I'd like Geert's comments on these patches first which
> > > might take a few days...
> > > 
> > Was there any feedback from Geert ? I don't recall seeing any.
> 
> He just got back from holidays and is bravely working through his mail
> queue :)
> 

Good to hear that I am not the only one with that problem :-).

Guenter

[GIT PULL FOR renesas-drivers] Display List Optimizations

[Kieran Bingham]

From: Kieran Bingham 

Hi Geert,

Please consider pulling the following changes into renesas-drivers.

This series is based upon a merge of my previous pa-improvements/v4 and
airlied-drm/drm-next to base on top of all pending VSP1 changes.


The following changes since commit f44bd631453bf7dcbe57f79b924db3a6dd038bff:

  Merge remote-tracking branch 'airlied-drm/drm-next' into vsp1/next 
(2017-08-08 19:51:06 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
tags/vsp1/tlb-optimise-v2

for you to fetch changes up to fa078611769415d7adbad208f1299d05bee3bda8:

  v4l: vsp1: Reduce display list body size (2017-08-14 15:58:38 +0100)


Kieran Bingham (8):
  v4l: vsp1: Protect fragments against overflow
  v4l: vsp1: Provide a fragment pool
  v4l: vsp1: Convert display lists to use new fragment pool
  v4l: vsp1: Use reference counting for fragments
  v4l: vsp1: Refactor display list configure operations
  v4l: vsp1: Adapt entities to configure into a body
  v4l: vsp1: Move video configuration to a cached dlb
  v4l: vsp1: Reduce display list body size

 drivers/media/platform/vsp1/vsp1_bru.c|  32 ++-
 drivers/media/platform/vsp1/vsp1_clu.c|  86 +---
 drivers/media/platform/vsp1/vsp1_clu.h|   1 +
 drivers/media/platform/vsp1/vsp1_dl.c | 331 --
 drivers/media/platform/vsp1/vsp1_dl.h |  13 +-
 drivers/media/platform/vsp1/vsp1_drm.c|  21 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  23 ++-
 drivers/media/platform/vsp1/vsp1_entity.h |  31 ++-
 drivers/media/platform/vsp1/vsp1_hgo.c|  26 +--
 drivers/media/platform/vsp1/vsp1_hgt.c|  28 ++-
 drivers/media/platform/vsp1/vsp1_hsit.c   |  20 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  23 +--
 drivers/media/platform/vsp1/vsp1_lut.c|  65 --
 drivers/media/platform/vsp1/vsp1_lut.h|   1 +
 drivers/media/platform/vsp1/vsp1_pipe.c   |   8 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |   7 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 179 
 drivers/media/platform/vsp1/vsp1_sru.c|  24 +--
 drivers/media/platform/vsp1/vsp1_uds.c|  73 ---
 drivers/media/platform/vsp1/vsp1_uds.h|   2 +-
 drivers/media/platform/vsp1/vsp1_video.c  |  82 
 drivers/media/platform/vsp1/vsp1_video.h  |   2 +
 drivers/media/platform/vsp1/vsp1_wpf.c| 325 +++--
 23 files changed, 753 insertions(+), 650 deletions(-)

Re: [PATCH 05/15] ARM: head: use PC-relative insn sequence for __smp_alt

[Ard Biesheuvel]

On 14 August 2017 at 17:19, Tony Lindgren  wrote:
> * Ard Biesheuvel  [170811 12:37]:
>> On 11 August 2017 at 16:13, Tony Lindgren  wrote:
>> > * Ard Biesheuvel  [170805 13:54]:
>> >> Replace the open coded PC relative offset calculations with a pair
>> >> of adr_l invocations.
>> >>
>> >> Signed-off-by: Ard Biesheuvel 
>> >> ---
>> >>  arch/arm/kernel/head.S | 12 ++--
>> >>  1 file changed, 2 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> >> index 6e9df3663a57..aed341e0f530 100644
>> >> --- a/arch/arm/kernel/head.S
>> >> +++ b/arch/arm/kernel/head.S
>> >> @@ -523,19 +523,11 @@ ARM_BE8(rev r0, r0) @ byteswap 
>> >> if big endian
>> >>   retne   lr
>> >>
>> >>  __fixup_smp_on_up:
>> >> - adr r0, 1f
>> >> - ldmia   r0, {r3 - r5}
>> >> - sub r3, r0, r3
>> >> - add r4, r4, r3
>> >> - add r5, r5, r3
>> >> + adr_l   r4, __smpalt_begin
>> >> + adr_l   r5, __smpalt_end
>> >>   b   __do_fixup_smp_on_up
>> >>  ENDPROC(__fixup_smp)
>> >>
>> >> - .align
>> >> -1:   .word   .
>> >> - .word   __smpalt_begin
>> >> - .word   __smpalt_end
>> >> -
>> >>   .pushsection .data
>> >>   .globl  smp_on_up
>> >>  smp_on_up:
>> >
>> > Ard, it's this one that cause boot to fail on omap3.
>> > The rest of your set works for me with just this one
>> > left out.
>> >
>>
>> I'm completely puzzled. The change is so simple that it is difficult
>> to reduce it in parts, but if you still have the time to spare, mind
>> trying the diff below?
>>
>>
>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> index 6e9df3663a57..c0361e608210 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -524,17 +524,15 @@ ARM_BE8(rev   r0, r0) @
>> byteswap if big endian
>>
>>  __fixup_smp_on_up:
>> adr r0, 1f
>> -   ldmia   r0, {r3 - r5}
>> -   sub r3, r0, r3
>> -   add r4, r4, r3
>> -   add r5, r5, r3
>> +   ldmia   r0, {r4 - r5}
>> +   add r4, r4, r0
>> +   add r5, r5, r0
>> b   __do_fixup_smp_on_up
>>  ENDPROC(__fixup_smp)
>>
>> .align
>> -1: .word   .
>> -   .word   __smpalt_begin
>> -   .word   __smpalt_end
>> +1: .word   __smpalt_begin - 1b
>> +   .word   __smpalt_end - 1b
>>
>> .pushsection .data
>> .globl  smp_on_up
>>
>> The main point of these changes is to eliminate absolute references,
>> not to use the new macros, so if this does work, I will go with this
>> instead.
>
> For reference, I manually did this changes as it did not apply
> after reverting your earlier version of this patch. No luck with
> this change, so I'll test again when you you have updated patches
> available.
>

Thanks Tony,

But Nico already found the issue: I was looking at the code with
another patch on top, which removed the reference to r3 in the
followup code.

In the KASLR series I just posted, I reordered that patch with this
one, so everything should be good.

Re: [PATCH 05/15] ARM: head: use PC-relative insn sequence for __smp_alt

[Tony Lindgren]

* Ard Biesheuvel  [170811 12:37]:
> On 11 August 2017 at 16:13, Tony Lindgren  wrote:
> > * Ard Biesheuvel  [170805 13:54]:
> >> Replace the open coded PC relative offset calculations with a pair
> >> of adr_l invocations.
> >>
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  arch/arm/kernel/head.S | 12 ++--
> >>  1 file changed, 2 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> >> index 6e9df3663a57..aed341e0f530 100644
> >> --- a/arch/arm/kernel/head.S
> >> +++ b/arch/arm/kernel/head.S
> >> @@ -523,19 +523,11 @@ ARM_BE8(rev r0, r0) @ byteswap 
> >> if big endian
> >>   retne   lr
> >>
> >>  __fixup_smp_on_up:
> >> - adr r0, 1f
> >> - ldmia   r0, {r3 - r5}
> >> - sub r3, r0, r3
> >> - add r4, r4, r3
> >> - add r5, r5, r3
> >> + adr_l   r4, __smpalt_begin
> >> + adr_l   r5, __smpalt_end
> >>   b   __do_fixup_smp_on_up
> >>  ENDPROC(__fixup_smp)
> >>
> >> - .align
> >> -1:   .word   .
> >> - .word   __smpalt_begin
> >> - .word   __smpalt_end
> >> -
> >>   .pushsection .data
> >>   .globl  smp_on_up
> >>  smp_on_up:
> >
> > Ard, it's this one that cause boot to fail on omap3.
> > The rest of your set works for me with just this one
> > left out.
> >
> 
> I'm completely puzzled. The change is so simple that it is difficult
> to reduce it in parts, but if you still have the time to spare, mind
> trying the diff below?
> 
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 6e9df3663a57..c0361e608210 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -524,17 +524,15 @@ ARM_BE8(rev   r0, r0) @
> byteswap if big endian
> 
>  __fixup_smp_on_up:
> adr r0, 1f
> -   ldmia   r0, {r3 - r5}
> -   sub r3, r0, r3
> -   add r4, r4, r3
> -   add r5, r5, r3
> +   ldmia   r0, {r4 - r5}
> +   add r4, r4, r0
> +   add r5, r5, r0
> b   __do_fixup_smp_on_up
>  ENDPROC(__fixup_smp)
> 
> .align
> -1: .word   .
> -   .word   __smpalt_begin
> -   .word   __smpalt_end
> +1: .word   __smpalt_begin - 1b
> +   .word   __smpalt_end - 1b
> 
> .pushsection .data
> .globl  smp_on_up
> 
> The main point of these changes is to eliminate absolute references,
> not to use the new macros, so if this does work, I will go with this
> instead.

For reference, I manually did this changes as it did not apply
after reverting your earlier version of this patch. No luck with
this change, so I'll test again when you you have updated patches
available.

Regards,

Tony

Re: [RFC PATCH 0/3] watchdog: renesas_wdt: use standard clock handling

[Wolfram Sang]

On Mon, Aug 14, 2017 at 08:32:30AM -0700, Guenter Roeck wrote:
> On Wed, Jul 26, 2017 at 11:54:36PM +0200, Wolfram Sang wrote:
> > As mentioned in a response to a previous patch, clock handling for Renesas
> > R-Car is done via RuntimePM. Patch 1 implements that consequently. Patch 2
> > is a cleanup then possible and patch 3 is a trivial copyright update.
> > 
> > This is RFC because I'd like Geert's comments on these patches first which
> > might take a few days...
> > 
> Was there any feedback from Geert ? I don't recall seeing any.

He just got back from holidays and is bravely working through his mail
queue :)



signature.asc
Description: PGP signature

Re: [RFT] arm64: dts: renesas: salvator-common: enable SDR104 for SD cards

[Wolfram Sang]

Hi Simon,

On Mon, Aug 14, 2017 at 07:10:23AM +0200, Simon Horman wrote:
> On Tue, Aug 08, 2017 at 08:54:45PM +0200, Wolfram Sang wrote:
> > 
> > > As it is an "RFT" I'm happy to apply it if you repost
> > > it or otherwise indicate that is what you would like to happen.
> > 
> > As discussed in a chat, I tried SDR104 with my SDIO WiFi cards:
> > 
> > H3:
> > - one slot worked flawlessly
> > - one slot could load FW but failed to read status
> > (with SDR50: both slots work)
> > 
> > M3-W:
> > - both slots could not load the firmware
> > (with SDR50: one slot works, one fails to load FW)
> > 
> > The cards, however, were correctly identified as SDR104 and there were
> > no tuning errors and no other SDHI related warnings.
> > 
> > Changing TDSEL in the PFC did not change anything.
> > 
> > The manual of the WiFi card (u-blox EMMY-W1) mentions a maximum line
> > length of 100mm. Measuring a direct line from the SoC to the slots,
> > I'd think we are very much on the edge of that. And given the length
> > of the SDIO adapter, we are surely exceeding that :(
> > 
> > Maybe we should do more tests with more boards? On the other hand, it
> > seems the WiFi card is running out of the specs.
> > 
> > So much for now. I'll sleep over it and try to get more data tomorrow.
> 
> Thanks. Unfortunately my H3 is out of arms length but I can arrange
> some testing if it is helpful.

Do you have UHS-SDIO cards? Otherwise, some more testing in Spain will
be good.

> Is one possibility to enable it for the slots listed above that are now
> thought to work but not for the other one?

I don't think so. We'd need more test coverage. My gut feeling is that
it varies from board to board. Or more precisely: from environment
around the board to environment around the board. I'd like to test a)
more boards) and b) a resoldered WLAN card to skip the extra cabling
there. I still think the wire length of ~23cm (exceeding the spec of max
10cm) is a factor here, so resoldering would save ~6cm. That all sounds
to me like a hacking sprint for our next meeting.

Maybe ULCB has less line lengths? Would be interesting to check, too.

I could also try to apply more shielding here at home, too.

> The SDR50 failure on M3-W seems particularly troubling as that
> has been enabled in upstream for a while, right?

Not nice, yes. Yet, until this thread, there have been no issues
reported. So, it doesn't look like a substantial fault to me (famous
last words?)

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [PATCH 3/4] arm: dts: renesas: add cec clock for Koelsch board

[Geert Uytterhoeven]

On Sun, Jul 30, 2017 at 3:07 PM, Hans Verkuil  wrote:
> From: Hans Verkuil 

Probably the one-line summary should be

ARM: dts: koelsch: Add CEC clock  for HDMI transmitter

> The adv7511 on the Koelsch board has a 12 MHz fixed clock
> for the CEC block. Specify this in the dts to enable CEC support.
>
> Signed-off-by: Hans Verkuil 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [RFC PATCH 0/3] watchdog: renesas_wdt: use standard clock handling

[Guenter Roeck]

On Wed, Jul 26, 2017 at 11:54:36PM +0200, Wolfram Sang wrote:
> As mentioned in a response to a previous patch, clock handling for Renesas
> R-Car is done via RuntimePM. Patch 1 implements that consequently. Patch 2
> is a cleanup then possible and patch 3 is a trivial copyright update.
> 
> This is RFC because I'd like Geert's comments on these patches first which
> might take a few days...
> 
Was there any feedback from Geert ? I don't recall seeing any.

Guenter

> Looking forward to other comments, too, of course :)
> 
> These patches are on top of the already reviewed 'better-precision' series for
> this watchdog. A branch can be found here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
> renesas/watchdog-fixes
> 
> These patches have been tested on a Renesas Salvator-X / r8a7796 (R-Car M3-W)
> 
> Thanks and kind regards,
> 
>Wolfram
> 
> 
> Wolfram Sang (3):
>   watchdog: renesas_wdt: consistently use RuntimePM for clock management
>   watchdog: renesas_wdt: make 'clk' a variable local to probe()
>   watchdog: renesas_wdt: update copyright dates
> 
>  drivers/watchdog/renesas_wdt.c | 47 
> +++---
>  1 file changed, 26 insertions(+), 21 deletions(-)
> 
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: renesas_sdhi: use extra flag for CBSY usage

[Wolfram Sang]

> Is this supposed to have any impact on the issue on Magnus' r8a7794/alt, where
> tuning failed before?

Nope, I'd be very surprised if it does. I wanted to look at this issue
with my next free time slot.



signature.asc
Description: PGP signature

RE: [PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support

[Chris Paterson]

Hello Geert,

> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> 
> Hi Chris,
> 
> On Mon, Aug 14, 2017 at 5:15 PM, Chris Paterson
>  wrote:
> >> From: geert.uytterhoe...@gmail.com
> >> [mailto:geert.uytterhoe...@gmail.com]
> >> On Behalf Of Geert Uytterhoeven
> >> Sent: 14 August 2017 15:22
> >>
> >> On Mon, Aug 14, 2017 at 1:19 PM, Biju Das 
> wrote:
> >> > Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI is
> >> > identical to the R-Car Gen2 family.
> >> >
> >> > Signed-off-by: Biju Das 
> >> > ---
> >> > This patch is compiled and tested against mmc/next.
> >> >
> >> >  drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
> >> >  1 file changed, 2 insertions(+)
> >> >
> >> > diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> >> > b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> >> > index 718cb8a..f709f7f 100644
> >> > --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> >> > +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> >> > @@ -95,6 +95,8 @@
> >> > { .compatible = "renesas,sdhi-r7s72100", .data = 
> >> > _rz_compatible,
> },
> >> > { .compatible = "renesas,sdhi-r8a7778", .data =
> >> _rcar_gen1_compatible, },
> >> > { .compatible = "renesas,sdhi-r8a7779", .data =
> >> > _rcar_gen1_compatible, },
> >> > +   { .compatible = "renesas,sdhi-r8a7743", .data =
> >> _rcar_gen2_compatible, },
> >> > +   { .compatible = "renesas,sdhi-r8a7745", .data =
> >> > + _rcar_gen2_compatible, },
> >> > { .compatible = "renesas,sdhi-r8a7790", .data =
> >> _rcar_gen2_compatible, },
> >> > { .compatible = "renesas,sdhi-r8a7791", .data =
> >> _rcar_gen2_compatible, },
> >> > { .compatible = "renesas,sdhi-r8a7792", .data =
> >> > _rcar_gen2_compatible, },
> >>
> >> I guess we want generic R-Car Gen2/3 compatible values here, too?
> >
> > Yes, but I assume that should be a separate patch submitted instead of this
> one?
> 
> Indeed. That would avoid having to add the SoC-specific compatible values to
> the driver for all RZ/G1 variants.

Okay. I'll send a new patch.

Kind regards, Chris

> 
> 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 ] mmc: renesas_sdhi: Add r8a7743/5 support

[Geert Uytterhoeven]

Hi Chris,

On Mon, Aug 14, 2017 at 5:15 PM, Chris Paterson
 wrote:
>> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
>> On Behalf Of Geert Uytterhoeven
>> Sent: 14 August 2017 15:22
>>
>> On Mon, Aug 14, 2017 at 1:19 PM, Biju Das  wrote:
>> > Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI is
>> > identical to the R-Car Gen2 family.
>> >
>> > Signed-off-by: Biju Das 
>> > ---
>> > This patch is compiled and tested against mmc/next.
>> >
>> >  drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
>> > b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
>> > index 718cb8a..f709f7f 100644
>> > --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
>> > +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
>> > @@ -95,6 +95,8 @@
>> > { .compatible = "renesas,sdhi-r7s72100", .data = 
>> > _rz_compatible, },
>> > { .compatible = "renesas,sdhi-r8a7778", .data =
>> _rcar_gen1_compatible, },
>> > { .compatible = "renesas,sdhi-r8a7779", .data =
>> > _rcar_gen1_compatible, },
>> > +   { .compatible = "renesas,sdhi-r8a7743", .data =
>> _rcar_gen2_compatible, },
>> > +   { .compatible = "renesas,sdhi-r8a7745", .data =
>> > + _rcar_gen2_compatible, },
>> > { .compatible = "renesas,sdhi-r8a7790", .data =
>> _rcar_gen2_compatible, },
>> > { .compatible = "renesas,sdhi-r8a7791", .data =
>> _rcar_gen2_compatible, },
>> > { .compatible = "renesas,sdhi-r8a7792", .data =
>> > _rcar_gen2_compatible, },
>>
>> I guess we want generic R-Car Gen2/3 compatible values here, too?
>
> Yes, but I assume that should be a separate patch submitted instead of this 
> one?

Indeed. That would avoid having to add the SoC-specific compatible values
to the driver for all RZ/G1 variants.

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support

[Chris Paterson]

> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: 14 August 2017 15:22
> 
> On Mon, Aug 14, 2017 at 1:19 PM, Biju Das  wrote:
> > Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI is
> > identical to the R-Car Gen2 family.
> >
> > Signed-off-by: Biju Das 
> > ---
> > This patch is compiled and tested against mmc/next.
> >
> >  drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > index 718cb8a..f709f7f 100644
> > --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> > @@ -95,6 +95,8 @@
> > { .compatible = "renesas,sdhi-r7s72100", .data = _rz_compatible, 
> > },
> > { .compatible = "renesas,sdhi-r8a7778", .data =
> _rcar_gen1_compatible, },
> > { .compatible = "renesas,sdhi-r8a7779", .data =
> > _rcar_gen1_compatible, },
> > +   { .compatible = "renesas,sdhi-r8a7743", .data =
> _rcar_gen2_compatible, },
> > +   { .compatible = "renesas,sdhi-r8a7745", .data =
> > + _rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7790", .data =
> _rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7791", .data =
> _rcar_gen2_compatible, },
> > { .compatible = "renesas,sdhi-r8a7792", .data =
> > _rcar_gen2_compatible, },
> 
> I guess we want generic R-Car Gen2/3 compatible values here, too?

Yes, but I assume that should be a separate patch submitted instead of this one?

Kind regards, Chris


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

[PATCH v2 8/8] v4l: vsp1: Reduce display list body size

[Kieran Bingham]

The display list originally allocated a body of 256 entries to store all
of the register lists required for each frame.

This has now been separated into fragments for constant stream setup, and
runtime updates.

Empirical testing shows that the body0 now uses a maximum of 41
registers for each frame, for both DRM and Video API pipelines thus a
rounded 64 entries provides a suitable allocation.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 176a258146ac..b3f5eb2f9a4f 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -21,7 +21,7 @@
 #include "vsp1.h"
 #include "vsp1_dl.h"
 
-#define VSP1_DL_NUM_ENTRIES256
+#define VSP1_DL_NUM_ENTRIES64
 
 #define VSP1_DLH_INT_ENABLE(1 << 1)
 #define VSP1_DLH_AUTO_START(1 << 0)
-- 
git-series 0.9.1

[PATCH v2 4/8] v4l: vsp1: Use reference counting for fragments

[Kieran Bingham]

Extend the display list body with a reference count, allowing bodies to
be kept as long as a reference is maintained. This provides the ability
to keep a cached copy of bodies which will not change, so that they can
be re-applied to multiple display lists.

Signed-off-by: Kieran Bingham 

---
This could be squashed into the fragment update code, but it's not a
straightforward squash as the refcounts will affect both:
  v4l: vsp1: Provide a fragment pool
and
  v4l: vsp1: Convert display lists to use new fragment pool
therefore, I have kept this separate to prevent breaking bisectability
of the vsp-tests.
---
 drivers/media/platform/vsp1/vsp1_clu.c |  7 ++-
 drivers/media/platform/vsp1/vsp1_dl.c  | 15 ++-
 drivers/media/platform/vsp1/vsp1_lut.c |  7 ++-
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 52c523625e2f..175717018e11 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -257,8 +257,13 @@ static void clu_configure(struct vsp1_entity *entity,
clu->clu = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_fragment(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_fragment_put(dlb);
+   }
+
break;
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 6ffdc3549283..37feda248946 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -58,6 +59,8 @@ struct vsp1_dl_body {
struct list_head list;
struct list_head free;
 
+   refcount_t refcnt;
+
struct vsp1_dl_fragment_pool *pool;
struct vsp1_device *vsp1;
 
@@ -230,6 +233,7 @@ struct vsp1_dl_body *vsp1_dl_fragment_get(struct 
vsp1_dl_fragment_pool *pool)
if (!list_empty(>free)) {
dlb = list_first_entry(>free, struct vsp1_dl_body, free);
list_del(>free);
+   refcount_set(>refcnt, 1);
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -244,6 +248,9 @@ void vsp1_dl_fragment_put(struct vsp1_dl_body *dlb)
if (!dlb)
return;
 
+   if (!refcount_dec_and_test(>refcnt))
+   return;
+
dlb->num_entries = 0;
 
spin_lock_irqsave(>pool->lock, flags);
@@ -428,7 +435,11 @@ void vsp1_dl_list_write(struct vsp1_dl_list *dl, u32 reg, 
u32 data)
  * list, in the order in which fragments are added.
  *
  * Adding a fragment to a display list passes ownership of the fragment to the
- * list. The caller must not touch the fragment after this call.
+ * list. The caller must not modify the fragment after this call, but can 
retain
+ * a reference to it for future use if necessary, to add to subsequent lists.
+ *
+ * The reference count of the body is incremented by this attachment, and thus
+ * the caller should release it's reference if does not want to cache the body.
  *
  * Fragments are only usable for display lists in header mode. Attempt to
  * add a fragment to a header-less display list will return an error.
@@ -440,6 +451,8 @@ int vsp1_dl_list_add_fragment(struct vsp1_dl_list *dl,
if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
return -EINVAL;
 
+   refcount_inc(>refcnt);
+
list_add_tail(>list, >fragments);
return 0;
 }
diff --git a/drivers/media/platform/vsp1/vsp1_lut.c 
b/drivers/media/platform/vsp1/vsp1_lut.c
index 57482e057e54..388bd89ade0b 100644
--- a/drivers/media/platform/vsp1/vsp1_lut.c
+++ b/drivers/media/platform/vsp1/vsp1_lut.c
@@ -213,8 +213,13 @@ static void lut_configure(struct vsp1_entity *entity,
lut->lut = NULL;
spin_unlock_irqrestore(>lock, flags);
 
-   if (dlb)
+   if (dlb) {
vsp1_dl_list_add_fragment(dl, dlb);
+
+   /* release our local reference */
+   vsp1_dl_fragment_put(dlb);
+   }
+
break;
}
 }
-- 
git-series 0.9.1

[PATCH v2 6/8] v4l: vsp1: Adapt entities to configure into a body

[Kieran Bingham]

Currently the entities store their configurations into a display list.
Adapt this such that the code can be configured into a body fragment
directly, allowing greater flexibility and control of the content.

All users of vsp1_dl_list_write() are removed in this process, thus it
too is removed.

A helper, vsp1_dl_list_body() is provided to access the internal body0
from the display list.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
 drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
 drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
 drivers/media/platform/vsp1/vsp1_entity.c | 16 -
 drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
 drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
 drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
 drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
 drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
 drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
 drivers/media/platform/vsp1/vsp1_sru.c| 14 
 drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
 drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
 drivers/media/platform/vsp1/vsp1_video.c  | 11 --
 drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
 20 files changed, 168 insertions(+), 153 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index b9ff96f76b3e..652b42e3ec2d 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -30,10 +30,10 @@
  * Device Access
  */
 
-static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list 
*dl,
- u32 reg, u32 data)
+static inline void vsp1_bru_write(struct vsp1_bru *bru,
+ struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, bru->base + reg, data);
+   vsp1_dl_fragment_write(dlb, bru->base + reg, data);
 }
 
 /* 
-
@@ -287,7 +287,7 @@ static const struct v4l2_subdev_ops bru_ops = {
 
 static void bru_prepare(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
-   struct vsp1_dl_list *dl)
+   struct vsp1_dl_body *dlb)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
@@ -309,7 +309,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * format at the pipeline output is premultiplied.
 */
flags = pipe->output ? pipe->output->format.flags : 0;
-   vsp1_bru_write(bru, dl, VI6_BRU_INCTRL,
+   vsp1_bru_write(bru, dlb, VI6_BRU_INCTRL,
   flags & V4L2_PIX_FMT_FLAG_PREMUL_ALPHA ?
   0 : VI6_BRU_INCTRL_NRM);
 
@@ -317,12 +317,12 @@ static void bru_prepare(struct vsp1_entity *entity,
 * Set the background position to cover the whole output image and
 * configure its color.
 */
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_SIZE,
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_SIZE,
   (format->width << VI6_BRU_VIRRPF_SIZE_HSIZE_SHIFT) |
   (format->height << VI6_BRU_VIRRPF_SIZE_VSIZE_SHIFT));
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_LOC, 0);
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_LOC, 0);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_VIRRPF_COL, bru->bgcolor |
+   vsp1_bru_write(bru, dlb, VI6_BRU_VIRRPF_COL, bru->bgcolor |
   (0xff << VI6_BRU_VIRRPF_COL_A_SHIFT));
 
/*
@@ -332,7 +332,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 * unit.
 */
if (entity->type == VSP1_ENTITY_BRU)
-   vsp1_bru_write(bru, dl, VI6_BRU_ROP,
+   vsp1_bru_write(bru, dlb, VI6_BRU_ROP,
   VI6_BRU_ROP_DSTSEL_BRUIN(1) |
   VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
   VI6_BRU_ROP_AROP(VI6_ROP_NOP));
@@ -374,7 +374,7 @@ static void bru_prepare(struct vsp1_entity *entity,
if (!(entity->type == VSP1_ENTITY_BRU && i == 1))
ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i);
 
-   vsp1_bru_write(bru, dl, VI6_BRU_CTRL(i), ctrl);
+   vsp1_bru_write(bru, dlb, VI6_BRU_CTRL(i), ctrl);
 
/*
 * Harcode the blending formula to
@@ -389,7 +389,7 @@ static void bru_prepare(struct vsp1_entity *entity,
 *
 * otherwise.
 */
-   

[PATCH v2 7/8] v4l: vsp1: Move video configuration to a cached dlb

[Kieran Bingham]

We are now able to configure a pipeline directly into a local display
list body. Take advantage of this fact, and create a cacheable body to
store the configuration of the pipeline in the video object.

vsp1_video_pipeline_run() is now the last user of the pipe->dl object.
Convert this function to use the cached video->config body and obtain a
local display list reference.

Attach the video->config body to the display list when needed before
committing to hardware.

The pipe object is marked as un-configured when entering a suspend. This
ensures that upon resume, where the hardware is reset - our cached
configuration will be re-attached to the next committed DL.

Signed-off-by: Kieran Bingham 
---

Our video DL usage now looks like the below output:

dl->body0 contains our disposable runtime configuration. Max 41.
dl_child->body0 is our partition specific configuration. Max 12.
dl->fragments shows our constant configuration and LUTs.

  These two are LUT/CLU:
 * dl->fragments[x]->num_entries 256 / max 256
 * dl->fragments[x]->num_entries 4914 / max 4914

Which shows that our 'constant' configuration cache is currently
utilised to a maximum of 64 entries.

trace-cmd report | \
grep max | sed 's/.*vsp1_dl_list_commit://g' | sort | uniq;

  dl->body0->num_entries 13 / max 128
  dl->body0->num_entries 14 / max 128
  dl->body0->num_entries 16 / max 128
  dl->body0->num_entries 20 / max 128
  dl->body0->num_entries 27 / max 128
  dl->body0->num_entries 34 / max 128
  dl->body0->num_entries 41 / max 128
  dl_child->body0->num_entries 10 / max 128
  dl_child->body0->num_entries 12 / max 128
  dl->fragments[x]->num_entries 15 / max 128
  dl->fragments[x]->num_entries 16 / max 128
  dl->fragments[x]->num_entries 17 / max 128
  dl->fragments[x]->num_entries 18 / max 128
  dl->fragments[x]->num_entries 20 / max 128
  dl->fragments[x]->num_entries 21 / max 128
  dl->fragments[x]->num_entries 256 / max 256
  dl->fragments[x]->num_entries 31 / max 128
  dl->fragments[x]->num_entries 32 / max 128
  dl->fragments[x]->num_entries 39 / max 128
  dl->fragments[x]->num_entries 40 / max 128
  dl->fragments[x]->num_entries 47 / max 128
  dl->fragments[x]->num_entries 48 / max 128
  dl->fragments[x]->num_entries 4914 / max 4914
  dl->fragments[x]->num_entries 55 / max 128
  dl->fragments[x]->num_entries 56 / max 128
  dl->fragments[x]->num_entries 63 / max 128
  dl->fragments[x]->num_entries 64 / max 128
---
 drivers/media/platform/vsp1/vsp1_pipe.c  |  4 +-
 drivers/media/platform/vsp1/vsp1_pipe.h  |  4 +-
 drivers/media/platform/vsp1/vsp1_video.c | 67 -
 drivers/media/platform/vsp1/vsp1_video.h |  2 +-
 4 files changed, 51 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 5012643583b6..7d1f7ba43060 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -249,6 +249,7 @@ void vsp1_pipeline_run(struct vsp1_pipeline *pipe)
vsp1_write(vsp1, VI6_CMD(pipe->output->entity.index),
   VI6_CMD_STRCMD);
pipe->state = VSP1_PIPELINE_RUNNING;
+   pipe->configured = true;
}
 
pipe->buffers_ready = 0;
@@ -430,6 +431,9 @@ void vsp1_pipelines_suspend(struct vsp1_device *vsp1)
spin_lock_irqsave(>irqlock, flags);
if (pipe->state == VSP1_PIPELINE_RUNNING)
pipe->state = VSP1_PIPELINE_STOPPING;
+
+   /* After a suspend, the hardware will be reset */
+   pipe->configured = false;
spin_unlock_irqrestore(>irqlock, flags);
}
 
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h 
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 90d29492b9b9..e7ad6211b4d0 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -90,6 +90,7 @@ struct vsp1_partition {
  * @irqlock: protects the pipeline state
  * @state: current state
  * @wq: wait queue to wait for state change completion
+ * @configured: flag determining if the hardware has run since reset
  * @frame_end: frame end interrupt handler
  * @lock: protects the pipeline use count and stream count
  * @kref: pipeline reference count
@@ -117,6 +118,7 @@ struct vsp1_pipeline {
spinlock_t irqlock;
enum vsp1_pipeline_state state;
wait_queue_head_t wq;
+   bool configured;
 
void (*frame_end)(struct vsp1_pipeline *pipe, bool completed);
 
@@ -143,8 +145,6 @@ struct vsp1_pipeline {
 */
struct list_head entities;
 
-   struct vsp1_dl_list *dl;
-
unsigned int partitions;
struct vsp1_partition *partition;
struct vsp1_partition *part_table;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index 7e825f3360bf..42b70b8465ba 100644
--- 

[PATCH v2 0/8] vsp1: TLB optimisation and DL caching

[Kieran Bingham]

Each display list currently allocates an area of DMA memory to store register
settings for the VSP1 to process. Each of these allocations adds pressure to
the IPMMU TLB entries.

We can reduce the pressure by pre-allocating larger areas and dividing the area
across multiple bodies represented as a pool.

With this reconfiguration of bodies, we can adapt the configuration code to
separate out constant hardware configuration and cache it for re-use.

Patch 1 adds protection to ensure that the display list body does not overflow
and will allow us to reduce the size of the body allocations in the future (it
has already helped me catch an overflow during the development of this series,
so I thought it was a worth while addition)

Patch 2 implements the fragment pool object and provides function helpers to
interact with the pool

Patch 3 converts the existing allocations to use the new fragment pool.

>From patch 4 to 7, we then refactor the display list handling code to separate
out the two stages of stream setup and frame configuration and then configure
directly into display list bodies. This allows us to cache the constant stream
configuration in a reusable display list body which also repairs suspend/resume
cycles for the video pipelines.

Finally in patch 8, the size of the internal display list body is reduced down
to 64 entries, as the maximum used is now 41 slots. The cached video pipeline
stream configuration appears to use a maximum of 64 entries, but to allow for
expansion this is set to 128 for now to prevent unexpected overflows.

Kieran Bingham (8):
  v4l: vsp1: Protect fragments against overflow
  v4l: vsp1: Provide a fragment pool
  v4l: vsp1: Convert display lists to use new fragment pool
  v4l: vsp1: Use reference counting for fragments
  v4l: vsp1: Refactor display list configure operations
  v4l: vsp1: Adapt entities to configure into a body
  v4l: vsp1: Move video configuration to a cached dlb
  v4l: vsp1: Reduce display list body size

 drivers/media/platform/vsp1/vsp1_bru.c|  32 +--
 drivers/media/platform/vsp1/vsp1_clu.c|  86 +++---
 drivers/media/platform/vsp1/vsp1_clu.h|   1 +-
 drivers/media/platform/vsp1/vsp1_dl.c | 331 ---
 drivers/media/platform/vsp1/vsp1_dl.h |  13 +-
 drivers/media/platform/vsp1/vsp1_drm.c|  21 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  23 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  31 +--
 drivers/media/platform/vsp1/vsp1_hgo.c|  26 +--
 drivers/media/platform/vsp1/vsp1_hgt.c|  28 +--
 drivers/media/platform/vsp1/vsp1_hsit.c   |  20 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  23 +--
 drivers/media/platform/vsp1/vsp1_lut.c|  65 +++--
 drivers/media/platform/vsp1/vsp1_lut.h|   1 +-
 drivers/media/platform/vsp1/vsp1_pipe.c   |   8 +-
 drivers/media/platform/vsp1/vsp1_pipe.h   |   7 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 179 ++--
 drivers/media/platform/vsp1/vsp1_sru.c|  24 +--
 drivers/media/platform/vsp1/vsp1_uds.c|  73 ++---
 drivers/media/platform/vsp1/vsp1_uds.h|   2 +-
 drivers/media/platform/vsp1/vsp1_video.c  |  82 +++---
 drivers/media/platform/vsp1/vsp1_video.h  |   2 +-
 drivers/media/platform/vsp1/vsp1_wpf.c| 325 ---
 23 files changed, 753 insertions(+), 650 deletions(-)

base-commit: f44bd631453bf7dcbe57f79b924db3a6dd038bff
-- 
git-series 0.9.1

[PATCH v2 2/8] v4l: vsp1: Provide a fragment pool

[Kieran Bingham]

Each display list allocates a body to store register values in a dma
accessible buffer from a dma_alloc_wc() allocation. Each of these
results in an entry in the TLB, and a large number of display list
allocations adds pressure to this resource.

Reduce TLB pressure on the IPMMUs by allocating multiple display list
bodies in a single allocation, and providing these to the display list
through a 'fragment pool'. A pool can be allocated by the display list
manager or entities which require their own body allocations.

Signed-off-by: Kieran Bingham 

---
v2:
 - assign dlb->dma correctly
---
 drivers/media/platform/vsp1/vsp1_dl.c | 129 +++-
 drivers/media/platform/vsp1/vsp1_dl.h |   8 ++-
 2 files changed, 137 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index cb4625ae13c2..aab9dd6ec0eb 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -45,6 +45,8 @@ struct vsp1_dl_entry {
 /**
  * struct vsp1_dl_body - Display list body
  * @list: entry in the display list list of bodies
+ * @free: entry in the pool free body list
+ * @pool: pool to which this body belongs
  * @vsp1: the VSP1 device
  * @entries: array of entries
  * @dma: DMA address of the entries
@@ -54,6 +56,9 @@ struct vsp1_dl_entry {
  */
 struct vsp1_dl_body {
struct list_head list;
+   struct list_head free;
+
+   struct vsp1_dl_fragment_pool *pool;
struct vsp1_device *vsp1;
 
struct vsp1_dl_entry *entries;
@@ -65,6 +70,30 @@ struct vsp1_dl_body {
 };
 
 /**
+ * struct vsp1_dl_fragment_pool - display list body/fragment pool
+ * @dma: DMA address of the entries
+ * @size: size of the full DMA memory pool in bytes
+ * @mem: CPU memory pointer for the pool
+ * @bodies: Array of DLB structures for the pool
+ * @free: List of free DLB entries
+ * @lock: Protects the pool and free list
+ * @vsp1: the VSP1 device
+ */
+struct vsp1_dl_fragment_pool {
+   /* DMA allocation */
+   dma_addr_t dma;
+   size_t size;
+   void *mem;
+
+   /* Body management */
+   struct vsp1_dl_body *bodies;
+   struct list_head free;
+   spinlock_t lock;
+
+   struct vsp1_device *vsp1;
+};
+
+/**
  * struct vsp1_dl_list - Display list
  * @list: entry in the display list manager lists
  * @dlm: the display list manager
@@ -104,6 +133,7 @@ enum vsp1_dl_mode {
  * @active: list currently being processed (loaded) by hardware
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
+ * @pool: fragment pool for the display list bodies
  * @gc_work: fragments garbage collector work struct
  * @gc_fragments: array of display list fragments waiting to be freed
  */
@@ -119,6 +149,8 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *queued;
struct vsp1_dl_list *pending;
 
+   struct vsp1_dl_fragment_pool *pool;
+
struct work_struct gc_work;
struct list_head gc_fragments;
 };
@@ -128,6 +160,103 @@ struct vsp1_dl_manager {
  */
 
 /*
+ * Fragment pool's reduce the pressure on the iommu TLB by allocating a single
+ * large area of DMA memory and allocating it as a pool of fragment bodies
+ */
+struct vsp1_dl_fragment_pool *
+vsp1_dl_fragment_pool_alloc(struct vsp1_device *vsp1, unsigned int qty,
+   unsigned int num_entries, size_t extra_size)
+{
+   struct vsp1_dl_fragment_pool *pool;
+   size_t dlb_size;
+   unsigned int i;
+
+   pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+   if (!pool)
+   return NULL;
+
+   pool->vsp1 = vsp1;
+
+   dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;
+   pool->size = dlb_size * qty;
+
+   pool->bodies = kcalloc(qty, sizeof(*pool->bodies), GFP_KERNEL);
+   if (!pool->bodies) {
+   kfree(pool);
+   return NULL;
+   }
+
+   pool->mem = dma_alloc_wc(vsp1->bus_master, pool->size, >dma,
+   GFP_KERNEL);
+   if (!pool->mem) {
+   kfree(pool->bodies);
+   kfree(pool);
+   return NULL;
+   }
+
+   spin_lock_init(>lock);
+   INIT_LIST_HEAD(>free);
+
+   for (i = 0; i < qty; ++i) {
+   struct vsp1_dl_body *dlb = >bodies[i];
+
+   dlb->pool = pool;
+   dlb->max_entries = num_entries;
+
+   dlb->dma = pool->dma + i * dlb_size;
+   dlb->entries = pool->mem + i * dlb_size;
+
+   list_add_tail(>free, >free);
+   }
+
+   return pool;
+}
+
+void vsp1_dl_fragment_pool_free(struct vsp1_dl_fragment_pool *pool)
+{
+   if (!pool)
+   return;
+
+   if (pool->mem)
+   dma_free_wc(pool->vsp1->bus_master, pool->size, pool->mem,
+   pool->dma);
+
+   kfree(pool->bodies);
+   

[PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

[Kieran Bingham]

The entities provide a single .configure operation which configures the
object into the target display list, based on the vsp1_entity_params
selection.

This restricts us to a single function prototype for both static
configuration (the pre-stream INIT stage) and the dynamic runtime stages
for both each frame - and each partition therein.

Split the configure function into two parts, '.prepare()' and
'.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
.configure(). The configuration for individual partitions is handled by
passing the partition number to the configure call, and processing any
runtime stage actions on the first partition only.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_clu.c|  43 +--
 drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
 drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
 drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
 drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
 drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
 drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
 drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
 drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
 drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
 drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
 15 files changed, 359 insertions(+), 371 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index e8fd2ae3b3eb..b9ff96f76b3e 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -285,19 +285,15 @@ static const struct v4l2_subdev_ops bru_ops = {
  * VSP1 Entity Operations
  */
 
-static void bru_configure(struct vsp1_entity *entity,
- struct vsp1_pipeline *pipe,
- struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+static void bru_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
 {
struct vsp1_bru *bru = to_bru(>subdev);
struct v4l2_mbus_framefmt *format;
unsigned int flags;
unsigned int i;
 
-   if (params != VSP1_ENTITY_PARAMS_INIT)
-   return;
-
format = vsp1_entity_get_pad_format(>entity, bru->entity.config,
bru->entity.source_pad);
 
@@ -404,7 +400,7 @@ static void bru_configure(struct vsp1_entity *entity,
 }
 
 static const struct vsp1_entity_operations bru_entity_ops = {
-   .configure = bru_configure,
+   .prepare = bru_prepare,
 };
 
 /* 
-
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index 175717018e11..5f65ce3ad97f 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -213,37 +213,37 @@ static const struct v4l2_subdev_ops clu_ops = {
 /* 
-
  * VSP1 Entity Operations
  */
+static void clu_prepare(struct vsp1_entity *entity,
+   struct vsp1_pipeline *pipe,
+   struct vsp1_dl_list *dl)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   /*
+* The format can't be changed during streaming, only verify it
+* at setup time and store the information internally for future
+* runtime configuration calls.
+*/
+   struct v4l2_mbus_framefmt *format;
+
+   format = vsp1_entity_get_pad_format(>entity,
+   clu->entity.config,
+   CLU_PAD_SINK);
+   clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
+}
 
 static void clu_configure(struct vsp1_entity *entity,
  struct vsp1_pipeline *pipe,
  struct vsp1_dl_list *dl,
- enum vsp1_entity_params params)
+ unsigned int partition)
 {
struct vsp1_clu *clu = to_clu(>subdev);
struct vsp1_dl_body *dlb;
unsigned long flags;
u32 ctrl = VI6_CLU_CTRL_AAI | VI6_CLU_CTRL_MVS | VI6_CLU_CTRL_EN;
 
-   switch (params) {
-   case VSP1_ENTITY_PARAMS_INIT: {
-   /*
-* The format can't be changed during streaming, only verify it
-* at setup time and store the information internally for future
-* runtime configuration calls.
-*/
-   struct v4l2_mbus_framefmt *format;
-
-  

[PATCH v2 3/8] v4l: vsp1: Convert display lists to use new fragment pool

[Kieran Bingham]

Adapt the dl->body0 object to use an object from the fragment pool.
This greatly reduces the pressure on the TLB for IPMMU use cases, as
all of the lists use a single allocation for the main body.

The CLU and LUT objects pre-allocate a pool containing two bodies,
allowing a userspace update before the hardware has committed a previous
set of tables.

Fragments are no longer 'freed' in interrupt context, but instead
released back to their respective pools.  This allows us to remove the
garbage collector in the DLM.

Signed-off-by: Kieran Bingham 

---
v2:
 - Use dl->body0->max_entries to determine header offset, instead of the
   global constant VSP1_DL_NUM_ENTRIES which is incorrect.
 - squash updates for LUT, CLU, and fragment cleanup into single patch.
   (Not fully bisectable when separated)
---
 drivers/media/platform/vsp1/vsp1_clu.c |  22 ++-
 drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
 drivers/media/platform/vsp1/vsp1_dl.c  | 223 +-
 drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
 drivers/media/platform/vsp1/vsp1_lut.c |  23 ++-
 drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
 6 files changed, 90 insertions(+), 183 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_clu.c 
b/drivers/media/platform/vsp1/vsp1_clu.c
index f2fb26e5ab4e..52c523625e2f 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -23,6 +23,8 @@
 #define CLU_MIN_SIZE   4U
 #define CLU_MAX_SIZE   8190U
 
+#define CLU_SIZE   (17 * 17 * 17)
+
 /* 
-
  * Device Access
  */
@@ -47,19 +49,19 @@ static int clu_set_table(struct vsp1_clu *clu, struct 
v4l2_ctrl *ctrl)
struct vsp1_dl_body *dlb;
unsigned int i;
 
-   dlb = vsp1_dl_fragment_alloc(clu->entity.vsp1, 1 + 17 * 17 * 17);
+   dlb = vsp1_dl_fragment_get(clu->pool);
if (!dlb)
return -ENOMEM;
 
vsp1_dl_fragment_write(dlb, VI6_CLU_ADDR, 0);
-   for (i = 0; i < 17 * 17 * 17; ++i)
+   for (i = 0; i < CLU_SIZE; ++i)
vsp1_dl_fragment_write(dlb, VI6_CLU_DATA, ctrl->p_new.p_u32[i]);
 
spin_lock_irq(>lock);
swap(clu->clu, dlb);
spin_unlock_irq(>lock);
 
-   vsp1_dl_fragment_free(dlb);
+   vsp1_dl_fragment_put(dlb);
return 0;
 }
 
@@ -261,8 +263,16 @@ static void clu_configure(struct vsp1_entity *entity,
}
 }
 
+static void clu_destroy(struct vsp1_entity *entity)
+{
+   struct vsp1_clu *clu = to_clu(>subdev);
+
+   vsp1_dl_fragment_pool_free(clu->pool);
+}
+
 static const struct vsp1_entity_operations clu_entity_ops = {
.configure = clu_configure,
+   .destroy = clu_destroy,
 };
 
 /* 
-
@@ -288,6 +298,12 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device *vsp1)
if (ret < 0)
return ERR_PTR(ret);
 
+   /* Allocate a fragment pool */
+   clu->pool = vsp1_dl_fragment_pool_alloc(clu->entity.vsp1, 2,
+   CLU_SIZE + 1, 0);
+   if (!clu->pool)
+   return ERR_PTR(-ENOMEM);
+
/* Initialize the control handler. */
v4l2_ctrl_handler_init(>ctrls, 2);
v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.h 
b/drivers/media/platform/vsp1/vsp1_clu.h
index 036e0a2f1a42..601ffb558e30 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.h
+++ b/drivers/media/platform/vsp1/vsp1_clu.h
@@ -36,6 +36,7 @@ struct vsp1_clu {
spinlock_t lock;
unsigned int mode;
struct vsp1_dl_body *clu;
+   struct vsp1_dl_fragment_pool *pool;
 };
 
 static inline struct vsp1_clu *to_clu(struct v4l2_subdev *subdev)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index aab9dd6ec0eb..6ffdc3549283 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -110,7 +110,7 @@ struct vsp1_dl_list {
struct vsp1_dl_header *header;
dma_addr_t dma;
 
-   struct vsp1_dl_body body0;
+   struct vsp1_dl_body *body0;
struct list_head fragments;
 
bool has_chain;
@@ -134,8 +134,6 @@ enum vsp1_dl_mode {
  * @queued: list queued to the hardware (written to the DL registers)
  * @pending: list waiting to be queued to the hardware
  * @pool: fragment pool for the display list bodies
- * @gc_work: fragments garbage collector work struct
- * @gc_fragments: array of display list fragments waiting to be freed
  */
 struct vsp1_dl_manager {
unsigned int index;
@@ -150,9 +148,6 @@ struct vsp1_dl_manager {
struct vsp1_dl_list *pending;
 
struct vsp1_dl_fragment_pool *pool;
-
-   struct work_struct gc_work;
-   struct list_head 

[PATCH v2 1/8] v4l: vsp1: Protect fragments against overflow

[Kieran Bingham]

The fragment write function relies on the code never asking it to
write more than the entries available in the list.

Currently with each list body containing 256 entries, this is fine,
but we can reduce this number greatly saving memory.

In preparation of this - add a level of protection to catch any
buffer overflows.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8b5cbb6b7a70..cb4625ae13c2 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -50,6 +50,7 @@ struct vsp1_dl_entry {
  * @dma: DMA address of the entries
  * @size: size of the DMA memory in bytes
  * @num_entries: number of stored entries
+ * @max_entries: number of entries available
  */
 struct vsp1_dl_body {
struct list_head list;
@@ -60,6 +61,7 @@ struct vsp1_dl_body {
size_t size;
 
unsigned int num_entries;
+   unsigned int max_entries;
 };
 
 /**
@@ -138,6 +140,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
 
dlb->vsp1 = vsp1;
dlb->size = size;
+   dlb->max_entries = num_entries;
 
dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, >dma,
GFP_KERNEL);
@@ -220,6 +223,11 @@ void vsp1_dl_fragment_free(struct vsp1_dl_body *dlb)
  */
 void vsp1_dl_fragment_write(struct vsp1_dl_body *dlb, u32 reg, u32 data)
 {
+   if (unlikely(dlb->num_entries >= dlb->max_entries)) {
+   WARN_ONCE(true, "DLB size exceeded (max %u)", dlb->max_entries);
+   return;
+   }
+
dlb->entries[dlb->num_entries].addr = reg;
dlb->entries[dlb->num_entries].data = data;
dlb->num_entries++;
-- 
git-series 0.9.1

Re: [PATCH] mmc: renesas_sdhi: use extra flag for CBSY usage

[Geert Uytterhoeven]

Hi Wolfram,

On Wed, Aug 9, 2017 at 9:00 PM, Wolfram Sang
 wrote:
> There is one SDHI instance on Gen2 which does not have the CBSY bit.
> So, turn CBSY usage into an extra flag and set it accordingly. This has
> the additional advantage that we can also set it for other incarnations
> later.
>
> Signed-off-by: Wolfram Sang 
> ---
>
> Tested on a M3-W Salvator-X and H2 Lager (with both SDHI instances). I could
> move large files around without problems. Note that on the special incarnation
> without the CBSY bit, the old code still worked, so there might be a CBSY bit.
> But it is not documented, so we better play safe.

Is this supposed to have any impact on the issue on Magnus' r8a7794/alt, where
tuning failed before?

sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure failed
mmc1: tuning execution failed: -110
mmc1: error -110 whilst initialising SD card

Gr{oetje,eeting}s,

Geert

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

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

RE: [PATCH 1/2] ARM: dts: iwg20d-q7: Add RTC support

[Biju Das]

> -Original Message-
> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: 14 August 2017 15:12
> To: Biju Das 
> Cc: Rob Herring ; Mark Rutland
> ; Simon Horman ; Magnus
> Damm ; Russell King ;
> Chris Paterson ; devicet...@vger.kernel.org;
> Linux-Renesas ; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] ARM: dts: iwg20d-q7: Add RTC support
>
> On Tue, Aug 8, 2017 at 3:04 PM, Biju Das  wrote:
> > Define the iWave RainboW-G20D-Qseven board dependent part of the RTC
> > device node.
> >
> > Signed-off-by: Biju Das 
>
> > @@ -54,3 +59,16 @@
> > micrel,led-mode = <1>;
> > };
> >  };
> > +
> > + {
> > +   pinctrl-0 = <_pins>;
> > +   pinctrl-names = "default";
> > +
> > +   status = "okay";
> > +   clock-frequency = <40>;
> > +
> > +   rtc@68 {
> > +   compatible = "bq32000";
>
> "ti,bq32000"

Thanks. I will change this.

> > +   reg = <0x68>;
> > +   };
> > +};
>
> 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



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

Re: [PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support

[Geert Uytterhoeven]

On Mon, Aug 14, 2017 at 1:19 PM, Biju Das  wrote:
> Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI
> is identical to the R-Car Gen2 family.
>
> Signed-off-by: Biju Das 
> ---
> This patch is compiled and tested against mmc/next.
>
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index 718cb8a..f709f7f 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -95,6 +95,8 @@
> { .compatible = "renesas,sdhi-r7s72100", .data = _rz_compatible, },
> { .compatible = "renesas,sdhi-r8a7778", .data = 
> _rcar_gen1_compatible, },
> { .compatible = "renesas,sdhi-r8a7779", .data = 
> _rcar_gen1_compatible, },
> +   { .compatible = "renesas,sdhi-r8a7743", .data = 
> _rcar_gen2_compatible, },
> +   { .compatible = "renesas,sdhi-r8a7745", .data = 
> _rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7790", .data = 
> _rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7791", .data = 
> _rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7792", .data = 
> _rcar_gen2_compatible, },

I guess we want generic R-Car Gen2/3 compatible values here, too?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/2] ARM: dts: r8a7743: Add IIC cores to dtsi

[Geert Uytterhoeven]

On Thu, Aug 10, 2017 at 3:49 PM, Chris Paterson
 wrote:
>> From: Wolfram Sang [mailto:w...@the-dreams.de]
>> Sent: 10 August 2017 12:24
>>
>>
>> > > >+i2c6: i2c@e60b {
>> > >
>> > >I'd use iic0 as the label.

Sergei: I assume you meant "iic3"? ;-)

>> >
>> > I have no preference here other than that we try to be consistent in
>> > DT for different R-Car SoCs. Wolfram, do you have an opinion on this?
>>
>> Back then, for M2-W, I decided to go with the schematics/datasheets.
>> And those mentioned i2c6 rather than iic0. For that reason, the comment
>
> The M2 schematics still use i2c6, and for consistency I'd vote to use the 
> same with RZ/G1M.
>
>>
>> "/* The memory map in the User's Manual maps the cores to bus numbers */"
>>
>> exists in r8a7791.dtsi. Dunno the manual of this SoC here.
>
> The manual for r8a7743 uses the same terminology as the r8a7791 manuals.

The pinctrl section does, indeed.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 1/2] ARM: dts: iwg20d-q7: Add RTC support

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 3:04 PM, Biju Das  wrote:
> Define the iWave RainboW-G20D-Qseven board dependent part of the
> RTC device node.
>
> Signed-off-by: Biju Das 

> @@ -54,3 +59,16 @@
> micrel,led-mode = <1>;
> };
>  };
> +
> + {
> +   pinctrl-0 = <_pins>;
> +   pinctrl-names = "default";
> +
> +   status = "okay";
> +   clock-frequency = <40>;
> +
> +   rtc@68 {
> +   compatible = "bq32000";

"ti,bq32000"

> +   reg = <0x68>;
> +   };
> +};

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/2] gpio: make regmap_irq_chip const

[Linus Walleij]

On Sat, Aug 12, 2017 at 8:09 AM, Bhumika Goyal  wrote:

> Make the structure const as it is only passed to the function
> devm_regmap_add_irq_chip having the corresponding argument as const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 3/3] arm64: dts: r8a7795: Use R-Car SATA Gen3 fallback compat string

[Geert Uytterhoeven]

On Wed, Aug 9, 2017 at 10:26 AM, Simon Horman
 wrote:
> Use newly added R-Car SATA Gen3 fallback compat string
> in the DT of the r8a7795 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before the fallback compat string is considered.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 2/3] ARM: dts: r8a7791: Use R-Car SATA Gen2 fallback compat string

[Geert Uytterhoeven]

On Wed, Aug 9, 2017 at 10:26 AM, Simon Horman
 wrote:
> Use newly added R-Car SATA Gen2 fallback compat string
> in the DT of the r8a7791 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before the fallback compat string is considered.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 1/3] ARM: dts: r8a7790: Use R-Car SATA Gen2 fallback compat string

[Geert Uytterhoeven]

On Wed, Aug 9, 2017 at 10:26 AM, Simon Horman
 wrote:
> Use newly added R-Car SATA Gen2 fallback compat string
> in the DT of the r8a7790 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before the fallback compat string is considered.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 10/10] arm64: dts: r8a7796: Use R-Car GPIO Gen3 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen3 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in the DT of the r8a7796 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 09/10] arm64: dts: r8a7795: Use R-Car GPIO Gen3 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen3 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in the DT of the r8a7795 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 07/10] ARM: dts: r8a7793: Use R-Car GPIO Gen2 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen2 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in the DT of the r8a7793 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 06/10] ARM: dts: r8a7792: Use R-Car GPIO Gen2 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen2 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in the DT of the r8a7792 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 05/10] ARM: dts: r8a7791: Use R-Car GPIO Gen2 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen2 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in the DT of the r8a7791 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 04/10] ARM: dts: r8a7790: Use R-Car GPIO Gen2 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen2 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in the DT of the r8a7790 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 03/10] ARM: dts: r8a7743: Use R-Car GPIO Gen2 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen2 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in the DT of the r8a7743 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 02/10] ARM: dts: r8a7779: Use R-Car GPIO Gen1 fallback compat string

[Geert Uytterhoeven]

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen1 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in DT of r8a7779 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.

That is not correct: the driver does not match against "renesas,gpio-r8a7779".
Hence this breaks using a new DTS and an old kernel (which we may decide not
to care about for R-Car Gen1, though).
But at least the DTS change should be postponed until commit d10bbd156926e65d
("gpio: rcar: add gen[123] fallback compatibility strings") has hit mainline.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 01/10] ARM: dts: r8a7778: Use R-Car GPIO Gen1 fallback compat string

[Geert Uytterhoeven]

Hi Simon,

On Tue, Aug 8, 2017 at 10:39 AM, Simon Horman
 wrote:
> Use newly added R-Car GPIO Gen1 fallback compat string
> in place of now deprecated non-generation specific
> R-Car GPIO fallback compat string in DT of r8a7778 SoC.
>
> This should have no run-time effect as the driver matches against
> the per-SoC compat string before considering the fallback compat string.

That is not correct: the driver does not match against "renesas,gpio-r8a7778".
Hence this breaks using a new DTS and an old kernel (which we may decide not
to care about for R-Car Gen1, though).
But at least the DTS change should be postponed until commit d10bbd156926e65d
("gpio: rcar: add gen[123] fallback compatibility strings") has hit mainline.

> Signed-off-by: Simon Horman 
> ---
>  arch/arm/boot/dts/r8a7778.dtsi | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
> index 8f3156c0e575..b3975e4c75dd 100644
> --- a/arch/arm/boot/dts/r8a7778.dtsi
> +++ b/arch/arm/boot/dts/r8a7778.dtsi
> @@ -88,7 +88,7 @@
> };
>
> gpio0: gpio@ffc4 {
> -   compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
> +   compatible = "renesas,gpio-r8a7778", "renesas,rcar-gen2-gpio";

... "renesas,rcar-gen1-gpio";

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] cpufreq: rcar: Add support for R8A7795 SoC

[Geert Uytterhoeven]

Hi Viresh,

On Mon, Aug 7, 2017 at 5:37 AM, Viresh Kumar  wrote:
> On 04-08-17, 15:18, Simon Horman wrote:
>> From: Khiem Nguyen 
>>
>> After the commit "a399dc9fc50 cpufreq: shmobile: Use generic platdev
>> driver", will use cpufreq-dt-platdev driver to enable cpufreq-dt support.
>> Hence, follow the implementation to support new R8A7795 SoC.
>>
>> Signed-off-by: Khiem Nguyen 
>> Signed-off-by: Simon Horman 
>> ---
>>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> This is identical to a patch posted by Khiem last year.
>> At the time it was asked if using opp-v2 was the preferred approach.
>>
>> https://patchwork.kernel.org/patch/9054011/
>>
>> An inspection of the current upstream kernel code seems to indicate
>> that adding a binding as this patch does is compatibile with using opp-v2
>> and I plan to post DTS patches separately which make use of the opp-v2
>> bindings - they depend on this driver change to work.
>>
>> I have provided an integration patch with this patch, those DTS changes,
>> and Renesas clock updates also depended on by the DTS changes. The result
>> is working CPUFreq for the r8a7795 (R-Car H3) ES1.0.
>>
>> If this work is acceptable I plan to follow up with patches to
>> enable CPUFreq on the r8a7796 (R-Car M3-W).
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
>> topic/r8a7795-cpufreq
>>
>> A description of steps taken to lightly exercise the above can be found here:
>>
>> http://elinux.org/Tests:R-CAR-GEN3-CPUFreq
>>
>> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
>> b/drivers/cpufreq/cpufreq-dt-platdev.c
>> index 096aea7fcb67..13b72f3c420b 100644
>> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> @@ -67,6 +67,7 @@ static const struct of_device_id machines[] __initconst = {
>>   { .compatible = "renesas,r8a7792", },
>>   { .compatible = "renesas,r8a7793", },
>>   { .compatible = "renesas,r8a7794", },
>> + { .compatible = "renesas,r8a7795", },
>>   { .compatible = "renesas,sh73a0", },
>>
>>   { .compatible = "rockchip,rk2928", },
>
> Acked-by: Viresh Kumar 

I'm still a bit confused about your original comment when introducing this
file with the ever-growing table of SoCs:

"And for new platforms we may do things differently as they are going
 to use opp-v2 bindings."

Hence I was under the impression the growing would be mitigated by new SoCs
using the opp-v2 bindings instead, and not needing an entry in the table.

Perhaps I have misunderstood that comment?

Thanks for the clarification!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH mmc/next] mmc: renesas-sdhi: provide a whitelist for Gen3 SoC ES versions

[Geert Uytterhoeven]

Hi Simon,

On Wed, Aug 2, 2017 at 2:48 PM, Simon Horman  wrote:
> Provide a whitelist for Gen3 SoC ES versions for both the SYS DMAC and
> internal DMAC variants of the SDHI driver.  This is to allow drivers to
> only initialise for Gen3 SoC ES versions for which they are the appropriate
> DMAC implementation.  Currently internal DMAC is the appropriate
> implementation for all supported Gen3 SoC ES versions.
>
> Signed-off-by: Simon Horman 
> ---
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 15 +++
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c  | 15 +++
>  2 files changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index a26c6ed8e029..6717003888e2 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c

> @@ -241,8 +242,22 @@ static struct tmio_mmc_dma_ops 
> renesas_sdhi_internal_dmac_dma_ops = {
> .dataend = renesas_sdhi_internal_dmac_dataend_dma,
>  };
>
> +/*
> + * Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
> + * implementation as others may use a different implementation.
> + */
> +static const struct soc_device_attribute gen3_soc_whitelist[] = {
> +{ .soc_id = "r8a7795", .revision = "ES1.*" },
> +{ .soc_id = "r8a7795", .revision = "ES2.0" },
> +{ .soc_id = "r8a7796", .revision = "ES1.0" },
> +{ /* sentinel */ }
> +};
> +
>  static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
>  {
> +   if (!soc_device_match(gen3_soc_whitelist))
> +   return -ENODEV;

The pattern followed here is different from the pattern followed so far in
other places where we use soc_device_match(): instead of implementing a
specific behavior for early SoC revisions, and another behavior for later (and
future!) SoC revisions, this check tests for all current SoC revisions, and
breaks[*] for future versions (R-Car H3 ES2.1 and later, R-Car M3-W ES1.1 and
later).

I guess this is done this way because we don't have any R-Car Gen3 SoCs yet
that do support SYS-DMAC for SDHI?

[*] I understand it doesn't really break, but falls back to PIO on future
revisions? Hence it should be OK.

> +
> return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
>  }
>
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index b6789f5197b3..718cb8a9d2ce 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c

> @@ -459,8 +461,21 @@ static const struct tmio_mmc_dma_ops 
> renesas_sdhi_sys_dmac_dma_ops = {
> .dataend = renesas_sdhi_sys_dmac_dataend_dma,
>  };
>
> +/*
> + * Whitelist of specific R-Car Gen3 SoC ES versions to use this DMAC
> + * implementation. Currently empty as all supported ES versions use
> + * the internal DMAC.
> + */
> +static const struct soc_device_attribute gen3_soc_whitelist[] = {
> +{ /* sentinel */ }
> +};
> +
>  static int renesas_sdhi_sys_dmac_probe(struct platform_device *pdev)
>  {
> +   if (of_device_get_match_data(>dev) == _rcar_gen3_compatible 
> &&
> +   !soc_device_match(gen3_soc_whitelist))
> +   return -ENODEV;
> +
> return renesas_sdhi_probe(pdev, _sdhi_sys_dmac_dma_ops);
>  }

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] gpio: rcar: reinstate generic compat string

[Linus Walleij]

On Thu, Aug 10, 2017 at 10:06 AM, Simon Horman  wrote:
> On Wed, Aug 09, 2017 at 10:21:06AM +0200, Simon Horman wrote:
>> commit d10bbd156926 ("gpio: rcar: add gen[123] fallback compatibility
>> strings") deprecated the generic compat string, renesas,gpio-rcar. After
>> further discussion this appears not to have been desirable as that compat
>> string is compatible with all R-Car SoCs supported in upstream.
>>
>> This commit partially reverts that commit, and updates related
>> documentation and examples.
>>
>> Fixes: d10bbd156926 ("gpio: rcar: add gen[123] fallback compatibility 
>> strings")
>> Signed-off-by: Simon Horman 
>
> Hi Linus,
>
> I believe Geert is on holidays at the moment (maybe you are to‽).

Nah neither of us are as it seems :)

I wait for the two of you to figure this out before applying anything.

Yours,
Linus Walleij

Re: [PATCH v2 0/4] sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration

[Geert Uytterhoeven]

On Fri, Jun 30, 2017 at 10:10 AM, Geert Uytterhoeven
 wrote:
> On Thu, May 11, 2017 at 10:03 AM, Geert Uytterhoeven
>  wrote:
>> Magnus reported that on sh7722/Migo-R, pinctrl registration fails with:
>>
>> sh-pfc pfc-sh7722: pin 0 already registered
>> sh-pfc pfc-sh7722: error during pin registration
>> sh-pfc pfc-sh7722: could not register: -22
>> sh-pfc: probe of pfc-sh7722 failed with error -22
>>
>> pinmux_pins[] is initialized through PINMUX_GPIO(), using designated
>> array initializers, where the GPIO_* enums serve as indices.
>> Apparently GPIO_PTQ7 was defined in the enum, but never used.
>> If enum values are defined, but never used, pinmux_pins[] contains
>> (zero-filled) holes.  Hence such entries are treated as pin zero, which
>> was registered before, and pinctrl registration fails.
>>
>> I can't see how this ever worked, as at the time of commit f5e25ae52feff2dc
>> ("sh-pfc: Add sh7722 pinmux support"), pinmux_gpios[] in
>> drivers/pinctrl/sh-pfc/pfc-sh7722.c already had the hole, and
>> drivers/pinctrl/core.c already had the check.
>>
>> Some scripting revealed a few more broken drivers:
>>   - sh7757 has four holes, due to nonexistent GPIO_PT[JLNQ]7_RESV.
>>   - sh7264 and sh7269 define GPIO_PH[0-7], but don't use it with
>> PINMUX_GPIO().
>>
>> Patch 1 fixes the issue on sh7722, and was tested.
>> Patches 3-4 should fix the issue on the other 3 SoCs, but was untested due
>> to lack of hardware.
>>
>> Changes compared to v1:
>>   - Replace fake error messages by references to sh7722,
>>   - Add Reviewed-by, Tested-by.
>>
>> Thanks for applying!
>>
>> Geert Uytterhoeven (4):
>>   sh: sh7722: Remove nonexistent GPIO_PTQ7 to fix pinctrl registration
>>   sh: sh7757: Remove nonexistent GPIO_PT[JLNQ]7_RESV to fix pinctrl
>> registration
>>   sh: sh7264: Remove nonexistent GPIO_PH[0-7] to fix pinctrl
>> registration
>>   sh: sh7269: Remove nonexistent GPIO_PH[0-7] to fix pinctrl
>> registration
>>
>>  arch/sh/include/cpu-sh2a/cpu/sh7264.h | 4 +---
>>  arch/sh/include/cpu-sh2a/cpu/sh7269.h | 4 +---
>>  arch/sh/include/cpu-sh4/cpu/sh7722.h  | 2 +-
>>  arch/sh/include/cpu-sh4/cpu/sh7757.h  | 8 
>>  4 files changed, 7 insertions(+), 11 deletions(-)
>
> Are these patches planned for inclusion in v4.13?
> I don't see them in next-2016.

In v4.14, perhaps?
I don't see them in next-20170811...

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] arm64: dts: r8a7795: Add OPPs table for cpu devices

[Geert Uytterhoeven]

Hi Simon,

2017-08-04 15:26 GMT+02:00 Simon Horman :
> From: Dien Pham 
>
> Current, OPP tables are defined temporary,
> they are being evaluated and adjust in future.
>
> Based in part on work by Hien Dang.
>
> Signed-off-by: Dien Pham 
> Signed-off-by: Takeshi Kihara 
> [simon: consolidated sseveral patches into one]
> Signed-off-by: Simon Horman 
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 309 
> +++
>  1 file changed, 309 insertions(+)
>
> I am not aware of any build-time depdendencies of this patch.
>
> This patch has run-time depdnencies on:
> * [PATCH] cpufreq: rcar: Add support for R8A7795 SoC
> * [PATCH 0/4] r8a7795: Add Z and Z2 clock support
>
> I have provided an integration patch with this patch, those DTS changes,
> and Renesas clock updates also depended on by the DTS changes. The result
> is working CPUFreq for the r8a7795 (R-Car H3) ES1.0.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
> topic/r8a7795-cpufreq
>
> A description of steps taken to lightly exercise the above can be found here:
>
> http://elinux.org/Tests:R-CAR-GEN3-CPUFreq
>
> If this work is acceptable I plan to follow up with patches to
> enable CPUFreq on the r8a7796 (R-Car M3-W).
>
> This patch is based on renesas-arm64-dt-for-v4.14
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index a87ae76880ab..f34da4c9ea52 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi

> @@ -126,6 +152,289 @@
> };
> };
>
> +   cluster0_opp_tb0: opp_table0 {
> +   compatible = "operating-points-v2";
> +   opp-shared;
> +
> +   opp@5 {

No complaints from "make W=1 dtbs" due to unit-address without reg property?

=> "opp-5 { ... };"

> +   opp-hz = /bits/ 64 <5>;
> +   opp-microvolt = <83>;
> +   clock-latency-ns = <30>;
> +   };

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 0/3] Add SDHI Support

[Biju Das]

This series aims to add SDHI support for r8a7743 SoC.

This series has been compiled and tested against renesas-dev tag
renesas-devel-20170814-v4.13-rc5.

There is no compile time dependencies.It has run time dependency on
[PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support.
https://patchwork.kernel.org/patch/9898611/ 

Biju Das (3):
  ARM: dts: r8a7743: Add SDHI controllers
  ARM: dts: iwg20m: Enable SDHI0 controller
  ARM: dts: iwg20d-q7: Add SDHI1 support

 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 48 +
 arch/arm/boot/dts/r8a7743-iwg20m.dtsi   | 17 
 arch/arm/boot/dts/r8a7743.dtsi  | 42 +
 3 files changed, 107 insertions(+)

-- 
1.9.1

[PATCH 2/3] ARM: dts: iwg20m: Enable SDHI0 controller

[Biju Das]

Enable the SDHI0 controller on iWave RZG1M Qseven SOM.

Signed-off-by: Biju Das 
---
 arch/arm/boot/dts/r8a7743-iwg20m.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi 
b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
index ff79938..4119737 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
+++ b/arch/arm/boot/dts/r8a7743-iwg20m.dtsi
@@ -9,6 +9,7 @@
  */
 
 #include "r8a7743.dtsi"
+#include 
 
 / {
compatible = "iwave,g20m", "renesas,r8a7743";
@@ -42,6 +43,12 @@
groups = "mmc_data8_b", "mmc_ctrl";
function = "mmc";
};
+
+   sdhi0_pins: sd0 {
+   groups = "sdhi0_data4", "sdhi0_ctrl";
+   function = "sdhi0";
+   power-source = <3300>;
+   };
 };
 
  {
@@ -53,3 +60,13 @@
non-removable;
status = "okay";
 };
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   vmmc-supply = <_3p3v>;
+   vqmmc-supply = <_3p3v>;
+   cd-gpios = < 11 GPIO_ACTIVE_LOW>;
+   status = "okay";
+};
-- 
1.9.1

[PATCH 3/3] ARM: dts: iwg20d-q7: Add SDHI1 support

[Biju Das]

Define the iWave RainboW-G20D-Qseven board dependent part of the
SDHI1 device node.

Signed-off-by: Biju Das 
---
 arch/arm/boot/dts/r8a7743-iwg20d-q7.dts | 48 +
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts 
b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
index b3a1efa..b5ac0ff 100644
--- a/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
+++ b/arch/arm/boot/dts/r8a7743-iwg20d-q7.dts
@@ -19,6 +19,29 @@
serial0 = 
ethernet0 = 
};
+
+   vcc_sdhi1: regulator-vcc-sdhi1 {
+   compatible = "regulator-fixed";
+
+   regulator-name = "SDHI1 Vcc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 16 GPIO_ACTIVE_LOW>;
+   };
+
+   vccq_sdhi1: regulator-vccq-sdhi1 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "SDHI1 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+
+   gpios = < 30 GPIO_ACTIVE_LOW>;
+   gpios-states = <1>;
+   states = <330 1
+ 180 0>;
+   };
 };
 
  {
@@ -36,6 +59,18 @@
groups = "i2c2";
function = "i2c2";
};
+
+   sdhi1_pins: sd1 {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <3300>;
+   };
+
+   sdhi1_pins_uhs: sd1_uhs {
+   groups = "sdhi1_data4", "sdhi1_ctrl";
+   function = "sdhi1";
+   power-source = <1800>;
+   };
 };
 
  {
@@ -72,3 +107,16 @@
reg = <0x68>;
};
 };
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_pins_uhs>;
+   pinctrl-names = "default", "state_uhs";
+
+   vmmc-supply = <_sdhi1>;
+   vqmmc-supply = <_sdhi1>;
+   cd-gpios = < 14 GPIO_ACTIVE_LOW>;
+   wp-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   sd-uhs-sdr50;
+   status = "okay";
+};
-- 
1.9.1

[PATCH 1/3] ARM: dts: r8a7743: Add SDHI controllers

[Biju Das]

Add the SDHI controllers to the r8a7743 device tree.

Signed-off-by: Biju Das 
---
 arch/arm/boot/dts/r8a7743.dtsi | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index ce80a26..3bd3ab5 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -754,6 +754,48 @@
max-frequency = <9750>;
status = "disabled";
};
+
+   sdhi0: sd@ee10 {
+   compatible = "renesas,sdhi-r8a7743";
+   reg = <0 0xee10 0 0x328>;
+   interrupts = ;
+   clocks = < CPG_MOD 314>;
+   dmas = < 0xcd>, < 0xce>,
+  < 0xcd>, < 0xce>;
+   dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <19500>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 314>;
+   status = "disabled";
+   };
+
+   sdhi1: sd@ee14 {
+   compatible = "renesas,sdhi-r8a7743";
+   reg = <0 0xee14 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 312>;
+   dmas = < 0xc1>, < 0xc2>,
+  < 0xc1>, < 0xc2>;
+   dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 312>;
+   status = "disabled";
+   };
+
+   sdhi2: sd@ee16 {
+   compatible = "renesas,sdhi-r8a7743";
+   reg = <0 0xee16 0 0x100>;
+   interrupts = ;
+   clocks = < CPG_MOD 311>;
+   dmas = < 0xd3>, < 0xd4>,
+  < 0xd3>, < 0xd4>;
+   dma-names = "tx", "rx", "tx", "rx";
+   max-frequency = <9750>;
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 311>;
+   status = "disabled";
+   };
};
 
/* External root clock */
-- 
1.9.1

[PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support

[Biju Das]

Add support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5) SDHI
is identical to the R-Car Gen2 family.

Signed-off-by: Biju Das 
---
This patch is compiled and tested againt linux next tag
next-20170811. This patch depend on the driver change
[PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support
https://patchwork.kernel.org/patch/9898611/


 Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt 
b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index 4fd8b7a..0d507ec 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -15,6 +15,8 @@ Required properties:
"renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC
"renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
"renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
+   "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC
+   "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC
"renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
"renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
"renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
@@ -34,8 +36,8 @@ Required properties:
  "core" and "cd". If the controller only has 1 clock, naming is not
  required.
  Below is the number clocks for each supported SoC:
-  1: SH73A0, R8A73A4, R8A7740, R8A7778, R8A7779, R8A7790
- R8A7791, R8A7792, R8A7793, R8A7794, R8A7795, R8A7796
+  1: SH73A0, R8A73A4, R8A7740, R8A7743, R8A7745, R8A7778, R8A7779,
+ R8A7790, R8A7791, R8A7792, R8A7793, R8A7794, R8A7795, R8A7796
   2: R7S72100
 
 Optional properties:
-- 
1.9.1

Re: [PATCH] gpio: rcar: reinstate generic compat string

[Geert Uytterhoeven]

Hi Simon,

On Wed, Aug 9, 2017 at 10:21 AM, Simon Horman
 wrote:
> commit d10bbd156926 ("gpio: rcar: add gen[123] fallback compatibility
> strings") deprecated the generic compat string, renesas,gpio-rcar. After
> further discussion this appears not to have been desirable as that compat
> string is compatible with all R-Car SoCs supported in upstream.

While "renesas,gpio-rcar" is treated as a GPIO controller on R-Car Gen1 SoCs,
it can indeed be used on R-Car Gen2 and Gen3, with reduced functionality.
In se this is compatible with the spirit of multiple compatible values.

> This commit partially reverts that commit, and updates related
> documentation and examples.
>
> Fixes: d10bbd156926 ("gpio: rcar: add gen[123] fallback compatibility 
> strings")
> Signed-off-by: Simon Horman 
> ---
>  .../devicetree/bindings/gpio/renesas,gpio-rcar.txt | 18 
> --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt 
> b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> index 48634b01f1bf..347d8ede2982 100644
> --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> @@ -16,11 +16,13 @@ Required Properties:
>  - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller.
>  - "renesas,rcar-gen2-gpio": for a generic R-Car Gen2 or RZ/G1 GPIO 
> controller.
>  - "renesas,rcar-gen3-gpio": for a generic R-Car Gen3 GPIO controller.
> -- "renesas,gpio-rcar": deprecated.
> +- "renesas,gpio-rcar": for generic R-Car GPIO controller.
>
> -When compatible with the generic version nodes must list the
> -SoC-specific version corresponding to the platform first followed by
> -the generic version.
> +Nodes should list all of the following that are compatible
> +in this order:
> +- A SoC-specific version
> +- A generic R-Car generation version
> +- The generic R-Car version

The main objective of commit d10bbd156926 ("gpio: rcar: add gen[123] fallback
compatibility strings") was avoiding the need to add more SoC-specific
compatible values to the match table in the driver, when adding driver
support for more R-Car and RZ/G SoCs.

With this amendment, this objective is met at the expense of adding a third
compatible value to each and every GPIO device node in R-Car .dtsi files :-(
IMHO keeping "renesas,gpio-rcar" everywhere adds little value.  The only
exception might be running an old kernel on a new SoC, but that is ruled out
for a few core components like clocks and PFC anyway.

Of course the driver has to keep matching on the deprecated value, which is
already the case without this amendment.

>- reg: Base address and length of each memory resource used by the GPIO
>  controller hardware module.
> @@ -50,7 +52,9 @@ interrupt-controller/interrupts.txt.
>  Example: R8A7779 (R-Car H1) GPIO controller nodes
>
> gpio0: gpio@ffc4 {
> -   compatible = "renesas,gpio-r8a7779", "renesas,rcar-gen1-gpio";
> +   compatible = "renesas,gpio-r8a7779",
> +"renesas,rcar-gen1-gpio",
> +"renesas,gpio-rcar";

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 3/4] net: sh_eth: constify platform_device_id

[Sergei Shtylyov]

Hello!

On 08/13/2017 02:12 PM, Arvind Yadav wrote:


platform_device_id are not supposed to change at runtime. All functions
working with platform_device_id provided by 
work with const platform_device_id. So mark the non-const structs as
const.

Signed-off-by: Arvind Yadav 


Acked-by: Sergei Shtylyov 

though it seems too late as DaveM has taken the series...

[...]

MBR, Sergei

[PATCH ] mmc: renesas_sdhi: Add r8a7743/5 support

[Biju Das]

Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI
is identical to the R-Car Gen2 family.

Signed-off-by: Biju Das 
---
This patch is compiled and tested against mmc/next.

 drivers/mmc/host/renesas_sdhi_sys_dmac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c 
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index 718cb8a..f709f7f 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -95,6 +95,8 @@
{ .compatible = "renesas,sdhi-r7s72100", .data = _rz_compatible, },
{ .compatible = "renesas,sdhi-r8a7778", .data = 
_rcar_gen1_compatible, },
{ .compatible = "renesas,sdhi-r8a7779", .data = 
_rcar_gen1_compatible, },
+   { .compatible = "renesas,sdhi-r8a7743", .data = 
_rcar_gen2_compatible, },
+   { .compatible = "renesas,sdhi-r8a7745", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7790", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7791", .data = 
_rcar_gen2_compatible, },
{ .compatible = "renesas,sdhi-r8a7792", .data = 
_rcar_gen2_compatible, },
-- 
1.9.1

Re: [PATCH v2] ravb: add wake-on-lan support via magic packet

[Geert Uytterhoeven]

Hi Andrew, Niklas,

On Sun, Jul 30, 2017 at 9:51 PM, Niklas Söderlund
 wrote:
> On 2017-07-30 19:07:38 +0200, Andrew Lunn wrote:
>> > @@ -2041,6 +2073,11 @@ static int ravb_probe(struct platform_device *pdev)
>> >
>> > priv->chip_id = chip_id;
>> >
>> > +   /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */
>> > +   priv->clk = devm_clk_get(>dev, NULL);
>> > +   if (IS_ERR(priv->clk))
>> > +   priv->clk = NULL;
>>
>> Can you get EPROBE_DEFER returned?
>
> I don't think so, but I'm not sure :-)
>
> The clock I'm trying to get is the module clock of the ravb itself, so
> if that clock is not available (and enabled) no register writes to the
> ravb would be possible in the first place, so i guess it's safe to
> assume -EPROBE_DEFER can not happen here?

In theory, the devm_clk_get() can fail.
In practice, it cannot, as the EtherAVB device is part of a clock domain,
through its "power-domains" property in DT.
Hence if the clock (which is the module clock, provided by the SoC's system
clock controller (CPG/MSSR)) is not yet available, the PM Domain subsystem
will prevent the device from being probed.

> I'm just trying to play it safe here since the clock is only needed to
> support WoL, I though it best to not change behavior here. Try to get
> the clock, if we can great we can do WoL if not then user-space will be
> prevented from enabling WoL and nothing in the current behavior changes.

And all this explicit clock handling is done only because
device_set_wakeup_enable() does not yet prevent the PM Domain code from
powering down the device during system suspend.  Once that's handled by genpd,
all clock magic can be removed.

Gr{oetje,eeting}s,

Geert

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

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

Re: [RFC 0/5] arm64: dts: renesas: add VIN, CSI-2 and ADV7482 nodes

[Geert Uytterhoeven]

Hi Niklas,

On Sun, Jul 30, 2017 at 10:56 PM, Niklas Söderlund
 wrote:
> This is a RFC for how I imagine the final DT for the video capture nodes
> will look. Since the DT file layout changed recently I wanted to post a
> RFC before I include these in my for-renesas-drivers branch.
>
> These are not intended for Simons tree, the DT bindings are not accepted
> upstream. checkpatch will warn about missing compat strings if not run
> ontop a tree which contains the driver patches for Gen3 VIN, CSI-2 and
> ADV7482.
>
> Please review and give some feedback if you don't think this should be
> included in renesas-drivers :-)

Preliminary general comment: "resets" properties are missing.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH V4 1/2] mfd: Add ROHM BD9571MWV-M PMIC DT bindings

[Geert Uytterhoeven]

Hi Marek,

You forgot to CC Lee (added ;-)

On Mon, Jul 17, 2017 at 10:45 PM, Marek Vasut  wrote:
> Add DT bindings for the ROHM BD9571MWV-M PMIC. This PMIC has
> the following features:
> - multiple voltage monitors for 1V8, 2V5, 3V3 voltage rail
> - one voltage regulator for DVFS
> - two GPIOs
>
> Signed-off-by: Marek Vasut 
> Cc: devicet...@vger.kernel.org
> Cc: Rob Herring 
> Cc: Geert Uytterhoeven 
> Cc: linux-renesas-soc@vger.kernel.org
> Acked-by: Rob Herring 
> ---
> V2: - Drop the compatible = "regulator-fixed" from the binding example,
>   it should not be there.
> - List the VD09 regulator
> V3: Replace bd9571@30 with pmic@30
> V4: No changes
> ---
>  .../devicetree/bindings/mfd/bd9571mwv.txt  | 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/bd9571mwv.txt

Anyway, as there were no changes in V4, Lee can just apply V3, for which he
was CCed.

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] clk: renesas: r8a7796: Add USB3.0 clock

[Geert Uytterhoeven]

On Wed, Jul 26, 2017 at 1:23 PM, Yoshihiro Shimoda
 wrote:
> From: Hiromitsu Yamasaki 
>
> This patch adds USB3.0-IF0 clock for R8A7796 SoC.
>
> Signed-off-by: Hiromitsu Yamasaki 
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

I.e. will queue in clk-renesas-for-v4.14.

je,eeting}s,

Geert

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

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