Re: [PATCH 2/6] dt-bindings: pwm: rcar: Document r8a774[35] PWM bindings

[Rob Herring]

On Thu, Dec 14, 2017 at 10:56:12AM +, Fabrizio Castro wrote:
> This patch adds compatible strings specific to r8a774[35], no driver
> change is needed as the fallback compatible string will activate the
> right code. Also, this patch replaces the example with a DT snippet used
> for adding PWM0 support to an r8a7743 based platform.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
> Dear All,
> 
> the reason for replacing the example with one of a different SoC is that
> the new example refers to recent code from a real use case. I hope that's ok.
> 
> Thanks,
> Fabrizio
> 
>  Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH 1/2] dt-bindings: thermal: rcar: Add device tree support for r8a7743

[Rob Herring]

On Wed, Dec 13, 2017 at 10:57:52AM +, Biju Das wrote:
> Add thermal sensor support for r8a7743 SoC. The Renesas RZ/G1M
> (r8a7743) thermal sensor module is identical to the R-Car Gen2 family.
> 
> No driver change is needed due to the fallback compatible value
> "renesas,rcar-gen2-thermal".
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 
> ---
>  Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring 

Re: [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Rob Herring]

On Tue, Dec 12, 2017 at 06:49:37PM +, Fabrizio Castro wrote:
> Document SoC specific compatible strings for r8a7743 and r8a7745.
> No driver change is needed as the fallback strings will activate
> the right code.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
>  Documentation/devicetree/bindings/timer/renesas,cmt.txt | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)

Reviewed-by: Rob Herring 

Re: [PATCH 4/6] dt-bindings: pwm: renesas-tpu: Document r8a774[35] support

[Rob Herring]

On Thu, Dec 14, 2017 at 10:56:14AM +, Fabrizio Castro wrote:
> Document r8a774[35] specific compatible strings. No driver change is
> needed as the fallback compatible string "renesas,tpu" activates the
> right code in the driver.
> 
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
>  Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

[Wolfram Sang]

> > Other thoughts?
> 
> Nope.

I have :) Another solution seems to be to switch to ioread16_rep and
friends. Those are defined on sparc64. Compiles locally here, now sent
it to buildbot.



signature.asc
Description: PGP signature

Re: arm64: unhandled level 0 translation fault

[Dave Martin]

On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
> Hi Dave,
> 
> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin  wrote:
> > On Thu, Dec 14, 2017 at 07:08:27PM +0100, Geert Uytterhoeven wrote:
> >> On Thu, Dec 14, 2017 at 4:24 PM, Dave P Martin  wrote:

[...]

> >> > Good work on the bisect -- I'll need to have a think about this...
> >> >
> >> > That patch fixes a genuine problem so we can't just revert it.
> >> >
> >> > What if you revert _just this function_ back to what it was in v4.14?
> >>
> >> With fpsimd_update_current_state() reverted to v4.14, and
> >>
> >> -   __this_cpu_write(fpsimd_last_state, st);
> >> +   __this_cpu_write(fpsimd_last_state.st, st);
> >>
> >> to make it build, the problem seems to be fixed, too.
> 
> > Interesting if I apply that to v4.14 and then flatten the new code for 
> > CONFIG_ARM64_SVE=n, I get:
> >
> > Working:
> >
> > void fpsimd_update_current_state(struct fpsimd_state *state)
> > {
> > local_bh_disable();
> >
> > fpsimd_load_state(state);
> > if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> > struct fpsimd_state *st = >thread.fpsimd_state;
> >
> > __this_cpu_write(fpsimd_last_state.st, st);
> > st->cpu = smp_processor_id();
> > }
> >
> > local_bh_enable();
> > }
> >
> > Broken:
> >
> > void fpsimd_update_current_state(struct fpsimd_state *state)
> > {
> > struct fpsimd_last_state_struct *last;
> > struct fpsimd_state *st;
> >
> > local_bh_disable();
> >
> > current->thread.fpsimd_state = *state;
> > fpsimd_load_state(>thread.fpsimd_state);
> >
> > if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> > last = this_cpu_ptr(_last_state);
> > st = >thread.fpsimd_state;
> >
> > last->st = st;
> > last->sve_in_use = test_thread_flag(TIF_SVE);
> > st->cpu = smp_processor_id();
> > }
> >
> > local_bh_enable();
> > }
> >
> > Can you try my flattened "broken" version by itself and see if that does
> > reproduce the bug?  If not, my flattening may be making bad assumptions...
> >
> > Assuming the "broken" version reproduces the bug, I can't yet see exactly
> > where the breakage comes from.
> 
> Correct, above "Working" is working, and "Broken" is broken.
> 
> > The two important differences here seem to be
> >
> > 1) Staging the state via current->thread.fpsimd_state instead of loading
> > directly:
> >
> > -   fpsimd_load_state(state);
> > +   current->thread.fpsimd_state = *state;
> > +   fpsimd_load_state(>thread.fpsimd_state);
> 
> The change above introduces the breakage.
> 
> > 2) Using this_cpu_ptr() + assignment instead of __this_cpu_write() when
> > reassociating the task's fpsimd context with the cpu:
> >
> >  {
> > +   struct fpsimd_last_state_struct *last;
> > +   struct fpsimd_state *st;
> >
> > [...]
> >
> > if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> > -   struct fpsimd_state *st = >thread.fpsimd_state;
> > -
> > -   __this_cpu_write(fpsimd_last_state.st, st);
> > -   st->cpu = smp_processor_id();
> > +   last = this_cpu_ptr(_last_state);
> > +   st = >thread.fpsimd_state;
> > +
> > +   last->st = st;
> > +   last->sve_in_use = test_thread_flag(TIF_SVE);
> > +   st->cpu = smp_processor_id();
> > }
> 
> The change above is fine.

Thanks for this.

Will came up with a convincing hypothesis for how the dodgy change broke
things here -- see the diff in his separate reply.

I'll cook up a more complete fix, but the diff Will provided should at
least get things working.

Cheers
---Dave

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

[Wolfram Sang]

> > Ulf, this patch then in deed should ideally be applied before 1-8 here.
> 
> Okay, once you post it to linux-mmc I will pick it up, and put it in front.

Bad news, that patch didn't help. The problem is that sparc64 doesn't
include 'asm-generic/io.h' and also has no own 'readsw'. No surprise
that just adding this include will cause lots of redefines which are way
too much to handle as a side-task.

So, the best option I see here is to drop COMPILE_TEST for now, report
this to the sparc64 maintainers (I assume they know already), and see if
they can fix it.

Other thoughts?



signature.asc
Description: PGP signature

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

[Ulf Hansson]

On 15 December 2017 at 17:30, Wolfram Sang  wrote:
>
>> > Ulf, this patch then in deed should ideally be applied before 1-8 here.
>>
>> Okay, once you post it to linux-mmc I will pick it up, and put it in front.
>
> Bad news, that patch didn't help. The problem is that sparc64 doesn't
> include 'asm-generic/io.h' and also has no own 'readsw'. No surprise
> that just adding this include will cause lots of redefines which are way
> too much to handle as a side-task.
>
> So, the best option I see here is to drop COMPILE_TEST for now, report
> this to the sparc64 maintainers (I assume they know already), and see if
> they can fix it.

Okay!

If some of you send a patch on top, I can fold it into the offending commit.

>
> Other thoughts?

Nope.

Kind regards
Uffe

Re: [PATCH 5/5] v4l2: async: Add debug output to v4l2-async module

[Sakari Ailus]

Hi Jacopo,

On Wed, Dec 13, 2017 at 07:26:20PM +0100, Jacopo Mondi wrote:
> The v4l2-async module operations are quite complex to follow, due to the
> asynchronous nature of subdevices and notifiers registration and
> matching procedures. In order to help with debugging of failed or
> erroneous matching between a subdevice and the notifier collected
> async_subdevice it gets matched against, introduce a few dev_dbg() calls
> in v4l2_async core operations.
> 
> Protect the debug operations with a Kconfig defined symbol, to make sure
> when debugging is disabled, no additional code or data is added to the
> module.
> 
> Notifiers are identified by the name of the subdevice or v4l2_dev they are
> registered by, while subdevice matching which now happens on endpoints,
> need a longer description built walking the fwnode graph backwards
> collecting parent nodes names (otherwise we would have had printouts
> like: "Matching "endpoint" with "endpoint"" which are not that useful).
> 
> Signed-off-by: Jacopo Mondi 
> 
> ---
> For fwnodes backed by OF, I may have used the "%pOF" format modifier to
> get the full node name instead of parsing the fwnode graph by myself with
> "v4l2_async_fwnode_full_name()". Unfortunately I'm not aware of anything
> like "%pOF" for ACPI backed fwnodes. Also, walking the fwnode graph by
> myself allows me to reduce the depth, to reduce the debug messages output
> length which is anyway long enough to result disturbing on a 80columns
> terminal window.

ACPI doesn't have such at the moment. I think printing the full path would
still be better. There isn't that much more to print after all.

> ---
> 
>  drivers/media/v4l2-core/Kconfig  |  8 
>  drivers/media/v4l2-core/v4l2-async.c | 81 
> 
>  2 files changed, 89 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
> index a35c336..8331736 100644
> --- a/drivers/media/v4l2-core/Kconfig
> +++ b/drivers/media/v4l2-core/Kconfig
> @@ -17,6 +17,14 @@ config VIDEO_ADV_DEBUG
> V4L devices.
> In doubt, say N.
> 
> +config VIDEO_V4L2_ASYNC_DEBUG
> + bool "Enable debug functionalities for V4L2 async module"
> + depends on VIDEO_V4L2

I'm not sure I'd add a Kconfig option. This is adding a fairly simple
function only to the kernel.

> + default n
> + ---help---
> +   Say Y here to enable debug output in V4L2 async module.
> +   In doubt, say N.
> +
>  config VIDEO_FIXED_MINOR_RANGES
>   bool "Enable old-style fixed minor ranges on drivers/video devices"
>   default n
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index c13a781..307e1a5 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -8,6 +8,10 @@
>   * published by the Free Software Foundation.
>   */
> 
> +#if defined(CONFIG_VIDEO_V4L2_ASYNC_DEBUG)
> +#define DEBUG

Do you need this?

> +#endif
> +
>  #include 
>  #include 
>  #include 
> @@ -25,6 +29,52 @@
>  #include 
>  #include 
> 
> +#if defined(CONFIG_VIDEO_V4L2_ASYNC_DEBUG)
> +#define V4L2_ASYNC_FWNODE_NAME_LEN   512
> +
> +static void __v4l2_async_fwnode_full_name(char *name,
> +   unsigned int len,
> +   unsigned int max_depth,
> +   struct fwnode_handle *fwnode)
> +{
> + unsigned int buf_len = len < V4L2_ASYNC_FWNODE_NAME_LEN ?
> +len : V4L2_ASYNC_FWNODE_NAME_LEN;
> + char __tmp[V4L2_ASYNC_FWNODE_NAME_LEN];

That's a bit too much to allocate from the stack I think.

> + struct fwnode_handle *parent;
> +
> + memset(name, 0, buf_len);
> + buf_len -= snprintf(__tmp, buf_len, "%s", fwnode_get_name(fwnode));
> +
> + parent = fwnode;
> + while ((parent = fwnode_get_parent(parent)) && buf_len &&
> + --max_depth) {
> + buf_len -= snprintf(name, buf_len, "%s/%s",
> + fwnode_get_name(parent), __tmp);
> + strcpy(__tmp, name);
> + }
> +}
> +
> +static void v4l2_async_fwnode_full_name(char *name,
> + unsigned int len,
> + struct fwnode_handle *fwnode)
> +{
> + /*
> +  * Usually 4 as nesting level is sufficient to identify an
> +  * endpoint firmware node uniquely.
> +  */
> + __v4l2_async_fwnode_full_name(name, len, 4, fwnode);
> +}
> +
> +#else /* CONFIG_VIDEO_V4L2_ASYNC_DEBUG */
> +#define V4L2_ASYNC_FWNODE_NAME_LEN   0
> +
> +static void v4l2_async_fwnode_full_name(char *name,
> + unsigned int len,
> + struct fwnode_handle *fwnode)
> +{
> +}
> +#endif /* CONFIG_VIDEO_V4L2_ASYNC_DEBUG */
> +
>  static struct device *v4l2_async_notifier_dev(
>   struct 

Re: arm64: unhandled level 0 translation fault

[Will Deacon]

On Fri, Dec 15, 2017 at 04:59:28PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 15, 2017 at 3:27 PM, Will Deacon  wrote:
> > On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
> >> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin  wrote:
> >> > The two important differences here seem to be
> >> >
> >> > 1) Staging the state via current->thread.fpsimd_state instead of loading
> >> > directly:
> >> >
> >> > -   fpsimd_load_state(state);
> >> > +   current->thread.fpsimd_state = *state;
> >> > +   fpsimd_load_state(>thread.fpsimd_state);
> >>
> >> The change above introduces the breakage.
> >
> > I finally managed to reproduce this, but only by using the exact same
> > compiler as Geert:
> >
> > https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_aarch64-linux.tar.xz
> >
> > I then reliably see the problem if I run:
> >
> >   # /usr/bin/update-ca-certificates
> 
> /usr/sbin/... ?
> 
> > from Debian Jessie.
> 
> Funny, I've just got both
> 
> *** Error in `/bin/sh': free(): invalid pointer: 0xc17d4988 ***
> 
> and
> 
> mountall.sh[2172]: unhandled level 0 translation fault (11) at
> 0x004d, esr 0x9204, in dash[ce7e5000+1a000]
> 
> during boot up, but I can't get update-ca-certificates to fail...

Can you try the diff below, please?

Will

--->8

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 540a1e010eb5..fae81f7964b4 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -1043,7 +1043,7 @@ void fpsimd_update_current_state(struct fpsimd_state 
*state)
 
local_bh_disable();
 
-   current->thread.fpsimd_state = *state;
+   current->thread.fpsimd_state.user_fpsimd = state->user_fpsimd;
if (system_supports_sve() && test_thread_flag(TIF_SVE))
fpsimd_to_sve(current);

Re: [PATCH 3/3] PM / Domains: Take WAKEUP_PATH driver flag into account in genpd

[Ulf Hansson]

On 15 December 2017 at 16:56, Ulf Hansson  wrote:
> In case the WAKEUP_PATH flag has been set in a later phase than from the
> ->suspend() callback, the PM core want set the ->power.wakeup_path status

/s/want/don't

If another version is needed I fix, else perhaps you can just amend the patch!?

Kind regards
Uffe

> flag for the device. Therefore, let's be safe and check it explicitly.
>
> Signed-off-by: Ulf Hansson 
> ---
>  drivers/base/power/domain.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index f9dcc98..32b4ba7 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1038,7 +1038,9 @@ static int genpd_finish_suspend(struct device *dev, 
> bool poweroff)
> if (IS_ERR(genpd))
> return -EINVAL;
>
> -   if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
> +   if ((dev->power.wakeup_path ||
> +   dev_pm_test_driver_flags(dev, DPM_FLAG_WAKEUP_PATH)) &&
> +   genpd_is_active_wakeup(genpd))
> return 0;
>
> if (poweroff)
> @@ -1093,7 +1095,9 @@ static int genpd_resume_noirq(struct device *dev)
> if (IS_ERR(genpd))
> return -EINVAL;
>
> -   if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
> +   if ((dev->power.wakeup_path ||
> +   dev_pm_test_driver_flags(dev, DPM_FLAG_WAKEUP_PATH)) &&
> +   genpd_is_active_wakeup(genpd))
> return 0;
>
> genpd_lock(genpd);
> --
> 2.7.4
>

[PULL REQUEST] renesas/topic/rcar-i2c-recovery for renesas drivers

[Wolfram Sang]

Hi Geert,

here is a topic branch for renesas-drivers which enables I2C bus
recovery on i2c-rcar IP cores.

It is based on i2c/for-next + renesas/dt-for-v4.16 +
renesas/topc/ip-switch-rework-2017.

Please pull.

Kind regards,

   Wolfram


The following changes since commit 62127db8d012c586fdd45d1768261aaa3938c8b7:

  Merge branch 'renesas/topc/ip-switch-rework-2017' into 
renesas/topic/rcar-i2c-recovery (2017-12-15 16:43:40 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
renesas/topic/rcar-i2c-recovery

for you to fetch changes up to e5bb5ef5f51d223dfcd188c803e746d445320b92:

  i2c: rcar: implement bus recovery (2017-12-15 16:45:43 +0100)


Wolfram Sang (7):
  i2c: algo-bit: init the bus to a known state
  i2c: make kerneldoc about bus recovery more precise
  i2c: add identifier in declarations for i2c_bus_recovery
  i2c: add 'set_sda' to bus_recovery_info
  i2c: ensure SDA is released in recovery if SDA is controllable
  i2c: send STOP after successful bus recovery
  i2c: rcar: implement bus recovery

 drivers/i2c/algos/i2c-algo-bit.c |  5 
 drivers/i2c/busses/i2c-rcar.c| 54 ++--
 drivers/i2c/i2c-core-base.c  | 25 ++-
 include/linux/i2c.h  | 20 +--
 4 files changed, 93 insertions(+), 11 deletions(-)


signature.asc
Description: PGP signature

Re: arm64: unhandled level 0 translation fault

[Geert Uytterhoeven]

Hi Will,

On Fri, Dec 15, 2017 at 3:27 PM, Will Deacon  wrote:
> On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin  wrote:
>> > The two important differences here seem to be
>> >
>> > 1) Staging the state via current->thread.fpsimd_state instead of loading
>> > directly:
>> >
>> > -   fpsimd_load_state(state);
>> > +   current->thread.fpsimd_state = *state;
>> > +   fpsimd_load_state(>thread.fpsimd_state);
>>
>> The change above introduces the breakage.
>
> I finally managed to reproduce this, but only by using the exact same
> compiler as Geert:
>
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_aarch64-linux.tar.xz
>
> I then reliably see the problem if I run:
>
>   # /usr/bin/update-ca-certificates

/usr/sbin/... ?

> from Debian Jessie.

Funny, I've just got both

*** Error in `/bin/sh': free(): invalid pointer: 0xc17d4988 ***

and

mountall.sh[2172]: unhandled level 0 translation fault (11) at
0x004d, esr 0x9204, in dash[ce7e5000+1a000]

during boot up, but I can't get update-ca-certificates to fail...

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: arm64: unhandled level 0 translation fault

[Geert Uytterhoeven]

On Fri, Dec 15, 2017 at 3:27 PM, Will Deacon  wrote:
> On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin  wrote:
>> > The two important differences here seem to be
>> >
>> > 1) Staging the state via current->thread.fpsimd_state instead of loading
>> > directly:
>> >
>> > -   fpsimd_load_state(state);
>> > +   current->thread.fpsimd_state = *state;
>> > +   fpsimd_load_state(>thread.fpsimd_state);
>>
>> The change above introduces the breakage.
>
> I finally managed to reproduce this, but only by using the exact same
> compiler as Geert:
>
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_aarch64-linux.tar.xz
>
> I then reliably see the problem if I run:
>
>   # /usr/bin/update-ca-certificates
>
> from Debian Jessie.
>
> Note that my normal toolchain (Linaro 7.1.1 build) works fine and also
> if I use the toolchain above but disable CONFIG_ARM64_CRYPTO then things
> work too.
>
> So there's some toolchain-specific interaction between this change and the
> crypto code...
>
> Will



