Re: [PATCH 1/1] perf tools: Fix build break on powerpc

[Arnaldo Carvalho de Melo]

Em Mon, Mar 28, 2016 at 09:35:31AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sun, Mar 27, 2016 at 01:19:03PM +0200, Jiri Olsa escreveu:
> > On Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu wrote:
> > > From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> > > From: Sukadev Bhattiprolu 
> > > Date: Sat, 26 Mar 2016 17:31:39 -0400
> > > Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: 8bit
> > > 
> > > 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> > > kernel sources")' seems to have accidentially removed the inclusion of
> > > "util/header.h" from "arch/powerpc/util/header.c".
> > > 
> > > "util/header.h" provides the prototype for get_cpuid() and is needed to
> > > build perf on Powerpc.
> > > 
> > >   arch/powerpc/util/header.c:17:1: error: no previous prototype for
> > >   ‘get_cpuid’ [-Werror=missing-prototypes]
> > > 
> > > Reported-by: Michael Ellerman 
> > > Signed-off-by: Sukadev Bhattiprolu 
> > > ---
> > >  tools/perf/arch/powerpc/util/header.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/tools/perf/arch/powerpc/util/header.c 
> > > b/tools/perf/arch/powerpc/util/header.c
> > > index 6138bde..5111e34 100644
> > > --- a/tools/perf/arch/powerpc/util/header.c
> > > +++ b/tools/perf/arch/powerpc/util/header.c
> > > @@ -4,6 +4,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include "../../util/header.h"
> > 
> > you could use just "header.h" right?
> 
> Like this? I'm trying to find a way to do ppc cross builds, one more
> thing to have in the build-tests...

Argh, only kernel x-builds are supported on Fedora, checking if this is
the case with Debian, if this is supported there, one more Docker image
for building perf :-)

[acme@jouet linux]$ make ARCH=ppc64 CROSS_COMPILE=ppc64-linux-gnu-
O=/tmp/build/perf-ppc64/ -C tools/perf install-bin
make: Entering directory '/home/acme/git/linux/tools/perf'
  BUILD:   Doing 'make -j4' parallel build

Auto-detecting system features:
... dwarf: [ OFF ]
... glibc: [ OFF ]
...  gtk2: [ OFF ]
...  libaudit: [ OFF ]
...libbfd: [ OFF ]
...libelf: [ OFF ]
...   libnuma: [ OFF ]
...numa_num_possible_cpus: [ OFF ]
...   libperl: [ OFF ]
... libpython: [ OFF ]
...  libslang: [ OFF ]
... libcrypto: [ OFF ]
... libunwind: [ OFF ]
...libdw-dwarf-unwind: [ OFF ]
...  zlib: [ OFF ]
...  lzma: [ OFF ]
... get_cpuid: [ OFF ]
...   bpf: [ OFF ]

config/Makefile:258: *** No gnu/libc-version.h found, please install
glibc-dev[el].  Stop.
Makefile:108: recipe for target 'install-bin' failed
make: *** [install-bin] Error 2
make: Leaving directory '/home/acme/git/linux/tools/perf'
[acme@jouet linux]$ rpm -q --qf "%{description}\n"
gcc-powerpc64-linux-gnu 
Cross-build GNU C compiler.

Only building kernels is currently supported.  Support for
cross-building user space programs is not currently provided as that
would massively multiply the number of packages.
[acme@jouet linux]$

Re: [PATCH 1/1] perf tools: Fix build break on powerpc

[Arnaldo Carvalho de Melo]

Em Mon, Mar 28, 2016 at 09:35:31AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sun, Mar 27, 2016 at 01:19:03PM +0200, Jiri Olsa escreveu:
> > On Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu wrote:
> > > From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> > > From: Sukadev Bhattiprolu 
> > > Date: Sat, 26 Mar 2016 17:31:39 -0400
> > > Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > > Content-Transfer-Encoding: 8bit
> > > 
> > > 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> > > kernel sources")' seems to have accidentially removed the inclusion of
> > > "util/header.h" from "arch/powerpc/util/header.c".
> > > 
> > > "util/header.h" provides the prototype for get_cpuid() and is needed to
> > > build perf on Powerpc.
> > > 
> > >   arch/powerpc/util/header.c:17:1: error: no previous prototype for
> > >   ‘get_cpuid’ [-Werror=missing-prototypes]
> > > 
> > > Reported-by: Michael Ellerman 
> > > Signed-off-by: Sukadev Bhattiprolu 
> > > ---
> > >  tools/perf/arch/powerpc/util/header.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/tools/perf/arch/powerpc/util/header.c 
> > > b/tools/perf/arch/powerpc/util/header.c
> > > index 6138bde..5111e34 100644
> > > --- a/tools/perf/arch/powerpc/util/header.c
> > > +++ b/tools/perf/arch/powerpc/util/header.c
> > > @@ -4,6 +4,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include "../../util/header.h"
> > 
> > you could use just "header.h" right?
> 
> Like this? I'm trying to find a way to do ppc cross builds, one more
> thing to have in the build-tests...

Argh, only kernel x-builds are supported on Fedora, checking if this is
the case with Debian, if this is supported there, one more Docker image
for building perf :-)

[acme@jouet linux]$ make ARCH=ppc64 CROSS_COMPILE=ppc64-linux-gnu-
O=/tmp/build/perf-ppc64/ -C tools/perf install-bin
make: Entering directory '/home/acme/git/linux/tools/perf'
  BUILD:   Doing 'make -j4' parallel build

Auto-detecting system features:
... dwarf: [ OFF ]
... glibc: [ OFF ]
...  gtk2: [ OFF ]
...  libaudit: [ OFF ]
...libbfd: [ OFF ]
...libelf: [ OFF ]
...   libnuma: [ OFF ]
...numa_num_possible_cpus: [ OFF ]
...   libperl: [ OFF ]
... libpython: [ OFF ]
...  libslang: [ OFF ]
... libcrypto: [ OFF ]
... libunwind: [ OFF ]
...libdw-dwarf-unwind: [ OFF ]
...  zlib: [ OFF ]
...  lzma: [ OFF ]
... get_cpuid: [ OFF ]
...   bpf: [ OFF ]

config/Makefile:258: *** No gnu/libc-version.h found, please install
glibc-dev[el].  Stop.
Makefile:108: recipe for target 'install-bin' failed
make: *** [install-bin] Error 2
make: Leaving directory '/home/acme/git/linux/tools/perf'
[acme@jouet linux]$ rpm -q --qf "%{description}\n"
gcc-powerpc64-linux-gnu 
Cross-build GNU C compiler.

Only building kernels is currently supported.  Support for
cross-building user space programs is not currently provided as that
would massively multiply the number of packages.
[acme@jouet linux]$

Re: [PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

[Neil Horman]

On Fri, Mar 25, 2016 at 03:16:36PM -0400, David Miller wrote:
> From: Bjorn Helgaas 
> Date: Fri, 25 Mar 2016 11:46:39 -0500
> 
> > You're right, there is an issue here.  I reproduced a problem with a
> > bond device.  bond_netpoll_setup() calls __netpoll_setup() directly
> > (not netpoll_setup()).  I'll debug it more; just wanted to let you
> > know there *is* a problem with this patch.
> 
> I bet that's why the assignment to np->dev and the reference counting
> were separated in the first place :-/
> 
> Indeed, commit 30fdd8a082a00126a6feec994e43e8dc12f5bccb:
> 
> commit 30fdd8a082a00126a6feec994e43e8dc12f5bccb
> Author: Jiri Pirko 
> Date:   Tue Jul 17 05:22:35 2012 +
> 
> netpoll: move np->dev and np->dev_name init into __netpoll_setup()
> 
> Signed-off-by: Jiri Pirko 
> Signed-off-by: David S. Miller 

We probably just want to balance the setting/clearing of np->dev in
__netpoll_setup, so that any error return (that would result in a drop of the
refcount in netpoll_setup) correlates to a setting of np->dev to NULL in
__netpoll_setup. That leaves us with the problem of having to watch for future
imbalances as you mentioned previously Dave, but it seems a potential problem
tomorrow is preferable to an actual problem today.

Another option would be to move the dev_hold/put into __netpoll_setup, but doing
so would I think require some additional refactoring in netpoll_setup.  Namely
that we would still need a dev_hold/put in netpoll_setup to prevent the device
from being removed during the period where we release the rtnl lock in the if
(!netif_running(ndev)) clause. We would have to hold the device, unlock rtnl,
then put the device after re-aquiring rtnl at the end of that if block.

Neil

Re: [PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

[Neil Horman]

On Fri, Mar 25, 2016 at 03:16:36PM -0400, David Miller wrote:
> From: Bjorn Helgaas 
> Date: Fri, 25 Mar 2016 11:46:39 -0500
> 
> > You're right, there is an issue here.  I reproduced a problem with a
> > bond device.  bond_netpoll_setup() calls __netpoll_setup() directly
> > (not netpoll_setup()).  I'll debug it more; just wanted to let you
> > know there *is* a problem with this patch.
> 
> I bet that's why the assignment to np->dev and the reference counting
> were separated in the first place :-/
> 
> Indeed, commit 30fdd8a082a00126a6feec994e43e8dc12f5bccb:
> 
> commit 30fdd8a082a00126a6feec994e43e8dc12f5bccb
> Author: Jiri Pirko 
> Date:   Tue Jul 17 05:22:35 2012 +
> 
> netpoll: move np->dev and np->dev_name init into __netpoll_setup()
> 
> Signed-off-by: Jiri Pirko 
> Signed-off-by: David S. Miller 

We probably just want to balance the setting/clearing of np->dev in
__netpoll_setup, so that any error return (that would result in a drop of the
refcount in netpoll_setup) correlates to a setting of np->dev to NULL in
__netpoll_setup. That leaves us with the problem of having to watch for future
imbalances as you mentioned previously Dave, but it seems a potential problem
tomorrow is preferable to an actual problem today.

Another option would be to move the dev_hold/put into __netpoll_setup, but doing
so would I think require some additional refactoring in netpoll_setup.  Namely
that we would still need a dev_hold/put in netpoll_setup to prevent the device
from being removed during the period where we release the rtnl lock in the if
(!netif_running(ndev)) clause. We would have to hold the device, unlock rtnl,
then put the device after re-aquiring rtnl at the end of that if block.

Neil

Re: [PATCH v14 3/4] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi

[Fu Wei]

Hi Wim, Guenter:

Great thanks for reviewing and applying this patchset :-)
Now I can see almost all the patches of this patchset have been merged
into the master branch of mainline kernel.
But only this one is still out of any branch or repo. It seems that
it's applied on linux-watchdog for a while, then disappeared.


So any thing I can do for this patch? Do I need to resubmit it?
Maybe I miss it in some repo? Could you help me ?
Great thanks ! :-)

On 29 February 2016 at 16:46,   wrote:
> From: Fu Wei 
>
> This can be a example of adding SBSA Generic Watchdog device node
> into some dts files for the Soc which contains SBSA Generic Watchdog.
>
> Acked-by: Arnd Bergmann 
> Signed-off-by: Suravee Suthikulpanit 
> Signed-off-by: Fu Wei 
> Reviewed-by: Guenter Roeck 
> ---
>  arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi 
> b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> index 2874d92..0a8ca1d 100644
> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> @@ -84,6 +84,14 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> +   watchdog0: watchdog@e0bb {
> +   compatible = "arm,sbsa-gwdt";
> +   reg = <0x0 0xe0bc 0 0x1000>,
> +   <0x0 0xe0bb 0 0x1000>;
> +   interrupts = <0 337 4>;
> +   timeout-sec = <15>;
> +   };
> +
> spi0: ssp@e102 {
> status = "disabled";
> compatible = "arm,pl022", "arm,primecell";
> --
> 2.5.0
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

Re: [PATCH v14 3/4] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi

[Fu Wei]

Hi Wim, Guenter:

Great thanks for reviewing and applying this patchset :-)
Now I can see almost all the patches of this patchset have been merged
into the master branch of mainline kernel.
But only this one is still out of any branch or repo. It seems that
it's applied on linux-watchdog for a while, then disappeared.


So any thing I can do for this patch? Do I need to resubmit it?
Maybe I miss it in some repo? Could you help me ?
Great thanks ! :-)

On 29 February 2016 at 16:46,   wrote:
> From: Fu Wei 
>
> This can be a example of adding SBSA Generic Watchdog device node
> into some dts files for the Soc which contains SBSA Generic Watchdog.
>
> Acked-by: Arnd Bergmann 
> Signed-off-by: Suravee Suthikulpanit 
> Signed-off-by: Fu Wei 
> Reviewed-by: Guenter Roeck 
> ---
>  arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi 
> b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> index 2874d92..0a8ca1d 100644
> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> @@ -84,6 +84,14 @@
> clock-names = "uartclk", "apb_pclk";
> };
>
> +   watchdog0: watchdog@e0bb {
> +   compatible = "arm,sbsa-gwdt";
> +   reg = <0x0 0xe0bc 0 0x1000>,
> +   <0x0 0xe0bb 0 0x1000>;
> +   interrupts = <0 337 4>;
> +   timeout-sec = <15>;
> +   };
> +
> spi0: ssp@e102 {
> status = "disabled";
> compatible = "arm,pl022", "arm,primecell";
> --
> 2.5.0
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

[PATCH] [media] v4l: Remove unused variable

[Charles Keepax]

Signed-off-by: Charles Keepax 
---
 drivers/media/v4l2-core/v4l2-mc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Based off Linus's tree, apologies but I was having some difficulty
finding the correct tree/branch to base this on, but it is causing
a warning on Linus's tree.

Thanks,
Charles

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index 2a7b79b..2228cd3 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -34,7 +34,7 @@ int v4l2_mc_create_media_graph(struct media_device *mdev)
 {
struct media_entity *entity;
struct media_entity *if_vid = NULL, *if_aud = NULL;
-   struct media_entity *tuner = NULL, *decoder = NULL, *dtv_demod = NULL;
+   struct media_entity *tuner = NULL, *decoder = NULL;
struct media_entity *io_v4l = NULL, *io_vbi = NULL, *io_swradio = NULL;
bool is_webcam = false;
u32 flags;
-- 
2.1.4

[PATCH] [media] v4l: Remove unused variable

[Charles Keepax]

Signed-off-by: Charles Keepax 
---
 drivers/media/v4l2-core/v4l2-mc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Based off Linus's tree, apologies but I was having some difficulty
finding the correct tree/branch to base this on, but it is causing
a warning on Linus's tree.

Thanks,
Charles

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index 2a7b79b..2228cd3 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -34,7 +34,7 @@ int v4l2_mc_create_media_graph(struct media_device *mdev)
 {
struct media_entity *entity;
struct media_entity *if_vid = NULL, *if_aud = NULL;
-   struct media_entity *tuner = NULL, *decoder = NULL, *dtv_demod = NULL;
+   struct media_entity *tuner = NULL, *decoder = NULL;
struct media_entity *io_v4l = NULL, *io_vbi = NULL, *io_swradio = NULL;
bool is_webcam = false;
u32 flags;
-- 
2.1.4

Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan Khoronzhuk]

On 28.03.16 15:44, ivan.khoronzhuk wrote:

Hi Paul,

The dmi_remap() is arch dependent function and for mainline used as 
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking 
about k4.5.

k4.5 -> v4.6-rc1.


It's rather bug of dmi_remap than the patch which just use it.

The only reason why the bug wasn't found earlier it was unmapped back at init, 
but it
doesn't mean it cannot be used after init, which can lead to strange behavior 
in future.
If it should be ioremap_cache(), it's better to change dmi_remap() for your 
arch.

Oh, yes, k4.2 is using the ioremap instead of ioremap_cache().
But seems it's currently solved with:
commit ce1143aa60273220a9f89012f2aaaed04f97e9a2
"x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()"
So, probably, it should be back ported.

On 28.03.16 11:44, Paul Menzel wrote:

Dear Ivan, dear Jeann,


There is an unwanted regression due to commit d7f96f97 (firmware:
dmi_scan: add SBMIOS entry and DMI tables).

Since Linux kernel 4.2 the utility `cbmem`, used to access information
stored in memory, from the coreboot project [1] does not work anymore
on a lot of systems as reported in coreboot’s issue tracker as ticket
#33 [2].

```
Failed to mmap /dev/mem: Resource temporarily unavailable
```

Aaron Durbin analyzed on the coreboot mailing list [3]:


3) Why is that range set as uncached-minus?  Would write-back work?


Please see this thread:
http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html

The actual issue stems from
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
which maintains a persistent mapping of smbios tables. It uses
dmi_remap() which is '#define dmi_remap ioremap' which is where the
uncached-minus PAT entry comes from. It should be using the same
mechanism as  the ACPI table mappings which uses ioremap_cache().


It’d be great, if the commit could be reverted, or the code be changed
in a way that `cbmem` still works.

If I should report this issue somewhere else, please tell me too, and
I’ll do my best to follow up there.


Thanks,

Paul


[1] https://www.coreboot.org
[2] https://ticket.coreboot.org/issues/33
[3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html



--
Regards,
Ivan Khoronzhuk

Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan Khoronzhuk]

On 28.03.16 15:44, ivan.khoronzhuk wrote:

Hi Paul,

The dmi_remap() is arch dependent function and for mainline used as 
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking 
about k4.5.

k4.5 -> v4.6-rc1.


It's rather bug of dmi_remap than the patch which just use it.

The only reason why the bug wasn't found earlier it was unmapped back at init, 
but it
doesn't mean it cannot be used after init, which can lead to strange behavior 
in future.
If it should be ioremap_cache(), it's better to change dmi_remap() for your 
arch.

Oh, yes, k4.2 is using the ioremap instead of ioremap_cache().
But seems it's currently solved with:
commit ce1143aa60273220a9f89012f2aaaed04f97e9a2
"x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()"
So, probably, it should be back ported.

On 28.03.16 11:44, Paul Menzel wrote:

Dear Ivan, dear Jeann,


There is an unwanted regression due to commit d7f96f97 (firmware:
dmi_scan: add SBMIOS entry and DMI tables).

Since Linux kernel 4.2 the utility `cbmem`, used to access information
stored in memory, from the coreboot project [1] does not work anymore
on a lot of systems as reported in coreboot’s issue tracker as ticket
#33 [2].

```
Failed to mmap /dev/mem: Resource temporarily unavailable
```

Aaron Durbin analyzed on the coreboot mailing list [3]:


3) Why is that range set as uncached-minus?  Would write-back work?


Please see this thread:
http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html

The actual issue stems from
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
which maintains a persistent mapping of smbios tables. It uses
dmi_remap() which is '#define dmi_remap ioremap' which is where the
uncached-minus PAT entry comes from. It should be using the same
mechanism as  the ACPI table mappings which uses ioremap_cache().


It’d be great, if the commit could be reverted, or the code be changed
in a way that `cbmem` still works.

If I should report this issue somewhere else, please tell me too, and
I’ll do my best to follow up there.


Thanks,

Paul


[1] https://www.coreboot.org
[2] https://ticket.coreboot.org/issues/33
[3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html



--
Regards,
Ivan Khoronzhuk

Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17

[Paul E. McKenney]

On Mon, Mar 28, 2016 at 08:25:47AM +0200, Peter Zijlstra wrote:
> On Sun, Mar 27, 2016 at 02:06:41PM -0700, Paul E. McKenney wrote:
> 
> > > But, you need hotplug for this to happen, right?
> > 
> > I do, but Ross Green is seeing something that looks similar, and without
> > CPU hotplug.
> 
> Yes, but that's two differences so far, you need hotplug and he's on ARM
> (which doesn't have TIF_POLLING_NR).
> 
> So either we're all looking at the wrong thing or these really are two
> different issues.

Given that this failure has grown more probable over the past several
releases, it does seem quite likely that we have more than one bug.
Or maybe a few bugs and additional innocent-bystander commits that make
one or more of the bugs more probable.

> > > We should not be migrating towards, or waking on, CPUs no longer present
> > > in cpu_active_map, and there is a rcu/sched_sync() after clearing that
> > > bit. Furthermore, migration_call() does a sched_ttwu_pending() (waking
> > > any remaining stragglers) before we migrate all runnable tasks off the
> > > dying CPU.
> > 
> > OK, so I should instrument migration_call() if I get the repro rate up?
> 
> Can do, maybe try the below first. (yes I know how long it all takes :/)

OK, will run this today, then run calibration for last night's run this
evening.

Speaking of which, last night's run (disabling TIF_POLLING_NRFLAG)
consisted of 24 two-hour runs.  Six of them had hard hangs, and another
had a hang that eventually unhung of its own accord.  I believe that this
is significantly fewer failures than from a stock kernel, but I could
be wrong, and it will take some serious testing to give statistical
confidence for whatever conclusion is correct.

> > > The other interesting case would be resched_cpu(), which uses
> > > set_nr_and_not_polling() to kick a remote cpu to call schedule(). It
> > > atomically sets TIF_NEED_RESCHED and returns if TIF_POLLING_NRFLAG was
> > > not set. If indeed not, it will send an IPI.
> > > 
> > > This assumes the idle 'exit' path will do the same as the IPI does; and
> > > if you look at cpu_idle_loop() it does indeed do both
> > > preempt_fold_need_resched() and sched_ttwu_pending().
> > > 
> > > Note that one cannot rely on irq_enter()/irq_exit() being called for the
> > > scheduler IPI.
> > 
> > OK, thank you for the info!  Any specific debug actions?
> 
> Dunno, something like the below should bring visibility into the
> (lockless) wake_list thingy.
> 
> So these trace_printk()s should happen between trace_sched_waking() and
> trace_sched_wakeup() (I've not fully read the thread, but ISTR you had
> some traces with these here thingies on).
> 
> ---
>  arch/x86/include/asm/bitops.h | 6 --
>  kernel/sched/core.c   | 9 +
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
> index 7766d1cf096e..5345784d5e41 100644
> --- a/arch/x86/include/asm/bitops.h
> +++ b/arch/x86/include/asm/bitops.h
> @@ -112,11 +112,13 @@ clear_bit(long nr, volatile unsigned long *addr)
>   if (IS_IMMEDIATE(nr)) {
>   asm volatile(LOCK_PREFIX "andb %1,%0"
>   : CONST_MASK_ADDR(nr, addr)
> - : "iq" ((u8)~CONST_MASK(nr)));
> + : "iq" ((u8)~CONST_MASK(nr))
> + : "memory");
>   } else {
>   asm volatile(LOCK_PREFIX "btr %1,%0"
>   : BITOP_ADDR(addr)
> - : "Ir" (nr));
> + : "Ir" (nr)
> + : "memory");
>   }
>  }

Is the above addition of "memory" strictly for the debug below, or is
it also a potential fix?

Starting it up regardless, but figured I should ask!

Thanx, Paul

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 0b21e7a724e1..b446f73c530d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1669,6 +1669,7 @@ void sched_ttwu_pending(void)
>   while (llist) {
>   p = llist_entry(llist, struct task_struct, wake_entry);
>   llist = llist_next(llist);
> + trace_printk("waking %d\n", p->pid);
>   ttwu_do_activate(rq, p, 0);
>   }
> 
> @@ -1719,6 +1720,7 @@ static void ttwu_queue_remote(struct task_struct *p, 
> int cpu)
>   struct rq *rq = cpu_rq(cpu);
> 
>   if (llist_add(>wake_entry, _rq(cpu)->wake_list)) {
> + trace_printk("queued %d for waking on %d\n", p->pid, cpu);
>   if (!set_nr_if_polling(rq->idle))
>   smp_send_reschedule(cpu);
>   else
> @@ -5397,10 +5399,17 @@ migration_call(struct notifier_block *nfb, unsigned 
> long action, void *hcpu)
>   migrate_tasks(rq);
>   BUG_ON(rq->nr_running != 1); /* the migration thread */
>   raw_spin_unlock_irqrestore(>lock, flags);
> +
> + /* really bad m'kay */
> + 

Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17

[Paul E. McKenney]

On Mon, Mar 28, 2016 at 08:25:47AM +0200, Peter Zijlstra wrote:
> On Sun, Mar 27, 2016 at 02:06:41PM -0700, Paul E. McKenney wrote:
> 
> > > But, you need hotplug for this to happen, right?
> > 
> > I do, but Ross Green is seeing something that looks similar, and without
> > CPU hotplug.
> 
> Yes, but that's two differences so far, you need hotplug and he's on ARM
> (which doesn't have TIF_POLLING_NR).
> 
> So either we're all looking at the wrong thing or these really are two
> different issues.

Given that this failure has grown more probable over the past several
releases, it does seem quite likely that we have more than one bug.
Or maybe a few bugs and additional innocent-bystander commits that make
one or more of the bugs more probable.

> > > We should not be migrating towards, or waking on, CPUs no longer present
> > > in cpu_active_map, and there is a rcu/sched_sync() after clearing that
> > > bit. Furthermore, migration_call() does a sched_ttwu_pending() (waking
> > > any remaining stragglers) before we migrate all runnable tasks off the
> > > dying CPU.
> > 
> > OK, so I should instrument migration_call() if I get the repro rate up?
> 
> Can do, maybe try the below first. (yes I know how long it all takes :/)

OK, will run this today, then run calibration for last night's run this
evening.

Speaking of which, last night's run (disabling TIF_POLLING_NRFLAG)
consisted of 24 two-hour runs.  Six of them had hard hangs, and another
had a hang that eventually unhung of its own accord.  I believe that this
is significantly fewer failures than from a stock kernel, but I could
be wrong, and it will take some serious testing to give statistical
confidence for whatever conclusion is correct.

> > > The other interesting case would be resched_cpu(), which uses
> > > set_nr_and_not_polling() to kick a remote cpu to call schedule(). It
> > > atomically sets TIF_NEED_RESCHED and returns if TIF_POLLING_NRFLAG was
> > > not set. If indeed not, it will send an IPI.
> > > 
> > > This assumes the idle 'exit' path will do the same as the IPI does; and
> > > if you look at cpu_idle_loop() it does indeed do both
> > > preempt_fold_need_resched() and sched_ttwu_pending().
> > > 
> > > Note that one cannot rely on irq_enter()/irq_exit() being called for the
> > > scheduler IPI.
> > 
> > OK, thank you for the info!  Any specific debug actions?
> 
> Dunno, something like the below should bring visibility into the
> (lockless) wake_list thingy.
> 
> So these trace_printk()s should happen between trace_sched_waking() and
> trace_sched_wakeup() (I've not fully read the thread, but ISTR you had
> some traces with these here thingies on).
> 
> ---
>  arch/x86/include/asm/bitops.h | 6 --
>  kernel/sched/core.c   | 9 +
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
> index 7766d1cf096e..5345784d5e41 100644
> --- a/arch/x86/include/asm/bitops.h
> +++ b/arch/x86/include/asm/bitops.h
> @@ -112,11 +112,13 @@ clear_bit(long nr, volatile unsigned long *addr)
>   if (IS_IMMEDIATE(nr)) {
>   asm volatile(LOCK_PREFIX "andb %1,%0"
>   : CONST_MASK_ADDR(nr, addr)
> - : "iq" ((u8)~CONST_MASK(nr)));
> + : "iq" ((u8)~CONST_MASK(nr))
> + : "memory");
>   } else {
>   asm volatile(LOCK_PREFIX "btr %1,%0"
>   : BITOP_ADDR(addr)
> - : "Ir" (nr));
> + : "Ir" (nr)
> + : "memory");
>   }
>  }

Is the above addition of "memory" strictly for the debug below, or is
it also a potential fix?

Starting it up regardless, but figured I should ask!

Thanx, Paul

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 0b21e7a724e1..b446f73c530d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1669,6 +1669,7 @@ void sched_ttwu_pending(void)
>   while (llist) {
>   p = llist_entry(llist, struct task_struct, wake_entry);
>   llist = llist_next(llist);
> + trace_printk("waking %d\n", p->pid);
>   ttwu_do_activate(rq, p, 0);
>   }
> 
> @@ -1719,6 +1720,7 @@ static void ttwu_queue_remote(struct task_struct *p, 
> int cpu)
>   struct rq *rq = cpu_rq(cpu);
> 
>   if (llist_add(>wake_entry, _rq(cpu)->wake_list)) {
> + trace_printk("queued %d for waking on %d\n", p->pid, cpu);
>   if (!set_nr_if_polling(rq->idle))
>   smp_send_reschedule(cpu);
>   else
> @@ -5397,10 +5399,17 @@ migration_call(struct notifier_block *nfb, unsigned 
> long action, void *hcpu)
>   migrate_tasks(rq);
>   BUG_ON(rq->nr_running != 1); /* the migration thread */
>   raw_spin_unlock_irqrestore(>lock, flags);
> +
> + /* really bad m'kay */
> + 

Re: [PATCH v6 0/3] Add more clock compatible features and support the RK3399 clock

[Heiko Stübner]

Am Montag, 28. März 2016, 17:51:34 schrieb Xing Zheng:
>   The patch series add support more mux parameters and multiple
> clock providers for the rockchip features of the clock framework,
> and support the clock controller for the RK3399.

applied all 3 for 4.7 with one change:

I've dropped the grf paragraph from the binding doc (as it is not used 
anymore) and also dropped the gmac_phy_rx_clk input clock.

We can add these back once they are getting used in the future.


Heiko

Re: [PATCH v6 0/3] Add more clock compatible features and support the RK3399 clock

[Heiko Stübner]

Am Montag, 28. März 2016, 17:51:34 schrieb Xing Zheng:
>   The patch series add support more mux parameters and multiple
> clock providers for the rockchip features of the clock framework,
> and support the clock controller for the RK3399.

applied all 3 for 4.7 with one change:

I've dropped the grf paragraph from the binding doc (as it is not used 
anymore) and also dropped the gmac_phy_rx_clk input clock.

We can add these back once they are getting used in the future.


Heiko

RE: [PATCH V7 5/6] dts: msm8974: Add blsp2_bam dma node

[Sricharan]

> On Fri, Mar 25, 2016 at 04:17:30PM -0700, Bjorn Andersson wrote:
> > On Tue, Jan 19, 2016 at 2:02 AM, Sricharan R 
> wrote:
> > > Signed-off-by: Sricharan R 
> > > Reviewed-by: Andy Gross 
> 
> 
> 
> > > +   blsp2_dma: dma-controller@f9944000 {
> > > +   compatible = "qcom,bam-v1.4.0";
> > > +   reg = <0xf9944000 0x19000>;
> > > +   interrupts = ;
> > > +   clocks = < GCC_BLSP2_AHB_CLK>;
> > > +   clock-names = "bam_clk";
> > > +   #dma-cells = <1>;
> > > +   qcom,ee = <0>;
> >
> > Without "qcom,bam_ctrl_remote;" and
> > https://patchwork.kernel.org/patch/8639181/ the Xperia Honami board
> > fails to boot with this patch included.
> 
> Ouch.  At least one set of pipes must be used by some other processor and
> TZ has locked down that BLSP.

 Hmm, this was not the case atleast on the apq8074DB board that I tested
this on.

Regards,
 Sricharan

RE: [PATCH V7 5/6] dts: msm8974: Add blsp2_bam dma node

[Sricharan]

> On Fri, Mar 25, 2016 at 04:17:30PM -0700, Bjorn Andersson wrote:
> > On Tue, Jan 19, 2016 at 2:02 AM, Sricharan R 
> wrote:
> > > Signed-off-by: Sricharan R 
> > > Reviewed-by: Andy Gross 
> 
> 
> 
> > > +   blsp2_dma: dma-controller@f9944000 {
> > > +   compatible = "qcom,bam-v1.4.0";
> > > +   reg = <0xf9944000 0x19000>;
> > > +   interrupts = ;
> > > +   clocks = < GCC_BLSP2_AHB_CLK>;
> > > +   clock-names = "bam_clk";
> > > +   #dma-cells = <1>;
> > > +   qcom,ee = <0>;
> >
> > Without "qcom,bam_ctrl_remote;" and
> > https://patchwork.kernel.org/patch/8639181/ the Xperia Honami board
> > fails to boot with this patch included.
> 
> Ouch.  At least one set of pipes must be used by some other processor and
> TZ has locked down that BLSP.

 Hmm, this was not the case atleast on the apq8074DB board that I tested
this on.

Regards,
 Sricharan

Re: ARC dw-mshc binding compat string

[Marek Vasut]

On 03/28/2016 12:34 PM, Jaehoon Chung wrote:
> Hi,

Hi,

[...]

 That said, I would rather prefer to see "snps,dw-mshc" prefix on 
 description
 of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
 seems
 to be redundant.
> 
> Yes..it's redundant..i should be combined to "snps,dw-mshc".

Should the compat string be
  compatible = "altr,socfpga-dw-mshc", "snps,dw-mshc";
or just
  compatible = "snps,dw-mshc";
?

I am under the impression that a soc-specific identifier in addition to
a generic one (used by the driver compat table) is a good idea, because
it can help discerning the IP block from a generic one if needed at some
future point in time. It will also not break the DT for systems
which may depend on the non-generic compat, like *BSDs and such.

What do you think ? (btw this is very much my question in this thread)

>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>> one needs it as well, but most likely yes.
>>>
>>> I wonder if that bit is needed on some particular version of the DWMMC
>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>> binding ? Or should we use DT property to discern the need for this bit 
>>> ?
>>>
>> That's the most common way to take into account peculiarities, add
>> a property and handle it from the driver.
> And by "that" you mean which of those two I listed , the
> "snps,dw-mshc-vN" or adding new DT prop ?
>
 I meant to add a new property, not a new compatible, but that's just
 my experience.

 Let me say it __might__ happen that a particular change you need is
 specific to a particular version of the DWMMC IP (query Synopsys
 by the way), but more probably it might be e.g. the same IP version with
 a different reduced or extended configuration or a minor fix/improvement
 to the IP block without resulting version number bump.

 For example I don't remember that errata fixes in IP blocks result in
 a new compatible, instead there are quite common optional "quirk"
 properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>
>>> Alexey, can you tell us if the requirement for setting
>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>> disappeared with some revision OR if this is some configuration
>>> option of the core during synthesis ?
>>
>> Sorry for not following that discussion during my weekend but I'll try
>> to address all questions now.
> 
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the 
> below things.
> 
> If Card is SDR50/SDR104/DDR50 mode..
>   1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 0,
>   2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 1,
> If Card is SDR12/SDR25 mode, then this bit is set to 1.
> 
> We need to check phase shift scheme..but as i knew, each SoC have been 
> implemented differently for phase shift.
> (Phase shift have dependency to SoC.)
> 
> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
> (It described whether IP have hold register or not)
> 
> I didn't read this thread entirely.
> I'm not sure what you have discussed..but my understanding is right..i 
> recommend to use "snps,dw-mshc" for ARC compat string.
> Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the 
> basic dw-mmc controller functionality.
> 
> After read this thread entirely, i will check more detailed what you 
> discussed.
> If i missed something, let me know, plz.

Thanks for the clarification, linux-next indeed contains changes which
make snps,dw-mshc and altr,socfpga-dw-mshc equal.

> Best Regards,
> Jaehoon Chung
> 
>>
>> DW Mobile Storage databook says:
>> ->8---
>> To meet the relatively high Input Hold Time requirement for SDR12, SDR25,
>> and other MMC speed modes, you should program bit[29]use_hold_Reg of the
>> CMD register to 1'b1.
>> ->8---
>>
>> So I'd say this specific setting has nothing to do with a particular IP block
>> but instead it is related to card's mode of operation. More precisely bus 
>> clock.
>> SDR12 stands for 12.5 MByte/s, SDR25 stands for 25 MByte/s. I.e. we probably 
>> need
>> so set that bit just for certain cases and regardless board that uses DW MMC.
>>
>> I'm adding DW MMC maintainer as well as linux-mmc mailing list so people who
>> understands that stuff better may comment here 

Re: ARC dw-mshc binding compat string

[Marek Vasut]

On 03/28/2016 02:43 PM, Rob Herring wrote:
> On Mon, Mar 28, 2016 at 5:34 AM, Jaehoon Chung  wrote:
>> Hi,
>>
>> On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
>>> Hi Marek, Vladimir,
>>>
>>> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
 On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 21:52, Marek Vasut wrote:
>>
>> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 20:10, Marek Vasut wrote:

 On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>
> Hi Marek,
>
> On 26.03.2016 19:30, Marek Vasut wrote:
>>
>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 12:14, Marek Vasut wrote:

 Hi!

 I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," 
 prefix in
 the DT compatible string:

 mmc@0x15000 {
 compatible = "altr,socfpga-dw-mshc";
 reg = < 0x15000 0x400 >;
 num-slots = < 1 >;
 fifo-depth = < 16 >;
 card-detect-delay = < 200 >;
 clocks = <>, <>;
 clock-names = "biu", "ciu";
 interrupts = < 7 >;
 bus-width = < 4 >;
 };

 I don't think this is OK, since ARC is unrelated to Altera, which 
 is
 what the "altr," prefix stands for. I think the socfpga-dw-mshc 
 shim
 should be extended with another compatibility string, something 
 like
 "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
 accordingly. What do you think ?

>>> There is "snps,dw-mshc" described in
>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and 
>>> supported by
>>> dw_mmc host controller driver.
>> Thanks, that's even better.
>>
>> btw what do you think of using altr, prefix on non-altera system, 
>> that
>> doesn't seem ok, right ?
> according to ePAPR the prefix should represent a device (IP block here
> I believe) manufacturer, so it should be okay to use "altr" prefix on
> non-Altera system, if Altera provides  another hardware vendor with
> some own IP block.
 In this case, it's Synopsys who provides the SD/MMC/MS core to other
 chip makers (Altera etc).
>>> Correct.
>>>

>
> That said, I would rather prefer to see "snps,dw-mshc" prefix on 
> description
> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
> seems
> to be redundant.
>>
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
> 
> socfpga is done correctly, IMO.
> 
 According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
 "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
 "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
 while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
 one needs it as well, but most likely yes.

 I wonder if that bit is needed on some particular version of the DWMMC
 core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
 binding ? Or should we use DT property to discern the need for this 
 bit ?

>>> That's the most common way to take into account peculiarities, add
>>> a property and handle it from the driver.
>> And by "that" you mean which of those two I listed , the
>> "snps,dw-mshc-vN" or adding new DT prop ?
>>
> I meant to add a new property, not a new compatible, but that's just
> my experience.
>
> Let me say it __might__ happen that a particular change you need is
> specific to a particular version of the DWMMC IP (query Synopsys
> by the way), but more probably it might be e.g. the same IP version with
> a different reduced or extended configuration or a minor fix/improvement
> to the IP block without resulting version number bump.
>
> For example I don't remember that errata fixes in IP blocks result in
> a new compatible, instead there are quite common optional "quirk"
> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
 Right, this very much matches how I see it as well. Thanks for confirming.

 Alexey, can you tell us if the requirement for setting
 SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
 disappeared with some revision OR if this is some configuration
 option of the core during synthesis ?
>>>
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions 

Re: ARC dw-mshc binding compat string

[Marek Vasut]

On 03/28/2016 12:34 PM, Jaehoon Chung wrote:
> Hi,

Hi,

[...]

 That said, I would rather prefer to see "snps,dw-mshc" prefix on 
 description
 of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
 seems
 to be redundant.
> 
> Yes..it's redundant..i should be combined to "snps,dw-mshc".

Should the compat string be
  compatible = "altr,socfpga-dw-mshc", "snps,dw-mshc";
or just
  compatible = "snps,dw-mshc";
?

I am under the impression that a soc-specific identifier in addition to
a generic one (used by the driver compat table) is a good idea, because
it can help discerning the IP block from a generic one if needed at some
future point in time. It will also not break the DT for systems
which may depend on the non-generic compat, like *BSDs and such.

What do you think ? (btw this is very much my question in this thread)

>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>> one needs it as well, but most likely yes.
>>>
>>> I wonder if that bit is needed on some particular version of the DWMMC
>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>> binding ? Or should we use DT property to discern the need for this bit 
>>> ?
>>>
>> That's the most common way to take into account peculiarities, add
>> a property and handle it from the driver.
> And by "that" you mean which of those two I listed , the
> "snps,dw-mshc-vN" or adding new DT prop ?
>
 I meant to add a new property, not a new compatible, but that's just
 my experience.

 Let me say it __might__ happen that a particular change you need is
 specific to a particular version of the DWMMC IP (query Synopsys
 by the way), but more probably it might be e.g. the same IP version with
 a different reduced or extended configuration or a minor fix/improvement
 to the IP block without resulting version number bump.

 For example I don't remember that errata fixes in IP blocks result in
 a new compatible, instead there are quite common optional "quirk"
 properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>
>>> Alexey, can you tell us if the requirement for setting
>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>> disappeared with some revision OR if this is some configuration
>>> option of the core during synthesis ?
>>
>> Sorry for not following that discussion during my weekend but I'll try
>> to address all questions now.
> 
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the 
> below things.
> 
> If Card is SDR50/SDR104/DDR50 mode..
>   1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 0,
>   2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 1,
> If Card is SDR12/SDR25 mode, then this bit is set to 1.
> 
> We need to check phase shift scheme..but as i knew, each SoC have been 
> implemented differently for phase shift.
> (Phase shift have dependency to SoC.)
> 
> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
> (It described whether IP have hold register or not)
> 
> I didn't read this thread entirely.
> I'm not sure what you have discussed..but my understanding is right..i 
> recommend to use "snps,dw-mshc" for ARC compat string.
> Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the 
> basic dw-mmc controller functionality.
> 
> After read this thread entirely, i will check more detailed what you 
> discussed.
> If i missed something, let me know, plz.

Thanks for the clarification, linux-next indeed contains changes which
make snps,dw-mshc and altr,socfpga-dw-mshc equal.

> Best Regards,
> Jaehoon Chung
> 
>>
>> DW Mobile Storage databook says:
>> ->8---
>> To meet the relatively high Input Hold Time requirement for SDR12, SDR25,
>> and other MMC speed modes, you should program bit[29]use_hold_Reg of the
>> CMD register to 1'b1.
>> ->8---
>>
>> So I'd say this specific setting has nothing to do with a particular IP block
>> but instead it is related to card's mode of operation. More precisely bus 
>> clock.
>> SDR12 stands for 12.5 MByte/s, SDR25 stands for 25 MByte/s. I.e. we probably 
>> need
>> so set that bit just for certain cases and regardless board that uses DW MMC.
>>
>> I'm adding DW MMC maintainer as well as linux-mmc mailing list so people who
>> understands that stuff better may comment here 

Re: ARC dw-mshc binding compat string

[Marek Vasut]

On 03/28/2016 02:43 PM, Rob Herring wrote:
> On Mon, Mar 28, 2016 at 5:34 AM, Jaehoon Chung  wrote:
>> Hi,
>>
>> On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
>>> Hi Marek, Vladimir,
>>>
>>> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
 On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 21:52, Marek Vasut wrote:
>>
>> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 20:10, Marek Vasut wrote:

 On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>
> Hi Marek,
>
> On 26.03.2016 19:30, Marek Vasut wrote:
>>
>> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 12:14, Marek Vasut wrote:

 Hi!

 I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," 
 prefix in
 the DT compatible string:

 mmc@0x15000 {
 compatible = "altr,socfpga-dw-mshc";
 reg = < 0x15000 0x400 >;
 num-slots = < 1 >;
 fifo-depth = < 16 >;
 card-detect-delay = < 200 >;
 clocks = <>, <>;
 clock-names = "biu", "ciu";
 interrupts = < 7 >;
 bus-width = < 4 >;
 };

 I don't think this is OK, since ARC is unrelated to Altera, which 
 is
 what the "altr," prefix stands for. I think the socfpga-dw-mshc 
 shim
 should be extended with another compatibility string, something 
 like
 "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
 accordingly. What do you think ?

>>> There is "snps,dw-mshc" described in
>>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and 
>>> supported by
>>> dw_mmc host controller driver.
>> Thanks, that's even better.
>>
>> btw what do you think of using altr, prefix on non-altera system, 
>> that
>> doesn't seem ok, right ?
> according to ePAPR the prefix should represent a device (IP block here
> I believe) manufacturer, so it should be okay to use "altr" prefix on
> non-Altera system, if Altera provides  another hardware vendor with
> some own IP block.
 In this case, it's Synopsys who provides the SD/MMC/MS core to other
 chip makers (Altera etc).
>>> Correct.
>>>

>
> That said, I would rather prefer to see "snps,dw-mshc" prefix on 
> description
> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
> seems
> to be redundant.
>>
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
> 
> socfpga is done correctly, IMO.
> 
 According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
 "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
 "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
 while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
 one needs it as well, but most likely yes.

 I wonder if that bit is needed on some particular version of the DWMMC
 core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
 binding ? Or should we use DT property to discern the need for this 
 bit ?

>>> That's the most common way to take into account peculiarities, add
>>> a property and handle it from the driver.
>> And by "that" you mean which of those two I listed , the
>> "snps,dw-mshc-vN" or adding new DT prop ?
>>
> I meant to add a new property, not a new compatible, but that's just
> my experience.
>
> Let me say it __might__ happen that a particular change you need is
> specific to a particular version of the DWMMC IP (query Synopsys
> by the way), but more probably it might be e.g. the same IP version with
> a different reduced or extended configuration or a minor fix/improvement
> to the IP block without resulting version number bump.
>
> For example I don't remember that errata fixes in IP blocks result in
> a new compatible, instead there are quite common optional "quirk"
> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
 Right, this very much matches how I see it as well. Thanks for confirming.

 Alexey, can you tell us if the requirement for setting
 SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
 disappeared with some revision OR if this is some configuration
 option of the core during synthesis ?
>>>
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions now.
>>
>> 

Re: [RFC PATCH v1 0/9] Tests for sync infrastructure

[Emilio López]

Hi,

I somehow missed these emails back in the day, sorry for the delay in 
replying.


El 09/03/16 a las 13:13, Shuah Khan escribió:

On 03/09/2016 08:28 AM, Emilio López wrote:

Hello everyone,

This is a series of tests to exercise the sync kernel infrastructure. It is
meant to be a test suite for the work Gustavo has been doing to destage it,
see [0] for his latest series to date.

These tests were originally part of a battery of tests shipping with
Android's libsync that were rewritten to use the new userspace interfaces.

As usual, all comments are welcome.

Cheers!
Emilio

[0] https://lists.freedesktop.org/archives/dri-devel/2016-March/102204.html


Good to see this suite added to Kselftest. Thanks for
being thorough and including .gitignore.

Are there any destructive and/or longer time tests
in this suite. If so could you please make them
optional to run. Please see selftests/timers as an
example for excluding.


As far as I know they shouldn't destroy anything. The full sync suite 
runs in under 5 seconds on my virtualized setup; we can make the stress 
tests optional if that's too long a time, what do you think?.


Cheers,
Emilio

Re: [RFC PATCH v1 0/9] Tests for sync infrastructure

[Emilio López]

Hi,

I somehow missed these emails back in the day, sorry for the delay in 
replying.


El 09/03/16 a las 13:13, Shuah Khan escribió:

On 03/09/2016 08:28 AM, Emilio López wrote:

Hello everyone,

This is a series of tests to exercise the sync kernel infrastructure. It is
meant to be a test suite for the work Gustavo has been doing to destage it,
see [0] for his latest series to date.

These tests were originally part of a battery of tests shipping with
Android's libsync that were rewritten to use the new userspace interfaces.

As usual, all comments are welcome.

Cheers!
Emilio

[0] https://lists.freedesktop.org/archives/dri-devel/2016-March/102204.html


Good to see this suite added to Kselftest. Thanks for
being thorough and including .gitignore.

Are there any destructive and/or longer time tests
in this suite. If so could you please make them
optional to run. Please see selftests/timers as an
example for excluding.


As far as I know they shouldn't destroy anything. The full sync suite 
runs in under 5 seconds on my virtualized setup; we can make the stress 
tests optional if that's too long a time, what do you think?.


Cheers,
Emilio

Re: [RFC PATCH v1 9/9] selftest: sync: disable tests that rely on not yet defined behaviour

[Emilio López]

El 09/03/16 a las 13:14, Shuah Khan escribió:

On 03/09/2016 08:29 AM, Emilio López wrote:

One of the tests rely on a behaviour only observed on the driver currently
in use in Android. Disable it here until the behaviour is implemented
or it is decided it should not be implemented on the driver in mainline.

Signed-off-by: Emilio López 

---

  tools/testing/selftests/sync/sync_test.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/tools/testing/selftests/sync/sync_test.c 
b/tools/testing/selftests/sync/sync_test.c
index c3e4c01..3f484318 100644
--- a/tools/testing/selftests/sync/sync_test.c
+++ b/tools/testing/selftests/sync/sync_test.c
@@ -66,7 +66,14 @@ int main(void)
err += RUN_TEST(test_fence_one_timeline_merge);
err += RUN_TEST(test_fence_merge_same_fence);
err += RUN_TEST(test_fence_multi_timeline_wait);
+#if 0
+   /* The following test has been disabled due to differences
+* between the upstream and Android kernel drivers. The behaviour
+* that should occur when destroying a timeline with active fences
+* has not been defined yet.
+*/
err += RUN_TEST(test_fence_wait_on_destroyed_timeline);
+#endif


It would be useful to have a real define here that can be
enabled later easily instead of if 0.


Ok, sounds good.

Thanks!
Emilio

Re: [RFC PATCH v1 9/9] selftest: sync: disable tests that rely on not yet defined behaviour

[Emilio López]

El 09/03/16 a las 13:14, Shuah Khan escribió:

On 03/09/2016 08:29 AM, Emilio López wrote:

One of the tests rely on a behaviour only observed on the driver currently
in use in Android. Disable it here until the behaviour is implemented
or it is decided it should not be implemented on the driver in mainline.

Signed-off-by: Emilio López 

---

  tools/testing/selftests/sync/sync_test.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/tools/testing/selftests/sync/sync_test.c 
b/tools/testing/selftests/sync/sync_test.c
index c3e4c01..3f484318 100644
--- a/tools/testing/selftests/sync/sync_test.c
+++ b/tools/testing/selftests/sync/sync_test.c
@@ -66,7 +66,14 @@ int main(void)
err += RUN_TEST(test_fence_one_timeline_merge);
err += RUN_TEST(test_fence_merge_same_fence);
err += RUN_TEST(test_fence_multi_timeline_wait);
+#if 0
+   /* The following test has been disabled due to differences
+* between the upstream and Android kernel drivers. The behaviour
+* that should occur when destroying a timeline with active fences
+* has not been defined yet.
+*/
err += RUN_TEST(test_fence_wait_on_destroyed_timeline);
+#endif


It would be useful to have a real define here that can be
enabled later easily instead of if 0.


Ok, sounds good.

Thanks!
Emilio

Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework

[Emilio López]

Hi,

El 28/03/16 a las 08:56, Emil Velikov escribió:

Hi Emilio,

On 9 March 2016 at 15:28, Emilio López  wrote:

These tests are based on the libsync test suite from Android.
This commit lays the ground for future tests, as well as includes
tests for a variety of basic allocation commands.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Emilio López 
---




  tools/testing/selftests/sync/sync.h   | 119 ++

Admittedly I know nothing about the kernel selftests although copying
the UAPI header, seems to defeat the purpose of this exercise.
Shouldn't one reuse the existing header ? It would even cause issues
as the interface gets updated (iirc Gustavo changed the ioctl numbers
and/or header name with latter series).


The problem is that one cannot use the system header without having 
built and installed the kernel first, which is rather problematic for 
eg. crosscompiling or virtualization. I discussed this with Gustavo and 
we agreed that the best way forward would be to copy the interfaces, as 
suggested by kernelnewbies' wiki[0]:


"""
The correct way to address this problem is to isolate the specific 
interfaces that you need, e.g. a single header file that is patched in a 
new kernel providing the ioctl numbers for a character device used by 
your program. In your own program, add a copy of that source file, with 
a notice that it should be kept in sync with new kernel versions.

"""

Cheers,
Emilio

[0] http://kernelnewbies.org/KernelHeaders

Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework

[Emilio López]

Hi,

El 28/03/16 a las 08:56, Emil Velikov escribió:

Hi Emilio,

On 9 March 2016 at 15:28, Emilio López  wrote:

These tests are based on the libsync test suite from Android.
This commit lays the ground for future tests, as well as includes
tests for a variety of basic allocation commands.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Emilio López 
---




  tools/testing/selftests/sync/sync.h   | 119 ++

Admittedly I know nothing about the kernel selftests although copying
the UAPI header, seems to defeat the purpose of this exercise.
Shouldn't one reuse the existing header ? It would even cause issues
as the interface gets updated (iirc Gustavo changed the ioctl numbers
and/or header name with latter series).


The problem is that one cannot use the system header without having 
built and installed the kernel first, which is rather problematic for 
eg. crosscompiling or virtualization. I discussed this with Gustavo and 
we agreed that the best way forward would be to copy the interfaces, as 
suggested by kernelnewbies' wiki[0]:


"""
The correct way to address this problem is to isolate the specific 
interfaces that you need, e.g. a single header file that is patched in a 
new kernel providing the ioctl numbers for a character device used by 
your program. In your own program, add a copy of that source file, with 
a notice that it should be kept in sync with new kernel versions.

"""

Cheers,
Emilio

[0] http://kernelnewbies.org/KernelHeaders

[PATCH] net: macb: Only call GPIO functions if there is a valid GPIO

[Charles Keepax]

GPIOlib will print warning messages if we call GPIO functions without a
valid GPIO. Change the code to avoid doing so.

Signed-off-by: Charles Keepax 
---
 drivers/net/ethernet/cadence/macb.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index 6619178..71bb42e 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2957,9 +2957,10 @@ static int macb_probe(struct platform_device *pdev)
phy_node =  of_get_next_available_child(np, NULL);
if (phy_node) {
int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
-   if (gpio_is_valid(gpio))
+   if (gpio_is_valid(gpio)) {
bp->reset_gpio = gpio_to_desc(gpio);
-   gpiod_direction_output(bp->reset_gpio, 1);
+   gpiod_direction_output(bp->reset_gpio, 1);
+   }
}
of_node_put(phy_node);
 
@@ -3029,7 +3030,8 @@ static int macb_remove(struct platform_device *pdev)
mdiobus_free(bp->mii_bus);
 
/* Shutdown the PHY if there is a GPIO reset */
-   gpiod_set_value(bp->reset_gpio, 0);
+   if (bp->reset_gpio)
+   gpiod_set_value(bp->reset_gpio, 0);
 
unregister_netdev(dev);
clk_disable_unprepare(bp->tx_clk);
-- 
2.1.4

[PATCH] net: macb: Only call GPIO functions if there is a valid GPIO

[Charles Keepax]

GPIOlib will print warning messages if we call GPIO functions without a
valid GPIO. Change the code to avoid doing so.

Signed-off-by: Charles Keepax 
---
 drivers/net/ethernet/cadence/macb.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index 6619178..71bb42e 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2957,9 +2957,10 @@ static int macb_probe(struct platform_device *pdev)
phy_node =  of_get_next_available_child(np, NULL);
if (phy_node) {
int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
-   if (gpio_is_valid(gpio))
+   if (gpio_is_valid(gpio)) {
bp->reset_gpio = gpio_to_desc(gpio);
-   gpiod_direction_output(bp->reset_gpio, 1);
+   gpiod_direction_output(bp->reset_gpio, 1);
+   }
}
of_node_put(phy_node);
 
@@ -3029,7 +3030,8 @@ static int macb_remove(struct platform_device *pdev)
mdiobus_free(bp->mii_bus);
 
/* Shutdown the PHY if there is a GPIO reset */
-   gpiod_set_value(bp->reset_gpio, 0);
+   if (bp->reset_gpio)
+   gpiod_set_value(bp->reset_gpio, 0);
 
unregister_netdev(dev);
clk_disable_unprepare(bp->tx_clk);
-- 
2.1.4

Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables

[ivan.khoronzhuk]

Hi Paul,

The dmi_remap() is arch dependent function and for mainline used as 
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking 
about k4.5.
It's rather bug of dmi_remap than the patch which just use it.

The only reason why the bug wasn't found earlier it was unmapped back at init, 
but it
doesn't mean it cannot be used after init, which can lead to strange behavior 
in future.
If it should be ioremap_cache(), it's better to change dmi_remap() for your 
arch.

Oh, yes, k4.2 is using the ioremap instead of ioremap_cache().
But seems it's currently solved with:
commit ce1143aa60273220a9f89012f2aaaed04f97e9a2
"x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()"
So, probably, it should be back ported.

On 28.03.16 11:44, Paul Menzel wrote:

Dear Ivan, dear Jeann,


There is an unwanted regression due to commit d7f96f97 (firmware:
dmi_scan: add SBMIOS entry and DMI tables).

Since Linux kernel 4.2 the utility `cbmem`, used to access information
stored in memory, from the coreboot project [1] does not work anymore
on a lot of systems as reported in coreboot’s issue tracker as ticket
#33 [2].

```
Failed to mmap /dev/mem: Resource temporarily unavailable
```

Aaron Durbin analyzed on the coreboot mailing list [3]:


3) Why is that range set as uncached-minus?  Would write-back work?


Please see this thread:
http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html

The actual issue stems from
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
which maintains a persistent mapping of smbios tables. It uses
dmi_remap() which is '#define dmi_remap ioremap' which is where the
uncached-minus PAT entry comes from. It should be using the same
mechanism as  the ACPI table mappings which uses ioremap_cache().


It’d be great, if the commit could be reverted, or the code be changed
in a way that `cbmem` still works.

If I should report this issue somewhere else, please tell me too, and
I’ll do my best to follow up there.


Thanks,

Paul


[1] https://www.coreboot.org
[2] https://ticket.coreboot.org/issues/33
[3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html

Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables

[ivan.khoronzhuk]

Hi Paul,

The dmi_remap() is arch dependent function and for mainline used as 
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking 
about k4.5.
It's rather bug of dmi_remap than the patch which just use it.

The only reason why the bug wasn't found earlier it was unmapped back at init, 
but it
doesn't mean it cannot be used after init, which can lead to strange behavior 
in future.
If it should be ioremap_cache(), it's better to change dmi_remap() for your 
arch.

Oh, yes, k4.2 is using the ioremap instead of ioremap_cache().
But seems it's currently solved with:
commit ce1143aa60273220a9f89012f2aaaed04f97e9a2
"x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()"
So, probably, it should be back ported.

On 28.03.16 11:44, Paul Menzel wrote:

Dear Ivan, dear Jeann,


There is an unwanted regression due to commit d7f96f97 (firmware:
dmi_scan: add SBMIOS entry and DMI tables).

Since Linux kernel 4.2 the utility `cbmem`, used to access information
stored in memory, from the coreboot project [1] does not work anymore
on a lot of systems as reported in coreboot’s issue tracker as ticket
#33 [2].

```
Failed to mmap /dev/mem: Resource temporarily unavailable
```

Aaron Durbin analyzed on the coreboot mailing list [3]:


3) Why is that range set as uncached-minus?  Would write-back work?


Please see this thread:
http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html

The actual issue stems from
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
which maintains a persistent mapping of smbios tables. It uses
dmi_remap() which is '#define dmi_remap ioremap' which is where the
uncached-minus PAT entry comes from. It should be using the same
mechanism as  the ACPI table mappings which uses ioremap_cache().


It’d be great, if the commit could be reverted, or the code be changed
in a way that `cbmem` still works.

If I should report this issue somewhere else, please tell me too, and
I’ll do my best to follow up there.


Thanks,

Paul


[1] https://www.coreboot.org
[2] https://ticket.coreboot.org/issues/33
[3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html

Re: ARC dw-mshc binding compat string

[Rob Herring]

On Mon, Mar 28, 2016 at 5:34 AM, Jaehoon Chung  wrote:
> Hi,
>
> On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
>> Hi Marek, Vladimir,
>>
>> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:

 On 26.03.2016 21:52, Marek Vasut wrote:
>
> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>
>> On 26.03.2016 20:10, Marek Vasut wrote:
>>>
>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:

 Hi Marek,

 On 26.03.2016 19:30, Marek Vasut wrote:
>
> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>
>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>
>>> Hi!
>>>
>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix 
>>> in
>>> the DT compatible string:
>>>
>>> mmc@0x15000 {
>>> compatible = "altr,socfpga-dw-mshc";
>>> reg = < 0x15000 0x400 >;
>>> num-slots = < 1 >;
>>> fifo-depth = < 16 >;
>>> card-detect-delay = < 200 >;
>>> clocks = <>, <>;
>>> clock-names = "biu", "ciu";
>>> interrupts = < 7 >;
>>> bus-width = < 4 >;
>>> };
>>>
>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>> should be extended with another compatibility string, something like
>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>> accordingly. What do you think ?
>>>
>> There is "snps,dw-mshc" described in
>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and 
>> supported by
>> dw_mmc host controller driver.
> Thanks, that's even better.
>
> btw what do you think of using altr, prefix on non-altera system, that
> doesn't seem ok, right ?
 according to ePAPR the prefix should represent a device (IP block here
 I believe) manufacturer, so it should be okay to use "altr" prefix on
 non-Altera system, if Altera provides  another hardware vendor with
 some own IP block.
>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>> chip makers (Altera etc).
>> Correct.
>>
>>>

 That said, I would rather prefer to see "snps,dw-mshc" prefix on 
 description
 of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
 seems
 to be redundant.
>
> Yes..it's redundant..i should be combined to "snps,dw-mshc".

socfpga is done correctly, IMO.

>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>> one needs it as well, but most likely yes.
>>>
>>> I wonder if that bit is needed on some particular version of the DWMMC
>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>> binding ? Or should we use DT property to discern the need for this bit 
>>> ?
>>>
>> That's the most common way to take into account peculiarities, add
>> a property and handle it from the driver.
> And by "that" you mean which of those two I listed , the
> "snps,dw-mshc-vN" or adding new DT prop ?
>
 I meant to add a new property, not a new compatible, but that's just
 my experience.

 Let me say it __might__ happen that a particular change you need is
 specific to a particular version of the DWMMC IP (query Synopsys
 by the way), but more probably it might be e.g. the same IP version with
 a different reduced or extended configuration or a minor fix/improvement
 to the IP block without resulting version number bump.

 For example I don't remember that errata fixes in IP blocks result in
 a new compatible, instead there are quite common optional "quirk"
 properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>
>>> Alexey, can you tell us if the requirement for setting
>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>> disappeared with some revision OR if this is some configuration
>>> option of the core during synthesis ?
>>
>> Sorry for not following that discussion during my weekend but I'll try
>> to address all questions now.
>
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the 
> below things.
>
> If Card is 

Re: ARC dw-mshc binding compat string

[Rob Herring]

On Mon, Mar 28, 2016 at 5:34 AM, Jaehoon Chung  wrote:
> Hi,
>
> On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
>> Hi Marek, Vladimir,
>>
>> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:

 On 26.03.2016 21:52, Marek Vasut wrote:
>
> On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>>
>> On 26.03.2016 20:10, Marek Vasut wrote:
>>>
>>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:

 Hi Marek,

 On 26.03.2016 19:30, Marek Vasut wrote:
>
> On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>>
>> On 26.03.2016 12:14, Marek Vasut wrote:
>>>
>>> Hi!
>>>
>>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix 
>>> in
>>> the DT compatible string:
>>>
>>> mmc@0x15000 {
>>> compatible = "altr,socfpga-dw-mshc";
>>> reg = < 0x15000 0x400 >;
>>> num-slots = < 1 >;
>>> fifo-depth = < 16 >;
>>> card-detect-delay = < 200 >;
>>> clocks = <>, <>;
>>> clock-names = "biu", "ciu";
>>> interrupts = < 7 >;
>>> bus-width = < 4 >;
>>> };
>>>
>>> I don't think this is OK, since ARC is unrelated to Altera, which is
>>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>>> should be extended with another compatibility string, something like
>>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>>> accordingly. What do you think ?
>>>
>> There is "snps,dw-mshc" described in
>> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and 
>> supported by
>> dw_mmc host controller driver.
> Thanks, that's even better.
>
> btw what do you think of using altr, prefix on non-altera system, that
> doesn't seem ok, right ?
 according to ePAPR the prefix should represent a device (IP block here
 I believe) manufacturer, so it should be okay to use "altr" prefix on
 non-Altera system, if Altera provides  another hardware vendor with
 some own IP block.
>>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>>> chip makers (Altera etc).
>> Correct.
>>
>>>

 That said, I would rather prefer to see "snps,dw-mshc" prefix on 
 description
 of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
 seems
 to be redundant.
>
> Yes..it's redundant..i should be combined to "snps,dw-mshc".

socfpga is done correctly, IMO.

>>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>>> one needs it as well, but most likely yes.
>>>
>>> I wonder if that bit is needed on some particular version of the DWMMC
>>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>>> binding ? Or should we use DT property to discern the need for this bit 
>>> ?
>>>
>> That's the most common way to take into account peculiarities, add
>> a property and handle it from the driver.
> And by "that" you mean which of those two I listed , the
> "snps,dw-mshc-vN" or adding new DT prop ?
>
 I meant to add a new property, not a new compatible, but that's just
 my experience.

 Let me say it __might__ happen that a particular change you need is
 specific to a particular version of the DWMMC IP (query Synopsys
 by the way), but more probably it might be e.g. the same IP version with
 a different reduced or extended configuration or a minor fix/improvement
 to the IP block without resulting version number bump.

 For example I don't remember that errata fixes in IP blocks result in
 a new compatible, instead there are quite common optional "quirk"
 properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>>> Right, this very much matches how I see it as well. Thanks for confirming.
>>>
>>> Alexey, can you tell us if the requirement for setting
>>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>>> disappeared with some revision OR if this is some configuration
>>> option of the core during synthesis ?
>>
>> Sorry for not following that discussion during my weekend but I'll try
>> to address all questions now.
>
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the 
> below things.
>
> If Card is SDR50/SDR104/DDR50 mode..
> 1) 

Re: [PATCH 00/23] Nokia N950 display support

[Emil Velikov]

Hi Sebastian,

On 9 March 2016 at 17:09, Sebastian Reichel  wrote:
> Hi Emil,
>
> On Wed, Mar 09, 2016 at 04:19:48PM +, Emil Velikov wrote:
>> Hi Sebastian,
>>
>> On 8 March 2016 at 16:39, Sebastian Reichel  wrote:
>>
>> >  arch/arm/boot/dts/omap3-n950-n9.dtsi|  72 +
>> >  arch/arm/boot/dts/omap3-n950.dts|  71 +
>> Just a friendly reminder that updating these and one will have to keep
>> the driver backwards compatible forever.
>
> Of course. Basically the new DT properties are:
>
>  * optional regulators (vpnl & vddi)
>  * boolean "has-dsi-backlight"
>  * resolution-x/y
>  * offset-x/y
>
> So probably not that much of a problem even if other API is
> invented. I just noticed, that I forgot to actually add documentation
> in Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
>
> I will fix that in the next patchset revision.
>
>> Tomi, has been in the process of removing all the unneeded cruft,
>> although omapdrm it is still using the custom panel, dsi and other
>> code as opposed to the ones provided by DRM. As he gets to reusing
>> those he might have some fun keeping things compatible.
>
> I could not find "generic" panel binding documentation. Can you
> give me a pointer? I can just stick to the same property names
> to avoid potential future problems.
>
Pardon for the late reply.

As mentioned in another email, if you're interested in reusing the drm
panel infrastructure you should be looking in
Documentation/devicetree/bindings/display/panel/. With display-timing
panel-dpi panel-dsi-cm and (optional) simple-panel as a start.

Would reshuffling/documenting things make it more obvious ? Feel free
to let Rob Herring, Thierry Reding know.

Regards,
Emil

Re: [PATCH 1/1] perf tools: Fix build break on powerpc

[Arnaldo Carvalho de Melo]

Em Sun, Mar 27, 2016 at 01:19:03PM +0200, Jiri Olsa escreveu:
> On Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu wrote:
> > From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> > From: Sukadev Bhattiprolu 
> > Date: Sat, 26 Mar 2016 17:31:39 -0400
> > Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> > 
> > 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> > kernel sources")' seems to have accidentially removed the inclusion of
> > "util/header.h" from "arch/powerpc/util/header.c".
> > 
> > "util/header.h" provides the prototype for get_cpuid() and is needed to
> > build perf on Powerpc.
> > 
> > arch/powerpc/util/header.c:17:1: error: no previous prototype for
> > ‘get_cpuid’ [-Werror=missing-prototypes]
> > 
> > Reported-by: Michael Ellerman 
> > Signed-off-by: Sukadev Bhattiprolu 
> > ---
> >  tools/perf/arch/powerpc/util/header.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/perf/arch/powerpc/util/header.c 
> > b/tools/perf/arch/powerpc/util/header.c
> > index 6138bde..5111e34 100644
> > --- a/tools/perf/arch/powerpc/util/header.c
> > +++ b/tools/perf/arch/powerpc/util/header.c
> > @@ -4,6 +4,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include "../../util/header.h"
> 
> you could use just "header.h" right?

Like this? I'm trying to find a way to do ppc cross builds, one more
thing to have in the build-tests...

commit 150da025b7f135450ca833fb80d54d59f0ddf185
Author: Sukadev Bhattiprolu 
Date:   Mon Mar 28 09:31:41 2016 -0300

perf tools: Fix build break on powerpc

Commit 531d2410635c ("perf tools: Do not include stringify.h from the
kernel sources") seems to have accidentially removed the inclusion of
"util/header.h" from "arch/powerpc/util/header.c".

"util/header.h" provides the prototype for get_cpuid() and is needed to
build perf on Powerpc:

arch/powerpc/util/header.c:17:1: error: no previous prototype for 
‘get_cpuid’ [-Werror=missing-prototypes]

Reported-by: Michael Ellerman 
Fixes: 531d2410635c ("perf tools: Do not include stringify.h from the 
kernel sources")
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Arnaldo Carvalho de Melo 

diff --git a/tools/perf/arch/powerpc/util/header.c 
b/tools/perf/arch/powerpc/util/header.c
index 6138bdef6e63..6de1a93241ae 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include "header.h"
 
 #define mfspr(rn)   ({unsigned long rval; \
 asm volatile("mfspr %0," __stringify(rn) \

Re: [PATCH 1/1] perf tools: Fix build break on powerpc

[Arnaldo Carvalho de Melo]

Em Sun, Mar 27, 2016 at 01:19:03PM +0200, Jiri Olsa escreveu:
> On Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu wrote:
> > From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> > From: Sukadev Bhattiprolu 
> > Date: Sat, 26 Mar 2016 17:31:39 -0400
> > Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> > 
> > 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> > kernel sources")' seems to have accidentially removed the inclusion of
> > "util/header.h" from "arch/powerpc/util/header.c".
> > 
> > "util/header.h" provides the prototype for get_cpuid() and is needed to
> > build perf on Powerpc.
> > 
> > arch/powerpc/util/header.c:17:1: error: no previous prototype for
> > ‘get_cpuid’ [-Werror=missing-prototypes]
> > 
> > Reported-by: Michael Ellerman 
> > Signed-off-by: Sukadev Bhattiprolu 
> > ---
> >  tools/perf/arch/powerpc/util/header.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/perf/arch/powerpc/util/header.c 
> > b/tools/perf/arch/powerpc/util/header.c
> > index 6138bde..5111e34 100644
> > --- a/tools/perf/arch/powerpc/util/header.c
> > +++ b/tools/perf/arch/powerpc/util/header.c
> > @@ -4,6 +4,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include "../../util/header.h"
> 
> you could use just "header.h" right?

Like this? I'm trying to find a way to do ppc cross builds, one more
thing to have in the build-tests...

commit 150da025b7f135450ca833fb80d54d59f0ddf185
Author: Sukadev Bhattiprolu 
Date:   Mon Mar 28 09:31:41 2016 -0300

perf tools: Fix build break on powerpc

Commit 531d2410635c ("perf tools: Do not include stringify.h from the
kernel sources") seems to have accidentially removed the inclusion of
"util/header.h" from "arch/powerpc/util/header.c".

"util/header.h" provides the prototype for get_cpuid() and is needed to
build perf on Powerpc:

arch/powerpc/util/header.c:17:1: error: no previous prototype for 
‘get_cpuid’ [-Werror=missing-prototypes]

Reported-by: Michael Ellerman 
Fixes: 531d2410635c ("perf tools: Do not include stringify.h from the 
kernel sources")
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Arnaldo Carvalho de Melo 

diff --git a/tools/perf/arch/powerpc/util/header.c 
b/tools/perf/arch/powerpc/util/header.c
index 6138bdef6e63..6de1a93241ae 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include "header.h"
 
 #define mfspr(rn)   ({unsigned long rval; \
 asm volatile("mfspr %0," __stringify(rn) \

Re: [PATCH 00/23] Nokia N950 display support

[Emil Velikov]

Hi Sebastian,

On 9 March 2016 at 17:09, Sebastian Reichel  wrote:
> Hi Emil,
>
> On Wed, Mar 09, 2016 at 04:19:48PM +, Emil Velikov wrote:
>> Hi Sebastian,
>>
>> On 8 March 2016 at 16:39, Sebastian Reichel  wrote:
>>
>> >  arch/arm/boot/dts/omap3-n950-n9.dtsi|  72 +
>> >  arch/arm/boot/dts/omap3-n950.dts|  71 +
>> Just a friendly reminder that updating these and one will have to keep
>> the driver backwards compatible forever.
>
> Of course. Basically the new DT properties are:
>
>  * optional regulators (vpnl & vddi)
>  * boolean "has-dsi-backlight"
>  * resolution-x/y
>  * offset-x/y
>
> So probably not that much of a problem even if other API is
> invented. I just noticed, that I forgot to actually add documentation
> in Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt
>
> I will fix that in the next patchset revision.
>
>> Tomi, has been in the process of removing all the unneeded cruft,
>> although omapdrm it is still using the custom panel, dsi and other
>> code as opposed to the ones provided by DRM. As he gets to reusing
>> those he might have some fun keeping things compatible.
>
> I could not find "generic" panel binding documentation. Can you
> give me a pointer? I can just stick to the same property names
> to avoid potential future problems.
>
Pardon for the late reply.

As mentioned in another email, if you're interested in reusing the drm
panel infrastructure you should be looking in
Documentation/devicetree/bindings/display/panel/. With display-timing
panel-dpi panel-dsi-cm and (optional) simple-panel as a start.

Would reshuffling/documenting things make it more obvious ? Feel free
to let Rob Herring, Thierry Reding know.

Regards,
Emil

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

[Kirill A. Shutemov]

On Wed, Mar 23, 2016 at 01:09:05PM -0700, Hugh Dickins wrote:
> On Sat, 12 Mar 2016, Kirill A. Shutemov wrote:
...
> As I've said on several occasions, I am not interested in emulating
> the limitations of hugetlbfs inside tmpfs: there might one day be a
> case for such a project, but it's transparent hugepages that we want to
> have now - blocksize 4kB, but in 2MB extents when possible (on x86_64).
> 
> I accept that supporting small files correctly is not the #1
> requirement for a "huge" tmpfs; and if it were impossible or
> unreasonable to ask for, I'd give up on it.  But since we (Google)
> have been using a successful implementation for a year now, I see
> no reason to give up on it at all: it allows for much wider and
> easier adoption (and testing) of huge tmpfs - without "but"s.

I think, once we get collapse work, huge=within_size would provide
reasonable support for fs with mixed-sized files.

Yes, we still would have overhead on sparsed or punch-holed files.
As for now, I don't see it being show-stopper. The hugepage allocation
policy can be overwritten with MADV/FADV_NOHUGEPAGE if an application
don't want to see huge pages in a particular case.

...

> Hmm, I just went to repeat that test, to see if MemFree goes down and
> down on each run, but got a VM_BUG_ON_PAGE(page_ref_count(page) == 0)
> in put_page_testzero() in find_get_entries() during shmem_evict_inode().
> So, something not quite right with the refcounting when under pressure.

I suspect some race with split_huge_page(), but don't see it so far.

> My third impression was much better, when I just did a straight
> cp /dev/zero /tmpfs_twice_size_of_RAM: that went smoothly,
> pushed into swap just as it should, nice.
> 
> > 
> > The main difference with Hugh's approach[1] is that I continue with
> > compound pages, where Hugh invents new way couple pages: team pages.
> > I believe THP refcounting rework made team pages unnecessary: compound
> > page are flexible enough to serve needs of page cache.
> 
> I have disagreed with you about the suitability of compound pages;
> but at some point on Sunday night, after reading your patchset,
> found myself looking at it differently, and now agreeing with you.
> 
> They are not flexible enough yet, but I believe you have done a large
> part of the work (by diverting all those tail ops to the head), and it
> just needs a little more.  I say "a little", but it might not be easy.
> 
> What I realize now, is that you should be able to do almost everything
> I did with team pages, instead with your compound pages.  Just abandon
> the idea that the whole compound page has to be initialized in one go:
> initialize (charge to memcg, add to page cache, fill, SetPageUptodate)
> each subpage as it is touched.  (But of course, the whole extent has
> to be to be initialized before it can be pmd-mapped.)

I'm not convinced, that doing such operations on per-4k is better.
All-at-once is simpler and has natural performance benefit from batching.

I think we can switch some operations to per-4k basis once upside will be
obvious. It's more on optimization side.

> And the convenient thing about a compound page is that you have plenty
> of space to hold your metadata: where I have been squeezing everything
> into page->private (which makes it difficult then to extend the same
> design to miscellaneous filesystems), you're free to use (certain)
> fields of 511 more struct pages.
> 
> I said above that you should be able to do almost everything: I think
> that "almost" involves dropping a few things that I have, that we can
> well do without.  With team pages, it is possible for each member to
> be charged to a different memcg; but I don't have anyone calling out
> for that behaviour, it's more an awkward possibility that we have to
> be on guard against in a few places, and I'd be quite happy just to
> stop it (charging instead to whichever memcg first touched the extent).
> 
> And it's been nice to entertain the idea of the individual team tails,
> travelling separately up and down their own lrus, subject to their own
> pagesize access patterns even while the whole is pmd-mapped.  But in
> practice, we continue to throw them on the unevictable list once they
> get in the way, with no attempt to bring them back when accessed
> individually; so I think it's a nice idea that we can live without.
> 
> And a compound page implementation would avoid the overhead I have,
> of putting all those tails on lru in the first place.

Exactly. LRU scanning is one of places where this kind of batching is
beneficial.

> Another thing I did, that I think you can safely fail to emulate:
> I was careful to allow sparse population, and not insist that the
> head page be instantiated.  That might turn out to be more of a
> problem for compound pages, and has been an awkward edge case for me.
> Although in principle there are sparse files which would be doubled
> in charge by insisting that the head be instantiated, I doubt they
> 

Re: [PATCHv4 00/25] THP-enabled tmpfs/shmem

[Kirill A. Shutemov]

On Wed, Mar 23, 2016 at 01:09:05PM -0700, Hugh Dickins wrote:
> On Sat, 12 Mar 2016, Kirill A. Shutemov wrote:
...
> As I've said on several occasions, I am not interested in emulating
> the limitations of hugetlbfs inside tmpfs: there might one day be a
> case for such a project, but it's transparent hugepages that we want to
> have now - blocksize 4kB, but in 2MB extents when possible (on x86_64).
> 
> I accept that supporting small files correctly is not the #1
> requirement for a "huge" tmpfs; and if it were impossible or
> unreasonable to ask for, I'd give up on it.  But since we (Google)
> have been using a successful implementation for a year now, I see
> no reason to give up on it at all: it allows for much wider and
> easier adoption (and testing) of huge tmpfs - without "but"s.

I think, once we get collapse work, huge=within_size would provide
reasonable support for fs with mixed-sized files.

Yes, we still would have overhead on sparsed or punch-holed files.
As for now, I don't see it being show-stopper. The hugepage allocation
policy can be overwritten with MADV/FADV_NOHUGEPAGE if an application
don't want to see huge pages in a particular case.

...

> Hmm, I just went to repeat that test, to see if MemFree goes down and
> down on each run, but got a VM_BUG_ON_PAGE(page_ref_count(page) == 0)
> in put_page_testzero() in find_get_entries() during shmem_evict_inode().
> So, something not quite right with the refcounting when under pressure.

I suspect some race with split_huge_page(), but don't see it so far.

> My third impression was much better, when I just did a straight
> cp /dev/zero /tmpfs_twice_size_of_RAM: that went smoothly,
> pushed into swap just as it should, nice.
> 
> > 
> > The main difference with Hugh's approach[1] is that I continue with
> > compound pages, where Hugh invents new way couple pages: team pages.
> > I believe THP refcounting rework made team pages unnecessary: compound
> > page are flexible enough to serve needs of page cache.
> 
> I have disagreed with you about the suitability of compound pages;
> but at some point on Sunday night, after reading your patchset,
> found myself looking at it differently, and now agreeing with you.
> 
> They are not flexible enough yet, but I believe you have done a large
> part of the work (by diverting all those tail ops to the head), and it
> just needs a little more.  I say "a little", but it might not be easy.
> 
> What I realize now, is that you should be able to do almost everything
> I did with team pages, instead with your compound pages.  Just abandon
> the idea that the whole compound page has to be initialized in one go:
> initialize (charge to memcg, add to page cache, fill, SetPageUptodate)
> each subpage as it is touched.  (But of course, the whole extent has
> to be to be initialized before it can be pmd-mapped.)

I'm not convinced, that doing such operations on per-4k is better.
All-at-once is simpler and has natural performance benefit from batching.

I think we can switch some operations to per-4k basis once upside will be
obvious. It's more on optimization side.

> And the convenient thing about a compound page is that you have plenty
> of space to hold your metadata: where I have been squeezing everything
> into page->private (which makes it difficult then to extend the same
> design to miscellaneous filesystems), you're free to use (certain)
> fields of 511 more struct pages.
> 
> I said above that you should be able to do almost everything: I think
> that "almost" involves dropping a few things that I have, that we can
> well do without.  With team pages, it is possible for each member to
> be charged to a different memcg; but I don't have anyone calling out
> for that behaviour, it's more an awkward possibility that we have to
> be on guard against in a few places, and I'd be quite happy just to
> stop it (charging instead to whichever memcg first touched the extent).
> 
> And it's been nice to entertain the idea of the individual team tails,
> travelling separately up and down their own lrus, subject to their own
> pagesize access patterns even while the whole is pmd-mapped.  But in
> practice, we continue to throw them on the unevictable list once they
> get in the way, with no attempt to bring them back when accessed
> individually; so I think it's a nice idea that we can live without.
> 
> And a compound page implementation would avoid the overhead I have,
> of putting all those tails on lru in the first place.

Exactly. LRU scanning is one of places where this kind of batching is
beneficial.

> Another thing I did, that I think you can safely fail to emulate:
> I was careful to allow sparse population, and not insist that the
> head page be instantiated.  That might turn out to be more of a
> problem for compound pages, and has been an awkward edge case for me.
> Although in principle there are sparse files which would be doubled
> in charge by insisting that the head be instantiated, I doubt they
> 

Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc

[Arnaldo Carvalho de Melo]

Em Mon, Mar 28, 2016 at 04:28:45PM +0530, Ravi Bangoria escreveu:
> Thanks Arnaldo for putting the effort.
> 
> I've tested this patch on powerpc and it looks fine to me. Please find my
> below comments.
> 
> On Friday 25 March 2016 02:45 AM, Arnaldo Carvalho de Melo wrote:
> >Em Tue, Mar 22, 2016 at 11:19:21PM -0300, Arnaldo Carvalho de Melo escreveu:
> >>Em Tue, Mar 22, 2016 at 04:12:11PM -0300, Arnaldo Carvalho de Melo escreveu:
> >>>Em Wed, Feb 24, 2016 at 02:37:42PM +0530, Ravi Bangoria escreveu:
> 'perf kvm record' is not available on powerpc because 'perf' relies on
> the 'cycles' event (a PMU event) to profile the guest. However, for
> powerpc, this can't be used from the host because the PMUs are controlled
> by the guest rather than the host.
> 
> There exists a tracepoint 'kvm_hv:kvm_guest_exit' in powerpc which is
> hit whenever any of the threads exit the guest context. The guest
> instruction pointer dumped along with this tracepoint data in the field
> 'pc', can be used as guest instruction pointer.
> 
> This patch changes default event as kvm_hv:kvm_guest_exit for recording
> guest data in host on powerpc. As we are using host event to record guest
> data, this approach will enable only --guest option of 'perf kvm'. Still
> --host --guest together won't work.
> >>>It should, i.e. --host --guest should translate to:
> >>>
> >>>-e cycles:H,kvm_hv:kvm_guest_exit
> >>>
> >>>I.e. both collect cycles only in the host, and also the tracepoint that
> >>>will allow us to get the guest approximation for the unavailable cycles
> >>>event, no?
> >>>
> >>>I'm putting the infrastructure work needed for this the perf/cpumode
> >>>branch. More work will be put there soon.
> >>So I took a different path and made perf_evsel__parse_sample set a new
> >>perf_sample.cpumode field, this way we'll end up having just to set a
> >>per-evsel ->post_parse_sample() callback for the event that replaces
> >>"cycles" for PPC guests where we'll just set data->ip and data->cpumode,
> >>the rest of the code remains unchanged.
> >>
> >>The changes I made looks useful in itself, as, IIRC more code was
> >>removed than added.
> >>
> >>I'll continue tomorrow and will test with the kvm:kvm_exit on x86_64 for
> >>testing, that has:
> >Ok, so the infrastructure got merged already and from there the next
> >steps are in running with:
> >
> >  perf kvm --guest record -a -e cycles:H,kvm:kvm_exit
> >
> >And then, with the patch below applied, try:
> >
> >perf kvm --guestkallsyms kallsyms.guest --guestmodules modules.guest report 
> >-i perf.data.guest --munge-ppc-guest-sample kvm:kvm_exit
> 
> 
> The initial proposal was to change the default event as "kvm_guest_exit" for
> kvm recording/reporting
> on ppc. If I understand it correctly, your patch creates a handler for
> reporting kvm events
> based on "munge_ppc_guest_event" and the required tracepoint i.e., we need
> to mention the
> required tracepoint event name for recording and reporting.

What is present in my patch is the creation of infrastructure that is as
much generic as possible, to enable doing this event conversion for PPC.

Doing it transparently in PPC systems and on other systems when handling
a perf.data file generated by 'perf kvm record' on PPC  will be done on
top of this, thanks for testing, I'll send a complete series soon.

- Arnaldo
 
> There might be a little bit of an issue here. For scripts which depend on
> generic perf kvm record/report,
> we need to change those appropriately to prevent those from failing on
> powerpc. Otherwise, (just a
> thought) can we create some kind of an alias to map the ppc specific perf
> kvm commands with the
> generic perf kvm.
> For e.g :
> perf kvm record -e "kvm_hv:kvm_guest_exit"  mapped to  perf kvm record
> &
> perf kvm report --munge-ppc-guest-sample kvm_hv:kvm_guest_exit mapped to
> perf kvm report.
> 
> 
> Regards,
> Ravi

Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc

[Arnaldo Carvalho de Melo]

Em Mon, Mar 28, 2016 at 04:28:45PM +0530, Ravi Bangoria escreveu:
> Thanks Arnaldo for putting the effort.
> 
> I've tested this patch on powerpc and it looks fine to me. Please find my
> below comments.
> 
> On Friday 25 March 2016 02:45 AM, Arnaldo Carvalho de Melo wrote:
> >Em Tue, Mar 22, 2016 at 11:19:21PM -0300, Arnaldo Carvalho de Melo escreveu:
> >>Em Tue, Mar 22, 2016 at 04:12:11PM -0300, Arnaldo Carvalho de Melo escreveu:
> >>>Em Wed, Feb 24, 2016 at 02:37:42PM +0530, Ravi Bangoria escreveu:
> 'perf kvm record' is not available on powerpc because 'perf' relies on
> the 'cycles' event (a PMU event) to profile the guest. However, for
> powerpc, this can't be used from the host because the PMUs are controlled
> by the guest rather than the host.
> 
> There exists a tracepoint 'kvm_hv:kvm_guest_exit' in powerpc which is
> hit whenever any of the threads exit the guest context. The guest
> instruction pointer dumped along with this tracepoint data in the field
> 'pc', can be used as guest instruction pointer.
> 
> This patch changes default event as kvm_hv:kvm_guest_exit for recording
> guest data in host on powerpc. As we are using host event to record guest
> data, this approach will enable only --guest option of 'perf kvm'. Still
> --host --guest together won't work.
> >>>It should, i.e. --host --guest should translate to:
> >>>
> >>>-e cycles:H,kvm_hv:kvm_guest_exit
> >>>
> >>>I.e. both collect cycles only in the host, and also the tracepoint that
> >>>will allow us to get the guest approximation for the unavailable cycles
> >>>event, no?
> >>>
> >>>I'm putting the infrastructure work needed for this the perf/cpumode
> >>>branch. More work will be put there soon.
> >>So I took a different path and made perf_evsel__parse_sample set a new
> >>perf_sample.cpumode field, this way we'll end up having just to set a
> >>per-evsel ->post_parse_sample() callback for the event that replaces
> >>"cycles" for PPC guests where we'll just set data->ip and data->cpumode,
> >>the rest of the code remains unchanged.
> >>
> >>The changes I made looks useful in itself, as, IIRC more code was
> >>removed than added.
> >>
> >>I'll continue tomorrow and will test with the kvm:kvm_exit on x86_64 for
> >>testing, that has:
> >Ok, so the infrastructure got merged already and from there the next
> >steps are in running with:
> >
> >  perf kvm --guest record -a -e cycles:H,kvm:kvm_exit
> >
> >And then, with the patch below applied, try:
> >
> >perf kvm --guestkallsyms kallsyms.guest --guestmodules modules.guest report 
> >-i perf.data.guest --munge-ppc-guest-sample kvm:kvm_exit
> 
> 
> The initial proposal was to change the default event as "kvm_guest_exit" for
> kvm recording/reporting
> on ppc. If I understand it correctly, your patch creates a handler for
> reporting kvm events
> based on "munge_ppc_guest_event" and the required tracepoint i.e., we need
> to mention the
> required tracepoint event name for recording and reporting.

What is present in my patch is the creation of infrastructure that is as
much generic as possible, to enable doing this event conversion for PPC.

Doing it transparently in PPC systems and on other systems when handling
a perf.data file generated by 'perf kvm record' on PPC  will be done on
top of this, thanks for testing, I'll send a complete series soon.

- Arnaldo
 
> There might be a little bit of an issue here. For scripts which depend on
> generic perf kvm record/report,
> we need to change those appropriately to prevent those from failing on
> powerpc. Otherwise, (just a
> thought) can we create some kind of an alias to map the ppc specific perf
> kvm commands with the
> generic perf kvm.
> For e.g :
> perf kvm record -e "kvm_hv:kvm_guest_exit"  mapped to  perf kvm record
> &
> perf kvm report --munge-ppc-guest-sample kvm_hv:kvm_guest_exit mapped to
> perf kvm report.
> 
> 
> Regards,
> Ravi

Re: [PATCH 1/1] perf tools: Fix build break on powerpc

[Arnaldo Carvalho de Melo]

Em Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu escreveu:
> From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu 
> Date: Sat, 26 Mar 2016 17:31:39 -0400
> Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> kernel sources")' seems to have accidentially removed the inclusion of
> "util/header.h" from "arch/powerpc/util/header.c".

My bad, will push this via perf/urgent, after fixing what Jiri reported.
 
> "util/header.h" provides the prototype for get_cpuid() and is needed to
> build perf on Powerpc.
> 
>   arch/powerpc/util/header.c:17:1: error: no previous prototype for
>   ‘get_cpuid’ [-Werror=missing-prototypes]
> 
> Reported-by: Michael Ellerman 
> Signed-off-by: Sukadev Bhattiprolu 
> ---
>  tools/perf/arch/powerpc/util/header.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/arch/powerpc/util/header.c 
> b/tools/perf/arch/powerpc/util/header.c
> index 6138bde..5111e34 100644
> --- a/tools/perf/arch/powerpc/util/header.c
> +++ b/tools/perf/arch/powerpc/util/header.c
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include "../../util/header.h"
>  
>  #define mfspr(rn)   ({unsigned long rval; \
>asm volatile("mfspr %0," __stringify(rn) \
> -- 
> 1.8.3.1

Re: [PATCH 1/1] perf tools: Fix build break on powerpc

[Arnaldo Carvalho de Melo]

Em Sat, Mar 26, 2016 at 11:01:47AM -0700, Sukadev Bhattiprolu escreveu:
> From 502e8236082412db1d33abfad95aaf14b539502e Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu 
> Date: Sat, 26 Mar 2016 17:31:39 -0400
> Subject: [PATCH 1/1] perf tools: Fix build break on powerpc
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> 'Commit 531d2410635c ("perf tools: Do not include stringify.h from the
> kernel sources")' seems to have accidentially removed the inclusion of
> "util/header.h" from "arch/powerpc/util/header.c".

My bad, will push this via perf/urgent, after fixing what Jiri reported.
 
> "util/header.h" provides the prototype for get_cpuid() and is needed to
> build perf on Powerpc.
> 
>   arch/powerpc/util/header.c:17:1: error: no previous prototype for
>   ‘get_cpuid’ [-Werror=missing-prototypes]
> 
> Reported-by: Michael Ellerman 
> Signed-off-by: Sukadev Bhattiprolu 
> ---
>  tools/perf/arch/powerpc/util/header.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/arch/powerpc/util/header.c 
> b/tools/perf/arch/powerpc/util/header.c
> index 6138bde..5111e34 100644
> --- a/tools/perf/arch/powerpc/util/header.c
> +++ b/tools/perf/arch/powerpc/util/header.c
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include "../../util/header.h"
>  
>  #define mfspr(rn)   ({unsigned long rval; \
>asm volatile("mfspr %0," __stringify(rn) \
> -- 
> 1.8.3.1

Re: [RFC PATCH v1 0/4] Add Rockchip RGA support

[Emil Velikov]

On 22 March 2016 at 00:42, Heiko Stuebner  wrote:
> Hi Yakir,
>
> Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang:
>> On 03/21/2016 07:29 PM, Heiko Stübner wrote:
>> > Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
>> >> This patch set would add the RGA direct rendering based 2d graphics
>> >> acceleration module.
>> >
>> > very cool to see that.
>>
>> ;)
>>
>> >> This patch set is based on git repository below:
>> >> git://people.freedesktop.org/~airlied/linux drm-next
>> >> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
>> >>
>> >> And the RGA driver is based on Exynos G2D driver, it only manages the
>> >> command lists received from user, so user should make the command list
>> >> to data and registers needed by operation to use.
>> >>
>> >> I have prepared an userspace demo application for testing:
>> >>https://github.com/yakir-Yang/libdrm-rockchip
>> >>
>> >> That is a rockchip libdrm library, and I have write a simple test case
>> >> "rockchip_rga_test" that would test the below RGA features:
>> >> - solid
>> >> - copy
>> >> - rotation
>> >> - flip
>> >> - window clip
>> >> - dithering
>> >
>> > Did you submit your libdrm changes as well?
>> >
>> > Userspace-interfaces need to be stable so the other side must also get
>> > accepted - even before the kernel change if I remember correctly.
>>
>> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm.
>> But I don't find the way to submit patches to libdrm, would you like
>> share some helps here ;)
>
> Looking at the libdrm sources on cgit.freedesktop.org, I did not find any
> specific manual on submitting patches.
>
> But looking at the dri-list archive, dri-de...@lists.freedesktop.org is the
> right list and looking at the libdrm history it looks like Emil Velikov
>  seems to be doing maintenance-stuff in libdrm.
> And as a 3rd recipient, please also include the linux-rockchip list.
>
> @Emil, please shout if I read that wrong :-)
>
You got it spot on Heiko. There are a few notes though...

As one reuses the existing hardware/IP block, it would be better to
avoid copy/pasting code around.
Namely:
 - (if possible) factor out the exynos g2d kernel functionality to a
separate kernel module and wire up the rockhip (via dt ?) to use it
 - factor out the g2d specifics out of exynos_drm.h (into
exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the
new header
 - if neither of these are possible, then please ensure that the new
header uses correct types (see the docs [1]), use MIT/X11 license (if
possible) and link where upstream userspace is happy with the
interface (ideally more than a simple test app like libdrm)

These might sound like an overkill, although getting UAPI right and
maintaining it forever forces us to do so.

Regards,
Emil

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt

Re: [RFC PATCH v1 0/4] Add Rockchip RGA support

[Emil Velikov]

On 22 March 2016 at 00:42, Heiko Stuebner  wrote:
> Hi Yakir,
>
> Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang:
>> On 03/21/2016 07:29 PM, Heiko Stübner wrote:
>> > Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
>> >> This patch set would add the RGA direct rendering based 2d graphics
>> >> acceleration module.
>> >
>> > very cool to see that.
>>
>> ;)
>>
>> >> This patch set is based on git repository below:
>> >> git://people.freedesktop.org/~airlied/linux drm-next
>> >> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
>> >>
>> >> And the RGA driver is based on Exynos G2D driver, it only manages the
>> >> command lists received from user, so user should make the command list
>> >> to data and registers needed by operation to use.
>> >>
>> >> I have prepared an userspace demo application for testing:
>> >>https://github.com/yakir-Yang/libdrm-rockchip
>> >>
>> >> That is a rockchip libdrm library, and I have write a simple test case
>> >> "rockchip_rga_test" that would test the below RGA features:
>> >> - solid
>> >> - copy
>> >> - rotation
>> >> - flip
>> >> - window clip
>> >> - dithering
>> >
>> > Did you submit your libdrm changes as well?
>> >
>> > Userspace-interfaces need to be stable so the other side must also get
>> > accepted - even before the kernel change if I remember correctly.
>>
>> Got it, and I just saw exynos_fimg2d already landed at mainline libdrm.
>> But I don't find the way to submit patches to libdrm, would you like
>> share some helps here ;)
>
> Looking at the libdrm sources on cgit.freedesktop.org, I did not find any
> specific manual on submitting patches.
>
> But looking at the dri-list archive, dri-de...@lists.freedesktop.org is the
> right list and looking at the libdrm history it looks like Emil Velikov
>  seems to be doing maintenance-stuff in libdrm.
> And as a 3rd recipient, please also include the linux-rockchip list.
>
> @Emil, please shout if I read that wrong :-)
>
You got it spot on Heiko. There are a few notes though...

As one reuses the existing hardware/IP block, it would be better to
avoid copy/pasting code around.
Namely:
 - (if possible) factor out the exynos g2d kernel functionality to a
separate kernel module and wire up the rockhip (via dt ?) to use it
 - factor out the g2d specifics out of exynos_drm.h (into
exynos_g2d_drm.h perhaps ?) and make sure exynos_drm.h includes the
new header
 - if neither of these are possible, then please ensure that the new
header uses correct types (see the docs [1]), use MIT/X11 license (if
possible) and link where upstream userspace is happy with the
interface (ideally more than a simple test app like libdrm)

These might sound like an overkill, although getting UAPI right and
maintaining it forever forces us to do so.

Regards,
Emil

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt

Re: [PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.

[Emil Velikov]

Hi all,

On 24 March 2016 at 11:28, Dan Carpenter  wrote:
> On Thu, Mar 24, 2016 at 11:41:46AM +0100, Enric Balletbo i Serra wrote:
>> + /* Map slave addresses of ANX7814 */
>> + for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
>> + anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter,
>> + anx78xx_i2c_addresses[i] >> 1);
>> + if (!anx78xx->i2c_dummy[i]) {
>> + DRM_ERROR("Failed to reserve i2c bus %02x.\n",
>> +   anx78xx_i2c_addresses[i]);
>
> Missing error code here.
>
>> + goto err_i2c;
>> + }
>
> I'm, of course, not a fan of the naming.  The name should be based on
> what the goto location does...  In this case it turns it off.  Which is
> slightly weird because we have not turned it on yet...  I always say
> that you should have multiple error labels and you only undo things
> which have been done.
>
> Having a common exit path for the other functions where it was "goto out"
> makes sense.  But again in those cases I would prefer a meaningful label
> name like "goto unlock;".  In the kernel "goto out;" is meaningless, it
> could do anything or everything or nothing.  A lot of people like it
> of course, but out: label code tends to be buggier than using a
> meaningful name.
>
Dan, I'm so glad to see another like minded person on the topic. It
seems that we're a minority though :-(

Enric, if you want to increase the chances of this getting reviewed I
would humbly suggest adding a per-patch changelog (must), explicitly
Cc (in the commit message) the people who commented on your patch
(highly recommended), and perhaps cutting down the 20+ people from the
To/Cc list (nitpicking).

Another option would be to assist/review similar (drm bridge) patches
for other contributors, who should return with the same :-)

Just some suggestions (my 2c as they say), seeing that this has been
around for a while.

Regards,
Emil

Re: [PATCH 3/3] drm: bridge: anx78xx: Add anx78xx bridge driver support.

[Emil Velikov]

Hi all,

On 24 March 2016 at 11:28, Dan Carpenter  wrote:
> On Thu, Mar 24, 2016 at 11:41:46AM +0100, Enric Balletbo i Serra wrote:
>> + /* Map slave addresses of ANX7814 */
>> + for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
>> + anx78xx->i2c_dummy[i] = i2c_new_dummy(client->adapter,
>> + anx78xx_i2c_addresses[i] >> 1);
>> + if (!anx78xx->i2c_dummy[i]) {
>> + DRM_ERROR("Failed to reserve i2c bus %02x.\n",
>> +   anx78xx_i2c_addresses[i]);
>
> Missing error code here.
>
>> + goto err_i2c;
>> + }
>
> I'm, of course, not a fan of the naming.  The name should be based on
> what the goto location does...  In this case it turns it off.  Which is
> slightly weird because we have not turned it on yet...  I always say
> that you should have multiple error labels and you only undo things
> which have been done.
>
> Having a common exit path for the other functions where it was "goto out"
> makes sense.  But again in those cases I would prefer a meaningful label
> name like "goto unlock;".  In the kernel "goto out;" is meaningless, it
> could do anything or everything or nothing.  A lot of people like it
> of course, but out: label code tends to be buggier than using a
> meaningful name.
>
Dan, I'm so glad to see another like minded person on the topic. It
seems that we're a minority though :-(

Enric, if you want to increase the chances of this getting reviewed I
would humbly suggest adding a per-patch changelog (must), explicitly
Cc (in the commit message) the people who commented on your patch
(highly recommended), and perhaps cutting down the 20+ people from the
To/Cc list (nitpicking).

Another option would be to assist/review similar (drm bridge) patches
for other contributors, who should return with the same :-)

Just some suggestions (my 2c as they say), seeing that this has been
around for a while.

Regards,
Emil

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #3]

[Mimi Zohar]

Hi David,

On Wed, 2016-03-09 at 11:19 +, David Howells wrote:
> Provide a config option (IMA_PERMIT_ADD_TO_IMA_KEYRINGS) that, when
> enabled, allows keys to be added to the IMA keyrings by userspace - with
> the restriction that each must be signed by a key in the system trusted
> keyrings.
> 
> EPERM will be returned if this option is disabled, ENOKEY will be returned if
> no authoritative key can be found and EKEYREJECTED will be returned if the
> signature doesn't match.  Other errors such as ENOPKG may also be returned.
> 
> If this new option is enabled, the builtin system keyring is searched, as is
> the secondary system keyring if that is also enabled.  Intermediate keys
> between the builtin system keyring and the key being added can be added to
> the secondary keyring (which replaces .ima_mok) to form a trust chain -
> provided they are also validly signed by a key in one of the trusted keyrings.
> 
> The .ima_mok keyring is removed.

This patch adds new Kconfig options, when it should be limited to
removing the .ima_mok keyring.   Lets change the title to "IMA: use the
secondary_trusted_keys instead of .ima_mok" and limit the new Kconfig
option to using the secondary_trusted_keys.

> Signed-off-by: David Howells 
> ---
> 
>  include/keys/system_keyring.h|9 --
>  security/integrity/digsig.c  |   33 
>  security/integrity/ima/Kconfig   |   62 
> +++---
>  security/integrity/ima/ima_mok.c |   15 ++---
>  4 files changed, 60 insertions(+), 59 deletions(-)
> 
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 614424029de7..87eeea4b816c 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -34,22 +34,13 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
>  #endif
> 
>  #ifdef CONFIG_IMA_MOK_KEYRING
> -extern struct key *ima_mok_keyring;
>  extern struct key *ima_blacklist_keyring;
> 
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> - return ima_mok_keyring;
> -}
>  static inline struct key *get_ima_blacklist_keyring(void)
>  {
>   return ima_blacklist_keyring;
>  }
>  #else
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> - return NULL;
> -}
>  static inline struct key *get_ima_blacklist_keyring(void)
>  {
>   return NULL;
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index 98ee4c752cf5..ef2f911d5c76 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -42,32 +42,12 @@ static bool init_keyring __initdata = true;
>  static bool init_keyring __initdata;
>  #endif
> 
> -#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
> -/*
> - * Restrict the addition of keys into the IMA keyring.
> - *
> - * Any key that needs to go in .ima keyring must be signed by CA in
> - * either .system or .ima_mok keyrings.
> - */
> -static int restrict_link_by_ima_mok(struct key *keyring,
> - const struct key_type *type,
> - const union key_payload *payload)
> -{
> - int ret;
> -
> - ret = restrict_link_by_builtin_trusted(keyring, type, payload);
> - if (ret != -ENOKEY)
> - return ret;
> -
> - return restrict_link_by_signature(get_ima_mok_keyring(),
> -   type, payload);
> -}
> +#if defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN)
> +#define restrict_link_to_ima restrict_link_by_builtin_trusted
> +#elif defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN_OR_SECONDARY)
> +#define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
>  #else
> -/*
> - * If there's no system trusted keyring, then keys cannot be loaded into
> - * .ima_mok and added keys cannot be marked trusted.
> - */
> -#define restrict_link_by_ima_mok restrict_link_reject
> +#define restrict_link_to_ima restrict_link_reject
>  #endif
> 
>  int integrity_digsig_verify(const unsigned int id, const char *sig, int 
> siglen,
> @@ -114,7 +94,8 @@ int __init integrity_init_keyring(const unsigned int id)
>KEY_USR_VIEW | KEY_USR_READ |
>KEY_USR_WRITE | KEY_USR_SEARCH),
>   KEY_ALLOC_NOT_IN_QUOTA,
> - restrict_link_by_ima_mok, NULL);
> + restrict_link_to_ima,
> + NULL);
>   if (IS_ERR(keyring[id])) {
>   err = PTR_ERR(keyring[id]);
>   pr_info("Can't allocate %s keyring (%d)\n",
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index e54a8a8dae94..90a65fba6f39 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -156,22 +156,60 @@ config IMA_TRUSTED_KEYRING
>  This option is deprecated in favor of INTEGRITY_TRUSTED_KEYRING
> 
>  config IMA_MOK_KEYRING

As we're 

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #3]

[Mimi Zohar]

Hi David,

On Wed, 2016-03-09 at 11:19 +, David Howells wrote:
> Provide a config option (IMA_PERMIT_ADD_TO_IMA_KEYRINGS) that, when
> enabled, allows keys to be added to the IMA keyrings by userspace - with
> the restriction that each must be signed by a key in the system trusted
> keyrings.
> 
> EPERM will be returned if this option is disabled, ENOKEY will be returned if
> no authoritative key can be found and EKEYREJECTED will be returned if the
> signature doesn't match.  Other errors such as ENOPKG may also be returned.
> 
> If this new option is enabled, the builtin system keyring is searched, as is
> the secondary system keyring if that is also enabled.  Intermediate keys
> between the builtin system keyring and the key being added can be added to
> the secondary keyring (which replaces .ima_mok) to form a trust chain -
> provided they are also validly signed by a key in one of the trusted keyrings.
> 
> The .ima_mok keyring is removed.

This patch adds new Kconfig options, when it should be limited to
removing the .ima_mok keyring.   Lets change the title to "IMA: use the
secondary_trusted_keys instead of .ima_mok" and limit the new Kconfig
option to using the secondary_trusted_keys.

> Signed-off-by: David Howells 
> ---
> 
>  include/keys/system_keyring.h|9 --
>  security/integrity/digsig.c  |   33 
>  security/integrity/ima/Kconfig   |   62 
> +++---
>  security/integrity/ima/ima_mok.c |   15 ++---
>  4 files changed, 60 insertions(+), 59 deletions(-)
> 
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 614424029de7..87eeea4b816c 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -34,22 +34,13 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
>  #endif
> 
>  #ifdef CONFIG_IMA_MOK_KEYRING
> -extern struct key *ima_mok_keyring;
>  extern struct key *ima_blacklist_keyring;
> 
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> - return ima_mok_keyring;
> -}
>  static inline struct key *get_ima_blacklist_keyring(void)
>  {
>   return ima_blacklist_keyring;
>  }
>  #else
> -static inline struct key *get_ima_mok_keyring(void)
> -{
> - return NULL;
> -}
>  static inline struct key *get_ima_blacklist_keyring(void)
>  {
>   return NULL;
> diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
> index 98ee4c752cf5..ef2f911d5c76 100644
> --- a/security/integrity/digsig.c
> +++ b/security/integrity/digsig.c
> @@ -42,32 +42,12 @@ static bool init_keyring __initdata = true;
>  static bool init_keyring __initdata;
>  #endif
> 
> -#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
> -/*
> - * Restrict the addition of keys into the IMA keyring.
> - *
> - * Any key that needs to go in .ima keyring must be signed by CA in
> - * either .system or .ima_mok keyrings.
> - */
> -static int restrict_link_by_ima_mok(struct key *keyring,
> - const struct key_type *type,
> - const union key_payload *payload)
> -{
> - int ret;
> -
> - ret = restrict_link_by_builtin_trusted(keyring, type, payload);
> - if (ret != -ENOKEY)
> - return ret;
> -
> - return restrict_link_by_signature(get_ima_mok_keyring(),
> -   type, payload);
> -}
> +#if defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN)
> +#define restrict_link_to_ima restrict_link_by_builtin_trusted
> +#elif defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN_OR_SECONDARY)
> +#define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
>  #else
> -/*
> - * If there's no system trusted keyring, then keys cannot be loaded into
> - * .ima_mok and added keys cannot be marked trusted.
> - */
> -#define restrict_link_by_ima_mok restrict_link_reject
> +#define restrict_link_to_ima restrict_link_reject
>  #endif
> 
>  int integrity_digsig_verify(const unsigned int id, const char *sig, int 
> siglen,
> @@ -114,7 +94,8 @@ int __init integrity_init_keyring(const unsigned int id)
>KEY_USR_VIEW | KEY_USR_READ |
>KEY_USR_WRITE | KEY_USR_SEARCH),
>   KEY_ALLOC_NOT_IN_QUOTA,
> - restrict_link_by_ima_mok, NULL);
> + restrict_link_to_ima,
> + NULL);
>   if (IS_ERR(keyring[id])) {
>   err = PTR_ERR(keyring[id]);
>   pr_info("Can't allocate %s keyring (%d)\n",
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index e54a8a8dae94..90a65fba6f39 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -156,22 +156,60 @@ config IMA_TRUSTED_KEYRING
>  This option is deprecated in favor of INTEGRITY_TRUSTED_KEYRING
> 
>  config IMA_MOK_KEYRING

As we're left with only the IMA 

Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework

[Emil Velikov]

Hi Emilio,

On 9 March 2016 at 15:28, Emilio López  wrote:
> These tests are based on the libsync test suite from Android.
> This commit lays the ground for future tests, as well as includes
> tests for a variety of basic allocation commands.
>
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Emilio López 
> ---
>

>  tools/testing/selftests/sync/sync.h   | 119 ++
Admittedly I know nothing about the kernel selftests although copying
the UAPI header, seems to defeat the purpose of this exercise.
Shouldn't one reuse the existing header ? It would even cause issues
as the interface gets updated (iirc Gustavo changed the ioctl numbers
and/or header name with latter series).

Regards,
Emil

Re: [RFC PATCH v1 1/9] selftest: sync: basic tests for sw_sync framework

[Emil Velikov]

Hi Emilio,

On 9 March 2016 at 15:28, Emilio López  wrote:
> These tests are based on the libsync test suite from Android.
> This commit lays the ground for future tests, as well as includes
> tests for a variety of basic allocation commands.
>
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Emilio López 
> ---
>

>  tools/testing/selftests/sync/sync.h   | 119 ++
Admittedly I know nothing about the kernel selftests although copying
the UAPI header, seems to defeat the purpose of this exercise.
Shouldn't one reuse the existing header ? It would even cause issues
as the interface gets updated (iirc Gustavo changed the ioctl numbers
and/or header name with latter series).

Regards,
Emil

Re: ARC dw-mshc binding compat string

[Jaehoon Chung]

On 03/28/2016 07:55 PM, Alexey Brodkin wrote:
> Hi Jaehoon,
> 
> On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote:
>> Hi,
> 
> [snip]
> 
>
> That said, I would rather prefer to see "snps,dw-mshc" prefix on 
> description
> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
> seems
> to be redundant.
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
> 
> So for socfpga platform compat string should be something like 
> "snps,dw-mshc-socfpga" then?

i think yes..since there is no SoC specific feature, isn't?

> 
>>>

>
>>
>>>

 According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
 "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
 "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
 while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
 one needs it as well, but most likely yes.

 I wonder if that bit is needed on some particular version of the DWMMC
 core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
 binding ? Or should we use DT property to discern the need for this 
 bit ?

>>> That's the most common way to take into account peculiarities, add
>>> a property and handle it from the driver.
>> And by "that" you mean which of those two I listed , the
>> "snps,dw-mshc-vN" or adding new DT prop ?
>>
> I meant to add a new property, not a new compatible, but that's just
> my experience.
>
> Let me say it __might__ happen that a particular change you need is
> specific to a particular version of the DWMMC IP (query Synopsys
> by the way), but more probably it might be e.g. the same IP version with
> a different reduced or extended configuration or a minor fix/improvement
> to the IP block without resulting version number bump.
>
> For example I don't remember that errata fixes in IP blocks result in
> a new compatible, instead there are quite common optional "quirk"
> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
 Right, this very much matches how I see it as well. Thanks for confirming.

 Alexey, can you tell us if the requirement for setting
 SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
 disappeared with some revision OR if this is some configuration
 option of the core during synthesis ?
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions now.
>> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using 
>> continuously.
>> But it's difficult to use the generic feature..because it's considered the 
>> below things.
>>
>> If Card is SDR50/SDR104/DDR50 mode..
>>  1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
>> is set to 0,
>>  2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
>> is set to 1,
>> If Card is SDR12/SDR25 mode, then this bit is set to 1.
> 
> So card type is also important here and for certain card type we don't need to
> set SDMMC_CMD_USE_HOLD_REG, right?

If you means card-type is card's speed mode, right..it's important.
In IP Databook, not mentioned about HS200 or HS400, but i thinks it doesn't 
need to set USE_HOLD_REG.
Because higher speed mode than 50MHz should be required the lowest input hold 
time. (~0.8ns)

> 
>> We need to check phase shift scheme..but as i knew, each SoC have been 
>> implemented differently for phase shift.
>> (Phase shift have dependency to SoC.)
> 
> Given my assumption above we need to check 2 things:
>  * Card type
>  * SoC-specific implementation detail (phase shift scheme)

In Exynos's case, there is CLKSEL register in DWMMC IP register.(as Vendor 
specific register.)
On other hands, rockchip is handling the phase sfiht with "clk_set_phase()"(as 
CMU.)

I can't know everything how they're implementing for shifting phase..

> 
>> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
>> (It described whether IP have hold register or not)
> 
> Ah actually 3 things
>  + IMPLEMENT_HOLD_REG

Almost all have IMPLEMENT_HOLD_REG...?

If i will implement... in dw-mmc.c

switch (ios->timing) {
case SDR50/DDR50/.../
if (check cclk_in_drv > 0 for each SoC) {
SDMMC_CMD_USE_HOLD_REG is set to 1
break;
}
case SDR12/SD25
SDMMC_CMD_USE_HOLD_REG is set to 1
default:
SDMMC_CMD_USE_HOLD_REG is set to 0.
}


> 
>> I didn't read this thread entirely.
>> I'm not sure what you have discussed..but my understanding is right..i 
>> recommend to use "snps,dw-mshc" for ARC compat
>> string.
>> Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the 
>> basic dw-mmc controller functionality.
> 
> Hm, interesting looks like you already made some changes here:
> 

Re: ARC dw-mshc binding compat string

[Jaehoon Chung]

On 03/28/2016 07:55 PM, Alexey Brodkin wrote:
> Hi Jaehoon,
> 
> On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote:
>> Hi,
> 
> [snip]
> 
>
> That said, I would rather prefer to see "snps,dw-mshc" prefix on 
> description
> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
> seems
> to be redundant.
>> Yes..it's redundant..i should be combined to "snps,dw-mshc".
> 
> So for socfpga platform compat string should be something like 
> "snps,dw-mshc-socfpga" then?

i think yes..since there is no SoC specific feature, isn't?

> 
>>>

>
>>
>>>

 According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
 "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
 "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
 while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
 one needs it as well, but most likely yes.

 I wonder if that bit is needed on some particular version of the DWMMC
 core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
 binding ? Or should we use DT property to discern the need for this 
 bit ?

>>> That's the most common way to take into account peculiarities, add
>>> a property and handle it from the driver.
>> And by "that" you mean which of those two I listed , the
>> "snps,dw-mshc-vN" or adding new DT prop ?
>>
> I meant to add a new property, not a new compatible, but that's just
> my experience.
>
> Let me say it __might__ happen that a particular change you need is
> specific to a particular version of the DWMMC IP (query Synopsys
> by the way), but more probably it might be e.g. the same IP version with
> a different reduced or extended configuration or a minor fix/improvement
> to the IP block without resulting version number bump.
>
> For example I don't remember that errata fixes in IP blocks result in
> a new compatible, instead there are quite common optional "quirk"
> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
 Right, this very much matches how I see it as well. Thanks for confirming.

 Alexey, can you tell us if the requirement for setting
 SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
 disappeared with some revision OR if this is some configuration
 option of the core during synthesis ?
>>> Sorry for not following that discussion during my weekend but I'll try
>>> to address all questions now.
>> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using 
>> continuously.
>> But it's difficult to use the generic feature..because it's considered the 
>> below things.
>>
>> If Card is SDR50/SDR104/DDR50 mode..
>>  1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
>> is set to 0,
>>  2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
>> is set to 1,
>> If Card is SDR12/SDR25 mode, then this bit is set to 1.
> 
> So card type is also important here and for certain card type we don't need to
> set SDMMC_CMD_USE_HOLD_REG, right?

If you means card-type is card's speed mode, right..it's important.
In IP Databook, not mentioned about HS200 or HS400, but i thinks it doesn't 
need to set USE_HOLD_REG.
Because higher speed mode than 50MHz should be required the lowest input hold 
time. (~0.8ns)

> 
>> We need to check phase shift scheme..but as i knew, each SoC have been 
>> implemented differently for phase shift.
>> (Phase shift have dependency to SoC.)
> 
> Given my assumption above we need to check 2 things:
>  * Card type
>  * SoC-specific implementation detail (phase shift scheme)

In Exynos's case, there is CLKSEL register in DWMMC IP register.(as Vendor 
specific register.)
On other hands, rockchip is handling the phase sfiht with "clk_set_phase()"(as 
CMU.)