-- 
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 3/3] PM / Domains: Take WAKEUP_PATH driver flag into account in genpd

[Ulf Hansson]

In case the WAKEUP_PATH flag has been set in a later phase than from the
->suspend() callback, the PM core want set the ->power.wakeup_path status
flag for the device. Therefore, let's be safe and check it explicitly.

Signed-off-by: Ulf Hansson 
---
 drivers/base/power/domain.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index f9dcc98..32b4ba7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1038,7 +1038,9 @@ static int genpd_finish_suspend(struct device *dev, bool 
poweroff)
if (IS_ERR(genpd))
return -EINVAL;
 
-   if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
+   if ((dev->power.wakeup_path ||
+   dev_pm_test_driver_flags(dev, DPM_FLAG_WAKEUP_PATH)) &&
+   genpd_is_active_wakeup(genpd))
return 0;
 
if (poweroff)
@@ -1093,7 +1095,9 @@ static int genpd_resume_noirq(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;
 
-   if (dev->power.wakeup_path && genpd_is_active_wakeup(genpd))
+   if ((dev->power.wakeup_path ||
+   dev_pm_test_driver_flags(dev, DPM_FLAG_WAKEUP_PATH)) &&
+   genpd_is_active_wakeup(genpd))
return 0;
 
genpd_lock(genpd);
-- 
2.7.4

[PATCH 0/3] PM / core: Extend behaviour for wakeup paths

[Ulf Hansson]

The generic problem this series intends to solve, is that for some PM domains,
especially genpd, the current information in the dev->power.wakeup_path, is not
sufficient for a PM domain to fully understand how to treat devices in the
wakeup path during system suspend.

Particularly this applies to resources being consumed by the driver that has
configured system wakeup settings for its device. Currently the PM domain lacks
information about these consumed resources, which means it may decide to power
of their corresponding device and its attached PM domain, while they actually
would need to stay powered to allow system wakeup signals to be delivered.

Geert Uytterhoeven, has been working on these kind of problems for some Renesas
SoCs and there have been lots of discussions around this. After some
consideration I have dropped my first attempt [1] on how to address these
problems, so here's hopefully a better one.

So far I haven't included any patches for dealing with the "OUT_BAND_WAKEUP"
thingy, but I suggest we do that in a second separate step, since it's not
immediately need to fix the problems for the Renesas SoCs.

Geert's Renesas series [2], needs to be re-based on top of this series to make
it convert to use the new DPM_FLAG_WAKEUP_PATH flag, which is introduced in
this series. That leads to a tree-wise-dependency, so perhaps Rafael can host
an immutable branch the Renesas tree can pull in. Let's see.

[1]
https://www.spinics.net/lists/linux-renesas-soc/msg20122.html

[2]
https://www.spinics.net/lists/linux-renesas-soc/msg19947.html

Ulf Hansson (3):
  PM / core: Assign the wakeup_path status flag in __device_prepare()
  PM / core: Add WAKEUP_PATH driver flag
  PM / Domains: Take WAKEUP_PATH driver flag into account in genpd

 drivers/base/power/domain.c | 8 ++--
 drivers/base/power/main.c   | 5 -
 include/linux/pm.h  | 7 +++
 3 files changed, 17 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH 2/3] PM / core: Add WAKEUP_PATH driver flag

[Ulf Hansson]

During system suspend, a driver may find that the wakeup setting is enabled
for its device and therefore configures it to deliver system wakeup
signals.

Additionally, sometimes the driver and its device, relies on some further
consumed resource, like an irqchip or a phy for example, to stay powered
on, as to be able to deliver system wakeup signals.

In general the driver deals with this, via raising an "enable count" of the
consumed resource or via a subsystem specific API, like irq_set_irq_wake()
or enable|disable_irq_wake() for an irqchip.

However, this information about the wakeup path for resources, is currently
not available to a PM domain (unless it has some HW-logic that knows this),
which means that it may decide to power off a device and its PM domain. In
other words, it may prevent the wakeup signal from being delivered.

For this reason, let's introduce a new WAKEUP_PATH driver flag, to allow a
driver to indicate that it controls a resource needed in the wakeup path.
Make the PM core to check the WAKEUP_PATH flag immediately after the
->suspend() callback has been invoked and set the wakeup_path status flag
accordingly. In this way the wakeup_path flag also becomes propagated to
the parent device, which may be useful for some cases.

For a PM domain that needs the information about the wakeup path, it should
check the wakeup_path status flag for its attached devices in a later
suspend phase, but perhaps also the WAKEUP_PATH driver flag explicitly, in
case it has been set after the ->suspend() callback has been invoked for
the device.

Signed-off-by: Ulf Hansson 
---
 drivers/base/power/main.c | 3 ++-
 include/linux/pm.h| 7 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 810e5fb..1327726 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1620,7 +1620,8 @@ static int __device_suspend(struct device *dev, 
pm_message_t state, bool async)
  End:
if (!error) {
dev->power.is_suspended = true;
-   if (device_may_wakeup(dev))
+   if (device_may_wakeup(dev) ||
+   dev_pm_test_driver_flags(dev, DPM_FLAG_WAKEUP_PATH))
dev->power.wakeup_path = true;
dpm_propagate_to_parent(dev);
dpm_clear_suppliers_direct_complete(dev);
diff --git a/include/linux/pm.h b/include/linux/pm.h
index e723b78..ebc6ef8 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -560,6 +560,7 @@ struct pm_subsys_data {
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
  * SMART_SUSPEND: No need to resume the device from runtime suspend.
  * LEAVE_SUSPENDED: Avoid resuming the device during system resume if possible.
+ * WAKEUP_PATH: The device is used in the wakeup path from system suspend.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -576,11 +577,17 @@ struct pm_subsys_data {
  *
  * Setting LEAVE_SUSPENDED informs the PM core and middle-layer code that the
  * driver prefers the device to be left in suspend after system resume.
+ *
+ * Setting WAKEUP_PATH informs the PM core and the PM domain, that the device 
is
+ * a part of the wakeup path at system suspend. The PM core detects this flag
+ * and sets the wakeup_path status flag immeditaley after the ->suspend()
+ * callback has been invoked for the the device.
  */
 #define DPM_FLAG_NEVER_SKIPBIT(0)
 #define DPM_FLAG_SMART_PREPARE BIT(1)
 #define DPM_FLAG_SMART_SUSPEND BIT(2)
 #define DPM_FLAG_LEAVE_SUSPENDED   BIT(3)
+#define DPM_FLAG_WAKEUP_PATH   BIT(4)
 
 struct dev_pm_info {
pm_message_tpower_state;
-- 
2.7.4

[PATCH 1/3] PM / core: Assign the wakeup_path status flag in __device_prepare()

[Ulf Hansson]

The PM core in the device_prepare() phase, resets the wakeup_path status
flag to the value of device_may_wakeup(). This means if a ->prepare() or a
->suspend() callback for the device would update the device's wakeup
setting, this doesn't become reflected in the wakeup_path status flag.

In general this isn't a problem, because wakeup settings isn't supposed to
be changed during those system suspend phases. Nevertheless, there are a
cases not conforming to that behaviour, as device_set_wakeup_enable() is
indeed called from ->suspend() callbacks.

To address this, let's move the assignment of the wakeup_path status flag
to the __device_suspend() phase and more precisely, after the ->suspend()
callback has been invoked.

Signed-off-by: Ulf Hansson 
---
 drivers/base/power/main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 6e8cc5d..810e5fb 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1620,6 +1620,8 @@ static int __device_suspend(struct device *dev, 
pm_message_t state, bool async)
  End:
if (!error) {
dev->power.is_suspended = true;
+   if (device_may_wakeup(dev))
+   dev->power.wakeup_path = true;
dpm_propagate_to_parent(dev);
dpm_clear_suppliers_direct_complete(dev);
}
@@ -1744,7 +1746,7 @@ static int device_prepare(struct device *dev, 
pm_message_t state)
 
device_lock(dev);
 
-   dev->power.wakeup_path = device_may_wakeup(dev);
+   dev->power.wakeup_path = false;
 
if (dev->power.no_pm_callbacks) {
ret = 1;/* Let device go direct_complete */
-- 
2.7.4

[PULL REQUEST] renesas/topc/ip-switch-rework-2017 for renesas drivers

[Wolfram Sang]

Hi Geert,

Here is the the topic branch to add the I2C IP core switcher to all
busses of Gen2 boards where some kind of switching is possible (mostly
to/from GPIO).

It is based on v4.15-rc1 + renesas/dt-for-v4.16 merged in.

Please pull.

Kind regards,

   Wolfram


The following changes since commit ea648c135fcb40f864f0c898b94ecd39782d895c:

  Merge tag 'renesas-dt-fixes-for-v4.15' into 
renesas/topc/ip-switch-rework-2017 (2017-12-08 12:17:55 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
renesas/topc/ip-switch-rework-2017

for you to fetch changes up to bec727d32dc69bdba3b4ea0b10a3b09461be6a9e:

  ARM: dts: gose: use demuxer for I2C4 (2017-12-08 14:54:43 +0100)


Wolfram Sang (9):
  ARM: dts: lager: use demuxer for IIC2/I2C2
  ARM: dts: lager: use demuxer for IIC3/I2C3
  ARM: dts: koelsch: use demuxer for I2C2
  ARM: dts: koelsch: use demuxer for I2C4
  ARM: dts: porter: use demuxer for I2C2
  ARM: dts: alt: use demuxer for I2C1
  ARM: dts: silk: use demuxer for I2C1
  ARM: dts: gose: use demuxer for I2C2
  ARM: dts: gose: use demuxer for I2C4

 arch/arm/boot/dts/r8a7790-lager.dts   | 279 --
 arch/arm/boot/dts/r8a7791-koelsch.dts | 232 +---
 arch/arm/boot/dts/r8a7791-porter.dts  | 128 +---
 arch/arm/boot/dts/r8a7793-gose.dts| 252 ++
 arch/arm/boot/dts/r8a7794-alt.dts |  53 +--
 arch/arm/boot/dts/r8a7794-silk.dts| 128 +---
 6 files changed, 654 insertions(+), 418 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH 4/5] v4l2: async: Postpone subdev_notifier registration

[Sakari Ailus]

Hi Jacopo,

On Wed, Dec 13, 2017 at 07:26:19PM +0100, Jacopo Mondi wrote:
> Currently, subdevice notifiers are tested against all available
> subdevices as soon as they get registered. It often happens anyway
> that the subdevice they are connected to is not yet initialized, as
> it usually gets registered later in drivers' code. This makes debug
> of v4l2_async particularly painful, as identifying a notifier with
> an unitialized subdevice is tricky as they don't have a valid
> 'struct device *' or 'struct fwnode_handle *' to be identified with.
> 
> In order to make sure that the notifier's subdevices is initialized
> when the notifier is tesed against available subdevices post-pone the
> actual notifier registration at subdevice registration time.
> 
> It is worth noting that post-poning registration of a subdevice notifier
> does not impact on the completion of the notifiers chain, as even if a
> subdev notifier completes as soon as it gets registered, the complete()
> call chain cannot be upscaled as long as the subdevice the notifiers
> belongs to is not registered.

Let me rephrase to make sure I understand the problem correctly ---

A sub-device notifier is registered but the notifier's sub-device is not
registered yet, and finding a match for this notifier leads, to, well
problems. Is that the reason for this patch?

I think there could be simpler solutions to address this.

I wonder if we could simply check for sub-device notifier's v4l2_dev field,
and fail in matching if it's not set. v4l2_device_register_subdev() would
still need to proceed with calling v4l2_async_notifier_try_all_subdevs()
and v4l2_async_notifier_try_complete() if that was the case.

What do you think?

> 
> Also, it is now safe to access a notifier 'struct device *' as we're now
> sure it is properly initialized when the notifier is actually
> registered.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 65 
> +++-
>  include/media/v4l2-async.h   |  2 ++
>  2 files changed, 43 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 0a1bf1d..c13a781 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -25,6 +25,13 @@
>  #include 
>  #include 
> 
> +static struct device *v4l2_async_notifier_dev(
> + struct v4l2_async_notifier *notifier)
> +{
> + return notifier->v4l2_dev ? notifier->v4l2_dev->dev :
> + notifier->sd->dev;
> +}
> +
>  static int v4l2_async_notifier_call_bound(struct v4l2_async_notifier *n,
> struct v4l2_subdev *subdev,
> struct v4l2_async_subdev *asd)
> @@ -124,19 +131,6 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
>   return NULL;
>  }
> 
> -/* Find the sub-device notifier registered by a sub-device driver. */
> -static struct v4l2_async_notifier *v4l2_async_find_subdev_notifier(
> - struct v4l2_subdev *sd)
> -{
> - struct v4l2_async_notifier *n;
> -
> - list_for_each_entry(n, _list, list)
> - if (n->sd == sd)
> - return n;
> -
> - return NULL;
> -}
> -
>  /* Get v4l2_device related to the notifier if one can be found. */
>  static struct v4l2_device *v4l2_async_notifier_find_v4l2_dev(
>   struct v4l2_async_notifier *notifier)
> @@ -160,7 +154,7 @@ static bool v4l2_async_notifier_can_complete(
> 
>   list_for_each_entry(sd, >done, async_list) {
>   struct v4l2_async_notifier *subdev_notifier =
> - v4l2_async_find_subdev_notifier(sd);
> + sd->subdev_notifier;
> 
>   if (subdev_notifier &&
>   !v4l2_async_notifier_can_complete(subdev_notifier))
> @@ -228,7 +222,7 @@ static int v4l2_async_match_notify(struct 
> v4l2_async_notifier *notifier,
>   /*
>* See if the sub-device has a notifier. If not, return here.
>*/
> - subdev_notifier = v4l2_async_find_subdev_notifier(sd);
> + subdev_notifier = sd->subdev_notifier;
>   if (!subdev_notifier || subdev_notifier->parent)
>   return 0;
> 
> @@ -294,7 +288,7 @@ static void v4l2_async_notifier_unbind_all_subdevs(
> 
>   list_for_each_entry_safe(sd, tmp, >done, async_list) {
>   struct v4l2_async_notifier *subdev_notifier =
> - v4l2_async_find_subdev_notifier(sd);
> + sd->subdev_notifier;
> 
>   if (subdev_notifier)
>   v4l2_async_notifier_unbind_all_subdevs(subdev_notifier);
> @@ -371,8 +365,7 @@ static bool v4l2_async_notifier_fwnode_has_async_subdev(
> 
>  static int __v4l2_async_notifier_register(struct v4l2_async_notifier 
> *notifier)
>  {
> - 

[PATCH 1/7] drm/img-rogue: adapt to changed fence API

[Ulrich Hecht]

Everything "fence..." is now "dma_fence...".

Signed-off-by: Ulrich Hecht 
---
 kernel/drivers/staging/imgtec/pvr_buffer_sync.c | 38 +++---
 kernel/drivers/staging/imgtec/pvr_fence.c   | 68 -
 kernel/drivers/staging/imgtec/pvr_fence.h   | 20 
 3 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/kernel/drivers/staging/imgtec/pvr_buffer_sync.c 
b/kernel/drivers/staging/imgtec/pvr_buffer_sync.c
index dcb4a32..361b59d 100644
--- a/kernel/drivers/staging/imgtec/pvr_buffer_sync.c
+++ b/kernel/drivers/staging/imgtec/pvr_buffer_sync.c
@@ -57,7 +57,7 @@ struct pvr_buffer_sync_context {
 };
 
 struct pvr_buffer_sync_check_data {
-   struct fence_cb base;
+   struct dma_fence_cb base;
 
u32 nr_fences;
struct pvr_fence **fences;
@@ -179,7 +179,7 @@ pvr_buffer_sync_pmrs_fence_count(u32 nr_pmrs, struct _PMR_ 
**pmrs,
 {
struct reservation_object *resv;
struct reservation_object_list *resv_list;
-   struct fence *fence;
+   struct dma_fence *fence;
u32 fence_count = 0;
bool exclusive;
int i;
@@ -214,7 +214,7 @@ pvr_buffer_sync_check_fences_create(struct 
pvr_fence_context *fence_ctx,
struct pvr_buffer_sync_check_data *data;
struct reservation_object *resv;
struct reservation_object_list *resv_list;
-   struct fence *fence;
+   struct dma_fence *fence;
u32 fence_count;
bool exclusive;
int i, j;
@@ -257,7 +257,7 @@ pvr_buffer_sync_check_fences_create(struct 
pvr_fence_context *fence_ctx,
if (!data->fences[data->nr_fences - 1]) {
data->nr_fences--;
PVR_FENCE_TRACE(fence, "waiting on exclusive 
fence\n");
-   WARN_ON(fence_wait(fence, true) <= 0);
+   WARN_ON(dma_fence_wait(fence, true) <= 0);
}
}
 
@@ -272,7 +272,7 @@ pvr_buffer_sync_check_fences_create(struct 
pvr_fence_context *fence_ctx,
if (!data->fences[data->nr_fences - 1]) {
data->nr_fences--;
PVR_FENCE_TRACE(fence, "waiting on 
non-exclusive fence\n");
-   WARN_ON(fence_wait(fence, true) <= 0);
+   WARN_ON(dma_fence_wait(fence, true) <= 
0);
}
}
}
@@ -304,7 +304,7 @@ pvr_buffer_sync_check_fences_destroy(struct 
pvr_buffer_sync_check_data *data)
 }
 
 static void
-pvr_buffer_sync_check_data_cleanup(struct fence *fence, struct fence_cb *cb)
+pvr_buffer_sync_check_data_cleanup(struct dma_fence *fence, struct 
dma_fence_cb *cb)
 {
struct pvr_buffer_sync_check_data *data =
container_of(cb, struct pvr_buffer_sync_check_data, base);
@@ -551,9 +551,9 @@ pvr_buffer_sync_append_start(struct pvr_buffer_sync_context 
*ctx,
 * Note: we take an additional reference on the update fence in case
 * it signals before we can add it to a reservation object.
 */
-   fence_get(>update_fence->base);
+   dma_fence_get(>update_fence->base);
 
-   err = fence_add_callback(>update_fence->base, _data->base,
+   err = dma_fence_add_callback(>update_fence->base, 
_data->base,
 pvr_buffer_sync_check_data_cleanup);
if (err) {
/*
@@ -624,7 +624,7 @@ pvr_buffer_sync_append_finish(struct 
pvr_buffer_sync_append_data *data)
 * objects we can safely drop the extra reference we took in
 * pvr_buffer_sync_append_start.
 */
-   fence_put(>update_fence->base);
+   dma_fence_put(>update_fence->base);
 
pvr_buffer_sync_pmrs_unlock(>ctx->acquire_ctx,
data->nr_pmrs,
@@ -653,7 +653,7 @@ pvr_buffer_sync_append_abort(struct 
pvr_buffer_sync_append_data *data)
 * reference taken in pvr_buffer_sync_append_start.
 */
pvr_fence_sync_sw_signal(data->update_fence);
-   fence_put(>update_fence->base);
+   dma_fence_put(>update_fence->base);
pvr_buffer_sync_pmrs_unlock(>ctx->acquire_ctx,
data->nr_pmrs,
data->pmrs);
@@ -697,7 +697,7 @@ pvr_buffer_sync_wait(struct pvr_buffer_sync_context *ctx,
 {
struct reservation_object *resv;
struct reservation_object_list *resv_list = NULL;
-   struct fence *fence, *wait_fence = NULL;
+   struct dma_fence *fence, *wait_fence = NULL;
unsigned seq;
int i;
long lerr;
@@ -721,8 +721,8 @@ retry:
for (i = 0; i < resv_list->shared_count; i++) {
fence = rcu_dereference(resv_list->shared[i]);
if (is_our_fence(ctx->fence_ctx, fence) 

[PATCH 4/7] drm/img-rogue: dma_buf_ops .kmap_* are now .map_*

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 services/server/env/linux/physmem_dmabuf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/services/server/env/linux/physmem_dmabuf.c 
b/services/server/env/linux/physmem_dmabuf.c
index 5faa62d..ac651d3 100644
--- a/services/server/env/linux/physmem_dmabuf.c
+++ b/services/server/env/linux/physmem_dmabuf.c
@@ -124,8 +124,8 @@ static const struct dma_buf_ops sPVRDmaBufOps =
.map_dma_buf   = PVRDmaBufOpsMap,
.unmap_dma_buf = PVRDmaBufOpsUnmap,
.release   = PVRDmaBufOpsRelease,
-   .kmap_atomic   = PVRDmaBufOpsKMap,
-   .kmap  = PVRDmaBufOpsKMap,
+   .map_atomic= PVRDmaBufOpsKMap,
+   .map   = PVRDmaBufOpsKMap,
.mmap  = PVRDmaBufOpsMMap,
 };
 
-- 
2.7.4

[PATCH 7/7] drm/img-rogue: replace call to obsolete drm_platform_init()

[Ulrich Hecht]

Use drm_dev_alloc(), drm_dev_register() and remove the .load and .unload
methods from drm_driver.

Signed-off-by: Ulrich Hecht 
---
 include/drm/pvr_drm.h|  2 ++
 kernel/drivers/staging/imgtec/pvr_drm.c  | 23 +--
 kernel/drivers/staging/imgtec/pvr_platform_drv.c | 19 ++-
 3 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/include/drm/pvr_drm.h b/include/drm/pvr_drm.h
index 5cd13cc..3308791 100644
--- a/include/drm/pvr_drm.h
+++ b/include/drm/pvr_drm.h
@@ -99,4 +99,6 @@ struct drm_pvr_dbgdrv_cmd {
 #defineDRM_IOCTL_PVR_SRVKM_CMD DRM_IOWR(DRM_COMMAND_BASE + 
DRM_PVR_SRVKM_CMD, struct drm_pvr_srvkm_cmd)
 #defineDRM_IOCTL_PVR_DBGDRV_CMDDRM_IOWR(DRM_COMMAND_BASE + 
DRM_PVR_DBGDRV_CMD, struct drm_pvr_dbgdrv_cmd)
 
+int pvr_drm_load(struct drm_device *ddev, unsigned long flags);
+
 #endif /* defined(__PVR_DRM_H__) */
diff --git a/kernel/drivers/staging/imgtec/pvr_drm.c 
b/kernel/drivers/staging/imgtec/pvr_drm.c
index 388943b..c69fec1 100644
--- a/kernel/drivers/staging/imgtec/pvr_drm.c
+++ b/kernel/drivers/staging/imgtec/pvr_drm.c
@@ -93,7 +93,7 @@ const struct dev_pm_ops pvr_pm_ops = {
 };
 
 
-static int pvr_drm_load(struct drm_device *ddev, unsigned long flags)
+int pvr_drm_load(struct drm_device *ddev, unsigned long flags)
 {
struct _PVRSRV_DEVICE_NODE_ *dev_node;
enum PVRSRV_ERROR srv_err;
@@ -101,13 +101,6 @@ static int pvr_drm_load(struct drm_device *ddev, unsigned 
long flags)
 
DRM_DEBUG_DRIVER("device %p\n", ddev->dev);
 
-   /*
-* The equivalent is done for PCI modesetting drivers by
-* drm_get_pci_dev()
-*/
-   if (ddev->platformdev)
-   platform_set_drvdata(ddev->platformdev, ddev);
-
srv_err = PVRSRVDeviceCreate(ddev->dev, _node);
if (srv_err != PVRSRV_OK) {
DRM_ERROR("failed to create device node for device %p (%s)\n",
@@ -134,18 +127,6 @@ err_exit:
return err;
 }
 
-static int pvr_drm_unload(struct drm_device *ddev)
-{
-   DRM_DEBUG_DRIVER("device %p\n", ddev->dev);
-
-   PVRSRVCommonDeviceDeinit(ddev->dev_private);
-
-   PVRSRVDeviceDestroy(ddev->dev_private);
-   ddev->dev_private = NULL;
-
-   return 0;
-}
-
 static int pvr_drm_open(struct drm_device *ddev, struct drm_file *dfile)
 {
int err;
@@ -237,8 +218,6 @@ const struct drm_driver pvr_drm_generic_driver = {
.driver_features= DRIVER_MODESET | DRIVER_RENDER,
 
.dev_priv_size  = 0,
-   .load   = pvr_drm_load,
-   .unload = pvr_drm_unload,
.open   = pvr_drm_open,
.postclose  = pvr_drm_release,
 
diff --git a/kernel/drivers/staging/imgtec/pvr_platform_drv.c 
b/kernel/drivers/staging/imgtec/pvr_platform_drv.c
index 54a7d02..63b142d 100644
--- a/kernel/drivers/staging/imgtec/pvr_platform_drv.c
+++ b/kernel/drivers/staging/imgtec/pvr_platform_drv.c
@@ -50,6 +50,7 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE SOFTWARE.
 
 #include "module_common.h"
 #include "pvr_drv.h"
+#include "pvr_drm.h"
 #include "pvrmodule.h"
 #include "sysinfo.h"
 
@@ -149,9 +150,25 @@ static void pvr_devices_unregister(void)
 
 static int pvr_probe(struct platform_device *pdev)
 {
+   struct drm_device *drm;
+   int result;
+
DRM_DEBUG_DRIVER("device %p\n", >dev);
 
-   return drm_platform_init(_drm_platform_driver, pdev);
+   drm = drm_dev_alloc(_drm_platform_driver, >dev);
+   if (IS_ERR(drm))
+   return PTR_ERR(drm);
+
+   platform_set_drvdata(pdev, drm);
+
+   result = pvr_drm_load(drm, 0);
+
+   if (result)
+   return result;
+
+   result = drm_dev_register(drm, 0);
+
+   return result;
 }
 
 static int pvr_remove(struct platform_device *pdev)
-- 
2.7.4

[PATCH 3/7] drm/img-rogue: #include in osfunc.c

[Ulrich Hecht]

Required for sched_clock()

Signed-off-by: Ulrich Hecht 
---
 services/server/env/linux/osfunc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/services/server/env/linux/osfunc.c 
b/services/server/env/linux/osfunc.c
index 39d4f89..c222095 100644
--- a/services/server/env/linux/osfunc.c
+++ b/services/server/env/linux/osfunc.c
@@ -53,6 +53,7 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE SOFTWARE.
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4

[PATCH 5/7] drm/img-rogue: dma_ops->sync_single_for_*() -> dma_sync_single_for_*()

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 services/server/env/linux/osfunc_arm64.c | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/services/server/env/linux/osfunc_arm64.c 
b/services/server/env/linux/osfunc_arm64.c
index 8b7f06d..70f747b 100644
--- a/services/server/env/linux/osfunc_arm64.c
+++ b/services/server/env/linux/osfunc_arm64.c
@@ -121,18 +121,12 @@ void OSFlushCPUCacheRangeKM(PVRSRV_DEVICE_NODE *psDevNode,
IMG_CPU_PHYADDR 
sCPUPhysEnd)
 {
struct device *dev = psDevNode->psDevConfig->pvOSDevice;
-   struct dma_map_ops *dma_ops = get_dma_ops(dev);
 
PVR_UNREFERENCED_PARAMETER(pvVirtStart);
PVR_UNREFERENCED_PARAMETER(pvVirtEnd);
 
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0))
-   dma_ops->sync_single_for_device(dev, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
-   dma_ops->sync_single_for_cpu(dev, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
-#else
-   dma_ops->sync_single_for_device(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
-   dma_ops->sync_single_for_cpu(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
-#endif
+   dma_sync_single_for_device(dev, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
+   dma_sync_single_for_cpu(dev, sCPUPhysStart.uiAddr, sCPUPhysEnd.uiAddr - 
sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
 }
 
 void OSCleanCPUCacheRangeKM(PVRSRV_DEVICE_NODE *psDevNode,
@@ -142,16 +136,11 @@ void OSCleanCPUCacheRangeKM(PVRSRV_DEVICE_NODE *psDevNode,
IMG_CPU_PHYADDR 
sCPUPhysEnd)
 {
struct device *dev = psDevNode->psDevConfig->pvOSDevice;
-   struct dma_map_ops *dma_ops = get_dma_ops(dev);
 
PVR_UNREFERENCED_PARAMETER(pvVirtStart);
PVR_UNREFERENCED_PARAMETER(pvVirtEnd);
 
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0))
-   dma_ops->sync_single_for_device(dev, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
-#else
-   dma_ops->sync_single_for_device(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
-#endif
+   dma_sync_single_for_device(dev, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
 }
 
 void OSInvalidateCPUCacheRangeKM(PVRSRV_DEVICE_NODE *psDevNode,
@@ -161,16 +150,11 @@ void OSInvalidateCPUCacheRangeKM(PVRSRV_DEVICE_NODE 
*psDevNode,
 
IMG_CPU_PHYADDR sCPUPhysEnd)
 {
struct device *dev = psDevNode->psDevConfig->pvOSDevice;
-   struct dma_map_ops *dma_ops = get_dma_ops(dev);
 
PVR_UNREFERENCED_PARAMETER(pvVirtStart);
PVR_UNREFERENCED_PARAMETER(pvVirtEnd);
 
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 8, 0))
-   dma_ops->sync_single_for_cpu(dev, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
-#else
-   dma_ops->sync_single_for_cpu(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
-#endif
+   dma_sync_single_for_cpu(dev, sCPUPhysStart.uiAddr, sCPUPhysEnd.uiAddr - 
sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
 }
 
 PVRSRV_CACHE_OP_ADDR_TYPE OSCPUCacheOpAddressType(PVRSRV_CACHE_OP uiCacheOp)
-- 
2.7.4

[PATCH 6/7] drm/img-rogue: init_timer() -> setup_timer()

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 services/server/env/linux/osfunc.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/services/server/env/linux/osfunc.c 
b/services/server/env/linux/osfunc.c
index c222095..b529c63 100644
--- a/services/server/env/linux/osfunc.c
+++ b/services/server/env/linux/osfunc.c
@@ -492,7 +492,7 @@ static inline IMG_UINT64 KClockns64(void)
 {
ktime_t sTime = ktime_get();
 
-   return sTime.tv64;
+   return sTime;
 }
 
 PVRSRV_ERROR OSClockMonotonicns64(IMG_UINT64 *pui64Time)
@@ -1135,9 +1135,9 @@ static void OSTimerCallbackBody(TIMER_CALLBACK_DATA 
*psTimerCBData)
 @DescriptionOS specific timer callback wrapper function
 @Input  uDataTimer callback data
 */ /**/
-static void OSTimerCallbackWrapper(uintptr_t uData)
+static void OSTimerCallbackWrapper(struct timer_list *t)
 {
-   TIMER_CALLBACK_DATA *psTimerCBData = (TIMER_CALLBACK_DATA*)uData;
+   TIMER_CALLBACK_DATA *psTimerCBData = from_timer(psTimerCBData, t, 
sTimer);
 
 #if defined(PVR_LINUX_TIMERS_USING_WORKQUEUES) || 
defined(PVR_LINUX_TIMERS_USING_SHARED_WORKQUEUE)
int res;
@@ -1219,12 +1219,8 @@ IMG_HANDLE OSAddTimer(PFN_TIMER_FUNC pfnTimerFunc, void 
*pvData, IMG_UINT32 ui32
psTimerCBData->ui32Delay = ((HZ * ui32MsTimeout) < 1000)
?   1
:   ((HZ * 
ui32MsTimeout) / 1000);
-   /* initialise object */
-   init_timer(>sTimer);
-
/* setup timer object */
-   psTimerCBData->sTimer.function = (void *)OSTimerCallbackWrapper;
-   psTimerCBData->sTimer.data = (uintptr_t)psTimerCBData;
+   timer_setup(>sTimer, OSTimerCallbackWrapper, 0);
 
return (IMG_HANDLE)(uintptr_t)(ui32i + 1);
 }
-- 
2.7.4

[PATCH 2/7] drm/img-rogue: change #include to

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 services/server/env/linux/pvr_uaccess.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/services/server/env/linux/pvr_uaccess.h 
b/services/server/env/linux/pvr_uaccess.h
index 74ddc58..382cca4 100644
--- a/services/server/env/linux/pvr_uaccess.h
+++ b/services/server/env/linux/pvr_uaccess.h
@@ -42,7 +42,7 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE SOFTWARE.
 #ifndef __PVR_UACCESS_H__
 #define __PVR_UACCESS_H__
 
-#include 
+#include 
 
 static inline unsigned long pvr_copy_to_user(void __user *pvTo, const void 
*pvFrom, unsigned long ulBytes)
 {
-- 
2.7.4

[PATCH 0/7] up-port of out-of-tree GSX GPU driver for r8a7796

[Ulrich Hecht]

Hi!

This is a set of patches to the out-of-tree driver for the PowerVR GX6650
GPU used in the R-Car M3-W SoC that is required to make it work on mainline.

The driver source can be downloaded here:
https://www.renesas.com/en-us/solutions/automotive/rcar-demoboard.html

The patched driver can also be found at
https://github.com/uli/r8a7796-gpu

The OpenCL tests and various others that are supplied with the "R-Car H3
Evaluation Software Package for Linux for Yocto v2.23.0" at
https://www.renesas.com/en-us/solutions/automotive/rcar-opencl.html
pass. Anything that relies on EGL, however, fails early with an error
from eglInitialize(). I suspect this to be an incompatibility of the binary
blob libraries with my user space and will look into it further.

A description of the test setup and some test results can be found here:
https://www.elinux.org/User:Uli/R-Car_M3-W_Mainline_GPU_Test

This relies on the series "r8a7796 bits required for out-of-tree GSX module"
for the DT and clock driver bits.

CU
Uli


Ulrich Hecht (7):
  drm/img-rogue: adapt to changed fence API
  drm/img-rogue: change #include  to 
  drm/img-rogue: #include  in osfunc.c
  drm/img-rogue: dma_buf_ops .kmap_* are now .map_*
  drm/img-rogue: dma_ops->sync_single_for_*() -> dma_sync_single_for_*()
  drm/img-rogue: init_timer() -> setup_timer()
  drm/img-rogue: replace call to obsolete drm_platform_init()

 include/drm/pvr_drm.h|  2 +
 kernel/drivers/staging/imgtec/pvr_buffer_sync.c  | 38 ++---
 kernel/drivers/staging/imgtec/pvr_drm.c  | 23 +---
 kernel/drivers/staging/imgtec/pvr_fence.c| 68 
 kernel/drivers/staging/imgtec/pvr_fence.h| 20 +++
 kernel/drivers/staging/imgtec/pvr_platform_drv.c | 19 ++-
 services/server/env/linux/osfunc.c   | 13 ++---
 services/server/env/linux/osfunc_arm64.c | 24 ++---
 services/server/env/linux/physmem_dmabuf.c   |  4 +-
 services/server/env/linux/pvr_uaccess.h  |  2 +-
 10 files changed, 96 insertions(+), 117 deletions(-)

-- 
2.7.4

[PATCH 2/4] clk: renesas: rcar-gen3: Add ZG clock divider support

[Ulrich Hecht]

From: Takeshi Kihara 

This patch adds ZG clock divider support for R-Car Gen3 SoC.

Signed-off-by: Takeshi Kihara 
---
 drivers/clk/renesas/rcar-gen3-cpg.c | 120 
 drivers/clk/renesas/rcar-gen3-cpg.h |   1 +
 2 files changed, 121 insertions(+)

diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c 
b/drivers/clk/renesas/rcar-gen3-cpg.c
index 102cfc2..6b5d5ec 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -73,6 +73,8 @@ static void cpg_simple_notifier_register(struct 
raw_notifier_head *notifiers,
  */
 #define CPG_FRQCRB 0x0004
 #define CPG_FRQCRB_KICKBIT(31)
+#define CPG_FRQCRB_ZGFC_MASK   (0x1f << 24)
+#define CPG_FRQCRB_ZGFC_SHIFT  24
 #define CPG_FRQCRC 0x00e0
 #define CPG_FRQCRC_ZFC_MASKGENMASK(12, 8)
 #define CPG_FRQCRC_Z2FC_MASK   GENMASK(4, 0)
@@ -197,6 +199,120 @@ static struct clk * __init cpg_z_clk_register(const char 
*name,
return clk;
 }
 
+static unsigned long cpg_zg_clk_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct cpg_z_clk *zclk = to_z_clk(hw);
+   unsigned long prate  = parent_rate / 2; /* PLL4 clock divided by 2 */
+   unsigned int mult;
+   unsigned int val;
+   unsigned long rate;
+
+   val = (clk_readl(zclk->reg) & CPG_FRQCRB_ZGFC_MASK)
+   >> CPG_FRQCRB_ZGFC_SHIFT;
+   mult = 32 - val;
+
+   rate = div_u64((u64)prate * mult + 16, 32);
+   /* Round to closest value at 10MHz unit */
+   rate = 1000 * DIV_ROUND_CLOSEST(rate, 1000);
+
+   return rate;
+}
+
+static long cpg_zg_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+   unsigned long prate  = *parent_rate / 2; /* PLL4 clock divided by 2 */
+   unsigned int mult;
+
+   mult = div_u64((u64)rate * 32 + prate / 2, prate);
+   mult = clamp(mult, 1U, 32U);
+
+   return prate / 32 * mult;
+}
+
+static int cpg_zg_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+  unsigned long parent_rate)
+{
+   struct cpg_z_clk *zclk = to_z_clk(hw);
+   unsigned long prate  = parent_rate / 2; /* PLL4 clock divided by 2 */
+   unsigned int mult;
+   u32 val, kick;
+   unsigned int i;
+
+   mult = div_u64((u64)rate * 32 + prate / 2, prate);
+   mult = clamp(mult, 1U, 32U);
+
+   if (clk_readl(zclk->kick_reg) & CPG_FRQCRB_KICK)
+   return -EBUSY;
+
+   val = clk_readl(zclk->reg);
+   val &= ~CPG_FRQCRB_ZGFC_MASK;
+   val |= (32 - mult) << CPG_FRQCRB_ZGFC_SHIFT;
+   clk_writel(val, zclk->reg);
+
+   /*
+* Set KICK bit in FRQCRB to update hardware setting and wait for
+* clock change completion.
+*/
+   kick = clk_readl(zclk->kick_reg);
+   kick |= CPG_FRQCRB_KICK;
+   clk_writel(kick, zclk->kick_reg);
+
+   /*
+* Note: There is no HW information about the worst case latency.
+*
+* Using experimental measurements, it seems that no more than
+* ~10 iterations are needed, independently of the CPU rate.
+* Since this value might be dependent of external xtal rate, pll1
+* rate or even the other emulation clocks rate, use 1000 as a
+* "super" safe value.
+*/
+   for (i = 1000; i; i--) {
+   if (!(clk_readl(zclk->kick_reg) & CPG_FRQCRB_KICK))
+   return 0;
+
+   cpu_relax();
+   }
+
+   return -ETIMEDOUT;
+}
+
+static const struct clk_ops cpg_zg_clk_ops = {
+   .recalc_rate = cpg_zg_clk_recalc_rate,
+   .round_rate = cpg_zg_clk_round_rate,
+   .set_rate = cpg_zg_clk_set_rate,
+};
+
+static struct clk * __init cpg_zg_clk_register(const char *name,
+  const char *parent_name,
+  void __iomem *reg)
+{
+   struct clk_init_data init;
+   struct cpg_z_clk *zclk;
+   struct clk *clk;
+
+   zclk = kzalloc(sizeof(*zclk), GFP_KERNEL);
+   if (!zclk)
+   return ERR_PTR(-ENOMEM);
+
+   init.name = name;
+   init.ops = _zg_clk_ops;
+   init.flags = 0;
+   init.parent_names = _name;
+   init.num_parents = 1;
+
+   zclk->reg = reg + CPG_FRQCRB;
+   zclk->kick_reg = reg + CPG_FRQCRB;
+   zclk->hw.init = 
+
+   clk = clk_register(NULL, >hw);
+   if (IS_ERR(clk))
+   kfree(zclk);
+
+   return clk;
+}
+
 /*
  * SDn Clock
  */
@@ -564,6 +680,10 @@ struct clk * __init rcar_gen3_cpg_clk_register(struct 
device *dev,
return cpg_z_clk_register(core->name, __clk_get_name(parent),
  base, CPG_FRQCRC_Z2FC_MASK);
 
+   case 

[PATCH 3/4] arm64: dts: r8a7796: Add GSX device node

[Ulrich Hecht]

From: Takeshi Kihara 

This patch adds GSX device node for R8A7796 SoC.

Signed-off-by: Takeshi Kihara 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 0b8558d..d3264e7 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2241,6 +2241,14 @@
};
};
 
+   gsx: gsx@fd00 {
+   compatible = "renesas,gsx";
+   reg = <0 0xfd00 0 0x3>;
+   interrupts = ;
+   clocks = < CPG_MOD 112>;
+   power-domains = < R8A7796_PD_3DG_B>;
+   };
+
pciec0: pcie@fe00 {
/* placeholder */
};
-- 
2.7.4

[PATCH 4/4] arm64: dts: r8a7796: Add DEVFREQ support for GSX

[Ulrich Hecht]

From: Gaku Inami 

This patch supports GSX frequency scaling using devfreq.

Includes update of the OPP tables for GSX because the typical voltage of
VDD_DVFS (power optimized) was updated to 0.83V by R-Car Gen3 EC Rev0.54E
specification.

Signed-off-by: Gaku Inami 
Signed-off-by: Takeshi Kihara 
Signed-off-by: Hien Dang 
Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index d3264e7..fb30390 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -166,6 +166,27 @@
};
};
 
+   gsx_opp_table: gsx_opp_table {
+   compatible = "operating-points-v2";
+
+   opp@2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <83>;
+   };
+   opp@3 {
+   opp-hz = /bits/ 64 <3>;
+   opp-microvolt = <83>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <83>;
+   };
+   opp@6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <83>;
+   };
+   };
+
extal_clk: extal {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -2246,6 +2267,7 @@
reg = <0 0xfd00 0 0x3>;
interrupts = ;
clocks = < CPG_MOD 112>;
+   operating-points-v2 = <_opp_table>;
power-domains = < R8A7796_PD_3DG_B>;
};
 
-- 
2.7.4

[PATCH 1/4] clk: renesas: r8a7796: Add ZG clock

[Ulrich Hecht]

From: Takeshi Kihara 

This patch adds ZG clock for R8A7796 SoC.

Signed-off-by: Takeshi Kihara 
---
 drivers/clk/renesas/r8a7796-cpg-mssr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c 
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 83a68e5..61247b5 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -76,6 +76,7 @@ static const struct cpg_core_clk r8a7796_core_clks[] 
__initconst = {
/* Core Clock Outputs */
DEF_BASE("z",   R8A7796_CLK_Z, CLK_TYPE_GEN3_Z, CLK_PLL0),
DEF_BASE("z2",  R8A7796_CLK_Z2,CLK_TYPE_GEN3_Z2, CLK_PLL2),
+   DEF_FIXED("zg", R8A7796_CLK_ZG,CLK_PLL4,   4, 1),
DEF_FIXED("ztr",R8A7796_CLK_ZTR,   CLK_PLL1_DIV2,  6, 1),
DEF_FIXED("ztrd2",  R8A7796_CLK_ZTRD2, CLK_PLL1_DIV2, 12, 1),
DEF_FIXED("zt", R8A7796_CLK_ZT,CLK_PLL1_DIV2,  4, 1),
@@ -117,6 +118,7 @@ static const struct cpg_core_clk r8a7796_core_clks[] 
__initconst = {
 };
 
 static const struct mssr_mod_clk r8a7796_mod_clks[] __initconst = {
+   DEF_MOD("3dge",  112,   R8A7796_CLK_ZG),
DEF_MOD("scif5", 202,   R8A7796_CLK_S3D4),
DEF_MOD("scif4", 203,   R8A7796_CLK_S3D4),
DEF_MOD("scif3", 204,   R8A7796_CLK_S3D4),
-- 
2.7.4

[PATCH 3/5] ARM: dts: iwg20d-q7-common: Sound DMA support via BUSIF on DTS

[Biju Das]

DMA transfer to/from SSIU

 DMA
[MEM] -> [SSIU] -> [SSI]

 DMA
[MEM] <- [SSIU] <- [SSI]

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/iwg20d-q7-common.dtsi | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi 
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index fd50065..38f1e2b 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -246,11 +246,6 @@
};
 };
 
- {
-   no-busif;
-};
-
  {
-   no-busif;
shared-pin;
 };
-- 
1.9.1

[PATCH 2/5] ARM: dts: iwg20d-q7-common: Sound DMA support on DTS

[Biju Das]

DMA transfer to/from SSI

 DMA
[MEM] -> [SSI]

 DMA
[MEM] <- [SSI]

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/iwg20d-q7-common.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi 
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 41bc4ed..fd50065 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -247,10 +247,10 @@
 };
 
  {
-   pio-transfer;
+   no-busif;
 };
 
  {
-   pio-transfer;
+   no-busif;
shared-pin;
 };
-- 
1.9.1

[PATCH 5/5] ARM: dts: iwg20d-q7-common: Sound DMA support via DVC on DTS

[Biju Das]

DMA transfer uses DVC

 DMA   DMApp
[MEM] -> [SRC] -> [DVC] -> [SSIU] -> [SSI]

 DMA   DMApp
[MEM] <- [DVC] <- [SRC] <- [SSIU] <- [SSI]

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/iwg20d-q7-common.dtsi | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi 
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 9f6ec25..ccbdf5a 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -8,6 +8,29 @@
  * kind, whether express or implied.
  */
 
+/*
+ * SSI-SGTL5000
+ *
+ * This command is required when Playback/Capture
+ *
+ *  amixer set "DVC Out" 100%
+ *  amixer set "DVC In" 100%
+ *
+ * You can use Mute
+ *
+ *  amixer set "DVC Out Mute" on
+ *  amixer set "DVC In Mute" on
+ *
+ * You can use Volume Ramp
+ *
+ *  amixer set "DVC Out Ramp Up Rate"   "0.125 dB/64 steps"
+ *  amixer set "DVC Out Ramp Down Rate" "0.125 dB/512 steps"
+ *  amixer set "DVC Out Ramp" on
+ *  aplay xxx.wav &
+ *  amixer set "DVC Out"  80%  // Volume Down
+ *  amixer set "DVC Out" 100%  // Volume Up
+ */
+
 / {
aliases {
serial0 = 
@@ -240,8 +263,8 @@
 
rcar_sound,dai {
dai0 {
-   playback = < >;
-   capture = < >;
+   playback = <  >;
+   capture = <  >;
};
};
 };
-- 
1.9.1

[PATCH 4/5] ARM: dts: iwg20d-q7-common: Sound DMA support via SRC on DTS

[Biju Das]

DMA transfer to/from SRC

 DMA  DMApp
[MEM] -> [SRC] -> [SSIU] -> [SSI]

 DMA  DMApp
[MEM] <- [SRC] <- [SSIU] <- [SSI]

Current sound driver is supporting SSI/SRC random connection.
So, this patch is trying
SSI1 -> SRC3
SSI0 <- SRC2

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/iwg20d-q7-common.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi 
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 38f1e2b..9f6ec25 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -240,8 +240,8 @@
 
rcar_sound,dai {
dai0 {
-   playback = <>;
-   capture = <>;
+   playback = < >;
+   capture = < >;
};
};
 };
-- 
1.9.1

[PATCH 0/5] Add sound support

[Biju Das]

This series aims to add sound support for iWave RZ/G1M board.

This patch series has below dependencies
1) https://www.spinics.net/lists/arm-kernel/msg622754.html
2) https://patchwork.kernel.org/patch/10108041/

Biju Das (5):
  ARM: dts: iwg20d-q7-common: Sound PIO support
  ARM: dts: iwg20d-q7-common: Sound DMA support on DTS
  ARM: dts: iwg20d-q7-common: Sound DMA support via BUSIF on DTS
  ARM: dts: iwg20d-q7-common: Sound DMA support via SRC on DTS
  ARM: dts: iwg20d-q7-common: Sound DMA support via DVC on DTS

 arch/arm/boot/dts/iwg20d-q7-common.dtsi | 64 +
 1 file changed, 64 insertions(+)

-- 
1.9.1

Re: [PATCH 3/5] include: v4l2_async: Add 'owner' field to notifier

[Sakari Ailus]

Hi Jacopo,

On Wed, Dec 13, 2017 at 07:26:18PM +0100, Jacopo Mondi wrote:
> Notifiers can be registered as root notifiers (identified by a 'struct
> v4l2_device *') or subdevice notifiers (identified by a 'struct
> v4l2_subdev *'). In order to identify a notifier no matter if it is root
> or not, add a 'struct fwnode_handle *owner' field, whose name can be
> printed out for debug purposes.
> 
> Signed-off-by: Jacopo Mondi 

You'll have struct device either through the v4l2_device or v4l2_subdev. Do
you need an additional field for this?

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 10/15] adv748x: csi2: add translation from pixelcode to CSI-2 datatype

[jacopo mondi]

Hi Kieran,

On Thu, Dec 14, 2017 at 10:25:36PM +, Kieran Bingham wrote:
> Hi Niklas,
>
> On 14/12/17 19:08, Niklas Söderlund wrote:
> > This will be needed to fill out the frame descriptor information
> > correctly.
> >
> > Signed-off-by: Niklas Söderlund 
> > ---
> >  drivers/media/i2c/adv748x/adv748x-csi2.c | 22 ++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/drivers/media/i2c/adv748x/adv748x-csi2.c 
> > b/drivers/media/i2c/adv748x/adv748x-csi2.c
> > index 2a5dff8c571013bf..a2a6d93077204731 100644
> > --- a/drivers/media/i2c/adv748x/adv748x-csi2.c
> > +++ b/drivers/media/i2c/adv748x/adv748x-csi2.c
> > @@ -18,6 +18,28 @@
> >
> >  #include "adv748x.h"
> >
> > +struct adv748x_csi2_format {
> > +   unsigned int code;
> > +   unsigned int datatype;
> > +};
> > +
> > +static const struct adv748x_csi2_format adv748x_csi2_formats[] = {
> > +   { .code = MEDIA_BUS_FMT_RGB888_1X24,.datatype = 0x24, },
> > +   { .code = MEDIA_BUS_FMT_UYVY8_1X16, .datatype = 0x1e, },
> > +   { .code = MEDIA_BUS_FMT_UYVY8_2X8,  .datatype = 0x1e, },
> > +   { .code = MEDIA_BUS_FMT_YUYV10_2X10,.datatype = 0x1e, },

YUV 422 10 bit is associated to data type 0x1d in CSI-2 specifications

> > +};
>
> Is the datatype mapping specific to the ADV748x here?
> or are these generic/common CSI2 mappings?
>
> What do those datatype magic numbers represent?

They are fixed mappings defined by CSI-2 specifications and they
should probably be generic to all drivers imho

>
> --
> Kieran
>
> > +
> > +static unsigned int adv748x_csi2_code_to_datatype(unsigned int code)
> > +{
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(adv748x_csi2_formats); i++)
> > +   if (adv748x_csi2_formats[i].code == code)
> > +   return adv748x_csi2_formats[i].datatype;
> > +   return 0;
> > +}
> > +
> >  static bool is_txa(struct adv748x_csi2 *tx)
> >  {
> > return tx == >state->txa;
> >

Re: [PATCH 2/5] device property: Add fwnode_get_name() operation

[Sakari Ailus]

Hi Jacopo,

Thanks for the patch.

Could you cc the next version to linux-a...@vger.kernel.org, please? Cc
Mika, too.

On Wed, Dec 13, 2017 at 07:26:17PM +0100, Jacopo Mondi wrote:
> Add operation to retrieve the device name from a fwnode handle.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/acpi/property.c  |  6 ++
>  drivers/base/property.c  | 12 
>  drivers/of/property.c|  6 ++
>  include/linux/fwnode.h   |  2 ++
>  include/linux/property.h |  1 +
>  5 files changed, 27 insertions(+)
> 
> diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> index e26ea20..1e3971c 100644
> --- a/drivers/acpi/property.c
> +++ b/drivers/acpi/property.c
> @@ -1186,6 +1186,11 @@ acpi_fwnode_property_read_string_array(const struct 
> fwnode_handle *fwnode,
>  val, nval);
>  }
>  
> +static const char *acpi_fwnode_get_name(const struct fwnode_handle *fwnode)
> +{
> + return acpi_dev_name(to_acpi_device_node(fwnode));

This works for device nodes but will fail miserably for non-device ACPI
nodes.

The ACPI nodes don't currently have a name such as the DT nodes do, it
would certainly help debugging if they did.

What you'll at least need to do is to check to_acpi_device_node() does not
return NULL.

acpi_dev_name() should be made const as well if the function is still used
in v2.

> +}
> +
>  static struct fwnode_handle *
>  acpi_fwnode_get_named_child_node(const struct fwnode_handle *fwnode,
>const char *childname)
> @@ -1281,6 +1286,7 @@ static int acpi_fwnode_graph_parse_endpoint(const 
> struct fwnode_handle *fwnode,
>   acpi_fwnode_property_read_string_array, \
>   .get_parent = acpi_node_get_parent, \
>   .get_next_child_node = acpi_get_next_subnode,   \
> + .get_name = acpi_fwnode_get_name,   \
>   .get_named_child_node = acpi_fwnode_get_named_child_node, \
>   .get_reference_args = acpi_fwnode_get_reference_args,   \
>   .graph_get_next_endpoint =  \
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 851b1b6..a87b4a9 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -950,6 +950,18 @@ int device_add_properties(struct device *dev,
>  EXPORT_SYMBOL_GPL(device_add_properties);
>  
>  /**
> + * fwnode_get_name - Return the fwnode_handle name
> + * @fwnode: Firmware node to get name from
> + *
> + * Returns a pointer to the firmware node name
> + */
> +const char *fwnode_get_name(const struct fwnode_handle *fwnode)
> +{
> + return fwnode_call_ptr_op(fwnode, get_name);
> +}
> +EXPORT_SYMBOL(fwnode_get_name);
> +
> +/**
>   * fwnode_get_next_parent - Iterate to the node's parent
>   * @fwnode: Firmware whose parent is retrieved
>   *
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 8ad33a4..6c195a8 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -875,6 +875,11 @@ of_fwnode_property_read_string_array(const struct 
> fwnode_handle *fwnode,
>   of_property_count_strings(node, propname);
>  }
>  
> +static const char *of_fwnode_get_name(const struct fwnode_handle *fwnode)
> +{
> + return of_node_full_name(to_of_node(fwnode));
> +}
> +
>  static struct fwnode_handle *
>  of_fwnode_get_parent(const struct fwnode_handle *fwnode)
>  {
> @@ -988,6 +993,7 @@ const struct fwnode_operations of_fwnode_ops = {
>   .property_present = of_fwnode_property_present,
>   .property_read_int_array = of_fwnode_property_read_int_array,
>   .property_read_string_array = of_fwnode_property_read_string_array,
> + .get_name = of_fwnode_get_name,
>   .get_parent = of_fwnode_get_parent,
>   .get_next_child_node = of_fwnode_get_next_child_node,
>   .get_named_child_node = of_fwnode_get_named_child_node,
> diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
> index 411a84c..5d3a8c6 100644
> --- a/include/linux/fwnode.h
> +++ b/include/linux/fwnode.h
> @@ -57,6 +57,7 @@ struct fwnode_reference_args {
>   *otherwise.
>   * @property_read_string_array: Read an array of string properties. Return 
> zero
>   *   on success, a negative error code otherwise.
> + * @get_name: Return the fwnode name.
>   * @get_parent: Return the parent of an fwnode.
>   * @get_next_child_node: Return the next child node in an iteration.
>   * @get_named_child_node: Return a child node with a given name.
> @@ -81,6 +82,7 @@ struct fwnode_operations {
>   (*property_read_string_array)(const struct fwnode_handle *fwnode_handle,
> const char *propname, const char **val,
> size_t nval);
> + const char *(*get_name)(const struct fwnode_handle *fwnode);
>   struct fwnode_handle *(*get_parent)(const struct 

Re: arm64: unhandled level 0 translation fault

[Will Deacon]

On Fri, Dec 15, 2017 at 02:30:00PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin  wrote:
> > The two important differences here seem to be
> >
> > 1) Staging the state via current->thread.fpsimd_state instead of loading
> > directly:
> >
> > -   fpsimd_load_state(state);
> > +   current->thread.fpsimd_state = *state;
> > +   fpsimd_load_state(>thread.fpsimd_state);
> 
> The change above introduces the breakage.

I finally managed to reproduce this, but only by using the exact same
compiler as Geert:

https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_aarch64-linux.tar.xz

I then reliably see the problem if I run:

  # /usr/bin/update-ca-certificates

from Debian Jessie.

Note that my normal toolchain (Linaro 7.1.1 build) works fine and also
if I use the toolchain above but disable CONFIG_ARM64_CRYPTO then things
work too.

So there's some toolchain-specific interaction between this change and the
crypto code...

Will

Re: [PATCH] v4l: rcar-csi2: Don't bail out from probe on no ep

[Niklas Söderlund]

Hi Hans,

On 2017-12-15 15:06:44 +0100, Hans Verkuil wrote:
> Niklas,
> 
> Did you look at this? If I should take it, can you Ack it? If you are
> going to squash or add it to our of your own patch series, then let me
> know and I can remove it from my todo queue.

I did look at it and talked to Jacobo about it. I think I have a better 
solution to his problem which I hope to try out in the near future. If 
my workaround turns out to not solve his problem I will squash this in 
when I resend the rcar-csi2 patch-set so in any case I think you can 
drop it from your todo queue.

The reason I'm a bit reluctant to ack this straight away is that I think 
it's kind of good that rcar-csi2 fails to probe if it finds no endpoints 
to work with, there is little use for the driver instance then. The 
problem Jacobo is trying to fix is related to how the rcar-vin Gen3 
group parses DT and I made a small mistake there which was discovered by 
Jacobo. And since the original fault is in the rcar-vin driver I think 
the issue should be fixed in that driver.

> 
> Regards,
> 
>   Hans
> 
> On 05/12/17 21:41, Jacopo Mondi wrote:
> > When rcar-csi interface is not connected to any endpoint, it fails and
> > bails out from probe before registering its own video subdevice.
> > This prevents rcar-vin registered notifier from completing and no
> > subdevice is ever registered, also for other properly connected csi
> > interfaces.
> > 
> > Fix this not returning an error when no endpoint is connected to a csi
> > interface and let the driver complete its probe function and register its
> > own video subdevice.
> > 
> > ---
> > Niklas,
> >please squash this patch in your next rcar-csi2 series (if you like it ;)
> > 
> > As we have discussed this is particularly useful for gmsl setup, where 
> > adv748x
> > is connected to CSI20 and max9286 to CSI40/CSI41. If we disable adv748x 
> > from DTS
> > we need CSI20 probe to complete anyhow otherwise no subdevice gets 
> > registered
> > for the two deserializers.
> > 
> > Please note we cannot disable CSI20 entirely otherwise VIN's graph parsing
> > breaks.
> > 
> > Thanks
> >j
> > 
> > ---
> >  drivers/media/platform/rcar-vin/rcar-csi2.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > index 2793efb..90c4062 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > @@ -928,8 +928,8 @@ static int rcar_csi2_parse_dt(struct rcar_csi2 *priv)
> > 
> > ep = of_graph_get_endpoint_by_regs(priv->dev->of_node, 0, 0);
> > if (!ep) {
> > -   dev_err(priv->dev, "Not connected to subdevice\n");
> > -   return -EINVAL;
> > +   dev_dbg(priv->dev, "Not connected to subdevice\n");
> > +   return 0;
> > }
> > 
> > ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), _ep);
> > --
> > 2.7.4
> > 
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH/RFC v2 07/15] rcar-csi2: use frame description information to configure CSI-2 bus

[jacopo mondi]

Hi Niklas,
   thanks for the patch!

On Thu, Dec 14, 2017 at 08:08:27PM +0100, Niklas Söderlund wrote:
> The driver now have access to frame descriptor information, use it. Only
> enable the virtual channels which are described in the frame descriptor
> and calculate the link based on all enabled streams.
>
> With multiplexed stream support it's now possible to have different
> formats on the different source pads. Make source formats independent
> off each other and disallowing a format on the multiplexed sink.
>
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 112 
> ++--
>  1 file changed, 58 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index 6b607b2e31e26063..2dd7d03d622d5510 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -296,24 +296,22 @@ static const struct phtw_testdin_data 
> testdin_data_v3m_e3[] = {
>  #define CSI0CLKFREQRANGE(n)  ((n & 0x3f) << 16)
>
>  struct rcar_csi2_format {
> - unsigned int code;
>   unsigned int datatype;
>   unsigned int bpp;
>  };
>
>  static const struct rcar_csi2_format rcar_csi2_formats[] = {
> - { .code = MEDIA_BUS_FMT_RGB888_1X24,.datatype = 0x24, .bpp = 24 },
> - { .code = MEDIA_BUS_FMT_UYVY8_1X16, .datatype = 0x1e, .bpp = 16 },
> - { .code = MEDIA_BUS_FMT_UYVY8_2X8,  .datatype = 0x1e, .bpp = 16 },
> - { .code = MEDIA_BUS_FMT_YUYV10_2X10,.datatype = 0x1e, .bpp = 16 },
> + { .datatype = 0x1e, .bpp = 16 },
> + { .datatype = 0x24, .bpp = 24 },
>  };
>
> -static const struct rcar_csi2_format *rcar_csi2_code_to_fmt(unsigned int 
> code)
> +static const struct rcar_csi2_format
> +*rcar_csi2_datatype_to_fmt(unsigned int datatype)
>  {
>   unsigned int i;
>
>   for (i = 0; i < ARRAY_SIZE(rcar_csi2_formats); i++)
> - if (rcar_csi2_formats[i].code == code)
> + if (rcar_csi2_formats[i].datatype == datatype)
>   return rcar_csi2_formats + i;
>
>   return NULL;
> @@ -355,7 +353,7 @@ struct rcar_csi2 {
>   struct v4l2_async_notifier notifier;
>   struct v4l2_async_subdev remote;
>
> - struct v4l2_mbus_framefmt mf;
> + struct v4l2_mbus_framefmt mf[4];
>
>   struct mutex lock;
>   int stream_count[4];
> @@ -411,25 +409,14 @@ static int rcar_csi2_wait_phy_start(struct rcar_csi2 
> *priv)
>   return -ETIMEDOUT;
>  }
>
> -static int rcar_csi2_calc_mbps(struct rcar_csi2 *priv, unsigned int bpp)
> +static int rcar_csi2_calc_mbps(struct rcar_csi2 *priv,
> +struct v4l2_subdev *source,
> +struct v4l2_mbus_frame_desc *fd)
>  {
> - struct media_pad *pad, *source_pad;
> - struct v4l2_subdev *source = NULL;
>   struct v4l2_ctrl *ctrl;
> + unsigned int i, bpp = 0;
>   u64 mbps;
>
> - /* Get remote subdevice */
> - pad = >subdev.entity.pads[RCAR_CSI2_SINK];
> - source_pad = media_entity_remote_pad(pad);
> - if (!source_pad) {
> - dev_err(priv->dev, "Could not find remote source pad\n");
> - return -ENODEV;
> - }
> - source = media_entity_to_v4l2_subdev(source_pad->entity);
> -
> - dev_dbg(priv->dev, "Using source %s pad: %u\n", source->name,
> - source_pad->index);
> -
>   /* Read the pixel rate control from remote */
>   ctrl = v4l2_ctrl_find(source->ctrl_handler, V4L2_CID_PIXEL_RATE);
>   if (!ctrl) {
> @@ -438,6 +425,21 @@ static int rcar_csi2_calc_mbps(struct rcar_csi2 *priv, 
> unsigned int bpp)
>   return -EINVAL;
>   }
>
> + /* Calculate total bpp */
> + for (i = 0; i < fd->num_entries; i++) {
> + const struct rcar_csi2_format *format;
> +
> + format = rcar_csi2_datatype_to_fmt(
> + fd->entry[i].bus.csi2.data_type);
> + if (!format) {
> + dev_err(priv->dev, "Unknown data type: %d\n",
> + fd->entry[i].bus.csi2.data_type);
> + return -EINVAL;
> + }
> +
> + bpp += format->bpp;
> + }
> +
>   /* Calculate the phypll */
>   mbps = v4l2_ctrl_g_ctrl_int64(ctrl) * bpp;
>   do_div(mbps, priv->lanes * 100);
> @@ -489,39 +491,33 @@ static int rcar_csi2_set_phtw(struct rcar_csi2 *priv, 
> unsigned int mbps)
>   return 0;
>  }
>
> -static int rcar_csi2_start(struct rcar_csi2 *priv)
> +static int rcar_csi2_start(struct rcar_csi2 *priv, struct v4l2_subdev 
> *source,
> +struct v4l2_mbus_frame_desc *fd)

I'm not sure I got this right, but with the new s_stream pad
operation, and with rcar-csi2 endpoints connected to differenct VIN
instances, is it possible for "rcar_csi2_s_stream()" to be called on
the same 

Re: [PATCH 0/4] kms++util: Provide validation helpers

[Tomi Valkeinen]

On 14/12/17 01:10, Kieran Bingham wrote:

From: Kieran Bingham 

Our kms-tests test suite for verifying the R-Car DU is based on kmsxx.

We are implementing a 'loop-back' validator, by providing an HDMI cable from
the display output directly into the HDMI receiver on the same development
board.

By using the existing VideoStreamer and pyvid objects, we can capture the output
and compare to provide automated display validation.

As an effort to commence this process, this series implements a basic frame
buffer comparison, which expects identical frame sizes to operate.

This could be could be expanded upon later to provide a more detailed
comparison at the pixel level later, but this serves as an initial starting
point to quickly verify if the data captured matches the data that we expected.

Kieran Bingham (4):
   videodevice: Fix minor spacing
   py: pyvid: Provide stream_off binding


Thanks, I've picked up the first two patches.

 Tomi

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

Re: [PATCH 4/4] kms++util: Add frame compare functionality

[Tomi Valkeinen]

Hi,

On 14/12/17 01:10, Kieran Bingham wrote:

From: Kieran Bingham 

Provide a means to compare two identically sized framebuffers.

This basic implementation expects the two buffers to have the same
formats and sizes, and will return zero for identical frames, or a
positive float representing and average difference otherwise.

Signed-off-by: Kieran Bingham 
---
  kms++util/inc/kms++util/kms++util.h |  1 +-
  kms++util/src/verification.cpp  | 31 ++-
  py/pykms/pykmsutil.cpp  |  2 ++-
  3 files changed, 34 insertions(+)

diff --git a/kms++util/inc/kms++util/kms++util.h 
b/kms++util/inc/kms++util/kms++util.h
index 431de0bb159a..753cee189451 100644
--- a/kms++util/inc/kms++util/kms++util.h
+++ b/kms++util/inc/kms++util/kms++util.h
@@ -29,6 +29,7 @@ void draw_color_bar(IFramebuffer& buf, int old_xpos, int 
xpos, int width);
  void draw_test_pattern(IFramebuffer , YUVType yuvt = YUVType::BT601_Lim);
  
  void save_raw_frame(IFramebuffer& fb, const char *filename);

+float compare_framebuffers(IFramebuffer& a, IFramebuffer& b);
  }
  
  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))

diff --git a/kms++util/src/verification.cpp b/kms++util/src/verification.cpp
index 3210bb144d2b..a46d6f924095 100644
--- a/kms++util/src/verification.cpp
+++ b/kms++util/src/verification.cpp
@@ -18,4 +18,35 @@ void save_raw_frame(IFramebuffer& fb, const char *filename)
os->write((char*)fb.map(i), fb.size(i));
  }
  
+float compare_framebuffers(IFramebuffer& a, IFramebuffer& b)


I think this needs a short comment above to explain the return value.


+{
+   unsigned int i;
+   unsigned int pixels = a.width() * a.height();
+   uint8_t *pa = a.map(0);
+   uint8_t *pb = b.map(0);


This is only checking plane 0, you need to go through all the planes.

Also, it's much nicer to introduce the locals near where they are 
needed, instead of having them all in the beginning of the function.



+
+   float diff = 0;
+
+   if (a.format() != b.format())
+   throw std::invalid_argument("Pixel formats differ...");
+
+   if ((a.width() != b.width() ||
+   (a.height() != b.height(
+   throw std::invalid_argument("Frame sizes differ...");
+
+   // Formats are identical, so num_planes are already identical
+   for (i = 0; i < a.num_planes(); i++) {
+   if ((a.offset(i) != b.offset(i)) ||
+   (a.stride(i) != b.stride(i)))
+   throw std::invalid_argument("Planes differ...");
+   }
+
+   // Simple byte comparisons to start.
+   // This expects a frame to be identical, including non-visible data.
+   for (i = 0; i < a.size(0) && i < b.size(0); i++)
+   diff += abs(pa[i] - pb[i]);


I don't think it's a good idea compare the non-valid pixels. They could 
as well contain random data.


Better to do the check properly, using the pixels inside width and 
height only, without making assumptions about the buffer layout. And 
that way you can drop the check for offset and stride, as they don't 
have to be the same, as long as width & height are the same.


 Tomi

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

Re: [PATCH] v4l: rcar-csi2: Don't bail out from probe on no ep

[Hans Verkuil]

Niklas,

Did you look at this? If I should take it, can you Ack it? If you are
going to squash or add it to our of your own patch series, then let me
know and I can remove it from my todo queue.

Regards,

Hans

On 05/12/17 21:41, Jacopo Mondi wrote:
> When rcar-csi interface is not connected to any endpoint, it fails and
> bails out from probe before registering its own video subdevice.
> This prevents rcar-vin registered notifier from completing and no
> subdevice is ever registered, also for other properly connected csi
> interfaces.
> 
> Fix this not returning an error when no endpoint is connected to a csi
> interface and let the driver complete its probe function and register its
> own video subdevice.
> 
> ---
> Niklas,
>please squash this patch in your next rcar-csi2 series (if you like it ;)
> 
> As we have discussed this is particularly useful for gmsl setup, where adv748x
> is connected to CSI20 and max9286 to CSI40/CSI41. If we disable adv748x from 
> DTS
> we need CSI20 probe to complete anyhow otherwise no subdevice gets registered
> for the two deserializers.
> 
> Please note we cannot disable CSI20 entirely otherwise VIN's graph parsing
> breaks.
> 
> Thanks
>j
> 
> ---
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index 2793efb..90c4062 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -928,8 +928,8 @@ static int rcar_csi2_parse_dt(struct rcar_csi2 *priv)
> 
>   ep = of_graph_get_endpoint_by_regs(priv->dev->of_node, 0, 0);
>   if (!ep) {
> - dev_err(priv->dev, "Not connected to subdevice\n");
> - return -EINVAL;
> + dev_dbg(priv->dev, "Not connected to subdevice\n");
> + return 0;
>   }
> 
>   ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), _ep);
> --
> 2.7.4
> 

[PATCH] [kms-tests] tests: Add colorkey test

[Laurent Pinchart]

The test will display an overlay with large colored boxes on top of the
root plane and turn the boxes translucent or transparent in sequence
using color keying.

Signed-off-by: Laurent Pinchart 
---
 tests/kms-test-colorkey.py | 111 +
 1 file changed, 111 insertions(+)
 create mode 100755 tests/kms-test-colorkey.py

diff --git a/tests/kms-test-colorkey.py b/tests/kms-test-colorkey.py
new file mode 100755
index ..310165f83b1e
--- /dev/null
+++ b/tests/kms-test-colorkey.py
@@ -0,0 +1,111 @@
+#!/usr/bin/python3
+
+import kmstest
+import pykms
+import time
+
+class ColorKeyTest(kmstest.KMSTest):
+"""Test color keying with two planes."""
+
+def main(self):
+self.start("color keying")
+
+# Find a CRTC with a connected connector and at least one overlay plane
+for connector in self.card.connectors:
+if not connector.connected():
+continue
+
+try:
+mode = connector.get_default_mode()
+except ValueError:
+continue
+
+crtcs = connector.get_possible_crtcs()
+for crtc in crtcs:
+overlay = None
+for plane in self.card.planes:
+if plane.supports_crtc(crtc) and plane != 
crtc.primary_plane:
+overlay = plane
+
+if overlay:
+break
+else:
+crtc = None
+
+if crtc:
+break
+
+else:
+self.skip("no CRTC available with connector and at least one 
overlay plane")
+return
+
+self.logger.log("Testing connector %s, CRTC %u, mode %s" % \
+  (connector.fullname, crtc.id, mode.name))
+
+# Create the frame buffers
+colors = ((255, 0, 0), (0, 255, 0), (0, 0, 255), (255, 255, 255))
+width = mode.hdisplay
+height = mode.vdisplay
+fbs = []
+
+fb = pykms.DumbFramebuffer(self.card, width, height, "XR24")
+pykms.draw_test_pattern(fb)
+fbs.append(fb)
+
+fb = pykms.DumbFramebuffer(self.card, width, height, "XR24")
+pykms.draw_rect(fb, 0,  0,   width // 2, height // 2, 
pykms.RGB(*colors[0]))
+pykms.draw_rect(fb, width // 2, 0,   width // 2, height // 2, 
pykms.RGB(*colors[1]))
+pykms.draw_rect(fb, 0,  height // 2, width // 2, height // 2, 
pykms.RGB(*colors[2]))
+pykms.draw_rect(fb, width // 2, height // 2, width // 2, height // 2, 
pykms.RGB(*colors[3]))
+fbs.append(fb)
+
+# Set the mode with the primary plane and add an overlay plane
+ret = self.atomic_crtc_mode_set(crtc, connector, mode, fbs[0])
+if ret < 0:
+self.fail("atomic mode set failed with %d" % ret)
+return
+
+self.logger.log("Initial atomic mode set completed")
+
+# Add the overlay plane to cover the whole CRTC
+source = kmstest.Rect(0, 0, fbs[1].width, fbs[1].height)
+destination = kmstest.Rect(0, 0, fbs[1].width, fbs[1].height)
+ret = self.atomic_plane_set(overlay, crtc, source, destination, 
fbs[1], sync=True)
+if ret < 0:
+self.fail("atomic plane set for overlay plane failed with %d" % 
ret)
+return
+
+self.logger.log("Overlay plane enabled")
+time.sleep(3)
+
+# Try to set different minimum and maximum values, this should be
+# rejected.
+req = pykms.AtomicReq(self.card)
+req.add(plane, {"colorkey.min": 1, "colorkey.max": 2})
+ret = req.commit_sync()
+if ret >= 0:
+self.fail("Non-equal colorkey min and max not rejected")
+return
+
+self.logger.log("Non-equal colorkey min and max correctly rejected")
+
+# Cycle over color keys to make the four rectangles in the overlay 
plane
+# transparent in turn.
+for i in range(len(colors)):
+color = (colors[i][0] << 40) | (colors[i][1] << 24) | 
(colors[i][2] << 8)
+
+plane.set_props({
+"colorkey.mode": 1,
+"colorkey.min": color,
+"colorkey.max": color,
+"colorkey.value": (255 * (len(colors) - i - 1) // 4) << 56,
+})
+
+self.logger.log("Color key set to %s" % repr(colors[i]))
+time.sleep(3)
+
+plane.set_prop("colorkey.mode", 0)
+self.atomic_crtc_disable(crtc)
+self.success()
+
+ColorKeyTest().execute()
-- 
Regards,

Laurent Pinchart

Re: [PATCH 3/4] kms++util: Add verification module

[Tomi Valkeinen]

Hi,

On 14/12/17 01:10, Kieran Bingham wrote:

From: Kieran Bingham 

Provide a util module to provide helpers involved in validation and verification
of data frames.

The first addition is a raw frame binary output with bindings to python modelled
on Tomi's implementation in wbcap.


I don't think verification.cpp is a good name for this. A function to 
save the fb sounds like a generic fb utility.


In fact, I'd like to have a helper utility function to save as png, as 
converting a raw image to png is a bit of a hassle. Then again, we'd 
need a png library for that, and possibly bigger pieces of code to 
handle all the different pixel formats...


So, a function to save the raw bits is fine, but how about "fbutils.cpp" 
or such?



Signed-off-by: Kieran Bingham 
---
  kms++util/inc/kms++util/kms++util.h |  2 ++
  kms++util/src/verification.cpp  | 21 +
  py/pykms/pykmsutil.cpp  |  5 +
  3 files changed, 28 insertions(+)
  create mode 100644 kms++util/src/verification.cpp

diff --git a/kms++util/inc/kms++util/kms++util.h 
b/kms++util/inc/kms++util/kms++util.h
index 8e45b0df3cde..431de0bb159a 100644
--- a/kms++util/inc/kms++util/kms++util.h
+++ b/kms++util/inc/kms++util/kms++util.h
@@ -27,6 +27,8 @@ void draw_text(IFramebuffer& buf, uint32_t x, uint32_t y, const 
std::string& str
  void draw_color_bar(IFramebuffer& buf, int old_xpos, int xpos, int width);
  
  void draw_test_pattern(IFramebuffer , YUVType yuvt = YUVType::BT601_Lim);

+
+void save_raw_frame(IFramebuffer& fb, const char *filename);
  }
  
  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))

diff --git a/kms++util/src/verification.cpp b/kms++util/src/verification.cpp
new file mode 100644
index ..3210bb144d2b
--- /dev/null
+++ b/kms++util/src/verification.cpp
@@ -0,0 +1,21 @@
+
+#include 
+#include 
+
+#include 
+
+using namespace std;
+
+namespace kms
+{
+
+void save_raw_frame(IFramebuffer& fb, const char *filename)
+{
+   unique_ptr os;
+   os = unique_ptr(new ofstream(filename, ofstream::binary));
+
+   for (unsigned i = 0; i < fb.num_planes(); ++i)
+   os->write((char*)fb.map(i), fb.size(i));
+}


You don't need any of that unique_ptr stuff here. I needed it as the 
code needed to handle the case where we don't save, i.e. os = null.


And I'm not fond of the function name, "frame" doesn't sound good. Maybe 
rather save_raw_fb(). Or save_fb_raw(), so in the future we might have 
also save_fb_png().



+
+}
diff --git a/py/pykms/pykmsutil.cpp b/py/pykms/pykmsutil.cpp
index 518d5eaa88f0..2d741751ba75 100644
--- a/py/pykms/pykmsutil.cpp
+++ b/py/pykms/pykmsutil.cpp
@@ -59,4 +59,9 @@ void init_pykmstest(py::module )
} );
m.def("draw_text", [](Framebuffer& fb, uint32_t x, uint32_t y, const 
string& str, RGB color) {
draw_text(fb, x, y, str, color); } );
+
+   // Verification and Validation
+   m.def("save_raw_frame", [](Framebuffer& fb, const char * filename) {
+   save_raw_frame(fb, filename);
+   });
  }



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

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

[Ulf Hansson]

On 15 December 2017 at 12:12, Wolfram Sang  wrote:
>
>> After 2, COMPILE_TEST will work correctly.
>>
>> Then, Wolfram mentioned we would need to include  from tmio_mmc.h
>>
>> https://patchwork.kernel.org/patch/10074333/
>>
>>
>> I was waiting for a patch from him.
>
> Yes, I am sorry. I am currently swamped with I2C work, not so much time
> for SDHI. However, I did this patch now and pushed the branch out to see
> if buildbot is happy.

Great!

>
> Ulf, this patch then in deed should ideally be applied before 1-8 here.

Okay, once you post it to linux-mmc I will pick it up, and put it in front.

Kind regards
Uffe

Re: arm64: unhandled level 0 translation fault

[Geert Uytterhoeven]

Hi Dave,

On Fri, Dec 15, 2017 at 12:23 PM, Dave Martin  wrote:
> On Thu, Dec 14, 2017 at 07:08:27PM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 14, 2017 at 4:24 PM, Dave P Martin  wrote:
>> > On Thu, Dec 14, 2017 at 02:34:50PM +, Geert Uytterhoeven wrote:
>> >> On Tue, Dec 12, 2017 at 11:20 AM, Geert Uytterhoeven
>> >>  wrote:
>> >> > During userspace (Debian jessie NFS root) boot on arm64:
>> >> >
>> >> > rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
>> >> > esr 0x9204, in dash[adf77000+1a000]
>> >> > CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>> >> > 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>> >> > Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 
>> >> > ES2.0+ (DT)
>> >>
>> >> This is a quad Cortex A57.
>> >>
>> >> > pstate: 8000 (Nzcv daif -PAN -UAO)
>> >> > pc : 0xadf8a51c
>> >> > lr : 0xadf8ac08
>> >> > sp : cffeac00
>> >> > x29: cffeac00 x28: adfa1000
>> >> > x27: cffebf7c x26: cffead20
>> >> > x25: cea1c5f0 x24: 
>> >> > x23: adfa1000 x22: adfa1000
>> >> > x21:  x20: 0008
>> >> > x19:  x18: cffeb500
>> >> > x17: a22babfc x16: adfa1ae8
>> >> > x15: a2363588 x14: 
>> >> > x13: 0020 x12: 0010
>> >> > x11: 0101010101010101 x10: adfa1000
>> >> > x9 : ff81 x8 : adfa2000
>> >> > x7 :  x6 : 
>> >> > x5 : adfa2338 x4 : adfa2000
>> >> > x3 : adfa2338 x2 : 
>> >> > x1 : adfa28b0 x0 : adfa4c30
>> >> >
>> >> > Sometimes it happens with other processes, but the main address, esr, 
>> >> > and
>> >> > pstate values are always the same.
>> >> >
>> >> > I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>> >> > releases, so the last time was two weeks ago), but never saw the issue
>> >> > before until today, so probably v4.15-rc1 is OK.
>> >> > Unfortunately it doesn't happen during every boot, which makes it
>> >> > cumbersome to bisect.
>> >> >
>> >> > My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>> >> > and even without today's arm64/for-next/core merged in, I still managed 
>> >> > to
>> >> > reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>> >> > v4.15-rc3.
>> >> >
>> >> > Once, when the kernel message above wasn't shown, I got an error from
>> >> > userspace, which may be related:
>> >> > *** Error in `/bin/sh': free(): invalid pointer: 0xdd970988 ***
>> >>
>> >> With more boots (10 instead of 6) to declare a kernel good, I bisected 
>> >> this
>> >> to commit 9de52a755cfb6da5 ("arm64: fpsimd: Fix failure to restore FPSIMD
>> >> state after signals").
>> >>
>> >> Reverting that commit on top of v4.15-rc3 fixed the issue for me.
>> >
>> > Good work on the bisect -- I'll need to have a think about this...
>> >
>> > That patch fixes a genuine problem so we can't just revert it.
>> >
>> > What if you revert _just this function_ back to what it was in v4.14?
>>
>> With fpsimd_update_current_state() reverted to v4.14, and
>>
>> -   __this_cpu_write(fpsimd_last_state, st);
>> +   __this_cpu_write(fpsimd_last_state.st, st);
>>
>> to make it build, the problem seems to be fixed, too.

> Interesting if I apply that to v4.14 and then flatten the new code for 
> CONFIG_ARM64_SVE=n, I get:
>
> Working:
>
> void fpsimd_update_current_state(struct fpsimd_state *state)
> {
> local_bh_disable();
>
> fpsimd_load_state(state);
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> struct fpsimd_state *st = >thread.fpsimd_state;
>
> __this_cpu_write(fpsimd_last_state.st, st);
> st->cpu = smp_processor_id();
> }
>
> local_bh_enable();
> }
>
> Broken:
>
> void fpsimd_update_current_state(struct fpsimd_state *state)
> {
> struct fpsimd_last_state_struct *last;
> struct fpsimd_state *st;
>
> local_bh_disable();
>
> current->thread.fpsimd_state = *state;
> fpsimd_load_state(>thread.fpsimd_state);
>
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> last = this_cpu_ptr(_last_state);
> st = >thread.fpsimd_state;
>
> last->st = st;
> last->sve_in_use = test_thread_flag(TIF_SVE);
> st->cpu = smp_processor_id();
> }
>
> local_bh_enable();
> }
>
> Can you try my flattened "broken" version by itself and see if that does
> reproduce the bug?  If not, my flattening may be making bad assumptions...
>
> Assuming the "broken" version reproduces the bug, I can't yet see exactly
> where the breakage comes from.

Correct, above "Working" is working, and 

Re: [PATCH/RFC v2 06/15] rcar-csi2: use frame description information when propagating .s_stream()

[Sakari Ailus]

Hi Niklas,

On Thu, Dec 14, 2017 at 08:08:26PM +0100, Niklas Söderlund wrote:
> Use the frame description from the remote subdevice of the rcar-csi2's
> sink pad to get the remote pad and stream pad needed to propagate the
> .s_stream() operation.
> 
> The CSI-2 virtual channel which should be acted upon can be determined
> by looking at which of the rcar-csi2 source pad the .s_stream() was
> called on. This is because the rcar-csi2 acts as a demultiplexer for the
> CSI-2 link on the one sink pad and outputs each virtual channel on a
> distinct and known source pad.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 58 
> -
>  1 file changed, 41 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index e0f56cc3d25179a9..6b607b2e31e26063 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -614,20 +614,31 @@ static void rcar_csi2_stop(struct rcar_csi2 *priv)
>   rcar_csi2_reset(priv);
>  }
>  
> -static int rcar_csi2_sd_info(struct rcar_csi2 *priv, struct v4l2_subdev **sd)
> +static int rcar_csi2_get_source_info(struct rcar_csi2 *priv,
> +  struct v4l2_subdev **subdev,

I wonder if using struct media_pad for this would be cleaner.

> +  unsigned int *pad,
> +  struct v4l2_mbus_frame_desc *fd)
>  {
> - struct media_pad *pad;
> + struct media_pad *remote_pad;
>  
> - pad = media_entity_remote_pad(>pads[RCAR_CSI2_SINK]);
> - if (!pad) {
> - dev_err(priv->dev, "Could not find remote pad\n");
> + /* Get source subdevice and pad */
> + remote_pad = media_entity_remote_pad(>pads[RCAR_CSI2_SINK]);
> + if (!remote_pad) {
> + dev_err(priv->dev, "Could not find remote source pad\n");
>   return -ENODEV;
>   }
> + *subdev = media_entity_to_v4l2_subdev(remote_pad->entity);
> + *pad = remote_pad->index;
>  
> - *sd = media_entity_to_v4l2_subdev(pad->entity);
> - if (!*sd) {
> - dev_err(priv->dev, "Could not find remote subdevice\n");
> - return -ENODEV;
> + /* Get frame descriptor */
> + if (v4l2_subdev_call(*subdev, pad, get_frame_desc, *pad, fd)) {
> + dev_err(priv->dev, "Could not read frame desc\n");
> + return -EINVAL;
> + }
> +
> + if (fd->type != V4L2_MBUS_FRAME_DESC_TYPE_CSI2) {
> + dev_err(priv->dev, "Frame desc do not describe CSI-2 link");
> + return -EINVAL;

I think this should also work with drivers that do not support frame
descriptors.

Alternatively support could be added for all drivers. In practice this
would mean having a few bus specific implementations of get_frame_desc op
that would dig the information from the frame format.

Perhaps the former option would make sense here, for now.

>   }
>  
>   return 0;
> @@ -637,9 +648,10 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
> unsigned int stream, int enable)
>  {
>   struct rcar_csi2 *priv = sd_to_csi2(sd);
> + struct v4l2_mbus_frame_desc fd;
>   struct v4l2_subdev *nextsd;
> - unsigned int i, count = 0;
> - int ret, vc;
> + unsigned int i, rpad, count = 0;
> + int ret, vc, rstream = -1;
>  
>   /* Only allow stream control on source pads and valid vc */
>   vc = rcar_csi2_pad_to_vc(pad);
> @@ -650,11 +662,23 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>   if (stream != 0)
>   return -EINVAL;
>  
> - mutex_lock(>lock);
> -
> - ret = rcar_csi2_sd_info(priv, );
> + /* Get information about multiplexed link */
> + ret = rcar_csi2_get_source_info(priv, , , );
>   if (ret)
> - goto out;
> + return ret;
> +
> + /* Get stream on multiplexed link */
> + for (i = 0; i < fd.num_entries; i++)
> + if (fd.entry[i].bus.csi2.channel == vc)
> + rstream = fd.entry[i].stream;

Virtual channel does not equate to the stream. You'll need the data type,
too.

You should actually obtain this from the configured routes instead.

How does this work btw. if you have several streams on the same virtual
channel that only have different data types?

> +
> + if (rstream < 0) {
> + dev_err(priv->dev, "Could not find stream for vc %u\n", vc);
> + return -EINVAL;
> + }
> +
> + /* Start or stop the requested stream */
> + mutex_lock(>lock);
>  
>   for (i = 0; i < 4; i++)
>   count += priv->stream_count[i];
> @@ -673,14 +697,14 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>   }
>  
>   if (enable && priv->stream_count[vc] == 0) 

Re: [PATCH/RFC v2 05/15] rcar-csi2: count usage for each source pad

[Sakari Ailus]

On Thu, Dec 14, 2017 at 08:08:25PM +0100, Niklas Söderlund wrote:
> The R-Car CSI-2 hardware can output the same virtual channel
> simultaneously to more then one R-Car VIN. For this reason we need to
> move the usage counting from the global device to each source pad.
> 
> If a source pads usage count go from 0 to 1 we need to signal that a new
> stream should start, likewise if it go from 1 to 0 we need to stop a
> stream. At the same time we only want to start or stop the R-Car
> CSI-2 device only on the first or last stream.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-csi2.c | 38 
> +++--
>  1 file changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c 
> b/drivers/media/platform/rcar-vin/rcar-csi2.c
> index 8ce0bfeef1113f9c..e0f56cc3d25179a9 100644
> --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> @@ -328,6 +328,14 @@ enum rcar_csi2_pads {
>   NR_OF_RCAR_CSI2_PAD,
>  };
>  
> +static int rcar_csi2_pad_to_vc(unsigned int pad)
> +{
> + if (pad < RCAR_CSI2_SOURCE_VC0 || pad > RCAR_CSI2_SOURCE_VC3)
> + return -EINVAL;
> +
> + return pad - RCAR_CSI2_SOURCE_VC0;
> +}
> +
>  struct rcar_csi2_info {
>   const struct phypll_hsfreqrange *hsfreqrange;
>   const struct phtw_testdin_data *testdin_data;
> @@ -350,7 +358,7 @@ struct rcar_csi2 {
>   struct v4l2_mbus_framefmt mf;
>  
>   struct mutex lock;
> - int stream_count;
> + int stream_count[4];

Why 4?

>  
>   unsigned short lanes;
>   unsigned char lane_swap[4];
> @@ -630,7 +638,13 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>  {
>   struct rcar_csi2 *priv = sd_to_csi2(sd);
>   struct v4l2_subdev *nextsd;
> - int ret;
> + unsigned int i, count = 0;
> + int ret, vc;
> +
> + /* Only allow stream control on source pads and valid vc */
> + vc = rcar_csi2_pad_to_vc(pad);
> + if (vc < 0)
> + return vc;
>  
>   /* Only one stream on each source pad */
>   if (stream != 0)
> @@ -642,7 +656,10 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>   if (ret)
>   goto out;
>  
> - if (enable && priv->stream_count == 0) {
> + for (i = 0; i < 4; i++)
> + count += priv->stream_count[i];
> +
> + if (enable && count == 0) {
>   pm_runtime_get_sync(priv->dev);
>  
>   ret = rcar_csi2_start(priv);
> @@ -650,20 +667,23 @@ static int rcar_csi2_s_stream(struct v4l2_subdev *sd, 
> unsigned int pad,
>   pm_runtime_put(priv->dev);
>   goto out;
>   }
> + } else if (!enable && count == 1) {
> + rcar_csi2_stop(priv);
> + pm_runtime_put(priv->dev);
> + }
>  
> + if (enable && priv->stream_count[vc] == 0) {
>   ret = v4l2_subdev_call(nextsd, video, s_stream, 1);
>   if (ret) {
>   rcar_csi2_stop(priv);
>   pm_runtime_put(priv->dev);
>   goto out;
>   }
> - } else if (!enable && priv->stream_count == 1) {
> - rcar_csi2_stop(priv);
> + } else if (!enable && priv->stream_count[vc] == 1) {

Do I understand correctly that you can start and streams here one by one,
independently of each other?

Sometimes this might not be the case. I wonder if we should have a way to
tell that to the caller.

>   ret = v4l2_subdev_call(nextsd, video, s_stream, 0);
> - pm_runtime_put(priv->dev);
>   }
>  
> - priv->stream_count += enable ? 1 : -1;
> + priv->stream_count[vc] += enable ? 1 : -1;
>  out:
>   mutex_unlock(>lock);
>  
> @@ -919,7 +939,9 @@ static int rcar_csi2_probe(struct platform_device *pdev)
>   priv->dev = >dev;
>  
>   mutex_init(>lock);
> - priv->stream_count = 0;
> +
> + for (i = 0; i < 4; i++)
> + priv->stream_count[i] = 0;
>  
>   ret = rcar_csi2_probe_resources(priv, pdev);
>   if (ret) {
> -- 
> 2.15.1
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 03/15] rcar-vin: use the pad and stream aware s_stream

[Sakari Ailus]

Hej,

On Thu, Dec 14, 2017 at 08:08:23PM +0100, Niklas Söderlund wrote:
> To work with multiplexed streams the pad and stream aware s_stream
> operation needs to be used.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index cf30e5fceb1d493a..8435491535060eae 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1180,7 +1180,7 @@ static int rvin_set_stream(struct rvin_dev *vin, int on)
>  
>   if (!on) {
>   media_pipeline_stop(vin->vdev.entity.pads);
> - return v4l2_subdev_call(sd, video, s_stream, 0);
> + return v4l2_subdev_call(sd, pad, s_stream, pad->index, 0, 0);

Have you thought of adding a wrapper for the s_stream callback?

I think you should either change all s_stream callbacks from video to pad,
or add a wrapper which then calls the video op instead of the pad op if the
pad op does not exist. Otherwise we again have two non-interoperable
classes of drivers for no good reason.

Thinking about it, I'm not all that certain changing all instances would be
that much work in the end; it should be done anyway. Devices that have a
single stream (i.e. everything right now) just don't care about the pad
number.

>   }
>  
>   fmt.pad = pad->index;
> @@ -1239,12 +1239,14 @@ static int rvin_set_stream(struct rvin_dev *vin, int 
> on)
>   if (media_pipeline_start(vin->vdev.entity.pads, pipe))
>   return -EPIPE;
>  
> - ret = v4l2_subdev_call(sd, video, s_stream, 1);
> + ret = v4l2_subdev_call(sd, pad, s_stream, pad->index, 0, 1);
>   if (ret == -ENOIOCTLCMD)
>   ret = 0;
>   if (ret)
>   media_pipeline_stop(vin->vdev.entity.pads);
>  
> + vin_dbg(vin, "pad: %u stream: 0 enable: %d\n", pad->index, on);
> +
>   return ret;
>  }
>  
> -- 
> 2.15.1
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 02/15] rcar-vin: use pad as the starting point for a pipeline

[Sakari Ailus]

On Thu, Dec 14, 2017 at 08:08:22PM +0100, Niklas Söderlund wrote:
> The pipeline will be moved from the entity to the pads; reflect this in
> the media pipeline function API.

I'll merge this to "media: entity: Use pad as the starting point for a
pipeline" if you're fine with that.

I haven't compiled everything for some time, and newly added drivers may be
lacking these changes. I'll re-check that soonish.

> 
> Signed-off-by: Niklas Söderlund 
> ---
>  drivers/media/platform/rcar-vin/rcar-dma.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
> b/drivers/media/platform/rcar-vin/rcar-dma.c
> index 03a914361a33125c..cf30e5fceb1d493a 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -1179,7 +1179,7 @@ static int rvin_set_stream(struct rvin_dev *vin, int on)
>   return -EPIPE;
>  
>   if (!on) {
> - media_pipeline_stop(>vdev.entity);
> + media_pipeline_stop(vin->vdev.entity.pads);
>   return v4l2_subdev_call(sd, video, s_stream, 0);
>   }
>  
> @@ -1235,15 +1235,15 @@ static int rvin_set_stream(struct rvin_dev *vin, int 
> on)
>   fmt.format.height != vin->format.height)
>   return -EPIPE;
>  
> - pipe = sd->entity.pipe ? sd->entity.pipe : >vdev.pipe;
> - if (media_pipeline_start(>vdev.entity, pipe))
> + pipe = sd->entity.pads->pipe ? sd->entity.pads->pipe : >vdev.pipe;
> + if (media_pipeline_start(vin->vdev.entity.pads, pipe))
>   return -EPIPE;
>  
>   ret = v4l2_subdev_call(sd, video, s_stream, 1);
>   if (ret == -ENOIOCTLCMD)
>   ret = 0;
>   if (ret)
> - media_pipeline_stop(>vdev.entity);
> + media_pipeline_stop(vin->vdev.entity.pads);
>  
>   return ret;
>  }
> -- 
> 2.15.1
> 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH/RFC v2 01/15] v4l2-subdev.h: add pad and stream aware s_stream

[Sakari Ailus]

Hejssan Niklas,

Tack för uppdaterade lappor!

On Thu, Dec 14, 2017 at 08:08:21PM +0100, Niklas Söderlund wrote:
> To be able to start and stop individual streams of a multiplexed pad the
> s_stream operation needs to be both pad and stream aware. Add a new
> operation to pad ops to facilitate this.
> 
> Signed-off-by: Niklas Söderlund 
> ---
>  include/media/v4l2-subdev.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index a30a94fad8dbacde..7288209338a48fda 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -669,6 +669,9 @@ struct v4l2_subdev_pad_config {
>   *
>   * @set_frame_desc: set the low level media bus frame parameters, @fd array
>   *  may be adjusted by the subdev driver to device 
> capabilities.
> + *
> + * @s_stream: used to notify the driver that a stream will start or has
> + *   stopped.

This is actually the callback which is used to control the stream state.
The above suggests that it's a notification of something that has happened
(or about to happen). How about:

Enable or disable streaming on a sub-device pad.

>   */
>  struct v4l2_subdev_pad_ops {
>   int (*init_cfg)(struct v4l2_subdev *sd,
> @@ -713,6 +716,8 @@ struct v4l2_subdev_pad_ops {
>  struct v4l2_subdev_routing *route);
>   int (*set_routing)(struct v4l2_subdev *sd,
>  struct v4l2_subdev_routing *route);
> + int (*s_stream)(struct v4l2_subdev *sd, unsigned int pad,
> + unsigned int stream, int enable);

How about bool for enable?

>  };
>  
>  /**

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: arm64: unhandled level 0 translation fault

[Dave Martin]

On Thu, Dec 14, 2017 at 07:08:27PM +0100, Geert Uytterhoeven wrote:
> Hi Dave,
> 
> On Thu, Dec 14, 2017 at 4:24 PM, Dave P Martin  wrote:
> > On Thu, Dec 14, 2017 at 02:34:50PM +, Geert Uytterhoeven wrote:
> >> On Tue, Dec 12, 2017 at 11:20 AM, Geert Uytterhoeven
> >>  wrote:
> >> > During userspace (Debian jessie NFS root) boot on arm64:
> >> >
> >> > rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
> >> > esr 0x9204, in dash[adf77000+1a000]
> >> > CPU: 0 PID: 1083 Comm: rpcbind Not tainted
> >> > 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
> >> > Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 
> >> > ES2.0+ (DT)
> >>
> >> This is a quad Cortex A57.
> >>
> >> > pstate: 8000 (Nzcv daif -PAN -UAO)
> >> > pc : 0xadf8a51c
> >> > lr : 0xadf8ac08
> >> > sp : cffeac00
> >> > x29: cffeac00 x28: adfa1000
> >> > x27: cffebf7c x26: cffead20
> >> > x25: cea1c5f0 x24: 
> >> > x23: adfa1000 x22: adfa1000
> >> > x21:  x20: 0008
> >> > x19:  x18: cffeb500
> >> > x17: a22babfc x16: adfa1ae8
> >> > x15: a2363588 x14: 
> >> > x13: 0020 x12: 0010
> >> > x11: 0101010101010101 x10: adfa1000
> >> > x9 : ff81 x8 : adfa2000
> >> > x7 :  x6 : 
> >> > x5 : adfa2338 x4 : adfa2000
> >> > x3 : adfa2338 x2 : 
> >> > x1 : adfa28b0 x0 : adfa4c30
> >> >
> >> > Sometimes it happens with other processes, but the main address, esr, and
> >> > pstate values are always the same.
> >> >
> >> > I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
> >> > releases, so the last time was two weeks ago), but never saw the issue
> >> > before until today, so probably v4.15-rc1 is OK.
> >> > Unfortunately it doesn't happen during every boot, which makes it
> >> > cumbersome to bisect.
> >> >
> >> > My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
> >> > and even without today's arm64/for-next/core merged in, I still managed 
> >> > to
> >> > reproduce the issue, so I believe it was introduced in v4.15-rc2 or
> >> > v4.15-rc3.
> >> >
> >> > Once, when the kernel message above wasn't shown, I got an error from
> >> > userspace, which may be related:
> >> > *** Error in `/bin/sh': free(): invalid pointer: 0xdd970988 ***
> >>
> >> With more boots (10 instead of 6) to declare a kernel good, I bisected this
> >> to commit 9de52a755cfb6da5 ("arm64: fpsimd: Fix failure to restore FPSIMD
> >> state after signals").
> >>
> >> Reverting that commit on top of v4.15-rc3 fixed the issue for me.
> >
> > Good work on the bisect -- I'll need to have a think about this...
> >
> > That patch fixes a genuine problem so we can't just revert it.
> >
> > What if you revert _just this function_ back to what it was in v4.14?
> 
> With fpsimd_update_current_state() reverted to v4.14, and
> 
> -   __this_cpu_write(fpsimd_last_state, st);
> +   __this_cpu_write(fpsimd_last_state.st, st);
> 
> to make it build, the problem seems to be fixed, too.
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> Geert

Interesting if I apply that to v4.14 and then flatten the new code for 
CONFIG_ARM64_SVE=n, I get:

Working:

void fpsimd_update_current_state(struct fpsimd_state *state)
{
local_bh_disable();

fpsimd_load_state(state);
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
struct fpsimd_state *st = >thread.fpsimd_state;

__this_cpu_write(fpsimd_last_state.st, st);
st->cpu = smp_processor_id();
}

local_bh_enable();
}

Broken:

void fpsimd_update_current_state(struct fpsimd_state *state)
{
struct fpsimd_last_state_struct *last;
struct fpsimd_state *st;

local_bh_disable();

current->thread.fpsimd_state = *state;
fpsimd_load_state(>thread.fpsimd_state);

if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
last = this_cpu_ptr(_last_state);
st = >thread.fpsimd_state;

last->st = st;
last->sve_in_use = test_thread_flag(TIF_SVE);
st->cpu = smp_processor_id();
}

local_bh_enable();
}

Can you try my flattened "broken" version by itself and see if that does
reproduce the bug?  If not, my flattening may be making bad assumptions...


Assuming the "broken" version reproduces the bug, I can't yet see exactly
where the breakage comes from.

The two important differences here seem to be

1) Staging the state via current->thread.fpsimd_state instead of loading
directly:

-   fpsimd_load_state(state);
+   current->thread.fpsimd_state = *state;
+  

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

[Wolfram Sang]

> After 2, COMPILE_TEST will work correctly.
> 
> Then, Wolfram mentioned we would need to include  from tmio_mmc.h
> 
> https://patchwork.kernel.org/patch/10074333/
> 
> 
> I was waiting for a patch from him.

Yes, I am sorry. I am currently swamped with I2C work, not so much time
for SDHI. However, I did this patch now and pushed the branch out to see
if buildbot is happy.

Ulf, this patch then in deed should ideally be applied before 1-8 here.



signature.asc
Description: PGP signature

Re: [PATCH 0/9] ARM: dts: gen2: add IP core switcher for all busses

[Wolfram Sang]

> Access to Porter did not work yet and will be investigated.

Magnus fixed that, so I could test, and the test went well.



signature.asc
Description: PGP signature

RE: [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM

[Fabrizio Castro]

Hi Geert,

> Subject: Re: [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM
>
> Hi Fabrizio,
>
> On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
>  wrote:
> > RZ/G1 and R-Car platforms have PWM timers. This patch enables PWM support
> > by default.
> >
> > Signed-off-by: Fabrizio Castro 
> > Reviewed-by: Biju Das 
>
> Thanks for your patch!

Thank you for your feedback.

>
> If I'm not mistaken, there are no current users of this PWM block in the
> current R-Car Gen2 and RZ/G1 DTS files?

PWM support will be needed very soon as we are going to use pwm3 on the iwg20d 
platform to control the RGB display backlight.
The work to add display support is in progress, I hope it will be ready by next 
week, would you rather I sent this patch with the series to add display support?

Thanks,
Fab

> If that's correct, I don't think it makes much sense to enable it already.
>
> Simon: what do you think?
>
> 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


[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



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

Re: [PATCH] phy: rcar-gen3-usb2: add dependency on USB

[Vladimir Murzin]

Hi,

On 15/12/17 10:27, Yoshihiro Shimoda wrote:
> Hi,
> 
>> -Original Message-
>> From: Vladimir Murzin, Sent: Friday, December 15, 2017 7:20 PM
>>
>> Following error showed up:
>>
>> drivers/phy/renesas/phy-rcar-gen3-usb2.o: In function 
>> `rcar_gen3_phy_usb2_probe':
>> /work/tools/linux/drivers/phy/renesas/phy-rcar-gen3-usb2.c:444: undefined 
>> reference to `of_usb_get_dr_mode_by_phy'
>> Makefile:993: recipe for target 'vmlinux' failed
>> make: *** [vmlinux] Error 1
>>
>> with CONFIG_USB_SUPPORT=n
>>
>> Add dependency on USB_SUPPORT and select USB_COMMON to make sure that
>> of_usb_get_dr_mode_by_phy() is available.
>>
>> Signed-off-by: Vladimir Murzin 
> 
> Thank you for the patch! However, Arnd already sent such a patch before.
> 
> https://lkml.org/lkml/2017/11/2/373
> 
> The latest Linux-phy.git doesn't apply it yet though...

Ahh, good!

Sorry for the noise!

Vladimir

> 
> Best regards,
> Yoshihiro Shimoda
> 

RE: [PATCH] phy: rcar-gen3-usb2: add dependency on USB

[Yoshihiro Shimoda]

Hi,

> -Original Message-
> From: Vladimir Murzin, Sent: Friday, December 15, 2017 7:20 PM
> 
> Following error showed up:
> 
> drivers/phy/renesas/phy-rcar-gen3-usb2.o: In function 
> `rcar_gen3_phy_usb2_probe':
> /work/tools/linux/drivers/phy/renesas/phy-rcar-gen3-usb2.c:444: undefined 
> reference to `of_usb_get_dr_mode_by_phy'
> Makefile:993: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
> 
> with CONFIG_USB_SUPPORT=n
> 
> Add dependency on USB_SUPPORT and select USB_COMMON to make sure that
> of_usb_get_dr_mode_by_phy() is available.
> 
> Signed-off-by: Vladimir Murzin 

Thank you for the patch! However, Arnd already sent such a patch before.

https://lkml.org/lkml/2017/11/2/373

The latest Linux-phy.git doesn't apply it yet though...

Best regards,
Yoshihiro Shimoda

[PATCH] phy: rcar-gen3-usb2: add dependency on USB

[Vladimir Murzin]

Following error showed up:

drivers/phy/renesas/phy-rcar-gen3-usb2.o: In function 
`rcar_gen3_phy_usb2_probe':
/work/tools/linux/drivers/phy/renesas/phy-rcar-gen3-usb2.c:444: undefined 
reference to `of_usb_get_dr_mode_by_phy'
Makefile:993: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

with CONFIG_USB_SUPPORT=n

Add dependency on USB_SUPPORT and select USB_COMMON to make sure that
of_usb_get_dr_mode_by_phy() is available.

Signed-off-by: Vladimir Murzin 
---
 drivers/phy/renesas/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/renesas/Kconfig b/drivers/phy/renesas/Kconfig
index cb09245..c845fac 100644
--- a/drivers/phy/renesas/Kconfig
+++ b/drivers/phy/renesas/Kconfig
@@ -12,7 +12,9 @@ config PHY_RCAR_GEN3_USB2
tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
depends on ARCH_RENESAS
depends on EXTCON
+   depends on USB_SUPPORT
select GENERIC_PHY
+   select USB_COMMON
help
  Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
 
-- 
1.9.1

Re: [PATCH 2/9] v4l: vsp1: Print the correct blending unit name in debug messages

[Kieran Bingham]

Hi Laurent,

On 03/12/17 10:57, Laurent Pinchart wrote:
> The DRM pipelines can use either the BRU or the BRS for blending. Make
> sure the right name is used in debugging messages to avoid confusion.

This could likely tag along with the preceding [PATCH 1/9] on it's short cut to
mainline before the rest of the CRC series is reviewed.

> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index ac85942162c1..0fe541084f5c 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -400,8 +400,11 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   struct v4l2_subdev_selection sel;
>   struct v4l2_subdev_format format;
>   const struct v4l2_rect *crop;
> + const char *bru_name;
>   int ret;
>  
> + bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
> +
>   /*
>* Configure the format on the RPF sink pad and propagate it up to the
>* BRU sink pad.
> @@ -473,9 +476,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, format.pad);
> + format.format.code, bru_name, format.pad);
>  
>   sel.pad = bru_input;
>   sel.target = V4L2_SEL_TGT_COMPOSE;
> @@ -486,10 +489,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev,
> - "%s: set selection (%u,%u)/%ux%u on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
>   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> - sel.pad);
> + bru_name, sel.pad);
>  
>   return 0;
>  }
> 

[GIT PULL FOR renesas-drivers] Display CRC calculation support

[Laurent Pinchart]

Hi Geert,

The following changes since commit 0f2278cc90181f0e1d938ba9d20928eaf1fd31ce:

  Merge branch 'drm/next/base' into vsp1/base (2017-12-14 01:11:25 +0200)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git tags/vsp1-discom-v1-20171215

for you to fetch changes up to cef620afa09ca165cbcdbdedbff0120e409ad946:

  drm: rcar-du: Add support for CRC computation (2017-12-14 01:11:50 +0200)

This will pull in the -next branches of the Linux media and DRM trees.


Laurent Pinchart (9):
  v4l: vsp1: Fix display stalls when requesting too many inputs
  v4l: vsp1: Print the correct blending unit name in debug messages
  v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code
  v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper
  v4l: vsp1: Document the vsp1_du_atomic_config structure
  v4l: vsp1: Extend the DU API to support CRC computation
  v4l: vsp1: Add support for the DISCOM entity
  v4l: vsp1: Integrate DISCOM in display pipeline
  drm: rcar-du: Add support for CRC computation

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 148 +++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h|  19 +++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  13 +-
 drivers/media/platform/vsp1/Makefile  |   2 +-
 drivers/media/platform/vsp1/vsp1.h|   4 +
 drivers/media/platform/vsp1/vsp1_clu.c|  65 ++---
 drivers/media/platform/vsp1/vsp1_drm.c| 138 +--
 drivers/media/platform/vsp1/vsp1_drm.h|  14 +-
 drivers/media/platform/vsp1/vsp1_drv.c|  20 +++
 drivers/media/platform/vsp1/vsp1_entity.c |  97 ++
 drivers/media/platform/vsp1/vsp1_entity.h |   7 +
 drivers/media/platform/vsp1/vsp1_histo.c  |  59 +---
 drivers/media/platform/vsp1/vsp1_lif.c|  65 ++---
 drivers/media/platform/vsp1/vsp1_lut.c|  65 ++---
 drivers/media/platform/vsp1/vsp1_regs.h   |  41 ++
 drivers/media/platform/vsp1/vsp1_uif.c| 275 +
 drivers/media/platform/vsp1/vsp1_uif.h|  36 +
 include/media/vsp1.h  |  39 +-
 18 files changed, 870 insertions(+), 237 deletions(-)
 create mode 100644 drivers/media/platform/vsp1/vsp1_uif.c
 create mode 100644 drivers/media/platform/vsp1/vsp1_uif.h

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/9] v4l: vsp1: Fix display stalls when requesting too many inputs

[Kieran Bingham]

Hi Laurent,

As this is a prevents hardware hangs, and is a distinct patch on it's own - I
feel it should be on an accelerated path to integration, and should be merged
separately from the rest of the CRC feature series.

On 03/12/17 10:57, Laurent Pinchart wrote:
> Make sure we don't accept more inputs than the hardware can handle. This
> is a temporary fix to avoid display stall, we need to instead allocate
> the BRU or BRS to display pipelines dynamically based on the number of
> planes they each use.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 7ce69f23f50a..ac85942162c1 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -530,6 +530,15 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   struct vsp1_rwpf *rpf = vsp1->rpf[i];
>   unsigned int j;
>  
> + /*
> +  * Make sure we don't accept more inputs than the hardware can
> +  * handle. This is a temporary fix to avoid display stall, we
> +  * need to instead allocate the BRU or BRS to display pipelines
> +  * dynamically based on the number of planes they each use.
> +  */
> + if (pipe->num_inputs >= pipe->bru->source_pad)
> + pipe->inputs[i] = NULL;
> +
>   if (!pipe->inputs[i])
>   continue;
>  
> 

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

[Masahiro Yamada]

2017-12-15 18:18 GMT+09:00 Ulf Hansson :
> On 24 November 2017 at 17:24, Masahiro Yamada
>  wrote:
>>
>> I am working on this IP for Socionext SoCs.
>>
>> I was hit by several issues, and noticed various
>> clean-up candidates.
>>
>>  - Fix and clean-up Kconfig
>>  - Fix various card detection problems
>>  - Move Renesas private data out of TMIO core
>>  - Allow to perform platform-specific settings before MMC host starts
>>  - Fix weird IRQ handling
>>
>> I am getting more and more patches for TMIO.
>> I put all in a single series to clarify the patch order.
>>
>> 1, 2, 4, 5, 6, 7 were already acked or reviewed by Wolfram Sang.
>>
>>
>> Masahiro Yamada (22):
>>   mmc: renesas_sdhi: consolidate DMAC CONFIG options
>>   mmc: renesas_sdhi: remove wrong depends on to enable compile test
>>   mmc: renesas_sdhi: remove eprobe jump label
>>   mmc: tmio: set tmio_mmc_host to driver data
>>   mmc: tmio: use devm_ioremap_resource() instead of devm_ioremap()
>>   mmc: tmio: move mmc_host_ops to struct tmio_mmc_host from static data
>>   mmc: tmio, renesas_sdhi: set mmc_host_ops hooks directly
>>   mmc: tmio: move mmc_gpio_request_cd() before mmc_add_host()
>>   mmc: tmio: use mmc_can_gpio_cd() instead of checking
>> TMIO_MMC_USE_GPIO_CD
>>   mmc: tmio: support IP-builtin card detection logic
>>   mmc: renesas_sdhi: remove always false condition
>>   mmc: tmio,renesas_sdhi: move struct tmio_mmc_dma to renesas_sdhi.h
>>   mmc: tmio,renesas_sdhi: move Renesas-specific DMA data to
>> renesas_sdhi.h
>>   mmc: tmio,renesas_sdhi: move ssc_tappos to renesas_sdhi.h
>>   mmc: tmio: change bus_shift to unsigned int
>>   mmc: tmio: fix never-detected card insertion bug
>>   mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place
>>   mmc: tmio: remove useless TMIO_MASK_CMD handling in
>> tmio_mmc_host_probe()
>>   mmc: tmio: ioremap memory resource in tmio_mmc_host_alloc()
>>   mmc: tmio: move clk_enable/disable out of tmio_mmc_host_probe()
>>   mmc: tmio: move {tmio_}mmc_of_parse() to tmio_mmc_host_alloc()
>>   mmc: tmio: remove dma_ops from tmio_mmc_host_probe() argument
>>
>>  drivers/mmc/host/Kconfig  |   5 +-
>>  drivers/mmc/host/Makefile |   8 +-
>>  drivers/mmc/host/renesas_sdhi.h   |  22 
>>  drivers/mmc/host/renesas_sdhi_core.c  |  49 -
>>  drivers/mmc/host/renesas_sdhi_internal_dmac.c |  14 ++-
>>  drivers/mmc/host/renesas_sdhi_sys_dmac.c  |  35 +++---
>>  drivers/mmc/host/tmio_mmc.c   |  23 ++--
>>  drivers/mmc/host/tmio_mmc.h   |  23 +---
>>  drivers/mmc/host/tmio_mmc_core.c  | 149 
>> +-
>>  9 files changed, 170 insertions(+), 158 deletions(-)
>>
>> --
>> 2.7.4
>>
>
> To get this moving, I have applied patch 1->8 for next, thanks!
>
> Kind regards
> Uffe



After 2, COMPILE_TEST will work correctly.

Then, Wolfram mentioned we would need to include  from tmio_mmc.h

https://patchwork.kernel.org/patch/10074333/


I was waiting for a patch from him.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM

[Geert Uytterhoeven]

Hi Fabrizio,

On Fri, Dec 15, 2017 at 10:48 AM, Fabrizio Castro
 wrote:
>> Subject: Re: [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM
>> On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
>>  wrote:
>> > RZ/G1 and R-Car platforms have PWM timers. This patch enables PWM support
>> > by default.
>> >
>> > Signed-off-by: Fabrizio Castro 
>> > Reviewed-by: Biju Das 
>>
>> Thanks for your patch!
>
> Thank you for your feedback.
>
>>
>> If I'm not mistaken, there are no current users of this PWM block in the
>> current R-Car Gen2 and RZ/G1 DTS files?
>
> PWM support will be needed very soon as we are going to use pwm3 on the 
> iwg20d platform to control the RGB display backlight.

Good to know, thanks!

> The work to add display support is in progress, I hope it will be ready by 
> next week, would you rather I sent this patch with the series to add display 
> support?

That's up to Simon.  But I guess it doesn't matter much, as defconfig updates
are queued in a separate branch anyway.

You may want to send a similar patch for multi_v7_defconfig.

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

[git pull] pinctrl: sh-pfc: Updates for v4.16

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the git repository at:

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

for you to fetch changes up to 527890f72892b127b67567af6bdbdc5288c211c1:

  pinctrl: sh-pfc: r8a77995: Add CAN FD support (2017-12-05 14:14:56 +0100)


pinctrl: sh-pfc: Updates for v4.16

  - Add CAN pin groups on RZ/G1E,
  - Add CAN and CAN FD pin groups on R-Car H3 ES2.0, and R-Car D3,
  - Add support for the new R-Car V3M SoC,
  - Add support for I2C on R-Car D3,
  - Small fixes and cleanups.

Thanks for pulling!

P.S. There seems to be issues with kernel.org mirrorring. I can't see my
 tag in the public repo, but the sh-pfc-for-v4.16 branch is up-to-date
 (last change 10 days ago).

Fabrizio Castro (3):
  pinctrl: sh-pfc: r8a7745: Add CAN[01] support
  pinctrl: sh-pfc: r8a7794: Add can_clk function
  pinctrl: sh-pfc: r8a7791: Add can_clk function

Ramesh Shanmugasundaram (2):
  pinctrl: sh-pfc: r8a7795: Add CAN support
  pinctrl: sh-pfc: r8a7795: Add CAN FD support

Sergei Shtylyov (2):
  pinctrl: sh-pfc: Add PORT_GP_CFG_{6|22}() helper macros
  pinctrl: sh-pfc: Add R8A77970 PFC support

Takeshi Kihara (6):
  pinctrl: sh-pfc: r8a7795: Add GP-1-28 port pin support
  pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using 
STP_ISEN_1_D
  pinctrl: sh-pfc: r8a7795: Fix to delete A20..A25 pins function definitions
  pinctrl: sh-pfc: r8a7796: Fix to delete A20..A25 pins function definitions
  pinctrl: sh-pfc: r8a7795: Rename RTS{0,1,3,4}# pin function definitions
  pinctrl: sh-pfc: r8a7796: Rename RTS{0,1,3,4}# pin function definitions

Ulrich Hecht (3):
  pinctrl: sh-pfc: r8a77995: Add missing pins SCL0 and SDA0 to pinmux data
  pinctrl: sh-pfc: r8a77995: Add CAN support
  pinctrl: sh-pfc: r8a77995: Add CAN FD support

 .../bindings/pinctrl/renesas,pfc-pinctrl.txt   |1 +
 drivers/pinctrl/sh-pfc/Kconfig |5 +
 drivers/pinctrl/sh-pfc/Makefile|1 +
 drivers/pinctrl/sh-pfc/core.c  |6 +
 drivers/pinctrl/sh-pfc/pfc-r8a7791.c   |   22 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7794.c   |  166 ++
 drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c   |2 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7795.c   |  169 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7796.c   |   66 +-
 drivers/pinctrl/sh-pfc/pfc-r8a77970.c  | 2329 
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c  |   88 +
 drivers/pinctrl/sh-pfc/sh_pfc.h|   17 +-
 12 files changed, 2788 insertions(+), 84 deletions(-)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a77970.c

Gr{oetje,eeting}s,

Geert

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

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

[git pull] clk: renesas: Updates for v4.16

[Geert Uytterhoeven]

Hi Mike, Stephen,

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/clk-renesas-for-v4.16-tag1

for you to fetch changes up to 7aff266552d6042b43d3d5a9b13f0009ef862033:

  clk: renesas: cpg-mssr: Keep wakeup sources active during system suspend 
(2017-12-14 16:40:36 +0100)


clk: renesas: Updates for v4.16

  - Add support for the LVDS module clock on R-Car V3M,
  - Keep wakeup sources in Clock Domains active during system suspend,
which will allow removing workarounds from drivers later.

Thanks for pulling!

P.S. There seems to be issues with kernel.org mirrorring. I can't see my
 tag in the public repo, but the clk-renesas-for-v4.16 branch is
 up-to-date (last change 18 hours ago).

Geert Uytterhoeven (2):
  clk: renesas: mstp: Keep wakeup sources active during system suspend
  clk: renesas: cpg-mssr: Keep wakeup sources active during system suspend

Sergei Shtylyov (1):
  clk: renesas: r8a77970: Add LVDS clock

 drivers/clk/renesas/clk-mstp.c  | 2 +-
 drivers/clk/renesas/r8a77970-cpg-mssr.c | 1 +
 drivers/clk/renesas/renesas-cpg-mssr.c  | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

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 MODULE_LICENSE

[Ulf Hansson]

On 13 December 2017 at 03:33, Yoshihiro Shimoda
 wrote:
> From: Masaharu Hayakawa 
>
> The following error occurs when loading renesas_sdhi_core.c module,
> so add MODULE_LICENSE("GPL v2").
>
>  renesas_sdhi_core: module license 'unspecified' taints kernel.
>
> Signed-off-by: Masaharu Hayakawa 
> Fixes: 9d08428afb72 ("mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main 
> module file")
> Cc:  # v4.13+
> [Shimoda: Added Fixes tag and Cc to the stable ML]
> Signed-off-by: Yoshihiro Shimoda 

Thanks, applied for fixes!

Kind regards
Uffe

> ---
>  drivers/mmc/host/renesas_sdhi_core.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
> b/drivers/mmc/host/renesas_sdhi_core.c
> index fcf7235..157e1d9 100644
> --- a/drivers/mmc/host/renesas_sdhi_core.c
> +++ b/drivers/mmc/host/renesas_sdhi_core.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -667,3 +668,5 @@ int renesas_sdhi_remove(struct platform_device *pdev)
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(renesas_sdhi_remove);
> +
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
>

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

[Ulf Hansson]

On 24 November 2017 at 17:24, Masahiro Yamada
 wrote:
>
> I am working on this IP for Socionext SoCs.
>
> I was hit by several issues, and noticed various
> clean-up candidates.
>
>  - Fix and clean-up Kconfig
>  - Fix various card detection problems
>  - Move Renesas private data out of TMIO core
>  - Allow to perform platform-specific settings before MMC host starts
>  - Fix weird IRQ handling
>
> I am getting more and more patches for TMIO.
> I put all in a single series to clarify the patch order.
>
> 1, 2, 4, 5, 6, 7 were already acked or reviewed by Wolfram Sang.
>
>
> Masahiro Yamada (22):
>   mmc: renesas_sdhi: consolidate DMAC CONFIG options
>   mmc: renesas_sdhi: remove wrong depends on to enable compile test
>   mmc: renesas_sdhi: remove eprobe jump label
>   mmc: tmio: set tmio_mmc_host to driver data
>   mmc: tmio: use devm_ioremap_resource() instead of devm_ioremap()
>   mmc: tmio: move mmc_host_ops to struct tmio_mmc_host from static data
>   mmc: tmio, renesas_sdhi: set mmc_host_ops hooks directly
>   mmc: tmio: move mmc_gpio_request_cd() before mmc_add_host()
>   mmc: tmio: use mmc_can_gpio_cd() instead of checking
> TMIO_MMC_USE_GPIO_CD
>   mmc: tmio: support IP-builtin card detection logic
>   mmc: renesas_sdhi: remove always false condition
>   mmc: tmio,renesas_sdhi: move struct tmio_mmc_dma to renesas_sdhi.h
>   mmc: tmio,renesas_sdhi: move Renesas-specific DMA data to
> renesas_sdhi.h
>   mmc: tmio,renesas_sdhi: move ssc_tappos to renesas_sdhi.h
>   mmc: tmio: change bus_shift to unsigned int
>   mmc: tmio: fix never-detected card insertion bug
>   mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place
>   mmc: tmio: remove useless TMIO_MASK_CMD handling in
> tmio_mmc_host_probe()
>   mmc: tmio: ioremap memory resource in tmio_mmc_host_alloc()
>   mmc: tmio: move clk_enable/disable out of tmio_mmc_host_probe()
>   mmc: tmio: move {tmio_}mmc_of_parse() to tmio_mmc_host_alloc()
>   mmc: tmio: remove dma_ops from tmio_mmc_host_probe() argument
>
>  drivers/mmc/host/Kconfig  |   5 +-
>  drivers/mmc/host/Makefile |   8 +-
>  drivers/mmc/host/renesas_sdhi.h   |  22 
>  drivers/mmc/host/renesas_sdhi_core.c  |  49 -
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c |  14 ++-
>  drivers/mmc/host/renesas_sdhi_sys_dmac.c  |  35 +++---
>  drivers/mmc/host/tmio_mmc.c   |  23 ++--
>  drivers/mmc/host/tmio_mmc.h   |  23 +---
>  drivers/mmc/host/tmio_mmc_core.c  | 149 
> +-
>  9 files changed, 170 insertions(+), 158 deletions(-)
>
> --
> 2.7.4
>

To get this moving, I have applied patch 1->8 for next, thanks!

Kind regards
Uffe

Re: [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM

[Geert Uytterhoeven]

Hi Fabrizio,

On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
 wrote:
> RZ/G1 and R-Car platforms have PWM timers. This patch enables PWM support
> by default.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 

Thanks for your patch!

If I'm not mistaken, there are no current users of this PWM block in the
current R-Car Gen2 and RZ/G1 DTS files?
If that's correct, I don't think it makes much sense to enable it already.

Simon: what do you think?

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: [renesas-drivers:topic/renesas-overlays 23/92] drivers/of/dynamic.c:1141:13: sparse: incorrect type in assignment (different base types)

[Geert Uytterhoeven]

Hi Fengguang,

On Thu, Dec 14, 2017 at 10:37 PM, kbuild test robot
 wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> topic/renesas-overlays
> head:   47d433a558bb60587eb9f86a4d010ef74e03fa0d
> commit: e068b1eab7180587d15bbc55abdc5851b7f216dc [23/92] of: changesets: 
> Introduce changeset helper methods
> reproduce:
> # apt-get install sparse
> git checkout e068b1eab7180587d15bbc55abdc5851b7f216dc
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
>
> vim +1141 drivers/of/dynamic.c
>
>   1124
>   1125  /**
>   1126   * of_changeset_add_property_u32 - Create a new u32 property
>   1127   *
>   1128   * @ocs:changeset pointer
>   1129   * @np: device node pointer
>   1130   * @name:   name of the property
>   1131   * @val:value in host endian format
>   1132   *
>   1133   * Adds a u32 property to the changeset.
>   1134   *
>   1135   * Returns zero on success, a negative error value otherwise.
>   1136   */
>   1137  int of_changeset_add_property_u32(struct of_changeset *ocs,
>   1138  struct device_node *np, const char *name, u32 val)
>   1139  {
>   1140  /* in place */
>> 1141  val = cpu_to_be32(val);
>   1142  return of_changeset_add_property_copy(ocs, np, name, , 
> sizeof(val));
>   1143  }

Thank you, folding

+   __be32 x;
+
/* in place */
-   val = cpu_to_be32(val);
-   return of_changeset_add_property_copy(ocs, np, name, , sizeof(val));
+   x = cpu_to_be32(val);
+   return of_changeset_add_property_copy(ocs, np, name, , sizeof(x));

into the offending commit.

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 v3 2/2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Geert Uytterhoeven]

Hi Morimoto-san,

On Fri, Dec 15, 2017 at 9:12 AM, Kuninori Morimoto
 wrote:
>> > From: Kuninori Morimoto 
>> > In general, PLL has VCO (= Voltage controlled oscillator),
>> > one of the very important electronic feature called as "jitter"
>> > is related to this VCO.
>> > In academic generalism, VCO should be maximum to be more small jitter.
>> > In high frequency clock, jitter will be large impact.
>> > Thus, selecting Hi VCO is general theory.
>>
>> Thanks for your patch!
>>
>> > One note here is that it should be 2000 < fvco < 4096MHz
>>
>> 2000 Hz? (else it could be misinterpreted that MHz applies to both values).
>
> Laurent had asked same question ;)
> But, yes, it is 2000 Hz

I've seen his question, that's why I think you should make it unambiguous.

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 v3 2/2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

Hi Geert

> > From: Kuninori Morimoto 
> > In general, PLL has VCO (= Voltage controlled oscillator),
> > one of the very important electronic feature called as "jitter"
> > is related to this VCO.
> > In academic generalism, VCO should be maximum to be more small jitter.
> > In high frequency clock, jitter will be large impact.
> > Thus, selecting Hi VCO is general theory.
> 
> Thanks for your patch!
> 
> > One note here is that it should be 2000 < fvco < 4096MHz
> 
> 2000 Hz? (else it could be misinterpreted that MHz applies to both values).

Laurent had asked same question ;)
But, yes, it is 2000 Hz

Best regards
---
Kuninori Morimoto

Re: [RFC PATCH renesas-drivers] of: overlay: overlay_changeset_release() can be static

[Geert Uytterhoeven]

On Thu, Dec 14, 2017 at 8:40 PM, kbuild test robot
 wrote:
> Fixes: 11de0d24be47 ("of: overlay: kobjectify overlay objects")
> Signed-off-by: Fengguang Wu 

Thank you, will fold in the offending prototype commit.

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 renesas-drivers] [RFC] of: dead_aliases_lookup can be static

[Geert Uytterhoeven]

Hi Fengguang,

On Fri, Dec 15, 2017 at 12:44 AM, kbuild test robot
 wrote:
> Fixes: 19e0da502da1 ("[RFC] of: Add of_alias_destroy()")
> Signed-off-by: Fengguang Wu 

Thank you, will fold in the offending prototype commit.

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 v3 2/2] drm: rcar-du: calculate DPLLCR to be more small jitter

[Geert Uytterhoeven]

Hi Morimoto-san,

On Fri, Dec 15, 2017 at 2:24 AM, Kuninori Morimoto
 wrote:
> From: Kuninori Morimoto 
> In general, PLL has VCO (= Voltage controlled oscillator),
> one of the very important electronic feature called as "jitter"
> is related to this VCO.
> In academic generalism, VCO should be maximum to be more small jitter.
> In high frequency clock, jitter will be large impact.
> Thus, selecting Hi VCO is general theory.

Thanks for your patch!

> One note here is that it should be 2000 < fvco < 4096MHz

2000 Hz? (else it could be misinterpreted that MHz applies to both values).

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