I can't know everything how they're implementing for shifting phase..

> 
>> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
>> (It described whether IP have hold register or not)
> 
> Ah actually 3 things
>  + IMPLEMENT_HOLD_REG

Almost all have IMPLEMENT_HOLD_REG...?

If i will implement... in dw-mmc.c

switch (ios->timing) {
case SDR50/DDR50/.../
if (check cclk_in_drv > 0 for each SoC) {
SDMMC_CMD_USE_HOLD_REG is set to 1
break;
}
case SDR12/SD25
SDMMC_CMD_USE_HOLD_REG is set to 1
default:
SDMMC_CMD_USE_HOLD_REG is set to 0.
}


> 
>> I didn't read this thread entirely.
>> I'm not sure what you have discussed..but my understanding is right..i 
>> recommend to use "snps,dw-mshc" for ARC compat
>> string.
>> Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the 
>> basic dw-mmc controller functionality.
> 
> Hm, interesting looks like you already made some changes here:
> 

Re: [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats

[Grumbach, Emmanuel]

On Mon, 2016-03-28 at 12:33 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> isr_stats is written twice with the same value, remove one of the
> redundant assignments to isr_stats.
> 
> Signed-off-by: Colin Ian King 
> ---


Applied - thanks.

>  drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index 4be3c35..253e4f0 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq,
> void *dev_id)
>   struct msix_entry *entry = dev_id;
>   struct iwl_trans_pcie *trans_pcie =
> iwl_pcie_get_trans_pcie(entry);
>   struct iwl_trans *trans = trans_pcie->trans;
> - struct isr_statistics *isr_stats = isr_stats = _pcie
> ->isr_stats;
> + struct isr_statistics *isr_stats = _pcie->isr_stats;
>   u32 inta_fh, inta_hw;
>  
>   lock_map_acquire(>sync_cmd_lockdep_map);

Re: [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats

[Grumbach, Emmanuel]

On Mon, 2016-03-28 at 12:33 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> isr_stats is written twice with the same value, remove one of the
> redundant assignments to isr_stats.
> 
> Signed-off-by: Colin Ian King 
> ---


Applied - thanks.

>  drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index 4be3c35..253e4f0 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq,
> void *dev_id)
>   struct msix_entry *entry = dev_id;
>   struct iwl_trans_pcie *trans_pcie =
> iwl_pcie_get_trans_pcie(entry);
>   struct iwl_trans *trans = trans_pcie->trans;
> - struct isr_statistics *isr_stats = isr_stats = _pcie
> ->isr_stats;
> + struct isr_statistics *isr_stats = _pcie->isr_stats;
>   u32 inta_fh, inta_hw;
>  
>   lock_map_acquire(>sync_cmd_lockdep_map);

Re: Warnings for invalid VDD (sdhci-s3c)

[Anand Moon]

Hi Krzysztof,

On 28 March 2016 at 11:03, Krzysztof Kozlowski  wrote:
> On 27.03.2016 16:41, Anand Moon wrote:
>>
>> On My Odroid U3 with debug flags enable I am observing bellow deadlock.
>
> There is a sleep in atomic context and possible deadlock, but:
> 1. Are you sure it does not happen without the patch?

I have tested this with this patch applied.

> 2. Are you sure it is not the same as already known issue on sdhci-s3c?
> For example reported here:
> http://www.spinics.net/lists/linux-samsung-soc/msg42398.html

Ok this is know issue.

>
> What is reproducibility rate?

It's reproducible intermediately.
If I am doing some thing wrong please ignore this.
Attach is the config options.

Best Regards.
-Anand Moon

>
> Best regards,
> Krzysztof
>
>> -
>> [  202.519524] BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:617
>> [  202.522364] in_atomic(): 1, irqs_disabled(): 128, pid: 100, name: mmcqd/0
>> [  202.529129] 1 lock held by mmcqd/0/100:
>> [  202.529150]  #0:  (&(>lock)->rlock#2){-.-...}, at:
>> [] sdhci_do_set_ios+0x1c/0x484
>> [  202.529271] irq event stamp: 703530
>> [  202.529291] hardirqs last  enabled at (703529): []
>> _raw_spin_unlock_irqrestore+0x6c/0x74
>> [  202.529343] hardirqs last disabled at (703530): []
>> _raw_spin_lock_irqsave+0x1c/0x84
>> [  202.529384] softirqs last  enabled at (703456): []
>> __do_softirq+0x244/0x2c0
>> [  202.529438] softirqs last disabled at (703445): []
>> irq_exit+0xec/0x128
>> [  202.529472] Preemption disabled at:[<  (null)>]   (null)
>> [  202.534415]
>> [  202.534449] CPU: 0 PID: 100 Comm: mmcqd/0 Not tainted 4.6.0-rc1-u3s #38
>> [  202.534473] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [  202.534544] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [  202.534594] [] (show_stack) from []
>> (dump_stack+0x98/0xc4)
>> [  202.534639] [] (dump_stack) from []
>> (mutex_lock_nested+0x2c/0x4dc)
>> [  202.534685] [] (mutex_lock_nested) from []
>> (clk_prepare_lock+0x50/0xf8)
>> [  202.534726] [] (clk_prepare_lock) from []
>> (clk_round_rate+0x1c/0x58)
>> [  202.534773] [] (clk_round_rate) from []
>> (sdhci_s3c_set_clock+0x18c/0x1b0)
>> [  202.534819] [] (sdhci_s3c_set_clock) from []
>> (sdhci_cmu_set_clock+0x24/0x17c)
>> [  202.534860] [] (sdhci_cmu_set_clock) from []
>> (sdhci_do_set_ios+0x78/0x484)
>> [  202.534904] [] (sdhci_do_set_ios) from []
>> (sdhci_runtime_resume_host+0x60/0x114)
>> [  202.534957] [] (sdhci_runtime_resume_host) from
>> [] (__rpm_callback+0x2c/0x60)
>> [  202.535000] [] (__rpm_callback) from []
>> (rpm_callback+0x54/0x80)
>> [  202.535041] [] (rpm_callback) from []
>> (rpm_resume+0x364/0x558)
>> [  202.535081] [] (rpm_resume) from []
>> (__pm_runtime_resume+0x60/0x8c)
>> [  202.535125] [] (__pm_runtime_resume) from []
>> (__mmc_claim_host+0x1b4/0x1f8)
>> [  202.535176] [] (__mmc_claim_host) from []
>> (mmc_sd_runtime_resume+0x20/0xac)
>> [  202.535220] [] (mmc_sd_runtime_resume) from []
>> (__rpm_callback+0x2c/0x60)
>> [  202.535259] [] (__rpm_callback) from []
>> (rpm_callback+0x54/0x80)
>> [  202.535299] [] (rpm_callback) from []
>> (rpm_resume+0x364/0x558)
>> [  202.535340] [] (rpm_resume) from []
>> (__pm_runtime_resume+0x60/0x8c)
>> [  202.535379] [] (__pm_runtime_resume) from []
>> (mmc_get_card+0x14/0x24)
>> [  202.535420] [] (mmc_get_card) from []
>> (mmc_blk_issue_rq+0x258/0x4f0)
>> [  202.535461] [] (mmc_blk_issue_rq) from []
>> (mmc_queue_thread+0xd0/0x1d8)
>> [  202.535513] [] (mmc_queue_thread) from []
>> (kthread+0xf4/0x10c)
>> [  202.535561] [] (kthread) from []
>> (ret_from_fork+0x14/0x24)
>> [  202.535624]
>> [  202.535893] ==
>> [  202.542059] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
>> [  202.548742] 4.6.0-rc1-u3s #38 Not tainted
>> [  202.552732] --
>> [  202.558902] mmcqd/0/100 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
>> [  202.565317]  (prepare_lock){+.+...}, at: []
>> clk_prepare_lock+0x50/0xf8
>> [  202.572695]
>> [  202.572695] and this task is already holding:
>> [  202.578510]  (&(>lock)->rlock#2){-.-...}, at: []
>> sdhci_do_set_ios+0x1c/0x484
>> [  202.586930] which would create a new lock dependency:
>> [  202.591964]  (&(>lock)->rlock#2){-.-...} -> (prepare_lock){+.+...}
>> [  202.598650]
>> [  202.598650] but this new dependency connects a HARDIRQ-irq-safe lock:
>> [  202.606546]  (&(>lock)->rlock#2){-.-...}
>> [  202.606546] ... which became HARDIRQ-irq-safe at:
>> [  202.614359]   [] _raw_spin_lock+0x3c/0x74
>> [  202.619219]   [] sdhci_irq+0x1c/0x814
>> [  202.623732]   [] handle_irq_event_percpu+0x9c/0x150
>> [  202.629461]   [] handle_irq_event+0x38/0x5c
>> [  202.634495]   [] handle_fasteoi_irq+0xd0/0x1a8
>> [  202.639790]   [] generic_handle_irq+0x24/0x34
>> [  202.644998]   [] 

Re: Warnings for invalid VDD (sdhci-s3c)

[Anand Moon]

Hi Krzysztof,

On 28 March 2016 at 11:03, Krzysztof Kozlowski  wrote:
> On 27.03.2016 16:41, Anand Moon wrote:
>>
>> On My Odroid U3 with debug flags enable I am observing bellow deadlock.
>
> There is a sleep in atomic context and possible deadlock, but:
> 1. Are you sure it does not happen without the patch?

I have tested this with this patch applied.

> 2. Are you sure it is not the same as already known issue on sdhci-s3c?
> For example reported here:
> http://www.spinics.net/lists/linux-samsung-soc/msg42398.html

Ok this is know issue.

>
> What is reproducibility rate?

It's reproducible intermediately.
If I am doing some thing wrong please ignore this.
Attach is the config options.

Best Regards.
-Anand Moon

>
> Best regards,
> Krzysztof
>
>> -
>> [  202.519524] BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:617
>> [  202.522364] in_atomic(): 1, irqs_disabled(): 128, pid: 100, name: mmcqd/0
>> [  202.529129] 1 lock held by mmcqd/0/100:
>> [  202.529150]  #0:  (&(>lock)->rlock#2){-.-...}, at:
>> [] sdhci_do_set_ios+0x1c/0x484
>> [  202.529271] irq event stamp: 703530
>> [  202.529291] hardirqs last  enabled at (703529): []
>> _raw_spin_unlock_irqrestore+0x6c/0x74
>> [  202.529343] hardirqs last disabled at (703530): []
>> _raw_spin_lock_irqsave+0x1c/0x84
>> [  202.529384] softirqs last  enabled at (703456): []
>> __do_softirq+0x244/0x2c0
>> [  202.529438] softirqs last disabled at (703445): []
>> irq_exit+0xec/0x128
>> [  202.529472] Preemption disabled at:[<  (null)>]   (null)
>> [  202.534415]
>> [  202.534449] CPU: 0 PID: 100 Comm: mmcqd/0 Not tainted 4.6.0-rc1-u3s #38
>> [  202.534473] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [  202.534544] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [  202.534594] [] (show_stack) from []
>> (dump_stack+0x98/0xc4)
>> [  202.534639] [] (dump_stack) from []
>> (mutex_lock_nested+0x2c/0x4dc)
>> [  202.534685] [] (mutex_lock_nested) from []
>> (clk_prepare_lock+0x50/0xf8)
>> [  202.534726] [] (clk_prepare_lock) from []
>> (clk_round_rate+0x1c/0x58)
>> [  202.534773] [] (clk_round_rate) from []
>> (sdhci_s3c_set_clock+0x18c/0x1b0)
>> [  202.534819] [] (sdhci_s3c_set_clock) from []
>> (sdhci_cmu_set_clock+0x24/0x17c)
>> [  202.534860] [] (sdhci_cmu_set_clock) from []
>> (sdhci_do_set_ios+0x78/0x484)
>> [  202.534904] [] (sdhci_do_set_ios) from []
>> (sdhci_runtime_resume_host+0x60/0x114)
>> [  202.534957] [] (sdhci_runtime_resume_host) from
>> [] (__rpm_callback+0x2c/0x60)
>> [  202.535000] [] (__rpm_callback) from []
>> (rpm_callback+0x54/0x80)
>> [  202.535041] [] (rpm_callback) from []
>> (rpm_resume+0x364/0x558)
>> [  202.535081] [] (rpm_resume) from []
>> (__pm_runtime_resume+0x60/0x8c)
>> [  202.535125] [] (__pm_runtime_resume) from []
>> (__mmc_claim_host+0x1b4/0x1f8)
>> [  202.535176] [] (__mmc_claim_host) from []
>> (mmc_sd_runtime_resume+0x20/0xac)
>> [  202.535220] [] (mmc_sd_runtime_resume) from []
>> (__rpm_callback+0x2c/0x60)
>> [  202.535259] [] (__rpm_callback) from []
>> (rpm_callback+0x54/0x80)
>> [  202.535299] [] (rpm_callback) from []
>> (rpm_resume+0x364/0x558)
>> [  202.535340] [] (rpm_resume) from []
>> (__pm_runtime_resume+0x60/0x8c)
>> [  202.535379] [] (__pm_runtime_resume) from []
>> (mmc_get_card+0x14/0x24)
>> [  202.535420] [] (mmc_get_card) from []
>> (mmc_blk_issue_rq+0x258/0x4f0)
>> [  202.535461] [] (mmc_blk_issue_rq) from []
>> (mmc_queue_thread+0xd0/0x1d8)
>> [  202.535513] [] (mmc_queue_thread) from []
>> (kthread+0xf4/0x10c)
>> [  202.535561] [] (kthread) from []
>> (ret_from_fork+0x14/0x24)
>> [  202.535624]
>> [  202.535893] ==
>> [  202.542059] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
>> [  202.548742] 4.6.0-rc1-u3s #38 Not tainted
>> [  202.552732] --
>> [  202.558902] mmcqd/0/100 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
>> [  202.565317]  (prepare_lock){+.+...}, at: []
>> clk_prepare_lock+0x50/0xf8
>> [  202.572695]
>> [  202.572695] and this task is already holding:
>> [  202.578510]  (&(>lock)->rlock#2){-.-...}, at: []
>> sdhci_do_set_ios+0x1c/0x484
>> [  202.586930] which would create a new lock dependency:
>> [  202.591964]  (&(>lock)->rlock#2){-.-...} -> (prepare_lock){+.+...}
>> [  202.598650]
>> [  202.598650] but this new dependency connects a HARDIRQ-irq-safe lock:
>> [  202.606546]  (&(>lock)->rlock#2){-.-...}
>> [  202.606546] ... which became HARDIRQ-irq-safe at:
>> [  202.614359]   [] _raw_spin_lock+0x3c/0x74
>> [  202.619219]   [] sdhci_irq+0x1c/0x814
>> [  202.623732]   [] handle_irq_event_percpu+0x9c/0x150
>> [  202.629461]   [] handle_irq_event+0x38/0x5c
>> [  202.634495]   [] handle_fasteoi_irq+0xd0/0x1a8
>> [  202.639790]   [] generic_handle_irq+0x24/0x34
>> [  202.644998]   [] __handle_domain_irq+0x7c/0xec
>> [  

[PATCH 0/5 v5] drm: Add support of ARC PGU display controller

[Alexey Brodkin]

This series add support of ARC PGU display controller.
ARC PGU is a quite simple byte streamer that gets data from the framebuffer
and pushes it to hte connected encoder (DP or HDMI).

It was tested on ARC SDP boards (axs101/103 in particular).

Note following series that introduces
drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite
now: https://lkml.org/lkml/2016/3/23/61

Changes v4 -> v5:
 * Removed encode node from DT bindings example (as suggested by Rob)

Changes v3 -> v4:
 * Main driver author is now set properly (thanks Carlos for all your efforts)
 * Implemented correct hsync and vsync setup (thanks Jose)
 * Dummy call-backs were removed (as suggested by Daniel)
 * Obsolete load()/unload() call-backs were removed (as suggested by Daniel)
 * With above in mind we were able to adopt recently introduced
   drm_connector_register_all()/drm_connector_unregister_all()
 * Implemented setup of properties (uncached) for FB user-pages
 * Minor clean-up in DT binding docs and axs10x_mb.dtsi

Changes v2 -> v3:
 * Improved failure path if arcpgu_connector wasn't allocated.
 * Fixed driver building as module.
 * Implemented uncached mapping of user-space FB pages.
 * Again updated DT bindings docs.

Changes v1 -> v2:
 * Clean-up of DT bindings documentation.
 * Added missing "pxlclk" clock in axs10x_mb.dtsi.

Cc: David Airlie 
Cc: devicet...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: linux-snps-...@lists.infradead.org
Cc: Mark Rutland 
Cc: Pawel Moll 
Cc: Rob Herring 
Cc: Vineet Gupta 
Cc: Jose Abreu 
Cc: Carlos Palminha 

Alexey Brodkin (4):
  drm: Add DT bindings documentation for ARC PGU display controller
  MAINTAINERS: Add maintainer for ARC PGU display controller
  arc: Add our own implementation of fb_pgprotect()
  arc: axs10x - add support of ARC PGU

Carlos Palminha (1):
  drm: Add support of ARC PGU display controller

 .../devicetree/bindings/display/snps,arcpgu.txt|  35 +++
 MAINTAINERS|   6 +
 arch/arc/boot/dts/axs10x_mb.dtsi   |  61 +
 arch/arc/include/asm/fb.h  |  19 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/arc/Kconfig|  10 +
 drivers/gpu/drm/arc/Makefile   |   2 +
 drivers/gpu/drm/arc/arcpgu.h   |  50 
 drivers/gpu/drm/arc/arcpgu_crtc.c  | 257 +++
 drivers/gpu/drm/arc/arcpgu_drv.c   | 282 +
 drivers/gpu/drm/arc/arcpgu_hdmi.c  | 201 +++
 drivers/gpu/drm/arc/arcpgu_regs.h  |  40 +++
 13 files changed, 966 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
 create mode 100644 arch/arc/include/asm/fb.h
 create mode 100644 drivers/gpu/drm/arc/Kconfig
 create mode 100644 drivers/gpu/drm/arc/Makefile
 create mode 100644 drivers/gpu/drm/arc/arcpgu.h
 create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h

-- 
2.5.0

[PATCH 4/5 v5] arc: Add our own implementation of fb_pgprotect()

[Alexey Brodkin]

During mmaping of frame-buffer pages to user-space
fb_protect() is called to set proper page settings.

In case of ARC we need to mark pages that are mmaped to
user as uncached because of 2 reasons:
 * Huge amount of data if passing through data cache will
   thrash cache a lot making cache almost useless for other
   less traffic hungry processes.
 * Data written by user in FB will be immediately available for
   hardware (such as PGU etc) without requirements to flush data
   cache regularly.

Signed-off-by: Alexey Brodkin 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
---

No changes v4 -> v5.

Changes v3 -> v4:
 * This change was introduced only in v4.

 arch/arc/include/asm/fb.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 arch/arc/include/asm/fb.h

diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
new file mode 100644
index 000..bd3f68c
--- /dev/null
+++ b/arch/arc/include/asm/fb.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_FB_H_
+#define _ASM_FB_H_
+
+#include 
+#include 
+#include 
+
+static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
+   unsigned long off)
+{
+   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+}
+
+static inline int fb_is_primary_device(struct fb_info *info)
+{
+   return 0;
+}
+
+#endif /* _ASM_FB_H_ */
-- 
2.5.0

[PATCH 3/5 v5] MAINTAINERS: Add maintainer for ARC PGU display controller

[Alexey Brodkin]

This updates MAINTEINERS file with information about maintainer of
ARC PGU display controller driver.

Signed-off-by: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
---

No changes v4 -> v5.

No changes v3 -> v4.

No changes v2 -> v3.

No changes v1 -> v2.

 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ea1d1de..0dcba67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -827,6 +827,12 @@ S: Maintained
 F: drivers/net/arcnet/
 F: include/uapi/linux/if_arcnet.h
 
+ARC PGU DRM DRIVER
+M: Alexey Brodkin 
+S: Supported
+F: drivers/gpu/drm/arc/
+F: Documentation/devicetree/bindings/display/snps,arcpgu.txt
+
 ARM HDLCD DRM DRIVER
 M: Liviu Dudau 
 S: Supported
-- 
2.5.0

[PATCH 0/5 v5] drm: Add support of ARC PGU display controller

[Alexey Brodkin]

This series add support of ARC PGU display controller.
ARC PGU is a quite simple byte streamer that gets data from the framebuffer
and pushes it to hte connected encoder (DP or HDMI).

It was tested on ARC SDP boards (axs101/103 in particular).

Note following series that introduces
drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite
now: https://lkml.org/lkml/2016/3/23/61

Changes v4 -> v5:
 * Removed encode node from DT bindings example (as suggested by Rob)

Changes v3 -> v4:
 * Main driver author is now set properly (thanks Carlos for all your efforts)
 * Implemented correct hsync and vsync setup (thanks Jose)
 * Dummy call-backs were removed (as suggested by Daniel)
 * Obsolete load()/unload() call-backs were removed (as suggested by Daniel)
 * With above in mind we were able to adopt recently introduced
   drm_connector_register_all()/drm_connector_unregister_all()
 * Implemented setup of properties (uncached) for FB user-pages
 * Minor clean-up in DT binding docs and axs10x_mb.dtsi

Changes v2 -> v3:
 * Improved failure path if arcpgu_connector wasn't allocated.
 * Fixed driver building as module.
 * Implemented uncached mapping of user-space FB pages.
 * Again updated DT bindings docs.

Changes v1 -> v2:
 * Clean-up of DT bindings documentation.
 * Added missing "pxlclk" clock in axs10x_mb.dtsi.

Cc: David Airlie 
Cc: devicet...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: linux-snps-...@lists.infradead.org
Cc: Mark Rutland 
Cc: Pawel Moll 
Cc: Rob Herring 
Cc: Vineet Gupta 
Cc: Jose Abreu 
Cc: Carlos Palminha 

Alexey Brodkin (4):
  drm: Add DT bindings documentation for ARC PGU display controller
  MAINTAINERS: Add maintainer for ARC PGU display controller
  arc: Add our own implementation of fb_pgprotect()
  arc: axs10x - add support of ARC PGU

Carlos Palminha (1):
  drm: Add support of ARC PGU display controller

 .../devicetree/bindings/display/snps,arcpgu.txt|  35 +++
 MAINTAINERS|   6 +
 arch/arc/boot/dts/axs10x_mb.dtsi   |  61 +
 arch/arc/include/asm/fb.h  |  19 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/arc/Kconfig|  10 +
 drivers/gpu/drm/arc/Makefile   |   2 +
 drivers/gpu/drm/arc/arcpgu.h   |  50 
 drivers/gpu/drm/arc/arcpgu_crtc.c  | 257 +++
 drivers/gpu/drm/arc/arcpgu_drv.c   | 282 +
 drivers/gpu/drm/arc/arcpgu_hdmi.c  | 201 +++
 drivers/gpu/drm/arc/arcpgu_regs.h  |  40 +++
 13 files changed, 966 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
 create mode 100644 arch/arc/include/asm/fb.h
 create mode 100644 drivers/gpu/drm/arc/Kconfig
 create mode 100644 drivers/gpu/drm/arc/Makefile
 create mode 100644 drivers/gpu/drm/arc/arcpgu.h
 create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h

-- 
2.5.0

[PATCH 4/5 v5] arc: Add our own implementation of fb_pgprotect()

[Alexey Brodkin]

During mmaping of frame-buffer pages to user-space
fb_protect() is called to set proper page settings.

In case of ARC we need to mark pages that are mmaped to
user as uncached because of 2 reasons:
 * Huge amount of data if passing through data cache will
   thrash cache a lot making cache almost useless for other
   less traffic hungry processes.
 * Data written by user in FB will be immediately available for
   hardware (such as PGU etc) without requirements to flush data
   cache regularly.

Signed-off-by: Alexey Brodkin 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
---

No changes v4 -> v5.

Changes v3 -> v4:
 * This change was introduced only in v4.

 arch/arc/include/asm/fb.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 arch/arc/include/asm/fb.h

diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
new file mode 100644
index 000..bd3f68c
--- /dev/null
+++ b/arch/arc/include/asm/fb.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_FB_H_
+#define _ASM_FB_H_
+
+#include 
+#include 
+#include 
+
+static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
+   unsigned long off)
+{
+   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+}
+
+static inline int fb_is_primary_device(struct fb_info *info)
+{
+   return 0;
+}
+
+#endif /* _ASM_FB_H_ */
-- 
2.5.0

[PATCH 3/5 v5] MAINTAINERS: Add maintainer for ARC PGU display controller

[Alexey Brodkin]

This updates MAINTEINERS file with information about maintainer of
ARC PGU display controller driver.

Signed-off-by: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
---

No changes v4 -> v5.

No changes v3 -> v4.

No changes v2 -> v3.

No changes v1 -> v2.

 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ea1d1de..0dcba67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -827,6 +827,12 @@ S: Maintained
 F: drivers/net/arcnet/
 F: include/uapi/linux/if_arcnet.h
 
+ARC PGU DRM DRIVER
+M: Alexey Brodkin 
+S: Supported
+F: drivers/gpu/drm/arc/
+F: Documentation/devicetree/bindings/display/snps,arcpgu.txt
+
 ARM HDLCD DRM DRIVER
 M: Liviu Dudau 
 S: Supported
-- 
2.5.0

[PATCH 2/5 v5] drm: Add DT bindings documentation for ARC PGU display controller

[Alexey Brodkin]

This add DT bindings documentation for ARC PGU display controller.

Signed-off-by: Alexey Brodkin 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Acked-by: Rob Herring 
---

Changes v4 -> v5: (addressing Rob's comment)
 * Added Rob's acked-by
 * Remove "encoder-slave" from the example as well.
   Now only "pgu" node is mentioned in the example.

Changes v3 -> v4: (addressing Rob's comments)
 * Removed "encoder-slave" from required properties
 * Removed "0x" from node names

Changes v2 -> v3:
 * Reverted back to initial larger version of example
   with minor fixes (thanks Rob for spotting those).

Changes v1 -> v2:
 * Removed everything except PGU node itself.

 .../devicetree/bindings/display/snps,arcpgu.txt| 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt

diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
new file mode 100644
index 000..c5c7dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
@@ -0,0 +1,35 @@
+ARC PGU
+
+This is a display controller found on several development boards produced
+by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
+framebuffer and sends it to a single digital encoder (usually HDMI).
+
+Required properties:
+  - compatible: "snps,arcpgu"
+  - reg: Physical base address and length of the controller's registers.
+  - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+  - clock-names: A list of clock names. For ARC PGU it should contain:
+  - "pxlclk" for the clock feeding the output PLL of the controller.
+
+Required sub-nodes:
+  - port: The PGU connection to an encoder chip.
+
+Example:
+
+/ {
+   ...
+
+   pgu@ {
+   compatible = "snps,arcpgu";
+   reg = <0x 0x400>;
+   clocks = <_node>;
+   clock-names = "pxlclk";
+
+   port {
+   pgu_output: endpoint {
+   remote-endpoint = <_enc_input>;
+   };
+   };
+   };
+};
-- 
2.5.0

[PATCH 2/5 v5] drm: Add DT bindings documentation for ARC PGU display controller

[Alexey Brodkin]

This add DT bindings documentation for ARC PGU display controller.

Signed-off-by: Alexey Brodkin 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Acked-by: Rob Herring 
---

Changes v4 -> v5: (addressing Rob's comment)
 * Added Rob's acked-by
 * Remove "encoder-slave" from the example as well.
   Now only "pgu" node is mentioned in the example.

Changes v3 -> v4: (addressing Rob's comments)
 * Removed "encoder-slave" from required properties
 * Removed "0x" from node names

Changes v2 -> v3:
 * Reverted back to initial larger version of example
   with minor fixes (thanks Rob for spotting those).

Changes v1 -> v2:
 * Removed everything except PGU node itself.

 .../devicetree/bindings/display/snps,arcpgu.txt| 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt

diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
new file mode 100644
index 000..c5c7dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
@@ -0,0 +1,35 @@
+ARC PGU
+
+This is a display controller found on several development boards produced
+by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
+framebuffer and sends it to a single digital encoder (usually HDMI).
+
+Required properties:
+  - compatible: "snps,arcpgu"
+  - reg: Physical base address and length of the controller's registers.
+  - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+  - clock-names: A list of clock names. For ARC PGU it should contain:
+  - "pxlclk" for the clock feeding the output PLL of the controller.
+
+Required sub-nodes:
+  - port: The PGU connection to an encoder chip.
+
+Example:
+
+/ {
+   ...
+
+   pgu@ {
+   compatible = "snps,arcpgu";
+   reg = <0x 0x400>;
+   clocks = <_node>;
+   clock-names = "pxlclk";
+
+   port {
+   pgu_output: endpoint {
+   remote-endpoint = <_enc_input>;
+   };
+   };
+   };
+};
-- 
2.5.0

[PATCH 5/5 v5] arc: axs10x - add support of ARC PGU

[Alexey Brodkin]

Synopsys DesignWare ARC SDP boards sport ARC SDP display
controller attached to ADV7511 HDMI encoder.

That change adds desctiption of both ARC PGU and ADV7511 in
ARC SDP'd base-board Device Tree.

Signed-off-by: Alexey Brodkin 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Vineet Gupta 
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
---

No changes v4 -> v5.

Changes v3 -> v4:
 * Removed "0x" from node names (as suggested by Rob)

No changes v2 -> v3.

Changes v1 -> v2:
 * Added missing "pxlclk" clock in axs10x_mb.dtsi

 arch/arc/boot/dts/axs10x_mb.dtsi | 61 
 1 file changed, 61 insertions(+)

diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 44a578c..8fee596 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -34,6 +34,12 @@
clock-frequency = <5000>;
#clock-cells = <0>;
};
+
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <7444>;
+   };
};
 
ethernet@0x18000 {
@@ -147,6 +153,37 @@
clocks = <>;
interrupts = <16>;
 
+   adv7511:adv7511@39{
+   compatible="adi,adv7511";
+   reg = <0x39>;
+   interrupts = <23>;
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,clock-delay = <0x03>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* RGB/YUV input */
+   port@0 {
+   reg = <0>;
+   adv7511_input:endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+
+   /* HDMI output */
+   port@1 {
+   reg = <1>;
+   adv7511_output: endpoint {
+   remote-endpoint = 
<_connector_in>;
+   };
+   };
+   };
+   };
+
eeprom@0x54{
compatible = "24c01";
reg = <0x54>;
@@ -160,6 +197,16 @@
};
};
 
+   hdmi0: connector {
+   compatible = "hdmi-connector";
+   type = "a";
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+   };
+
gpio0:gpio@13000 {
compatible = "snps,dw-apb-gpio";
reg = <0x13000 0x1000>;
@@ -221,5 +268,19 @@
reg = <2>;
};
};
+
+   pgu@17000 {
+   compatible = "snps,arcpgu";
+   reg = <0x17000 0x400>;
+   encoder-slave = <>;
+   clocks = <>;
+   clock-names = "pxlclk";
+
+   port {
+   pgu_output: endpoint {
+   remote-endpoint = <_input>;
+   };
+   };
+   };
};
 };
-- 
2.5.0

[PATCH 1/5 v5] drm: Add support of ARC PGU display controller

[Alexey Brodkin]

From: Carlos Palminha 

ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.

Signed-off-by: Carlos Palminha 
Signed-off-by: Alexey Brodkin 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-snps-...@lists.infradead.org
---

Note following series that introduces
drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite
now: https://lkml.org/lkml/2016/3/23/61

No changes v4 -> v5.

Changes v3 -> v4:
 * The driver author is now set properly (thanks Carlos for all your efforts)
 * Implemented correct hsync and vsync setup (thanks Jose)
 * Dummy call-backs were removed (as suggested by Daniel)
 * Obsolete load()/unload() call-backs were removed (as suggested by Daniel)
 * With above in mind we were able to adopt recently introduced
   drm_connector_register_all()/drm_connector_unregister_all()

Changes v2 -> v3:
 * Improved failure path if arcpgu_connector wasn't allocated (thanks Jose).
 * Fixed driver building as module (reported by 0-DAY kernel test infrastruct.)
 * Implemented uncached mapping of user-space FB pages.

No changes v1 -> v2.

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/arc/Kconfig   |  10 ++
 drivers/gpu/drm/arc/Makefile  |   2 +
 drivers/gpu/drm/arc/arcpgu.h  |  50 +++
 drivers/gpu/drm/arc/arcpgu_crtc.c | 257 ++
 drivers/gpu/drm/arc/arcpgu_drv.c  | 282 ++
 drivers/gpu/drm/arc/arcpgu_hdmi.c | 201 +++
 drivers/gpu/drm/arc/arcpgu_regs.h |  40 ++
 9 files changed, 845 insertions(+)
 create mode 100644 drivers/gpu/drm/arc/Kconfig
 create mode 100644 drivers/gpu/drm/arc/Makefile
 create mode 100644 drivers/gpu/drm/arc/arcpgu.h
 create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f2a74d0..9e4f2f1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -281,3 +281,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/arc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6eb94fc..c338d04 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,3 +78,4 @@ obj-y += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_ARCPGU)+= arc/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
new file mode 100644
index 000..f9a13b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/Kconfig
@@ -0,0 +1,10 @@
+config DRM_ARCPGU
+   tristate "ARC PGU"
+   depends on DRM && OF
+   select DRM_KMS_CMA_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_HELPER
+   help
+ Choose this option if you have an ARC PGU controller.
+
+ If M is selected the module will be called arcpgu.
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
new file mode 100644
index 000..d48fda7
--- /dev/null
+++ b/drivers/gpu/drm/arc/Makefile
@@ -0,0 +1,2 @@
+arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_drv.o
+obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
new file mode 100644
index 000..86574b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -0,0 +1,50 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _ARCPGU_H_
+#define _ARCPGU_H_
+
+struct arcpgu_drm_private {
+   void __iomem*regs;
+   struct clk  *clk;
+   struct drm_fbdev_cma*fbdev;
+   struct drm_framebuffer  *fb;
+   struct list_headevent_list;
+   struct drm_crtc crtc;
+   struct drm_plane*plane;
+};
+
+#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
+
+static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
+unsigned int reg, u32 value)
+{
+   iowrite32(value, arcpgu->regs + reg);
+}
+
+static 

[PATCH 5/5 v5] arc: axs10x - add support of ARC PGU

[Alexey Brodkin]

Synopsys DesignWare ARC SDP boards sport ARC SDP display
controller attached to ADV7511 HDMI encoder.

That change adds desctiption of both ARC PGU and ADV7511 in
ARC SDP'd base-board Device Tree.

Signed-off-by: Alexey Brodkin 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Vineet Gupta 
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
---

No changes v4 -> v5.

Changes v3 -> v4:
 * Removed "0x" from node names (as suggested by Rob)

No changes v2 -> v3.

Changes v1 -> v2:
 * Added missing "pxlclk" clock in axs10x_mb.dtsi

 arch/arc/boot/dts/axs10x_mb.dtsi | 61 
 1 file changed, 61 insertions(+)

diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 44a578c..8fee596 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -34,6 +34,12 @@
clock-frequency = <5000>;
#clock-cells = <0>;
};
+
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <7444>;
+   };
};
 
ethernet@0x18000 {
@@ -147,6 +153,37 @@
clocks = <>;
interrupts = <16>;
 
+   adv7511:adv7511@39{
+   compatible="adi,adv7511";
+   reg = <0x39>;
+   interrupts = <23>;
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,clock-delay = <0x03>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* RGB/YUV input */
+   port@0 {
+   reg = <0>;
+   adv7511_input:endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+
+   /* HDMI output */
+   port@1 {
+   reg = <1>;
+   adv7511_output: endpoint {
+   remote-endpoint = 
<_connector_in>;
+   };
+   };
+   };
+   };
+
eeprom@0x54{
compatible = "24c01";
reg = <0x54>;
@@ -160,6 +197,16 @@
};
};
 
+   hdmi0: connector {
+   compatible = "hdmi-connector";
+   type = "a";
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+   };
+
gpio0:gpio@13000 {
compatible = "snps,dw-apb-gpio";
reg = <0x13000 0x1000>;
@@ -221,5 +268,19 @@
reg = <2>;
};
};
+
+   pgu@17000 {
+   compatible = "snps,arcpgu";
+   reg = <0x17000 0x400>;
+   encoder-slave = <>;
+   clocks = <>;
+   clock-names = "pxlclk";
+
+   port {
+   pgu_output: endpoint {
+   remote-endpoint = <_input>;
+   };
+   };
+   };
};
 };
-- 
2.5.0

[PATCH 1/5 v5] drm: Add support of ARC PGU display controller

[Alexey Brodkin]

From: Carlos Palminha 

ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.

Signed-off-by: Carlos Palminha 
Signed-off-by: Alexey Brodkin 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-snps-...@lists.infradead.org
---

Note following series that introduces
drm_connector_register_all()/drm_connector_unregister_all() is a prerequisite
now: https://lkml.org/lkml/2016/3/23/61

No changes v4 -> v5.

Changes v3 -> v4:
 * The driver author is now set properly (thanks Carlos for all your efforts)
 * Implemented correct hsync and vsync setup (thanks Jose)
 * Dummy call-backs were removed (as suggested by Daniel)
 * Obsolete load()/unload() call-backs were removed (as suggested by Daniel)
 * With above in mind we were able to adopt recently introduced
   drm_connector_register_all()/drm_connector_unregister_all()

Changes v2 -> v3:
 * Improved failure path if arcpgu_connector wasn't allocated (thanks Jose).
 * Fixed driver building as module (reported by 0-DAY kernel test infrastruct.)
 * Implemented uncached mapping of user-space FB pages.

No changes v1 -> v2.

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/arc/Kconfig   |  10 ++
 drivers/gpu/drm/arc/Makefile  |   2 +
 drivers/gpu/drm/arc/arcpgu.h  |  50 +++
 drivers/gpu/drm/arc/arcpgu_crtc.c | 257 ++
 drivers/gpu/drm/arc/arcpgu_drv.c  | 282 ++
 drivers/gpu/drm/arc/arcpgu_hdmi.c | 201 +++
 drivers/gpu/drm/arc/arcpgu_regs.h |  40 ++
 9 files changed, 845 insertions(+)
 create mode 100644 drivers/gpu/drm/arc/Kconfig
 create mode 100644 drivers/gpu/drm/arc/Makefile
 create mode 100644 drivers/gpu/drm/arc/arcpgu.h
 create mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_drv.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
 create mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f2a74d0..9e4f2f1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -281,3 +281,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/arc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6eb94fc..c338d04 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,3 +78,4 @@ obj-y += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_ARCPGU)+= arc/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
new file mode 100644
index 000..f9a13b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/Kconfig
@@ -0,0 +1,10 @@
+config DRM_ARCPGU
+   tristate "ARC PGU"
+   depends on DRM && OF
+   select DRM_KMS_CMA_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_HELPER
+   help
+ Choose this option if you have an ARC PGU controller.
+
+ If M is selected the module will be called arcpgu.
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
new file mode 100644
index 000..d48fda7
--- /dev/null
+++ b/drivers/gpu/drm/arc/Makefile
@@ -0,0 +1,2 @@
+arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_drv.o
+obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
new file mode 100644
index 000..86574b6
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -0,0 +1,50 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _ARCPGU_H_
+#define _ARCPGU_H_
+
+struct arcpgu_drm_private {
+   void __iomem*regs;
+   struct clk  *clk;
+   struct drm_fbdev_cma*fbdev;
+   struct drm_framebuffer  *fb;
+   struct list_headevent_list;
+   struct drm_crtc crtc;
+   struct drm_plane*plane;
+};
+
+#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
+
+static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
+unsigned int reg, u32 value)
+{
+   iowrite32(value, arcpgu->regs + reg);
+}
+
+static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
+ 

[PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats

[Colin King]

From: Colin Ian King 

isr_stats is written twice with the same value, remove one of the
redundant assignments to isr_stats.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index 4be3c35..253e4f0 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void 
*dev_id)
struct msix_entry *entry = dev_id;
struct iwl_trans_pcie *trans_pcie = iwl_pcie_get_trans_pcie(entry);
struct iwl_trans *trans = trans_pcie->trans;
-   struct isr_statistics *isr_stats = isr_stats = _pcie->isr_stats;
+   struct isr_statistics *isr_stats = _pcie->isr_stats;
u32 inta_fh, inta_hw;
 
lock_map_acquire(>sync_cmd_lockdep_map);
-- 
2.7.4

[PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats

[Colin King]

From: Colin Ian King 

isr_stats is written twice with the same value, remove one of the
redundant assignments to isr_stats.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index 4be3c35..253e4f0 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void 
*dev_id)
struct msix_entry *entry = dev_id;
struct iwl_trans_pcie *trans_pcie = iwl_pcie_get_trans_pcie(entry);
struct iwl_trans *trans = trans_pcie->trans;
-   struct isr_statistics *isr_stats = isr_stats = _pcie->isr_stats;
+   struct isr_statistics *isr_stats = _pcie->isr_stats;
u32 inta_fh, inta_hw;
 
lock_map_acquire(>sync_cmd_lockdep_map);
-- 
2.7.4

[PATCH v2] hp206c: Initial support for reading sensor values

[Crestez Dan Leonard]

Hello,

Changes since the first version:
* Use data->client instead of to_i2c_client(indio_dev->dev.parent)
* Adjust i2c_check_functionality bits requested.

I also fixed gitconfig so it won't create attachments or suppress cc.

Signed-off-by: Crestez Dan Leonard 
---
 drivers/iio/pressure/Kconfig  |  10 +
 drivers/iio/pressure/Makefile |   1 +
 drivers/iio/pressure/hp206c.c | 416 ++
 3 files changed, 427 insertions(+)
 create mode 100644 drivers/iio/pressure/hp206c.c

diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
index 31c0e1f..8de0192 100644
--- a/drivers/iio/pressure/Kconfig
+++ b/drivers/iio/pressure/Kconfig
@@ -148,4 +148,14 @@ config T5403
  To compile this driver as a module, choose M here: the module
  will be called t5403.
 
+config HP206C
+   tristate "HOPERF HP206C precision barometer and altimeter sensor"
+   depends on I2C
+   help
+ Say yes here to build support for the HOPREF HP206C precision
+ barometer and altimeter sensor.
+
+ This driver can also be built as a module. If so, the module will
+ be called hp206c.
+
 endmenu
diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile
index d336af1..6e60863 100644
--- a/drivers/iio/pressure/Makefile
+++ b/drivers/iio/pressure/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_IIO_ST_PRESS) += st_pressure.o
 st_pressure-y := st_pressure_core.o
 st_pressure-$(CONFIG_IIO_BUFFER) += st_pressure_buffer.o
 obj-$(CONFIG_T5403) += t5403.o
+obj-$(CONFIG_HP206C) += hp206c.o
 
 obj-$(CONFIG_IIO_ST_PRESS_I2C) += st_pressure_i2c.o
 obj-$(CONFIG_IIO_ST_PRESS_SPI) += st_pressure_spi.o
diff --git a/drivers/iio/pressure/hp206c.c b/drivers/iio/pressure/hp206c.c
new file mode 100644
index 000..9c2c49d
--- /dev/null
+++ b/drivers/iio/pressure/hp206c.c
@@ -0,0 +1,416 @@
+/*
+ * hp206c.c - HOPERF HP206C precision barometer and altimeter sensor
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License.  See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * (7-bit I2C slave address 0x76)
+ *
+ * Datasheet:
+ *  http://www.hoperf.com/upload/sensor/HP206C_DataSheet_EN_V2.0.pdf
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* I2C commands: */
+#define HP206C_CMD_SOFT_RST0x06
+
+#define HP206C_CMD_ADC_CVT 0x40
+
+#define HP206C_CMD_ADC_CVT_OSR_40960x00
+#define HP206C_CMD_ADC_CVT_OSR_20480x04
+#define HP206C_CMD_ADC_CVT_OSR_10240x08
+#define HP206C_CMD_ADC_CVT_OSR_512 0x0c
+#define HP206C_CMD_ADC_CVT_OSR_256 0x10
+#define HP206C_CMD_ADC_CVT_OSR_128 0x14
+
+#define HP206C_CMD_ADC_CVT_CHNL_PT 0x00
+#define HP206C_CMD_ADC_CVT_CHNL_T  0x02
+
+#define HP206C_CMD_READ_P  0x30
+#define HP206C_CMD_READ_T  0x32
+
+#define HP206C_CMD_READ_REG0x80
+#define HP206C_CMD_WRITE_REG   0xc0
+
+#define HP206C_REG_INT_EN  0x0b
+#define HP206C_REG_INT_CFG 0x0c
+
+#define HP206C_REG_INT_SRC 0x0d
+#define HP206C_FLAG_DEV_RDY0x40
+
+#define HP206C_REG_PARA0x0f
+#define HP206C_FLAG_CMPS_EN0x80
+
+/* Maximum spin for DEV_RDY */
+#define HP206C_MAX_DEV_RDY_WAIT_COUNT 20
+#define HP206C_DEV_RDY_WAIT_US2
+
+struct hp206c_data {
+   struct mutex mutex;
+   struct i2c_client *client;
+   u8 temp_osr_index;
+   u8 pres_osr_index;
+};
+
+struct hp206c_osr_setting {
+   u8 osr_mask;
+   unsigned int temp_conv_time_us;
+   unsigned int pres_conv_time_us;
+};
+
+/* Data from Table 5 in datasheet. */
+static const struct hp206c_osr_setting hp206c_osr_settings[] = {
+   { HP206C_CMD_ADC_CVT_OSR_4096,  65600,  131100},
+   { HP206C_CMD_ADC_CVT_OSR_2048,  32800,  65600},
+   { HP206C_CMD_ADC_CVT_OSR_1024,  16400,  32800},
+   { HP206C_CMD_ADC_CVT_OSR_512,   8200,   16400},
+   { HP206C_CMD_ADC_CVT_OSR_256,   4100,   8200},
+   { HP206C_CMD_ADC_CVT_OSR_128,   2100,   4100},
+};
+static const int hp206c_osr_rates[] = { 4096, 2048, 1024, 512, 256, 128 };
+static const char hp206c_osr_rates_str[] = "4096 2048 1024 512 256 128";
+
+static inline int hp206c_read_reg(struct i2c_client *client, u8 reg)
+{
+   return i2c_smbus_read_byte_data(client, HP206C_CMD_READ_REG | reg);
+}
+
+static inline int hp206c_write_reg(struct i2c_client *client, u8 reg, u8 val)
+{
+   return i2c_smbus_write_byte_data(client,
+   HP206C_CMD_WRITE_REG | reg, val);
+}
+
+static int hp206c_read_20bit(struct i2c_client *client, u8 cmd)
+{
+   int ret;
+   uint8_t values[3];
+
+   ret = i2c_smbus_read_i2c_block_data(client, cmd, 3, values);
+   if (ret < 0)
+   return ret;
+   if (ret != 3)
+   return -EIO;
+   return ((values[0] & 0xF) << 16) | (values[1] << 8) | (values[2]);
+}
+
+/* Spin 

[PATCH v2] hp206c: Initial support for reading sensor values

[Crestez Dan Leonard]

Hello,

Changes since the first version:
* Use data->client instead of to_i2c_client(indio_dev->dev.parent)
* Adjust i2c_check_functionality bits requested.

I also fixed gitconfig so it won't create attachments or suppress cc.

Signed-off-by: Crestez Dan Leonard 
---
 drivers/iio/pressure/Kconfig  |  10 +
 drivers/iio/pressure/Makefile |   1 +
 drivers/iio/pressure/hp206c.c | 416 ++
 3 files changed, 427 insertions(+)
 create mode 100644 drivers/iio/pressure/hp206c.c

diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
index 31c0e1f..8de0192 100644
--- a/drivers/iio/pressure/Kconfig
+++ b/drivers/iio/pressure/Kconfig
@@ -148,4 +148,14 @@ config T5403
  To compile this driver as a module, choose M here: the module
  will be called t5403.
 
+config HP206C
+   tristate "HOPERF HP206C precision barometer and altimeter sensor"
+   depends on I2C
+   help
+ Say yes here to build support for the HOPREF HP206C precision
+ barometer and altimeter sensor.
+
+ This driver can also be built as a module. If so, the module will
+ be called hp206c.
+
 endmenu
diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile
index d336af1..6e60863 100644
--- a/drivers/iio/pressure/Makefile
+++ b/drivers/iio/pressure/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_IIO_ST_PRESS) += st_pressure.o
 st_pressure-y := st_pressure_core.o
 st_pressure-$(CONFIG_IIO_BUFFER) += st_pressure_buffer.o
 obj-$(CONFIG_T5403) += t5403.o
+obj-$(CONFIG_HP206C) += hp206c.o
 
 obj-$(CONFIG_IIO_ST_PRESS_I2C) += st_pressure_i2c.o
 obj-$(CONFIG_IIO_ST_PRESS_SPI) += st_pressure_spi.o
diff --git a/drivers/iio/pressure/hp206c.c b/drivers/iio/pressure/hp206c.c
new file mode 100644
index 000..9c2c49d
--- /dev/null
+++ b/drivers/iio/pressure/hp206c.c
@@ -0,0 +1,416 @@
+/*
+ * hp206c.c - HOPERF HP206C precision barometer and altimeter sensor
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License.  See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * (7-bit I2C slave address 0x76)
+ *
+ * Datasheet:
+ *  http://www.hoperf.com/upload/sensor/HP206C_DataSheet_EN_V2.0.pdf
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* I2C commands: */
+#define HP206C_CMD_SOFT_RST0x06
+
+#define HP206C_CMD_ADC_CVT 0x40
+
+#define HP206C_CMD_ADC_CVT_OSR_40960x00
+#define HP206C_CMD_ADC_CVT_OSR_20480x04
+#define HP206C_CMD_ADC_CVT_OSR_10240x08
+#define HP206C_CMD_ADC_CVT_OSR_512 0x0c
+#define HP206C_CMD_ADC_CVT_OSR_256 0x10
+#define HP206C_CMD_ADC_CVT_OSR_128 0x14
+
+#define HP206C_CMD_ADC_CVT_CHNL_PT 0x00
+#define HP206C_CMD_ADC_CVT_CHNL_T  0x02
+
+#define HP206C_CMD_READ_P  0x30
+#define HP206C_CMD_READ_T  0x32
+
+#define HP206C_CMD_READ_REG0x80
+#define HP206C_CMD_WRITE_REG   0xc0
+
+#define HP206C_REG_INT_EN  0x0b
+#define HP206C_REG_INT_CFG 0x0c
+
+#define HP206C_REG_INT_SRC 0x0d
+#define HP206C_FLAG_DEV_RDY0x40
+
+#define HP206C_REG_PARA0x0f
+#define HP206C_FLAG_CMPS_EN0x80
+
+/* Maximum spin for DEV_RDY */
+#define HP206C_MAX_DEV_RDY_WAIT_COUNT 20
+#define HP206C_DEV_RDY_WAIT_US2
+
+struct hp206c_data {
+   struct mutex mutex;
+   struct i2c_client *client;
+   u8 temp_osr_index;
+   u8 pres_osr_index;
+};
+
+struct hp206c_osr_setting {
+   u8 osr_mask;
+   unsigned int temp_conv_time_us;
+   unsigned int pres_conv_time_us;
+};
+
+/* Data from Table 5 in datasheet. */
+static const struct hp206c_osr_setting hp206c_osr_settings[] = {
+   { HP206C_CMD_ADC_CVT_OSR_4096,  65600,  131100},
+   { HP206C_CMD_ADC_CVT_OSR_2048,  32800,  65600},
+   { HP206C_CMD_ADC_CVT_OSR_1024,  16400,  32800},
+   { HP206C_CMD_ADC_CVT_OSR_512,   8200,   16400},
+   { HP206C_CMD_ADC_CVT_OSR_256,   4100,   8200},
+   { HP206C_CMD_ADC_CVT_OSR_128,   2100,   4100},
+};
+static const int hp206c_osr_rates[] = { 4096, 2048, 1024, 512, 256, 128 };
+static const char hp206c_osr_rates_str[] = "4096 2048 1024 512 256 128";
+
+static inline int hp206c_read_reg(struct i2c_client *client, u8 reg)
+{
+   return i2c_smbus_read_byte_data(client, HP206C_CMD_READ_REG | reg);
+}
+
+static inline int hp206c_write_reg(struct i2c_client *client, u8 reg, u8 val)
+{
+   return i2c_smbus_write_byte_data(client,
+   HP206C_CMD_WRITE_REG | reg, val);
+}
+
+static int hp206c_read_20bit(struct i2c_client *client, u8 cmd)
+{
+   int ret;
+   uint8_t values[3];
+
+   ret = i2c_smbus_read_i2c_block_data(client, cmd, 3, values);
+   if (ret < 0)
+   return ret;
+   if (ret != 3)
+   return -EIO;
+   return ((values[0] & 0xF) << 16) | (values[1] << 8) | (values[2]);
+}
+
+/* Spin for max 160ms until DEV_RDY 

Re: [PATCH v2 1/3] phy: rockchip-dp: should be a child device of the GRF

[Yakir Yang]

Hi Heiko,

On 03/25/2016 05:29 AM, Heiko Stuebner wrote:

The displayport-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate platform-
device but instead a sub-device of the GRF - using the simply-mfd mechanism.

The driver entered the kernel in the current merge-window, so we can still
adapt the binding without needing a fallback, as the binding hasn't been
released with a full kernel yet.

While the edp phy is fully part of the GRF, it doesn't have any separate
register set there, so doesn't get any register-area assigned.

Signed-off-by: Heiko Stuebner 

Thanks for your improved.

Reviewed-by: Yakir Yang 

---
While one of my intermediate versions did include that conversion
already, it looks like it was lost when the dp-phy got split out into
its own series and I missed that dropped change.

As mentioned in the patch description above, this is meant as a fixup for
kernel 4.6.

  .../devicetree/bindings/phy/rockchip-dp-phy.txt| 18 +++---
  drivers/phy/phy-rockchip-dp.c  |  7 +--
  2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
index 50c4f9b..e3b4809 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -8,15 +8,19 @@ Required properties:
of memory mapped region.
  - clock-names: from common clock binding:
Required elements: "24m"
-- rockchip,grf: phandle to the syscon managing the "general register files"
  - #phy-cells : from the generic PHY bindings, must be 0;
  
  Example:
  
-edp_phy: edp-phy {

-   compatible = "rockchip,rk3288-dp-phy";
-   rockchip,grf = <>;
-   clocks = < SCLK_EDP_24M>;
-   clock-names = "24m";
-   #phy-cells = <0>;
+grf: syscon@ff77 {
+   compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
+
+...
+
+   edp_phy: edp-phy {
+   compatible = "rockchip,rk3288-dp-phy";
+   clocks = < SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+   };
  };
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
index 77e2d02..793ecb6 100644
--- a/drivers/phy/phy-rockchip-dp.c
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -86,6 +86,9 @@ static int rockchip_dp_phy_probe(struct platform_device *pdev)
if (!np)
return -ENODEV;
  
+	if (!dev->parent || !dev->parent->of_node)

+   return -ENODEV;
+
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
if (IS_ERR(dp))
return -ENOMEM;
@@ -104,9 +107,9 @@ static int rockchip_dp_phy_probe(struct platform_device 
*pdev)
return ret;
}
  
-	dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");

+   dp->grf = syscon_node_to_regmap(dev->parent->of_node);
if (IS_ERR(dp->grf)) {
-   dev_err(dev, "rk3288-dp needs rockchip,grf property\n");
+   dev_err(dev, "rk3288-dp needs the General Register Files 
syscon\n");
return PTR_ERR(dp->grf);
}
  

Re: [PATCH v2 1/3] phy: rockchip-dp: should be a child device of the GRF

[Yakir Yang]

Hi Heiko,

On 03/25/2016 05:29 AM, Heiko Stuebner wrote:

The displayport-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate platform-
device but instead a sub-device of the GRF - using the simply-mfd mechanism.

The driver entered the kernel in the current merge-window, so we can still
adapt the binding without needing a fallback, as the binding hasn't been
released with a full kernel yet.

While the edp phy is fully part of the GRF, it doesn't have any separate
register set there, so doesn't get any register-area assigned.

Signed-off-by: Heiko Stuebner 

Thanks for your improved.

Reviewed-by: Yakir Yang 

---
While one of my intermediate versions did include that conversion
already, it looks like it was lost when the dp-phy got split out into
its own series and I missed that dropped change.

As mentioned in the patch description above, this is meant as a fixup for
kernel 4.6.

  .../devicetree/bindings/phy/rockchip-dp-phy.txt| 18 +++---
  drivers/phy/phy-rockchip-dp.c  |  7 +--
  2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
index 50c4f9b..e3b4809 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -8,15 +8,19 @@ Required properties:
of memory mapped region.
  - clock-names: from common clock binding:
Required elements: "24m"
-- rockchip,grf: phandle to the syscon managing the "general register files"
  - #phy-cells : from the generic PHY bindings, must be 0;
  
  Example:
  
-edp_phy: edp-phy {

-   compatible = "rockchip,rk3288-dp-phy";
-   rockchip,grf = <>;
-   clocks = < SCLK_EDP_24M>;
-   clock-names = "24m";
-   #phy-cells = <0>;
+grf: syscon@ff77 {
+   compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
+
+...
+
+   edp_phy: edp-phy {
+   compatible = "rockchip,rk3288-dp-phy";
+   clocks = < SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+   };
  };
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
index 77e2d02..793ecb6 100644
--- a/drivers/phy/phy-rockchip-dp.c
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -86,6 +86,9 @@ static int rockchip_dp_phy_probe(struct platform_device *pdev)
if (!np)
return -ENODEV;
  
+	if (!dev->parent || !dev->parent->of_node)

+   return -ENODEV;
+
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
if (IS_ERR(dp))
return -ENOMEM;
@@ -104,9 +107,9 @@ static int rockchip_dp_phy_probe(struct platform_device 
*pdev)
return ret;
}
  
-	dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");

+   dp->grf = syscon_node_to_regmap(dev->parent->of_node);
if (IS_ERR(dp->grf)) {
-   dev_err(dev, "rk3288-dp needs rockchip,grf property\n");
+   dev_err(dev, "rk3288-dp needs the General Register Files 
syscon\n");
return PTR_ERR(dp->grf);
}
  

Re: [PART1 RFC v3 08/12] KVM: x86: Add trace events for AVIC

[Suravee Suthikulpanit]

Hi Paolo,

On 3/18/16 17:24, Paolo Bonzini wrote:

+   TP_printk("vcpu=%#x, icrh:icrl=%#010x:%08x, id=%u, index=%u\n",

vcpus are usually printed with %u.  Apart from this, the patch looks
good.  You can squash it in "svm: Add VMEXIT handlers for AVIC".

Paolo



Sure, thanks for the feedback.

Suravee

Re: [PART1 RFC v3 08/12] KVM: x86: Add trace events for AVIC

[Suravee Suthikulpanit]

Hi Paolo,

On 3/18/16 17:24, Paolo Bonzini wrote:

+   TP_printk("vcpu=%#x, icrh:icrl=%#010x:%08x, id=%u, index=%u\n",

vcpus are usually printed with %u.  Apart from this, the patch looks
good.  You can squash it in "svm: Add VMEXIT handlers for AVIC".

Paolo



Sure, thanks for the feedback.

Suravee

[PATCH] rtc: at91sam9: remove duplicate assignment of variable mr

[Colin King]

From: Colin Ian King 

mr is written twice with the same value, remove one of the
redundant assignments to mr.

Signed-off-by: Colin Ian King 
---
 drivers/rtc/rtc-at91sam9.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
index 7206e2f..99732e6 100644
--- a/drivers/rtc/rtc-at91sam9.c
+++ b/drivers/rtc/rtc-at91sam9.c
@@ -268,7 +268,7 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
 static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
 {
struct sam9_rtc *rtc = dev_get_drvdata(dev);
-   u32 mr = mr = rtt_readl(rtc, MR);
+   u32 mr = rtt_readl(rtc, MR);
 
seq_printf(seq, "update_IRQ\t: %s\n",
(mr & AT91_RTT_RTTINCIEN) ? "yes" : "no");
-- 
2.7.4

[PATCH] rtc: at91sam9: remove duplicate assignment of variable mr

[Colin King]

From: Colin Ian King 

mr is written twice with the same value, remove one of the
redundant assignments to mr.

Signed-off-by: Colin Ian King 
---
 drivers/rtc/rtc-at91sam9.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
index 7206e2f..99732e6 100644
--- a/drivers/rtc/rtc-at91sam9.c
+++ b/drivers/rtc/rtc-at91sam9.c
@@ -268,7 +268,7 @@ static int at91_rtc_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
 static int at91_rtc_proc(struct device *dev, struct seq_file *seq)
 {
struct sam9_rtc *rtc = dev_get_drvdata(dev);
-   u32 mr = mr = rtt_readl(rtc, MR);
+   u32 mr = rtt_readl(rtc, MR);
 
seq_printf(seq, "update_IRQ\t: %s\n",
(mr & AT91_RTT_RTTINCIEN) ? "yes" : "no");
-- 
2.7.4

Re: [PATCH v6 6/6] rockchip: power-domain: Modify power domain driver for rk3399

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:24:38 schrieb Elaine Zhang:
> This driver is modified to support RK3399 SoC.
> 
> Signed-off-by: Elaine Zhang 

applied for 4.7 with small indentation fixes in the domain list


Thanks
Heiko

Re: [PATCH v6 6/6] rockchip: power-domain: Modify power domain driver for rk3399

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:24:38 schrieb Elaine Zhang:
> This driver is modified to support RK3399 SoC.
> 
> Signed-off-by: Elaine Zhang 

applied for 4.7 with small indentation fixes in the domain list


Thanks
Heiko

Re: [PATCH v6 5/6] dt/bindings: rockchip: modify document of Rockchip power domains

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:24:21 schrieb Elaine Zhang:
> Add binding documentation for the power domains
> found on Rockchip RK3399 SoCs
> 
> Signed-off-by: Elaine Zhang 

applied for 4.7 with Kevin's Ack from v5

Thanks
Heiko

Re: [PATCH v6 5/6] dt/bindings: rockchip: modify document of Rockchip power domains

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:24:21 schrieb Elaine Zhang:
> Add binding documentation for the power domains
> found on Rockchip RK3399 SoCs
> 
> Signed-off-by: Elaine Zhang 

applied for 4.7 with Kevin's Ack from v5

Thanks
Heiko

Re: [PATCH v6 4/6] dt/bindings: power: add RK3399 SoCs header for power-domain

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:22:56 schrieb Elaine Zhang:
> According to a description from TRM, add all the power domains
> 
> Signed-off-by: Elaine Zhang 

applied for 4.7

Thanks
Heiko

Re: [PATCH v6 4/6] dt/bindings: power: add RK3399 SoCs header for power-domain

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:22:56 schrieb Elaine Zhang:
> According to a description from TRM, add all the power domains
> 
> Signed-off-by: Elaine Zhang 

applied for 4.7

Thanks
Heiko

[PATCH] i40iw: pass hw_stats by reference rather than by value

[Colin King]

From: Colin Ian King 

passing hw_stats by value requires a 280 byte copy so instead
pass it by reference is much more efficient.

Signed-off-by: Colin Ian King 
---
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c 
b/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
index 6b68f78..62bb8265 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
@@ -254,7 +254,7 @@ static void vchnl_pf_send_get_hmc_fcn_resp(struct 
i40iw_sc_dev *dev,
 static void vchnl_pf_send_get_pe_stats_resp(struct i40iw_sc_dev *dev,
u32 vf_id,
struct i40iw_virtchnl_op_buf 
*vchnl_msg,
-   struct i40iw_dev_hw_stats hw_stats)
+   struct i40iw_dev_hw_stats *hw_stats)
 {
enum i40iw_status_code ret_code;
u8 resp_buffer[sizeof(struct i40iw_virtchnl_resp_buf) + sizeof(struct 
i40iw_dev_hw_stats) - 1];
@@ -264,7 +264,7 @@ static void vchnl_pf_send_get_pe_stats_resp(struct 
i40iw_sc_dev *dev,
vchnl_msg_resp->iw_chnl_op_ctx = vchnl_msg->iw_chnl_op_ctx;
vchnl_msg_resp->iw_chnl_buf_len = sizeof(resp_buffer);
vchnl_msg_resp->iw_op_ret_code = I40IW_SUCCESS;
-   *((struct i40iw_dev_hw_stats *)vchnl_msg_resp->iw_chnl_buf) = hw_stats;
+   *((struct i40iw_dev_hw_stats *)vchnl_msg_resp->iw_chnl_buf) = *hw_stats;
ret_code = dev->vchnl_if.vchnl_send(dev, vf_id, resp_buffer, 
sizeof(resp_buffer));
if (ret_code)
i40iw_debug(dev, I40IW_DEBUG_VIRT,
@@ -541,7 +541,7 @@ enum i40iw_status_code i40iw_vchnl_recv_pf(struct 
i40iw_sc_dev *dev,
devstat->ops.iw_hw_stat_read_all(devstat, >hw_stats);
spin_unlock_irqrestore(>dev_pestat.stats_lock, flags);
vf_dev->msg_count--;
-   vchnl_pf_send_get_pe_stats_resp(dev, vf_id, vchnl_msg, 
devstat->hw_stats);
+   vchnl_pf_send_get_pe_stats_resp(dev, vf_id, vchnl_msg, 
>hw_stats);
break;
default:
i40iw_debug(dev, I40IW_DEBUG_VIRT,
-- 
2.7.4

[PATCH] i40iw: pass hw_stats by reference rather than by value

[Colin King]

From: Colin Ian King 

passing hw_stats by value requires a 280 byte copy so instead
pass it by reference is much more efficient.

Signed-off-by: Colin Ian King 
---
 drivers/infiniband/hw/i40iw/i40iw_virtchnl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c 
b/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
index 6b68f78..62bb8265 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_virtchnl.c
@@ -254,7 +254,7 @@ static void vchnl_pf_send_get_hmc_fcn_resp(struct 
i40iw_sc_dev *dev,
 static void vchnl_pf_send_get_pe_stats_resp(struct i40iw_sc_dev *dev,
u32 vf_id,
struct i40iw_virtchnl_op_buf 
*vchnl_msg,
-   struct i40iw_dev_hw_stats hw_stats)
+   struct i40iw_dev_hw_stats *hw_stats)
 {
enum i40iw_status_code ret_code;
u8 resp_buffer[sizeof(struct i40iw_virtchnl_resp_buf) + sizeof(struct 
i40iw_dev_hw_stats) - 1];
@@ -264,7 +264,7 @@ static void vchnl_pf_send_get_pe_stats_resp(struct 
i40iw_sc_dev *dev,
vchnl_msg_resp->iw_chnl_op_ctx = vchnl_msg->iw_chnl_op_ctx;
vchnl_msg_resp->iw_chnl_buf_len = sizeof(resp_buffer);
vchnl_msg_resp->iw_op_ret_code = I40IW_SUCCESS;
-   *((struct i40iw_dev_hw_stats *)vchnl_msg_resp->iw_chnl_buf) = hw_stats;
+   *((struct i40iw_dev_hw_stats *)vchnl_msg_resp->iw_chnl_buf) = *hw_stats;
ret_code = dev->vchnl_if.vchnl_send(dev, vf_id, resp_buffer, 
sizeof(resp_buffer));
if (ret_code)
i40iw_debug(dev, I40IW_DEBUG_VIRT,
@@ -541,7 +541,7 @@ enum i40iw_status_code i40iw_vchnl_recv_pf(struct 
i40iw_sc_dev *dev,
devstat->ops.iw_hw_stat_read_all(devstat, >hw_stats);
spin_unlock_irqrestore(>dev_pestat.stats_lock, flags);
vf_dev->msg_count--;
-   vchnl_pf_send_get_pe_stats_resp(dev, vf_id, vchnl_msg, 
devstat->hw_stats);
+   vchnl_pf_send_get_pe_stats_resp(dev, vf_id, vchnl_msg, 
>hw_stats);
break;
default:
i40iw_debug(dev, I40IW_DEBUG_VIRT,
-- 
2.7.4

Re: [PATCH v6 3/6] rockchip: power-domain: add support for sub-power domains

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:22:55 schrieb Elaine Zhang:
> This patch adds support for making one power domain a sub-domain of
> other domain. This is useful for modeling power dependences,
> which needs to have more than one power domain enabled to be operational.
> 
> Signed-off-by: Elaine Zhang 

applied to my armsoc/drivers branch for 4.7 [0] with some changes.

Please shout if things don't look right :-)

Apart from additional error outputs, I moved the of_put of parent in the
error case, as we shouldn't touch of_nodes we get as parameters. Instead
rockchip_pm_add_subdomain would already do that for subdomains and
rockchip_pm_domain_probe now also does it itself.

Also when rockchip_pm_add_subdomain for a sub-sub-domain fails
(in rockchip_pm_add_subdomain), we don't need to remove the parent
domain association, so I removed the return there.


Heiko

---
diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 0181534..1fca9e5 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -380,10 +380,11 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu 
*pmu,
for_each_child_of_node(parent, np) {
u32 idx;
 
-   if (of_property_read_u32(parent, "reg", )) {
+   error = of_property_read_u32(parent, "reg", );
+   if (error) {
dev_err(pmu->dev,
-   "%s: failed to retrieve domain id (reg)\n",
-   parent->name);
+   "%s: failed to retrieve domain id (reg): %d\n",
+   parent->name, error);
goto err_out;
}
parent_domain = pmu->genpd_data.domains[idx];
@@ -395,17 +396,19 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu 
*pmu,
goto err_out;
}
 
-   if (of_property_read_u32(np, "reg", )) {
+   error = of_property_read_u32(np, "reg", );
+   if (error) {
dev_err(pmu->dev,
-   "%s: failed to retrieve domain id (reg)\n",
-   np->name);
+   "%s: failed to retrieve domain id (reg): %d\n",
+   np->name, error);
goto err_out;
}
child_domain = pmu->genpd_data.domains[idx];
 
-   if (pm_genpd_add_subdomain(parent_domain, child_domain)) {
-   dev_err(pmu->dev, "%s failed to add subdomain: %s\n",
-   parent_domain->name, child_domain->name);
+   error = pm_genpd_add_subdomain(parent_domain, child_domain);
+   if (error) {
+   dev_err(pmu->dev, "%s failed to add subdomain %s: %d\n",
+   parent_domain->name, child_domain->name, error);
goto err_out;
} else {
dev_dbg(pmu->dev, "%s add subdomain: %s\n",
@@ -414,16 +417,10 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu 
*pmu,
 
-   error = rockchip_pm_add_subdomain(pmu, np);
-   if (error < 0)
-   goto rm_sub_domain;
+   rockchip_pm_add_subdomain(pmu, np);
}
return 0;
 
 err_out:
-   of_node_put(parent);
of_node_put(np);
-   return -EINVAL;
-rm_sub_domain:
-   pm_genpd_remove_subdomain(parent_domain, child_domain);
return error;
 }
 
@@ -498,6 +497,7 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
if (error < 0) {
dev_err(dev, "failed to handle subdomain node %s: %d\n",
node->name, error);
+   of_node_put(node);
goto err_out;
}
}
---


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v4.7-armsoc/drivers=6be05b5ec16132f3df3f1d857ab01e30f726b542

Re: [PATCH v6 3/6] rockchip: power-domain: add support for sub-power domains

[Heiko Stübner]

Am Donnerstag, 10. März 2016, 05:22:55 schrieb Elaine Zhang:
> This patch adds support for making one power domain a sub-domain of
> other domain. This is useful for modeling power dependences,
> which needs to have more than one power domain enabled to be operational.
> 
> Signed-off-by: Elaine Zhang 

applied to my armsoc/drivers branch for 4.7 [0] with some changes.

Please shout if things don't look right :-)

Apart from additional error outputs, I moved the of_put of parent in the
error case, as we shouldn't touch of_nodes we get as parameters. Instead
rockchip_pm_add_subdomain would already do that for subdomains and
rockchip_pm_domain_probe now also does it itself.

Also when rockchip_pm_add_subdomain for a sub-sub-domain fails
(in rockchip_pm_add_subdomain), we don't need to remove the parent
domain association, so I removed the return there.


Heiko

---
diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 0181534..1fca9e5 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -380,10 +380,11 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu 
*pmu,
for_each_child_of_node(parent, np) {
u32 idx;
 
-   if (of_property_read_u32(parent, "reg", )) {
+   error = of_property_read_u32(parent, "reg", );
+   if (error) {
dev_err(pmu->dev,
-   "%s: failed to retrieve domain id (reg)\n",
-   parent->name);
+   "%s: failed to retrieve domain id (reg): %d\n",
+   parent->name, error);
goto err_out;
}
parent_domain = pmu->genpd_data.domains[idx];
@@ -395,17 +396,19 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu 
*pmu,
goto err_out;
}
 
-   if (of_property_read_u32(np, "reg", )) {
+   error = of_property_read_u32(np, "reg", );
+   if (error) {
dev_err(pmu->dev,
-   "%s: failed to retrieve domain id (reg)\n",
-   np->name);
+   "%s: failed to retrieve domain id (reg): %d\n",
+   np->name, error);
goto err_out;
}
child_domain = pmu->genpd_data.domains[idx];
 
-   if (pm_genpd_add_subdomain(parent_domain, child_domain)) {
-   dev_err(pmu->dev, "%s failed to add subdomain: %s\n",
-   parent_domain->name, child_domain->name);
+   error = pm_genpd_add_subdomain(parent_domain, child_domain);
+   if (error) {
+   dev_err(pmu->dev, "%s failed to add subdomain %s: %d\n",
+   parent_domain->name, child_domain->name, error);
goto err_out;
} else {
dev_dbg(pmu->dev, "%s add subdomain: %s\n",
@@ -414,16 +417,10 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu 
*pmu,
 
-   error = rockchip_pm_add_subdomain(pmu, np);
-   if (error < 0)
-   goto rm_sub_domain;
+   rockchip_pm_add_subdomain(pmu, np);
}
return 0;
 
 err_out:
-   of_node_put(parent);
of_node_put(np);
-   return -EINVAL;
-rm_sub_domain:
-   pm_genpd_remove_subdomain(parent_domain, child_domain);
return error;
 }
 
@@ -498,6 +497,7 @@ static int rockchip_pm_domain_probe(struct platform_device 
*pdev)
if (error < 0) {
dev_err(dev, "failed to handle subdomain node %s: %d\n",
node->name, error);
+   of_node_put(node);
goto err_out;
}
}
---


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?h=v4.7-armsoc/drivers=6be05b5ec16132f3df3f1d857ab01e30f726b542

Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc

[Ravi Bangoria]

Thanks Arnaldo for putting the effort.

I've tested this patch on powerpc and it looks fine to me. Please find 
my below comments.


On Friday 25 March 2016 02:45 AM, Arnaldo Carvalho de Melo wrote:

Em Tue, Mar 22, 2016 at 11:19:21PM -0300, Arnaldo Carvalho de Melo escreveu:

Em Tue, Mar 22, 2016 at 04:12:11PM -0300, Arnaldo Carvalho de Melo escreveu:

Em Wed, Feb 24, 2016 at 02:37:42PM +0530, Ravi Bangoria escreveu:

'perf kvm record' is not available on powerpc because 'perf' relies on
the 'cycles' event (a PMU event) to profile the guest. However, for
powerpc, this can't be used from the host because the PMUs are controlled
by the guest rather than the host.

There exists a tracepoint 'kvm_hv:kvm_guest_exit' in powerpc which is
hit whenever any of the threads exit the guest context. The guest
instruction pointer dumped along with this tracepoint data in the field
'pc', can be used as guest instruction pointer.

This patch changes default event as kvm_hv:kvm_guest_exit for recording
guest data in host on powerpc. As we are using host event to record guest
data, this approach will enable only --guest option of 'perf kvm'. Still
--host --guest together won't work.

It should, i.e. --host --guest should translate to:

-e cycles:H,kvm_hv:kvm_guest_exit

I.e. both collect cycles only in the host, and also the tracepoint that
will allow us to get the guest approximation for the unavailable cycles
event, no?

I'm putting the infrastructure work needed for this the perf/cpumode
branch. More work will be put there soon.

So I took a different path and made perf_evsel__parse_sample set a new
perf_sample.cpumode field, this way we'll end up having just to set a
per-evsel ->post_parse_sample() callback for the event that replaces
"cycles" for PPC guests where we'll just set data->ip and data->cpumode,
the rest of the code remains unchanged.

The changes I made looks useful in itself, as, IIRC more code was
removed than added.

I'll continue tomorrow and will test with the kvm:kvm_exit on x86_64 for
testing, that has:

Ok, so the infrastructure got merged already and from there the next
steps are in running with:

  perf kvm --guest record -a -e cycles:H,kvm:kvm_exit

And then, with the patch below applied, try:

perf kvm --guestkallsyms kallsyms.guest --guestmodules modules.guest report -i 
perf.data.guest --munge-ppc-guest-sample kvm:kvm_exit



The initial proposal was to change the default event as "kvm_guest_exit" 
for kvm recording/reporting
on ppc. If I understand it correctly, your patch creates a handler for 
reporting kvm events
based on "munge_ppc_guest_event" and the required tracepoint i.e., we 
need to mention the

required tracepoint event name for recording and reporting.

There might be a little bit of an issue here. For scripts which depend 
on generic perf kvm record/report,
we need to change those appropriately to prevent those from failing on 
powerpc. Otherwise, (just a
thought) can we create some kind of an alias to map the ppc specific 
perf kvm commands with the

generic perf kvm.
For e.g :
perf kvm record -e "kvm_hv:kvm_guest_exit"  mapped to  perf kvm record
&
perf kvm report --munge-ppc-guest-sample kvm_hv:kvm_guest_exit mapped 
to  perf kvm report.



Regards,
Ravi

Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc

[Ravi Bangoria]

Thanks Arnaldo for putting the effort.

I've tested this patch on powerpc and it looks fine to me. Please find 
my below comments.


On Friday 25 March 2016 02:45 AM, Arnaldo Carvalho de Melo wrote:

Em Tue, Mar 22, 2016 at 11:19:21PM -0300, Arnaldo Carvalho de Melo escreveu:

Em Tue, Mar 22, 2016 at 04:12:11PM -0300, Arnaldo Carvalho de Melo escreveu:

Em Wed, Feb 24, 2016 at 02:37:42PM +0530, Ravi Bangoria escreveu:

'perf kvm record' is not available on powerpc because 'perf' relies on
the 'cycles' event (a PMU event) to profile the guest. However, for
powerpc, this can't be used from the host because the PMUs are controlled
by the guest rather than the host.

There exists a tracepoint 'kvm_hv:kvm_guest_exit' in powerpc which is
hit whenever any of the threads exit the guest context. The guest
instruction pointer dumped along with this tracepoint data in the field
'pc', can be used as guest instruction pointer.

This patch changes default event as kvm_hv:kvm_guest_exit for recording
guest data in host on powerpc. As we are using host event to record guest
data, this approach will enable only --guest option of 'perf kvm'. Still
--host --guest together won't work.

It should, i.e. --host --guest should translate to:

-e cycles:H,kvm_hv:kvm_guest_exit

I.e. both collect cycles only in the host, and also the tracepoint that
will allow us to get the guest approximation for the unavailable cycles
event, no?

I'm putting the infrastructure work needed for this the perf/cpumode
branch. More work will be put there soon.

So I took a different path and made perf_evsel__parse_sample set a new
perf_sample.cpumode field, this way we'll end up having just to set a
per-evsel ->post_parse_sample() callback for the event that replaces
"cycles" for PPC guests where we'll just set data->ip and data->cpumode,
the rest of the code remains unchanged.

The changes I made looks useful in itself, as, IIRC more code was
removed than added.

I'll continue tomorrow and will test with the kvm:kvm_exit on x86_64 for
testing, that has:

Ok, so the infrastructure got merged already and from there the next
steps are in running with:

  perf kvm --guest record -a -e cycles:H,kvm:kvm_exit

And then, with the patch below applied, try:

perf kvm --guestkallsyms kallsyms.guest --guestmodules modules.guest report -i 
perf.data.guest --munge-ppc-guest-sample kvm:kvm_exit



The initial proposal was to change the default event as "kvm_guest_exit" 
for kvm recording/reporting
on ppc. If I understand it correctly, your patch creates a handler for 
reporting kvm events
based on "munge_ppc_guest_event" and the required tracepoint i.e., we 
need to mention the

required tracepoint event name for recording and reporting.

There might be a little bit of an issue here. For scripts which depend 
on generic perf kvm record/report,
we need to change those appropriately to prevent those from failing on 
powerpc. Otherwise, (just a
thought) can we create some kind of an alias to map the ppc specific 
perf kvm commands with the

generic perf kvm.
For e.g :
perf kvm record -e "kvm_hv:kvm_guest_exit"  mapped to  perf kvm record
&
perf kvm report --munge-ppc-guest-sample kvm_hv:kvm_guest_exit mapped 
to  perf kvm report.



Regards,
Ravi

Re: ARC dw-mshc binding compat string

[Alexey Brodkin]

Hi Jaehoon,

On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote:
> Hi,

[snip]

> > > > > > > > 
> > > > > > > > That said, I would rather prefer to see "snps,dw-mshc" prefix 
> > > > > > > > on description
> > > > > > > > of an MMC controller found on SoCFPGA series, 
> > > > > > > > "altr,socfpga-dw-mshc" seems
> > > > > > > > to be redundant.
> Yes..it's redundant..i should be combined to "snps,dw-mshc".

So for socfpga platform compat string should be something like 
"snps,dw-mshc-socfpga" then?

> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA 
> > > > > > > one
> > > > > > > "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio 
> > > > > > > one
> > > > > > > "img,pistachio-dw-mshc" need specialty bit 
> > > > > > > (SDMMC_CMD_USE_HOLD_REG),
> > > > > > > while the stock one "snps,dw-mshc" does not. I am not sure if the 
> > > > > > > ARC
> > > > > > > one needs it as well, but most likely yes.
> > > > > > > 
> > > > > > > I wonder if that bit is needed on some particular version of the 
> > > > > > > DWMMC
> > > > > > > core. In that case, should we have "snps,dw-mshc" and 
> > > > > > > "snps,dw-mshc-vN"
> > > > > > > binding ? Or should we use DT property to discern the need for 
> > > > > > > this bit ?
> > > > > > > 
> > > > > > That's the most common way to take into account peculiarities, add
> > > > > > a property and handle it from the driver.
> > > > > And by "that" you mean which of those two I listed , the
> > > > > "snps,dw-mshc-vN" or adding new DT prop ?
> > > > > 
> > > > I meant to add a new property, not a new compatible, but that's just
> > > > my experience.
> > > > 
> > > > Let me say it __might__ happen that a particular change you need is
> > > > specific to a particular version of the DWMMC IP (query Synopsys
> > > > by the way), but more probably it might be e.g. the same IP version with
> > > > a different reduced or extended configuration or a minor fix/improvement
> > > > to the IP block without resulting version number bump.
> > > > 
> > > > For example I don't remember that errata fixes in IP blocks result in
> > > > a new compatible, instead there are quite common optional "quirk"
> > > > properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
> > > Right, this very much matches how I see it as well. Thanks for confirming.
> > > 
> > > Alexey, can you tell us if the requirement for setting
> > > SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
> > > disappeared with some revision OR if this is some configuration
> > > option of the core during synthesis ?
> > Sorry for not following that discussion during my weekend but I'll try
> > to address all questions now.
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the 
> below things.
> 
> If Card is SDR50/SDR104/DDR50 mode..
>   1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 0,
>   2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 1,
> If Card is SDR12/SDR25 mode, then this bit is set to 1.

So card type is also important here and for certain card type we don't need to
set SDMMC_CMD_USE_HOLD_REG, right?

> We need to check phase shift scheme..but as i knew, each SoC have been 
> implemented differently for phase shift.
> (Phase shift have dependency to SoC.)

Given my assumption above we need to check 2 things:
 * Card type
 * SoC-specific implementation detail (phase shift scheme)

> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
> (It described whether IP have hold register or not)

Ah actually 3 things
 + IMPLEMENT_HOLD_REG

> I didn't read this thread entirely.
> I'm not sure what you have discussed..but my understanding is right..i 
> recommend to use "snps,dw-mshc" for ARC compat
> string.
> Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the 
> basic dw-mmc controller functionality.

Hm, interesting looks like you already made some changes here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb7a933471f6413ca44dd36efd57f2fa9429

So now driver checks if SoC has HOLD REG then SDMMC_CMD_USE_HOLD_REG will be set
(regardless card type).

And what's interesting and connected to this discussion since mentioned commit
there's no point in having both "altr,socfpga-dw-mshc" and 
"img,pistachio-dw-mshc"
compat strings because the do nothing now. I.e. it's time to replace both 
mentioned
compat strings with generic "snps,dw-mshc".

Anybody volunteers for that .dts* cleanup?

-Alexey

Re: ARC dw-mshc binding compat string

[Alexey Brodkin]

Hi Jaehoon,

On Mon, 2016-03-28 at 19:34 +0900, Jaehoon Chung wrote:
> Hi,

[snip]

> > > > > > > > 
> > > > > > > > That said, I would rather prefer to see "snps,dw-mshc" prefix 
> > > > > > > > on description
> > > > > > > > of an MMC controller found on SoCFPGA series, 
> > > > > > > > "altr,socfpga-dw-mshc" seems
> > > > > > > > to be redundant.
> Yes..it's redundant..i should be combined to "snps,dw-mshc".

So for socfpga platform compat string should be something like 
"snps,dw-mshc-socfpga" then?

> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA 
> > > > > > > one
> > > > > > > "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio 
> > > > > > > one
> > > > > > > "img,pistachio-dw-mshc" need specialty bit 
> > > > > > > (SDMMC_CMD_USE_HOLD_REG),
> > > > > > > while the stock one "snps,dw-mshc" does not. I am not sure if the 
> > > > > > > ARC
> > > > > > > one needs it as well, but most likely yes.
> > > > > > > 
> > > > > > > I wonder if that bit is needed on some particular version of the 
> > > > > > > DWMMC
> > > > > > > core. In that case, should we have "snps,dw-mshc" and 
> > > > > > > "snps,dw-mshc-vN"
> > > > > > > binding ? Or should we use DT property to discern the need for 
> > > > > > > this bit ?
> > > > > > > 
> > > > > > That's the most common way to take into account peculiarities, add
> > > > > > a property and handle it from the driver.
> > > > > And by "that" you mean which of those two I listed , the
> > > > > "snps,dw-mshc-vN" or adding new DT prop ?
> > > > > 
> > > > I meant to add a new property, not a new compatible, but that's just
> > > > my experience.
> > > > 
> > > > Let me say it __might__ happen that a particular change you need is
> > > > specific to a particular version of the DWMMC IP (query Synopsys
> > > > by the way), but more probably it might be e.g. the same IP version with
> > > > a different reduced or extended configuration or a minor fix/improvement
> > > > to the IP block without resulting version number bump.
> > > > 
> > > > For example I don't remember that errata fixes in IP blocks result in
> > > > a new compatible, instead there are quite common optional "quirk"
> > > > properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
> > > Right, this very much matches how I see it as well. Thanks for confirming.
> > > 
> > > Alexey, can you tell us if the requirement for setting
> > > SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
> > > disappeared with some revision OR if this is some configuration
> > > option of the core during synthesis ?
> > Sorry for not following that discussion during my weekend but I'll try
> > to address all questions now.
> SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
> But it's difficult to use the generic feature..because it's considered the 
> below things.
> 
> If Card is SDR50/SDR104/DDR50 mode..
>   1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 0,
>   2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
> is set to 1,
> If Card is SDR12/SDR25 mode, then this bit is set to 1.

So card type is also important here and for certain card type we don't need to
set SDMMC_CMD_USE_HOLD_REG, right?

> We need to check phase shift scheme..but as i knew, each SoC have been 
> implemented differently for phase shift.
> (Phase shift have dependency to SoC.)

Given my assumption above we need to check 2 things:
 * Card type
 * SoC-specific implementation detail (phase shift scheme)

> And it have to check HCON register..there is IMPLEMENT_HOLD_REG(bit[22]).
> (It described whether IP have hold register or not)

Ah actually 3 things
 + IMPLEMENT_HOLD_REG

> I didn't read this thread entirely.
> I'm not sure what you have discussed..but my understanding is right..i 
> recommend to use "snps,dw-mshc" for ARC compat
> string.
> Otherwise it need to add "dw_mmc-.c". dw_mmc-pltfm.c should provide the 
> basic dw-mmc controller functionality.

Hm, interesting looks like you already made some changes here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eb7a933471f6413ca44dd36efd57f2fa9429

So now driver checks if SoC has HOLD REG then SDMMC_CMD_USE_HOLD_REG will be set
(regardless card type).

And what's interesting and connected to this discussion since mentioned commit
there's no point in having both "altr,socfpga-dw-mshc" and 
"img,pistachio-dw-mshc"
compat strings because the do nothing now. I.e. it's time to replace both 
mentioned
compat strings with generic "snps,dw-mshc".

Anybody volunteers for that .dts* cleanup?

-Alexey

Hello Dear

[cynthia bikomagu]

-- 
Hello Dear,

My name is Cynthia, I got your email from Facebook and i will like you
to contact me back at this email ( cynthiabikom...@gmail.com ) is very
important.

Yours Faithful
Cynthia

Hello Dear

[cynthia bikomagu]

-- 
Hello Dear,

My name is Cynthia, I got your email from Facebook and i will like you
to contact me back at this email ( cynthiabikom...@gmail.com ) is very
important.

Yours Faithful
Cynthia

Re: [PATCH 0/4 v3] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

Hi Daniel,

On Wed, 2016-03-23 at 11:37 +0100, Daniel Vetter wrote:
> On Wed, Mar 23, 2016 at 11:42:53AM +0300, Alexey Brodkin wrote:
> > 
> > As a pair to already existing drm_connector_unplug_all()
> > (which we'll rename in this series to drm_connector_unregister_all())
> > we're adding generic implementation of what is already done in some drivers
> > for registering all connectors.
> > 
> > After implementation of that new helper we're updating 2 drivers
> > that used to use it's own implementation:
> >  [1] atmel_hlcdc
> >  [2] rcar_du
> > 
> > And one driver that uses unregister():
> >  [1] udl
> > 
> > Other drivers still use load() callback and so should be first modified so
> > their load() gets called from their probe() explicitly.
> > 
> > Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x 
> > board).
> > 
> > Changes v2 -> v3:
> >  * Added acks for 1, 3 and 4 patches
> >  * Updated kerneldoc descriptins of both register_ and unregister_all()
> >  * Updated commit messages (mostly spellos and grammar issues)
> > 
> > Changes v1 -> v2:
> >  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> >  * Use drm_for_each_connector() instead of list_for_each_entry()
> >  * Updated kerneldoc for drm_dev_register()
> > 
> > Alexey Brodkin (4):
> >   drm: Rename drm_connector_unplug_all() to
> > drm_connector_unregister_all()
> >   drm: Introduce drm_connector_register_all() helper
> >   drm: atmel_hldc: Use generic drm_connector_register_all() helper
> >   drm: rcar-du: Use generic drm_connector_register_all() helper
> lgtm overall, but merge window is happening so don't want to throw 4.7
> patches into drm-misc. So will let these soak for a while more, please
> ping me after -rc1 is out that I don't forget them.

As you asked I'm pinging you with request to apply that series.

Also would be very nice if you take a look at that comment from
David Herrmann before application of that series:
http://article.gmane.org/gmane.comp.video.dri.devel/149708/match=re+patch+2+4+v3+drm+introduce+drm_connector_register_al
l+helper

-Alexey

Re: [PATCH 0/4 v3] drm: Introduce drm_connector_register_all() helper

[Alexey Brodkin]

Hi Daniel,

On Wed, 2016-03-23 at 11:37 +0100, Daniel Vetter wrote:
> On Wed, Mar 23, 2016 at 11:42:53AM +0300, Alexey Brodkin wrote:
> > 
> > As a pair to already existing drm_connector_unplug_all()
> > (which we'll rename in this series to drm_connector_unregister_all())
> > we're adding generic implementation of what is already done in some drivers
> > for registering all connectors.
> > 
> > After implementation of that new helper we're updating 2 drivers
> > that used to use it's own implementation:
> >  [1] atmel_hlcdc
> >  [2] rcar_du
> > 
> > And one driver that uses unregister():
> >  [1] udl
> > 
> > Other drivers still use load() callback and so should be first modified so
> > their load() gets called from their probe() explicitly.
> > 
> > Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x 
> > board).
> > 
> > Changes v2 -> v3:
> >  * Added acks for 1, 3 and 4 patches
> >  * Updated kerneldoc descriptins of both register_ and unregister_all()
> >  * Updated commit messages (mostly spellos and grammar issues)
> > 
> > Changes v1 -> v2:
> >  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
> >  * Use drm_for_each_connector() instead of list_for_each_entry()
> >  * Updated kerneldoc for drm_dev_register()
> > 
> > Alexey Brodkin (4):
> >   drm: Rename drm_connector_unplug_all() to
> > drm_connector_unregister_all()
> >   drm: Introduce drm_connector_register_all() helper
> >   drm: atmel_hldc: Use generic drm_connector_register_all() helper
> >   drm: rcar-du: Use generic drm_connector_register_all() helper
> lgtm overall, but merge window is happening so don't want to throw 4.7
> patches into drm-misc. So will let these soak for a while more, please
> ping me after -rc1 is out that I don't forget them.

As you asked I'm pinging you with request to apply that series.

Also would be very nice if you take a look at that comment from
David Herrmann before application of that series:
http://article.gmane.org/gmane.comp.video.dri.devel/149708/match=re+patch+2+4+v3+drm+introduce+drm_connector_register_al
l+helper

-Alexey

Re: ARC dw-mshc binding compat string

[Jaehoon Chung]

Hi,

On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
> Hi Marek, Vladimir,
> 
> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 21:52, Marek Vasut wrote:

 On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 20:10, Marek Vasut wrote:
>>
>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>
>>> Hi Marek,
>>>
>>> On 26.03.2016 19:30, Marek Vasut wrote:

 On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 12:14, Marek Vasut wrote:
>>
>> Hi!
>>
>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix 
>> in
>> the DT compatible string:
>>
>> mmc@0x15000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = < 0x15000 0x400 >;
>> num-slots = < 1 >;
>> fifo-depth = < 16 >;
>> card-detect-delay = < 200 >;
>> clocks = <>, <>;
>> clock-names = "biu", "ciu";
>> interrupts = < 7 >;
>> bus-width = < 4 >;
>> };
>>
>> I don't think this is OK, since ARC is unrelated to Altera, which is
>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>> should be extended with another compatibility string, something like
>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>> accordingly. What do you think ?
>>
> There is "snps,dw-mshc" described in
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and 
> supported by
> dw_mmc host controller driver.
 Thanks, that's even better.

 btw what do you think of using altr, prefix on non-altera system, that
 doesn't seem ok, right ?
>>> according to ePAPR the prefix should represent a device (IP block here
>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>> non-Altera system, if Altera provides  another hardware vendor with
>>> some own IP block.
>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>> chip makers (Altera etc).
> Correct.
>
>>
>>>
>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on 
>>> description
>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
>>> seems
>>> to be redundant.

Yes..it's redundant..i should be combined to "snps,dw-mshc".

>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>> one needs it as well, but most likely yes.
>>
>> I wonder if that bit is needed on some particular version of the DWMMC
>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>> binding ? Or should we use DT property to discern the need for this bit ?
>>
> That's the most common way to take into account peculiarities, add
> a property and handle it from the driver.
 And by "that" you mean which of those two I listed , the
 "snps,dw-mshc-vN" or adding new DT prop ?

>>> I meant to add a new property, not a new compatible, but that's just
>>> my experience.
>>>
>>> Let me say it __might__ happen that a particular change you need is
>>> specific to a particular version of the DWMMC IP (query Synopsys
>>> by the way), but more probably it might be e.g. the same IP version with
>>> a different reduced or extended configuration or a minor fix/improvement
>>> to the IP block without resulting version number bump.
>>>
>>> For example I don't remember that errata fixes in IP blocks result in
>>> a new compatible, instead there are quite common optional "quirk"
>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>> Right, this very much matches how I see it as well. Thanks for confirming.
>>
>> Alexey, can you tell us if the requirement for setting
>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>> disappeared with some revision OR if this is some configuration
>> option of the core during synthesis ?
> 
> Sorry for not following that discussion during my weekend but I'll try
> to address all questions now.

SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
But it's difficult to use the generic feature..because it's considered the 
below things.

If Card is SDR50/SDR104/DDR50 mode..
1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
is set to 0,
2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
is set to 1,
If Card is SDR12/SDR25 mode, then this bit is 

Re: ARC dw-mshc binding compat string

[Jaehoon Chung]

Hi,

On 03/28/2016 06:37 PM, Alexey Brodkin wrote:
> Hi Marek, Vladimir,
> 
> On Sat, 2016-03-26 at 21:24 +0100, Marek Vasut wrote:
>> On 03/26/2016 09:12 PM, Vladimir Zapolskiy wrote:
>>>
>>> On 26.03.2016 21:52, Marek Vasut wrote:

 On 03/26/2016 07:16 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 20:10, Marek Vasut wrote:
>>
>> On 03/26/2016 06:52 PM, Vladimir Zapolskiy wrote:
>>>
>>> Hi Marek,
>>>
>>> On 26.03.2016 19:30, Marek Vasut wrote:

 On 03/26/2016 06:26 PM, Vladimir Zapolskiy wrote:
>
> On 26.03.2016 12:14, Marek Vasut wrote:
>>
>> Hi!
>>
>> I noticed that arch/arc/boot/dts/axs10x_mb.dtsi uses "altr," prefix 
>> in
>> the DT compatible string:
>>
>> mmc@0x15000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = < 0x15000 0x400 >;
>> num-slots = < 1 >;
>> fifo-depth = < 16 >;
>> card-detect-delay = < 200 >;
>> clocks = <>, <>;
>> clock-names = "biu", "ciu";
>> interrupts = < 7 >;
>> bus-width = < 4 >;
>> };
>>
>> I don't think this is OK, since ARC is unrelated to Altera, which is
>> what the "altr," prefix stands for. I think the socfpga-dw-mshc shim
>> should be extended with another compatibility string, something like
>> "snps,arc-dw-mshc" and the axs10x_mb.dtsi should be adjusted
>> accordingly. What do you think ?
>>
> There is "snps,dw-mshc" described in
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt and 
> supported by
> dw_mmc host controller driver.
 Thanks, that's even better.

 btw what do you think of using altr, prefix on non-altera system, that
 doesn't seem ok, right ?
>>> according to ePAPR the prefix should represent a device (IP block here
>>> I believe) manufacturer, so it should be okay to use "altr" prefix on
>>> non-Altera system, if Altera provides  another hardware vendor with
>>> some own IP block.
>> In this case, it's Synopsys who provides the SD/MMC/MS core to other
>> chip makers (Altera etc).
> Correct.
>
>>
>>>
>>> That said, I would rather prefer to see "snps,dw-mshc" prefix on 
>>> description
>>> of an MMC controller found on SoCFPGA series, "altr,socfpga-dw-mshc" 
>>> seems
>>> to be redundant.

Yes..it's redundant..i should be combined to "snps,dw-mshc".

>> According to drivers/mmc/host/dw_mmc-pltfm.c , the Altera SoCFPGA one
>> "altr,socfpga-dw-mshc" and also Imagination Technology Pistacio one
>> "img,pistachio-dw-mshc" need specialty bit (SDMMC_CMD_USE_HOLD_REG),
>> while the stock one "snps,dw-mshc" does not. I am not sure if the ARC
>> one needs it as well, but most likely yes.
>>
>> I wonder if that bit is needed on some particular version of the DWMMC
>> core. In that case, should we have "snps,dw-mshc" and "snps,dw-mshc-vN"
>> binding ? Or should we use DT property to discern the need for this bit ?
>>
> That's the most common way to take into account peculiarities, add
> a property and handle it from the driver.
 And by "that" you mean which of those two I listed , the
 "snps,dw-mshc-vN" or adding new DT prop ?

>>> I meant to add a new property, not a new compatible, but that's just
>>> my experience.
>>>
>>> Let me say it __might__ happen that a particular change you need is
>>> specific to a particular version of the DWMMC IP (query Synopsys
>>> by the way), but more probably it might be e.g. the same IP version with
>>> a different reduced or extended configuration or a minor fix/improvement
>>> to the IP block without resulting version number bump.
>>>
>>> For example I don't remember that errata fixes in IP blocks result in
>>> a new compatible, instead there are quite common optional "quirk"
>>> properties for broken IPs -- e.g. check bindings/usb/dwc3.txt :)
>> Right, this very much matches how I see it as well. Thanks for confirming.
>>
>> Alexey, can you tell us if the requirement for setting
>> SDMMC_CMD_USE_HOLD_REG came with some new revision of the core or
>> disappeared with some revision OR if this is some configuration
>> option of the core during synthesis ?
> 
> Sorry for not following that discussion during my weekend but I'll try
> to address all questions now.

SDMMC_CMD_USE_HOLD_REG didn't come with new revision..It's using continuously.
But it's difficult to use the generic feature..because it's considered the 
below things.

If Card is SDR50/SDR104/DDR50 mode..
1) and phase shift of cclk_in_drv is 0 then SDMMC_CMD_USE_HOLD_REG bit 
is set to 0,
2) and phase shift of cclk_in_drv > 0 then SDMMC_CMD_USE_HOLD_REG bit 
is set to 1,
If Card is SDR12/SDR25 mode, then this bit is 

[PATCH net-next 1/2] net: hns: fixed the setting and getting overtime bug

[Yisen Zhuang]

From: Lisheng 

The overtime setting and getting REGs in HNS V2 is defferent from HNS V1.
It needs to be distinguished between them if getting or setting the REGs.

Signed-off-by: Lisheng 
Signed-off-by: Yisen Zhuang 
---
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |  60 +++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 196 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h |  23 +--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |   1 +
 4 files changed, 126 insertions(+), 154 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 285c893..1dd1d69 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -159,11 +159,6 @@ struct hnae_handle *hns_ae_get_handle(struct hnae_ae_dev 
*dev,
ae_handle->qs[i]->tx_ring.q = ae_handle->qs[i];
 
ring_pair_cb->used_by_vf = 1;
-   if (port_idx < DSAF_SERVICE_PORT_NUM_PER_DSAF)
-   ring_pair_cb->port_id_in_dsa = port_idx;
-   else
-   ring_pair_cb->port_id_in_dsa = 0;
-
ring_pair_cb++;
}
 
@@ -453,59 +448,46 @@ static int hns_ae_set_pauseparam(struct hnae_handle 
*handle,
 static void hns_ae_get_coalesce_usecs(struct hnae_handle *handle,
  u32 *tx_usecs, u32 *rx_usecs)
 {
-   int port;
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   *tx_usecs = hns_rcb_get_coalesce_usecs(
-   hns_ae_get_dsaf_dev(handle->dev),
-   hns_dsaf_get_comm_idx_by_port(port));
-   *rx_usecs = hns_rcb_get_coalesce_usecs(
-   hns_ae_get_dsaf_dev(handle->dev),
-   hns_dsaf_get_comm_idx_by_port(port));
+   *tx_usecs = hns_rcb_get_coalesce_usecs(ring_pair->rcb_common,
+  ring_pair->port_id_in_comm);
+   *rx_usecs = hns_rcb_get_coalesce_usecs(ring_pair->rcb_common,
+  ring_pair->port_id_in_comm);
 }
 
 static void hns_ae_get_rx_max_coalesced_frames(struct hnae_handle *handle,
   u32 *tx_frames, u32 *rx_frames)
 {
-   int port;
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   assert(handle);
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
-
-   *tx_frames = hns_rcb_get_coalesced_frames(
-   hns_ae_get_dsaf_dev(handle->dev), port);
-   *rx_frames = hns_rcb_get_coalesced_frames(
-   hns_ae_get_dsaf_dev(handle->dev), port);
+   *tx_frames = hns_rcb_get_coalesced_frames(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
+   *rx_frames = hns_rcb_get_coalesced_frames(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
 }
 
 static void hns_ae_set_coalesce_usecs(struct hnae_handle *handle,
  u32 timeout)
 {
-   int port;
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   assert(handle);
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
-
-   hns_rcb_set_coalesce_usecs(hns_ae_get_dsaf_dev(handle->dev),
-  port, timeout);
+   (void)hns_rcb_set_coalesce_usecs(
+   ring_pair->rcb_common, ring_pair->port_id_in_comm, timeout);
 }
 
 static int  hns_ae_set_coalesce_frames(struct hnae_handle *handle,
   u32 coalesce_frames)
 {
-   int port;
-   int ret;
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   assert(handle);
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
-
-   ret = hns_rcb_set_coalesced_frames(hns_ae_get_dsaf_dev(handle->dev),
-  port, coalesce_frames);
-   return ret;
+   return hns_rcb_set_coalesced_frames(
+   ring_pair->rcb_common,
+   ring_pair->port_id_in_comm, coalesce_frames);
 }
 
 void hns_ae_update_stats(struct hnae_handle *handle,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 1218880..28ee26e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -215,9 +215,9 @@ static void hns_rcb_ring_init(struct ring_pair_cb 
*ring_pair, int ring_type)
dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
 

[PATCH net-next 1/2] net: hns: fixed the setting and getting overtime bug

[Yisen Zhuang]

From: Lisheng 

The overtime setting and getting REGs in HNS V2 is defferent from HNS V1.
It needs to be distinguished between them if getting or setting the REGs.

Signed-off-by: Lisheng 
Signed-off-by: Yisen Zhuang 
---
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |  60 +++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 196 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h |  23 +--
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h |   1 +
 4 files changed, 126 insertions(+), 154 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 285c893..1dd1d69 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -159,11 +159,6 @@ struct hnae_handle *hns_ae_get_handle(struct hnae_ae_dev 
*dev,
ae_handle->qs[i]->tx_ring.q = ae_handle->qs[i];
 
ring_pair_cb->used_by_vf = 1;
-   if (port_idx < DSAF_SERVICE_PORT_NUM_PER_DSAF)
-   ring_pair_cb->port_id_in_dsa = port_idx;
-   else
-   ring_pair_cb->port_id_in_dsa = 0;
-
ring_pair_cb++;
}
 
@@ -453,59 +448,46 @@ static int hns_ae_set_pauseparam(struct hnae_handle 
*handle,
 static void hns_ae_get_coalesce_usecs(struct hnae_handle *handle,
  u32 *tx_usecs, u32 *rx_usecs)
 {
-   int port;
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   *tx_usecs = hns_rcb_get_coalesce_usecs(
-   hns_ae_get_dsaf_dev(handle->dev),
-   hns_dsaf_get_comm_idx_by_port(port));
-   *rx_usecs = hns_rcb_get_coalesce_usecs(
-   hns_ae_get_dsaf_dev(handle->dev),
-   hns_dsaf_get_comm_idx_by_port(port));
+   *tx_usecs = hns_rcb_get_coalesce_usecs(ring_pair->rcb_common,
+  ring_pair->port_id_in_comm);
+   *rx_usecs = hns_rcb_get_coalesce_usecs(ring_pair->rcb_common,
+  ring_pair->port_id_in_comm);
 }
 
 static void hns_ae_get_rx_max_coalesced_frames(struct hnae_handle *handle,
   u32 *tx_frames, u32 *rx_frames)
 {
-   int port;
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   assert(handle);
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
-
-   *tx_frames = hns_rcb_get_coalesced_frames(
-   hns_ae_get_dsaf_dev(handle->dev), port);
-   *rx_frames = hns_rcb_get_coalesced_frames(
-   hns_ae_get_dsaf_dev(handle->dev), port);
+   *tx_frames = hns_rcb_get_coalesced_frames(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
+   *rx_frames = hns_rcb_get_coalesced_frames(ring_pair->rcb_common,
+ ring_pair->port_id_in_comm);
 }
 
 static void hns_ae_set_coalesce_usecs(struct hnae_handle *handle,
  u32 timeout)
 {
-   int port;
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   assert(handle);
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
-
-   hns_rcb_set_coalesce_usecs(hns_ae_get_dsaf_dev(handle->dev),
-  port, timeout);
+   (void)hns_rcb_set_coalesce_usecs(
+   ring_pair->rcb_common, ring_pair->port_id_in_comm, timeout);
 }
 
 static int  hns_ae_set_coalesce_frames(struct hnae_handle *handle,
   u32 coalesce_frames)
 {
-   int port;
-   int ret;
+   struct ring_pair_cb *ring_pair =
+   container_of(handle->qs[0], struct ring_pair_cb, q);
 
-   assert(handle);
-
-   port = hns_ae_map_eport_to_dport(handle->eport_id);
-
-   ret = hns_rcb_set_coalesced_frames(hns_ae_get_dsaf_dev(handle->dev),
-  port, coalesce_frames);
-   return ret;
+   return hns_rcb_set_coalesced_frames(
+   ring_pair->rcb_common,
+   ring_pair->port_id_in_comm, coalesce_frames);
 }
 
 void hns_ae_update_stats(struct hnae_handle *handle,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 1218880..28ee26e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -215,9 +215,9 @@ static void hns_rcb_ring_init(struct ring_pair_cb 
*ring_pair, int ring_type)
dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
   bd_size_type);
dsaf_write_dev(q,