Re: [PATCH v2] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Alexey Brodkin 
Hi Daniel,

On Sun, 2018-11-18 at 03:17 +0100, Daniel Lezcano wrote:
> On 05/11/2018 15:39, Daniel Lezcano wrote:
> > On 24/10/2018 00:33, Vineet Gupta wrote:
> > > On 10/17/2018 04:30 AM, Alexey Brodkin wrote:
> > > > It turned out we used to use default implementation of sched_clock()
> > > > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > > > by default we had 10 msec granularity of time measurement.
> > > > 
> > > > Now given ARC built-in timers are clocked with the same frequency as
> > > > CPU cores we may get much higher precision of time tracking.
> > > > 
> > > > Thus we switch to generic sched_clock which really reads ARC hardware
> > > > counters.
> > > > 
> > > > This is especially helpful for measuring short events.
> > > > That's what we used to have:
> > > > -->8
> > > > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> > > > 
> > > >  Performance counter stats for '/bin/sh -c 
> > > > /root/lmbench-master/bin/arc/hello':
> > > > 
> > > >  10.00  task-clock (msec) #2.832 CPUs 
> > > > utilized
> > > >  1  context-switches  #0.100 K/sec
> > > >  1  cpu-migrations#0.100 K/sec
> > > > 63  page-faults   #0.006 M/sec
> > > >3049480  cycles#0.305 GHz
> > > >1091259  instructions  #0.36  insn per 
> > > > cycle
> > > > 256828  branches  #   25.683 M/sec
> > > >  27026  branch-misses #   10.52% of all 
> > > > branches
> > > > 
> > > >0.003530687 seconds time elapsed
> > > > 
> > > >0.0 seconds user
> > > >0.01000 seconds sys
> > > > -->8
> > > > 
> > > > And now we'll see:
> > > > -->8
> > > > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> > > > 
> > > >  Performance counter stats for '/bin/sh -c 
> > > > /root/lmbench-master/bin/arc/hello':
> > > > 
> > > >   3.004322  task-clock (msec) #0.865 CPUs 
> > > > utilized
> > > >  1  context-switches  #0.333 K/sec
> > > >  1  cpu-migrations#0.333 K/sec
> > > > 63  page-faults   #0.021 M/sec
> > > >2986734  cycles#0.994 GHz
> > > >1087466  instructions  #0.36  insn per 
> > > > cycle
> > > > 255209  branches  #   84.947 M/sec
> > > >  26002  branch-misses #   10.19% of all 
> > > > branches
> > > > 
> > > >0.003474829 seconds time elapsed
> > > > 
> > > >0.003519000 seconds user
> > > >0.0 seconds sys
> > > > -->8
> > > > 
> > > > Note how much more meaningful is the second output - time spent for
> > > > execution pretty much matches number of cycles spent (we're running
> > > > @ 1GHz here).
> > > > 
> > > > Signed-off-by: Alexey Brodkin 
> > > > Cc: Daniel Lezcano 
> > > > Cc: Vineet Gupta 
> > > > Cc: Thomas Gleixner 
> > > > ---
> > > 
> > > Acked-by: Vineet Gupta 
> > > 
> > > @Daniel is this going via timer tree or you want me to pick it up.
> > 
> > I will take care of it.
> 
> Please resend without the arch Kconfig change

I'm wondering if there's a problem with arc/arc/Kconfig change going
through your tree? This way it will be really atomic change and it will be
much easier to back-port (and that's what we'd really like to happen).

If Vineet is OK with that IMHO it's safe to keep it in the one and only commit.

Otherwise should I just split this patch in 2 and still submit them as series or
have 2 completely not-related patches one for you and one for Vineet?

In that case do I understand correctly that we may enable GENERIC_SCHED_CLOCK
for ARC even before proposed change for arc_timer.c gets merged - i.e. with no
special GENERIC_SCHED_CLOCK driver we'll safely fall-back to jiffie-based
sched clock which we anyways use now when GENERIC_SCHED_CLOCK is disabled, 
right?

-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Daniel Lezcano 
On 19/11/2018 10:31, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Sun, 2018-11-18 at 03:17 +0100, Daniel Lezcano wrote:
>> On 05/11/2018 15:39, Daniel Lezcano wrote:
>>> On 24/10/2018 00:33, Vineet Gupta wrote:
 On 10/17/2018 04:30 AM, Alexey Brodkin wrote:
> It turned out we used to use default implementation of sched_clock()
> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> by default we had 10 msec granularity of time measurement.
>
> Now given ARC built-in timers are clocked with the same frequency as
> CPU cores we may get much higher precision of time tracking.
>
> Thus we switch to generic sched_clock which really reads ARC hardware
> counters.
>
> This is especially helpful for measuring short events.
> That's what we used to have:
> -->8
> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
>
>  Performance counter stats for '/bin/sh -c 
> /root/lmbench-master/bin/arc/hello':
>
>  10.00  task-clock (msec) #2.832 CPUs utilized
>  1  context-switches  #0.100 K/sec
>  1  cpu-migrations#0.100 K/sec
> 63  page-faults   #0.006 M/sec
>3049480  cycles#0.305 GHz
>1091259  instructions  #0.36  insn per 
> cycle
> 256828  branches  #   25.683 M/sec
>  27026  branch-misses #   10.52% of all 
> branches
>
>0.003530687 seconds time elapsed
>
>0.0 seconds user
>0.01000 seconds sys
> -->8
>
> And now we'll see:
> -->8
> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
>
>  Performance counter stats for '/bin/sh -c 
> /root/lmbench-master/bin/arc/hello':
>
>   3.004322  task-clock (msec) #0.865 CPUs utilized
>  1  context-switches  #0.333 K/sec
>  1  cpu-migrations#0.333 K/sec
> 63  page-faults   #0.021 M/sec
>2986734  cycles#0.994 GHz
>1087466  instructions  #0.36  insn per 
> cycle
> 255209  branches  #   84.947 M/sec
>  26002  branch-misses #   10.19% of all 
> branches
>
>0.003474829 seconds time elapsed
>
>0.003519000 seconds user
>0.0 seconds sys
> -->8
>
> Note how much more meaningful is the second output - time spent for
> execution pretty much matches number of cycles spent (we're running
> @ 1GHz here).
>
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Lezcano 
> Cc: Vineet Gupta 
> Cc: Thomas Gleixner 
> ---

 Acked-by: Vineet Gupta 

 @Daniel is this going via timer tree or you want me to pick it up.
>>>
>>> I will take care of it.
>>
>> Please resend without the arch Kconfig change
> 
> I'm wondering if there's a problem with arc/arc/Kconfig change going
> through your tree? This way it will be really atomic change and it will be
> much easier to back-port (and that's what we'd really like to happen).
> 
> If Vineet is OK with that IMHO it's safe to keep it in the one and only 
> commit.
> 
> Otherwise should I just split this patch in 2 and still submit them as series 
> or
> have 2 completely not-related patches one for you and one for Vineet?
> 
> In that case do I understand correctly that we may enable GENERIC_SCHED_CLOCK
> for ARC even before proposed change for arc_timer.c gets merged - i.e. with no
> special GENERIC_SCHED_CLOCK driver we'll safely fall-back to jiffie-based
> sched clock which we anyways use now when GENERIC_SCHED_CLOCK is disabled, 
> right?

The ARC's Kconfig part does not apply on tip/timers/core.

As you described, sending a separate arc timer change is fine IMO.





-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Alexey Brodkin 
Hi Daniel,

On Mon, 2018-11-19 at 10:43 +0100, Daniel Lezcano wrote:
> On 19/11/2018 10:31, Alexey Brodkin wrote:
> > Hi Daniel,
> > 
> > On Sun, 2018-11-18 at 03:17 +0100, Daniel Lezcano wrote:
> > > On 05/11/2018 15:39, Daniel Lezcano wrote:
> > > > On 24/10/2018 00:33, Vineet Gupta wrote:
> > > > > On 10/17/2018 04:30 AM, Alexey Brodkin wrote:
> > > > > > It turned out we used to use default implementation of sched_clock()
> > > > > > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > > > > > by default we had 10 msec granularity of time measurement.
> > > > > > 
> > > > > > Now given ARC built-in timers are clocked with the same frequency as
> > > > > > CPU cores we may get much higher precision of time tracking.
> > > > > > 
> > > > > > Thus we switch to generic sched_clock which really reads ARC 
> > > > > > hardware
> > > > > > counters.
> > > > > > 
> > > > > > This is especially helpful for measuring short events.
> > > > > > That's what we used to have:
> > > > > > -->8
> > > > > > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > 
> > > > > > /dev/null
> > > > > > 
> > > > > >  Performance counter stats for '/bin/sh -c 
> > > > > > /root/lmbench-master/bin/arc/hello':
> > > > > > 
> > > > > >  10.00  task-clock (msec) #2.832 CPUs 
> > > > > > utilized
> > > > > >  1  context-switches  #0.100 K/sec
> > > > > >  1  cpu-migrations#0.100 K/sec
> > > > > > 63  page-faults   #0.006 M/sec
> > > > > >3049480  cycles#0.305 GHz
> > > > > >1091259  instructions  #0.36  insn 
> > > > > > per cycle
> > > > > > 256828  branches  #   25.683 M/sec
> > > > > >  27026  branch-misses #   10.52% of all 
> > > > > > branches
> > > > > > 
> > > > > >0.003530687 seconds time elapsed
> > > > > > 
> > > > > >0.0 seconds user
> > > > > >0.01000 seconds sys
> > > > > > -->8
> > > > > > 
> > > > > > And now we'll see:
> > > > > > -->8
> > > > > > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > 
> > > > > > /dev/null
> > > > > > 
> > > > > >  Performance counter stats for '/bin/sh -c 
> > > > > > /root/lmbench-master/bin/arc/hello':
> > > > > > 
> > > > > >   3.004322  task-clock (msec) #0.865 CPUs 
> > > > > > utilized
> > > > > >  1  context-switches  #0.333 K/sec
> > > > > >  1  cpu-migrations#0.333 K/sec
> > > > > > 63  page-faults   #0.021 M/sec
> > > > > >2986734  cycles#0.994 GHz
> > > > > >1087466  instructions  #0.36  insn 
> > > > > > per cycle
> > > > > > 255209  branches  #   84.947 M/sec
> > > > > >  26002  branch-misses #   10.19% of all 
> > > > > > branches
> > > > > > 
> > > > > >0.003474829 seconds time elapsed
> > > > > > 
> > > > > >0.003519000 seconds user
> > > > > >0.0 seconds sys
> > > > > > -->8
> > > > > > 
> > > > > > Note how much more meaningful is the second output - time spent for
> > > > > > execution pretty much matches number of cycles spent (we're running
> > > > > > @ 1GHz here).
> > > > > > 
> > > > > > Signed-off-by: Alexey Brodkin 
> > > > > > Cc: Daniel Lezcano 
> > > > > > Cc: Vineet Gupta 
> > > > > > Cc: Thomas Gleixner 
> > > > > > ---
> > > > > 
> > > > > Acked-by: Vineet Gupta 
> > > > > 
> > > > > @Daniel is this going via timer tree or you want me to pick it up.
> > > > 
> > > > I will take care of it.
> > > 
> > > Please resend without the arch Kconfig change
> > 
> > I'm wondering if there's a problem with arc/arc/Kconfig change going
> > through your tree? This way it will be really atomic change and it will be
> > much easier to back-port (and that's what we'd really like to happen).
> > 
> > If Vineet is OK with that IMHO it's safe to keep it in the one and only 
> > commit.
> > 
> > Otherwise should I just split this patch in 2 and still submit them as 
> > series or
> > have 2 completely not-related patches one for you and one for Vineet?
> > 
> > In that case do I understand correctly that we may enable 
> > GENERIC_SCHED_CLOCK
> > for ARC even before proposed change for arc_timer.c gets merged - i.e. with 
> > no
> > special GENERIC_SCHED_CLOCK driver we'll safely fall-back to jiffie-based
> > sched clock which we anyways use now when GENERIC_SCHED_CLOCK is disabled, 
> > right?
> 
> The ARC's Kconfig part does not apply on tip/timers/core.

May I

Re: [PATCH v2] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Daniel Lezcano 

Hi Alexey,

On 19/11/2018 10:55, Alexey Brodkin wrote:
> Hi Daniel,

[ ... ]

>>> In that case do I understand correctly that we may enable 
>>> GENERIC_SCHED_CLOCK
>>> for ARC even before proposed change for arc_timer.c gets merged - i.e. with 
>>> no
>>> special GENERIC_SCHED_CLOCK driver we'll safely fall-back to jiffie-based
>>> sched clock which we anyways use now when GENERIC_SCHED_CLOCK is disabled, 
>>> right?
>>
>> The ARC's Kconfig part does not apply on tip/timers/core.
> 
> May I have a reference to that tree so I may check what gets in the way there
> and then I'll just move "select GENERIC_SCHED_CLOCK" a bit below so there're 
> no
> clashes any longer.

sure, here it is:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=timers/core


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v3] u-boot: Add mkenvimage tool

2018-11-19 Thread Alexey Brodkin 
This utility is used for creation of images containing
usable in run-time U-Boot environment.

As of today this utility is added per-board like here [1]
for Intel Edison board.

[1] 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb

Given there're quite some U-Boot tools that we may want to add later
this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools"
still for compatibility we provide "u-boot-mkimage" with help
of PROVIDES as well as proposed "u-boot-mkenvimage".

Signed-off-by: Alexey Brodkin 
Cc: Richard Purdie 
Cc: Otavio Salvador 
Cc: Martin Jansa 
Cc: Ross Burton 
Cc: Marek Vasut 
---

Changes v2 -> v3:
 * Recipe renamed to "u-boot-tools" to better match its contents
   (especially in the future as we add more tools there)
 * Existing "u-boot-mkimage" and newly introduced "u-boot-mkenvimage"
   made avaialble via PROVIDES

Changes v1 -> v2:
 * Got rid of a separate recipe and instead added mkenvimage
   to u-boot mkimage recipy

 .../{u-boot-mkimage_2018.07.bb => u-boot-tools_2018.07.bb}   | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)
 rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2018.07.bb => 
u-boot-tools_2018.07.bb} (83%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
similarity index 83%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb
rename to meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
index 08bff1d161..140afa8dfe 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
@@ -1,7 +1,8 @@
 require u-boot-common_${PV}.inc
 
-SUMMARY = "U-Boot bootloader image creation tool"
+SUMMARY = "U-Boot bootloader tools"
 DEPENDS += "openssl"
+PROVIDES = "u-boot-mkimage u-boot-mkenvimage"
 
 EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} 
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
STRIP=true V=1'
 EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1'
@@ -20,8 +21,14 @@ do_compile () {
 
 do_install () {
install -d ${D}${bindir}
+
+   # mkimage
install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage
ln -sf uboot-mkimage ${D}${bindir}/mkimage
+
+   # mkenvimage
+   install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
+   ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
 }
 
 RDEPENDS_${PN} += "dtc"
-- 
2.16.2


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v3] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Alexey Brodkin 
It turned out we used to use default implementation of sched_clock()
from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
by default we had 10 msec granularity of time measurement.

Now given ARC built-in timers are clocked with the same frequency as
CPU cores we may get much higher precision of time tracking.

Thus we switch to generic sched_clock which really reads ARC hardware
counters.

This is especially helpful for measuring short events.
That's what we used to have:
-->8
$ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null

 Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':

 10.00  task-clock (msec) #2.832 CPUs utilized
 1  context-switches  #0.100 K/sec
 1  cpu-migrations#0.100 K/sec
63  page-faults   #0.006 M/sec
   3049480  cycles#0.305 GHz
   1091259  instructions  #0.36  insn per cycle
256828  branches  #   25.683 M/sec
 27026  branch-misses #   10.52% of all branches

   0.003530687 seconds time elapsed

   0.0 seconds user
   0.01000 seconds sys
-->8

And now we'll see:
-->8
$ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null

 Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':

  3.004322  task-clock (msec) #0.865 CPUs utilized
 1  context-switches  #0.333 K/sec
 1  cpu-migrations#0.333 K/sec
63  page-faults   #0.021 M/sec
   2986734  cycles#0.994 GHz
   1087466  instructions  #0.36  insn per cycle
255209  branches  #   84.947 M/sec
 26002  branch-misses #   10.19% of all branches

   0.003474829 seconds time elapsed

   0.003519000 seconds user
   0.0 seconds sys
-->8

Note how much more meaningful is the second output - time spent for
execution pretty much matches number of cycles spent (we're runnign
@ 1GHz here).

Signed-off-by: Alexey Brodkin 
Cc: Daniel Lezcano 
Cc: Vineet Gupta 
Cc: Thomas Gleixner 
---

Changes v2 -> v3:
 * Rebased on top of v4.20-rc3
 * Moved GENERIC_SCHED_CLOCK to alphabetically-sorted location in
   arch/arc/Kconfig

Changes v1 -> v2:
 * Timer read callbacks marked as "notrace"
 * ARC Timer1 explicitly described as 32-bit one on
   sched_clock_register() invocation

 arch/arc/Kconfig|  1 +
 drivers/clocksource/Kconfig |  1 +
 drivers/clocksource/arc_timer.c | 22 ++
 3 files changed, 24 insertions(+)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index c9e2a1323536..74b5a654f664 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -26,6 +26,7 @@ config ARC
select GENERIC_IRQ_SHOW
select GENERIC_PCI_IOMAP
select GENERIC_PENDING_IRQ if SMP
+   select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 55c77e44bb2d..d9c8a779dd7d 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -290,6 +290,7 @@ config CLKSRC_MPS2
 
 config ARC_TIMERS
bool "Support for 32-bit TIMERn counters in ARC Cores" if COMPILE_TEST
+   depends on GENERIC_SCHED_CLOCK
select TIMER_OF
help
  These are legacy 32-bit TIMER0 and TIMER1 counters found on all ARC 
cores
diff --git a/drivers/clocksource/arc_timer.c b/drivers/clocksource/arc_timer.c
index 20da9b1d7f7d..b28970ca4a7a 100644
--- a/drivers/clocksource/arc_timer.c
+++ b/drivers/clocksource/arc_timer.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -88,6 +89,11 @@ static u64 arc_read_gfrc(struct clocksource *cs)
return (((u64)h) << 32) | l;
 }
 
+static notrace u64 arc_gfrc_clock_read(void)
+{
+   return arc_read_gfrc(NULL);
+}
+
 static struct clocksource arc_counter_gfrc = {
.name   = "ARConnect GFRC",
.rating = 400,
@@ -111,6 +117,8 @@ static int __init arc_cs_setup_gfrc(struct device_node 
*node)
if (ret)
return ret;
 
+   sched_clock_register(arc_gfrc_clock_read, 64, arc_timer_freq);
+
return clocksource_register_hz(&arc_counter_gfrc, arc_timer_freq);
 }
 TIMER_OF_DECLARE(arc_gfrc, "snps,archs-timer-gfrc", arc_cs_setup_gfrc);
@@ -139,6 +147,11 @@ static u64 arc_read_rtc(struct clocksource *cs)
return ((

Re: [PATCH v2] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Alexey Brodkin 
Hi Daniel,

On Mon, 2018-11-19 at 10:58 +0100, Daniel Lezcano wrote:
> Hi Alexey,
> 
> On 19/11/2018 10:55, Alexey Brodkin wrote:
> > Hi Daniel,
> 
> [ ... ]
> 
> > > > In that case do I understand correctly that we may enable 
> > > > GENERIC_SCHED_CLOCK
> > > > for ARC even before proposed change for arc_timer.c gets merged - i.e. 
> > > > with no
> > > > special GENERIC_SCHED_CLOCK driver we'll safely fall-back to 
> > > > jiffie-based
> > > > sched clock which we anyways use now when GENERIC_SCHED_CLOCK is 
> > > > disabled, right?
> > > 
> > > The ARC's Kconfig part does not apply on tip/timers/core.
> > 
> > May I have a reference to that tree so I may check what gets in the way 
> > there
> > and then I'll just move "select GENERIC_SCHED_CLOCK" a bit below so 
> > there're no
> > clashes any longer.
> 
> sure, here it is:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_tip_tip.git_log_-3Fh-3Dtimers_core&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=r2hJtdjpPi2Y1yDo7wgo7nKu7MV8MU8gRPg3DD1mcyI&s=NOTZZBd25Vlk8-jmMUHxtpEhfxlkanXdvKN3-HQSc9w&e=

Well I did have it based on 4.18 for some reason thus were those clashes.
Rebased on top of Linus' up-to-date tree and re-sent v3.

-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Daniel Lezcano 
On 19/11/2018 12:29, Alexey Brodkin wrote:

[ ... ]

>  arch/arc/Kconfig|  1 +
>  drivers/clocksource/Kconfig |  1 +
>  drivers/clocksource/arc_timer.c | 22 ++
>  3 files changed, 24 insertions(+)
> 
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig

Can I have an Ack for the arch part ?

Thanks
  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3] u-boot: Add mkenvimage tool

2018-11-19 Thread Marek Vasut 
On 11/19/2018 11:04 AM, Alexey Brodkin wrote:
> This utility is used for creation of images containing
> usable in run-time U-Boot environment.
> 
> As of today this utility is added per-board like here [1]
> for Intel Edison board.
> 
> [1] 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb
> 
> Given there're quite some U-Boot tools that we may want to add later
> this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools"
> still for compatibility we provide "u-boot-mkimage" with help
> of PROVIDES as well as proposed "u-boot-mkenvimage".
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Richard Purdie 
> Cc: Otavio Salvador 
> Cc: Martin Jansa 
> Cc: Ross Burton 
> Cc: Marek Vasut 

Do we want to generate one package per tool or not ?

> ---
> 
> Changes v2 -> v3:
>  * Recipe renamed to "u-boot-tools" to better match its contents
>(especially in the future as we add more tools there)
>  * Existing "u-boot-mkimage" and newly introduced "u-boot-mkenvimage"
>made avaialble via PROVIDES
> 
> Changes v1 -> v2:
>  * Got rid of a separate recipe and instead added mkenvimage
>to u-boot mkimage recipy
> 
>  .../{u-boot-mkimage_2018.07.bb => u-boot-tools_2018.07.bb}   | 9 
> -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>  rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2018.07.bb => 
> u-boot-tools_2018.07.bb} (83%)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb 
> b/meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
> similarity index 83%
> rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb
> rename to meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
> index 08bff1d161..140afa8dfe 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2018.07.bb
> +++ b/meta/recipes-bsp/u-boot/u-boot-tools_2018.07.bb
> @@ -1,7 +1,8 @@
>  require u-boot-common_${PV}.inc
>  
> -SUMMARY = "U-Boot bootloader image creation tool"
> +SUMMARY = "U-Boot bootloader tools"
>  DEPENDS += "openssl"
> +PROVIDES = "u-boot-mkimage u-boot-mkenvimage"
>  
>  EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} 
> ${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
> STRIP=true V=1'
>  EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} 
> ${BUILD_LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
> STRIP=true V=1'
> @@ -20,8 +21,14 @@ do_compile () {
>  
>  do_install () {
>   install -d ${D}${bindir}
> +
> + # mkimage
>   install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage
>   ln -sf uboot-mkimage ${D}${bindir}/mkimage
> +
> + # mkenvimage
> + install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
> + ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
>  }
>  
>  RDEPENDS_${PN} += "dtc"
> 


-- 
Best regards,
Marek Vasut

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v2 0/2] MTD: spi-nor: add support for sst26wf016, sst26wf032

2018-11-19 Thread Eugeniy Paltsev 
Hi Boris,

As 4.20-rc1 is already out I guess you can pick this patches to spi-nor/next?

Thanks.

On Mon, 2018-10-22 at 15:56 +0200, Boris Brezillon wrote:
> +Tudor
> 
> Hi Eugeniy,
> 
> Sorry, it's already too late for 4.20, and I won't apply patches to the
> spi-nor/next branch before 4.20-rc1 is out.
> 
> Tudor, Marek, can I have a Reviewed-by/Acked-by on this patchset?
> 
> Thanks,
> 
> Boris
> 
> > 
> > On Mon, 2018-09-10 at 14:46 +0300, Eugeniy Paltsev wrote:
> > > Add support for the SST sst26wf016 and sst26wf032 flash IC:
> > > 
> > > sst26wf*** flash series block protection implementation differs from other
> > > SST series, so we add implementation for sst26wf*** lock/unlock/is_locked
> > > functions.
> > > 
> > > Add sst26wf016 and sst26wf032 flash IC info to spi_flash_ids list.
> > > 
> > > Eugeniy Paltsev (2):
> > >   mtd: spi-nor: Add support of sst26wf* flash ICs protection ops
> > >   mtd: spi-nor: add support for sst26wf016, sst26wf032
> > > 
> > >  drivers/mtd/spi-nor/spi-nor.c | 179 
> > > ++
> > >  include/linux/mtd/spi-nor.h   |   4 +
> > >  2 files changed, 183 insertions(+)
> > >   
> 
> 
-- 
 Eugeniy Paltsev
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Vineet Gupta 
On 11/19/18 3:30 AM, Alexey Brodkin wrote:
> It turned out we used to use default implementation of sched_clock()
> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> by default we had 10 msec granularity of time measurement.
>
> Now given ARC built-in timers are clocked with the same frequency as
> CPU cores we may get much higher precision of time tracking.
>
> Thus we switch to generic sched_clock which really reads ARC hardware
> counters.
>
> This is especially helpful for measuring short events.
> That's what we used to have:
> -->8
> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
>
>  Performance counter stats for '/bin/sh -c 
> /root/lmbench-master/bin/arc/hello':
>
>  10.00  task-clock (msec) #2.832 CPUs utilized
>  1  context-switches  #0.100 K/sec
>  1  cpu-migrations#0.100 K/sec
> 63  page-faults   #0.006 M/sec
>3049480  cycles#0.305 GHz
>1091259  instructions  #0.36  insn per cycle
> 256828  branches  #   25.683 M/sec
>  27026  branch-misses #   10.52% of all branches
>
>0.003530687 seconds time elapsed
>
>0.0 seconds user
>0.01000 seconds sys
> -->8
>
> And now we'll see:
> -->8
> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
>
>  Performance counter stats for '/bin/sh -c 
> /root/lmbench-master/bin/arc/hello':
>
>   3.004322  task-clock (msec) #0.865 CPUs utilized
>  1  context-switches  #0.333 K/sec
>  1  cpu-migrations#0.333 K/sec
> 63  page-faults   #0.021 M/sec
>2986734  cycles#0.994 GHz
>1087466  instructions  #0.36  insn per cycle
> 255209  branches  #   84.947 M/sec
>  26002  branch-misses #   10.19% of all branches
>
>0.003474829 seconds time elapsed
>
>0.003519000 seconds user
>0.0 seconds sys
> -->8
>
> Note how much more meaningful is the second output - time spent for
> execution pretty much matches number of cycles spent (we're runnign
> @ 1GHz here).
>
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Lezcano 
> Cc: Vineet Gupta 
> Cc: Thomas Gleixner 

Acked-by: Vineet Gupta 

Thx,
-Vineet

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool

2018-11-19 Thread Tom Rini 
On Mon, Nov 19, 2018 at 01:51:41PM +0100, Marek Vasut wrote:
> On 11/19/2018 11:04 AM, Alexey Brodkin wrote:
> > This utility is used for creation of images containing
> > usable in run-time U-Boot environment.
> > 
> > As of today this utility is added per-board like here [1]
> > for Intel Edison board.
> > 
> > [1] 
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb
> > 
> > Given there're quite some U-Boot tools that we may want to add later
> > this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools"
> > still for compatibility we provide "u-boot-mkimage" with help
> > of PROVIDES as well as proposed "u-boot-mkenvimage".
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Richard Purdie 
> > Cc: Otavio Salvador 
> > Cc: Martin Jansa 
> > Cc: Ross Burton 
> > Cc: Marek Vasut 
> 
> Do we want to generate one package per tool or not ?

I think so, yes.  Not all places will want all tools.

-- 
Tom


signature.asc
Description: PGP signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool

2018-11-19 Thread Otavio Salvador 
On Mon, Nov 19, 2018 at 5:08 PM Tom Rini  wrote:
>
> On Mon, Nov 19, 2018 at 01:51:41PM +0100, Marek Vasut wrote:
> > On 11/19/2018 11:04 AM, Alexey Brodkin wrote:
> > > This utility is used for creation of images containing
> > > usable in run-time U-Boot environment.
> > >
> > > As of today this utility is added per-board like here [1]
> > > for Intel Edison board.
> > >
> > > [1] 
> > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot-tools_2014.04.bb
> > >
> > > Given there're quite some U-Boot tools that we may want to add later
> > > this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools"
> > > still for compatibility we provide "u-boot-mkimage" with help
> > > of PROVIDES as well as proposed "u-boot-mkenvimage".
> > >
> > > Signed-off-by: Alexey Brodkin 
> > > Cc: Richard Purdie 
> > > Cc: Otavio Salvador 
> > > Cc: Martin Jansa 
> > > Cc: Ross Burton 
> > > Cc: Marek Vasut 
> >
> > Do we want to generate one package per tool or not ?
>
> I think so, yes.  Not all places will want all tools.

And a bonus to add a u-boot-tools-meta which rdepends on all. You can
copy code to do that from gstreamer-plugins packages.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [OE-core] [PATCH v3] u-boot: Add mkenvimage tool

2018-11-19 Thread Alexey Brodkin 
Hi Otavio, Tom, all,

On Mon, 2018-11-19 at 17:22 -0200, Otavio Salvador wrote:
> On Mon, Nov 19, 2018 at 5:08 PM Tom Rini  wrote:
> > On Mon, Nov 19, 2018 at 01:51:41PM +0100, Marek Vasut wrote:
> > > On 11/19/2018 11:04 AM, Alexey Brodkin wrote:
> > > > This utility is used for creation of images containing
> > > > usable in run-time U-Boot environment.
> > > > 
> > > > As of today this utility is added per-board like here [1]
> > > > for Intel Edison board.
> > > > 
> > > > [1] 
> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.yoctoproject.org_cgit_cgit.cgi_meta-2Dintel-2Dedison_tree_meta-2Dintel-2Dedison-2Dbsp_recipes-2Dbsp_u-2Dboot_u-2Dboot-2Dtools-5F2014.04.bb&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=sQnruA_KoGH_aC_YyN_lCddYmWBmcOpMVXzZtSwSbWo&s=pXmv0aNPFSCoj8CwGvwcZj-4bN_Sdjob3YwHYTzxDlw&e=
> > > > 
> > > > Given there're quite some U-Boot tools that we may want to add later
> > > > this recipe name switch from "u-boot-mkimage" to generic "u-boot-tools"
> > > > still for compatibility we provide "u-boot-mkimage" with help
> > > > of PROVIDES as well as proposed "u-boot-mkenvimage".
> > > > 
> > > > Signed-off-by: Alexey Brodkin 
> > > > Cc: Richard Purdie 
> > > > Cc: Otavio Salvador 
> > > > Cc: Martin Jansa 
> > > > Cc: Ross Burton 
> > > > Cc: Marek Vasut 
> > > 
> > > Do we want to generate one package per tool or not ?
> > 
> > I think so, yes.  Not all places will want all tools.
> 
> And a bonus to add a u-boot-tools-meta which rdepends on all. You can
> copy code to do that from gstreamer-plugins packages.

That's how we start from simple enhancement one-liner and end-up
with rework of a different scale :)

I'm still ramping-up with OE but hopefully will be able to
implement proposed tool-per-package feature sometime soon.

-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Daniel Lezcano 
On 19/11/2018 12:29, Alexey Brodkin wrote:
> It turned out we used to use default implementation of sched_clock()
> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> by default we had 10 msec granularity of time measurement.
> 
> Now given ARC built-in timers are clocked with the same frequency as
> CPU cores we may get much higher precision of time tracking.
> 
> Thus we switch to generic sched_clock which really reads ARC hardware
> counters.
> 
> This is especially helpful for measuring short events.
> That's what we used to have:
> -->8
> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> 
>  Performance counter stats for '/bin/sh -c 
> /root/lmbench-master/bin/arc/hello':
> 
>  10.00  task-clock (msec) #2.832 CPUs utilized
>  1  context-switches  #0.100 K/sec
>  1  cpu-migrations#0.100 K/sec
> 63  page-faults   #0.006 M/sec
>3049480  cycles#0.305 GHz
>1091259  instructions  #0.36  insn per cycle
> 256828  branches  #   25.683 M/sec
>  27026  branch-misses #   10.52% of all branches
> 
>0.003530687 seconds time elapsed
> 
>0.0 seconds user
>0.01000 seconds sys
> -->8
> 
> And now we'll see:
> -->8
> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> 
>  Performance counter stats for '/bin/sh -c 
> /root/lmbench-master/bin/arc/hello':
> 
>   3.004322  task-clock (msec) #0.865 CPUs utilized
>  1  context-switches  #0.333 K/sec
>  1  cpu-migrations#0.333 K/sec
> 63  page-faults   #0.021 M/sec
>2986734  cycles#0.994 GHz
>1087466  instructions  #0.36  insn per cycle
> 255209  branches  #   84.947 M/sec
>  26002  branch-misses #   10.19% of all branches
> 
>0.003474829 seconds time elapsed
> 
>0.003519000 seconds user
>0.0 seconds sys
> -->8
> 
> Note how much more meaningful is the second output - time spent for
> execution pretty much matches number of cycles spent (we're runnign
> @ 1GHz here).
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Lezcano 
> Cc: Vineet Gupta 
> Cc: Thomas Gleixner 
> ---

Applied, thanks.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Alexey Brodkin 
Hi Daniel,

On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
> On 19/11/2018 12:29, Alexey Brodkin wrote:
> > It turned out we used to use default implementation of sched_clock()
> > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > by default we had 10 msec granularity of time measurement.
> > 
> > Now given ARC built-in timers are clocked with the same frequency as
> > CPU cores we may get much higher precision of time tracking.
> > 
> > Thus we switch to generic sched_clock which really reads ARC hardware
> > counters.
> > 
> > This is especially helpful for measuring short events.
> > That's what we used to have:
> > -->8
> > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> > 
> >  Performance counter stats for '/bin/sh -c 
> > /root/lmbench-master/bin/arc/hello':
> > 
> >  10.00  task-clock (msec) #2.832 CPUs utilized
> >  1  context-switches  #0.100 K/sec
> >  1  cpu-migrations#0.100 K/sec
> > 63  page-faults   #0.006 M/sec
> >3049480  cycles#0.305 GHz
> >1091259  instructions  #0.36  insn per cycle
> > 256828  branches  #   25.683 M/sec
> >  27026  branch-misses #   10.52% of all branches
> > 
> >0.003530687 seconds time elapsed
> > 
> >0.0 seconds user
> >0.01000 seconds sys
> > -->8
> > 
> > And now we'll see:
> > -->8
> > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> > 
> >  Performance counter stats for '/bin/sh -c 
> > /root/lmbench-master/bin/arc/hello':
> > 
> >   3.004322  task-clock (msec) #0.865 CPUs utilized
> >  1  context-switches  #0.333 K/sec
> >  1  cpu-migrations#0.333 K/sec
> > 63  page-faults   #0.021 M/sec
> >2986734  cycles#0.994 GHz
> >1087466  instructions  #0.36  insn per cycle
> > 255209  branches  #   84.947 M/sec
> >  26002  branch-misses #   10.19% of all branches
> > 
> >0.003474829 seconds time elapsed
> > 
> >0.003519000 seconds user
> >0.0 seconds sys
> > -->8
> > 
> > Note how much more meaningful is the second output - time spent for
> > execution pretty much matches number of cycles spent (we're runnign
> > @ 1GHz here).
> > 
> > Signed-off-by: Alexey Brodkin 
> > Cc: Daniel Lezcano 
> > Cc: Vineet Gupta 
> > Cc: Thomas Gleixner 
> > ---
> 
> Applied, thanks.

Maybe a bit too late but I completely forgot to add stable tag into Cc list.
Any chance to add it still?

-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Daniel Lezcano 
On 19/11/2018 22:53, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
>> On 19/11/2018 12:29, Alexey Brodkin wrote:
>>> It turned out we used to use default implementation of sched_clock()
>>> from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
>>> by default we had 10 msec granularity of time measurement.
>>>
>>> Now given ARC built-in timers are clocked with the same frequency as
>>> CPU cores we may get much higher precision of time tracking.
>>>
>>> Thus we switch to generic sched_clock which really reads ARC hardware
>>> counters.
>>>
>>> This is especially helpful for measuring short events.
>>> That's what we used to have:
>>> -->8
>>> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
>>>
>>>  Performance counter stats for '/bin/sh -c 
>>> /root/lmbench-master/bin/arc/hello':
>>>
>>>  10.00  task-clock (msec) #2.832 CPUs utilized
>>>  1  context-switches  #0.100 K/sec
>>>  1  cpu-migrations#0.100 K/sec
>>> 63  page-faults   #0.006 M/sec
>>>3049480  cycles#0.305 GHz
>>>1091259  instructions  #0.36  insn per cycle
>>> 256828  branches  #   25.683 M/sec
>>>  27026  branch-misses #   10.52% of all branches
>>>
>>>0.003530687 seconds time elapsed
>>>
>>>0.0 seconds user
>>>0.01000 seconds sys
>>> -->8
>>>
>>> And now we'll see:
>>> -->8
>>> $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
>>>
>>>  Performance counter stats for '/bin/sh -c 
>>> /root/lmbench-master/bin/arc/hello':
>>>
>>>   3.004322  task-clock (msec) #0.865 CPUs utilized
>>>  1  context-switches  #0.333 K/sec
>>>  1  cpu-migrations#0.333 K/sec
>>> 63  page-faults   #0.021 M/sec
>>>2986734  cycles#0.994 GHz
>>>1087466  instructions  #0.36  insn per cycle
>>> 255209  branches  #   84.947 M/sec
>>>  26002  branch-misses #   10.19% of all branches
>>>
>>>0.003474829 seconds time elapsed
>>>
>>>0.003519000 seconds user
>>>0.0 seconds sys
>>> -->8
>>>
>>> Note how much more meaningful is the second output - time spent for
>>> execution pretty much matches number of cycles spent (we're runnign
>>> @ 1GHz here).
>>>
>>> Signed-off-by: Alexey Brodkin 
>>> Cc: Daniel Lezcano 
>>> Cc: Vineet Gupta 
>>> Cc: Thomas Gleixner 
>>> ---
>>
>> Applied, thanks.
> 
> Maybe a bit too late but I completely forgot to add stable tag into Cc list.
> Any chance to add it still?

Yes, no problem, I've added it.



[1]
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/Documentation/process/stable-kernel-rules.rst?h=timers/core


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3] clocksource/drivers/arc_timer: Utilize generic sched_clock

2018-11-19 Thread Alexey Brodkin 
On Mon, 2018-11-19 at 23:09 +0100, Daniel Lezcano wrote:
> On 19/11/2018 22:53, Alexey Brodkin wrote:
> > Hi Daniel,
> > 
> > On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
> > > On 19/11/2018 12:29, Alexey Brodkin wrote:
> > > > It turned out we used to use default implementation of sched_clock()
> > > > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > > > by default we had 10 msec granularity of time measurement.
> > > > 
> > > > Now given ARC built-in timers are clocked with the same frequency as
> > > > CPU cores we may get much higher precision of time tracking.
> > > > 
> > > > Thus we switch to generic sched_clock which really reads ARC hardware
> > > > counters.
> > > > 
> > > > This is especially helpful for measuring short events.
> > > > That's what we used to have:
> > > > -->8
> > > > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> > > > 
> > > >  Performance counter stats for '/bin/sh -c 
> > > > /root/lmbench-master/bin/arc/hello':
> > > > 
> > > >  10.00  task-clock (msec) #2.832 CPUs 
> > > > utilized
> > > >  1  context-switches  #0.100 K/sec
> > > >  1  cpu-migrations#0.100 K/sec
> > > > 63  page-faults   #0.006 M/sec
> > > >3049480  cycles#0.305 GHz
> > > >1091259  instructions  #0.36  insn per 
> > > > cycle
> > > > 256828  branches  #   25.683 M/sec
> > > >  27026  branch-misses #   10.52% of all 
> > > > branches
> > > > 
> > > >0.003530687 seconds time elapsed
> > > > 
> > > >0.0 seconds user
> > > >0.01000 seconds sys
> > > > -->8
> > > > 
> > > > And now we'll see:
> > > > -->8
> > > > $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
> > > > 
> > > >  Performance counter stats for '/bin/sh -c 
> > > > /root/lmbench-master/bin/arc/hello':
> > > > 
> > > >   3.004322  task-clock (msec) #0.865 CPUs 
> > > > utilized
> > > >  1  context-switches  #0.333 K/sec
> > > >  1  cpu-migrations#0.333 K/sec
> > > > 63  page-faults   #0.021 M/sec
> > > >2986734  cycles#0.994 GHz
> > > >1087466  instructions  #0.36  insn per 
> > > > cycle
> > > > 255209  branches  #   84.947 M/sec
> > > >  26002  branch-misses #   10.19% of all 
> > > > branches
> > > > 
> > > >0.003474829 seconds time elapsed
> > > > 
> > > >0.003519000 seconds user
> > > >0.0 seconds sys
> > > > -->8
> > > > 
> > > > Note how much more meaningful is the second output - time spent for
> > > > execution pretty much matches number of cycles spent (we're runnign
> > > > @ 1GHz here).
> > > > 
> > > > Signed-off-by: Alexey Brodkin 
> > > > Cc: Daniel Lezcano 
> > > > Cc: Vineet Gupta 
> > > > Cc: Thomas Gleixner 
> > > > ---
> > > 
> > > Applied, thanks.
> > 
> > Maybe a bit too late but I completely forgot to add stable tag into Cc list.
> > Any chance to add it still?
> 
> Yes, no problem, I've added it.

Cool, thanks!

-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 00/15] Prepare for PTRACE_GET_SYSCALL_INFO

2018-11-19 Thread Dmitry V. Levin 
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.

The primary intent is that the triple (audit_arch, syscall_nr, arg1..arg6)
should describe what system call is being called and what its arguments are.


Dmitry V. Levin (15):
  Move EM_HEXAGON to uapi/linux/elf-em.h
  Move EM_ARCOMPACT and EM_ARCV2 to uapi/linux/elf-em.h
  Move EM_UNICORE to uapi/linux/elf-em.h
  elf-em.h: add EM_NDS32
  elf-em.h: add EM_XTENSA
  m68k: define syscall_get_arch()
  arc: define syscall_get_arch()
  c6x: define syscall_get_arch()
  h8300: define syscall_get_arch()
  hexagon: define syscall_get_arch()
  nds32: define syscall_get_arch()
  nios2: define syscall_get_arch()
  riscv: define syscall_get_arch()
  unicore32: define syscall_get_arch()
  xtensa: define syscall_get_arch()

 arch/arc/include/asm/elf.h   |  6 +-
 arch/arc/include/asm/syscall.h   | 10 ++
 arch/c6x/include/asm/syscall.h   |  7 +++
 arch/h8300/include/asm/syscall.h |  5 +
 arch/hexagon/include/asm/elf.h   |  6 +-
 arch/hexagon/include/asm/syscall.h   |  8 
 arch/m68k/include/asm/syscall.h  | 12 
 arch/nds32/include/asm/syscall.h |  8 
 arch/nios2/include/asm/syscall.h |  6 ++
 arch/riscv/include/asm/syscall.h | 10 ++
 arch/unicore32/include/asm/elf.h |  3 +--
 arch/unicore32/include/asm/syscall.h | 12 
 arch/xtensa/include/asm/syscall.h|  7 +++
 include/uapi/linux/audit.h   | 15 +++
 include/uapi/linux/elf-em.h  |  7 +++
 15 files changed, 110 insertions(+), 12 deletions(-)
 create mode 100644 arch/m68k/include/asm/syscall.h
 create mode 100644 arch/unicore32/include/asm/syscall.h

-- 
ldv

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 02/15] Move EM_ARCOMPACT and EM_ARCV2 to uapi/linux/elf-em.h

2018-11-19 Thread Dmitry V. Levin 
These should never have been defined in the arch tree to begin with, and
now uapi/linux/audit.h header is going to use EM_ARCOMPACT and EM_ARCV2
in order to define AUDIT_ARCH_ARCOMPACT and AUDIT_ARCH_ARCV2 which are
needed to implement syscall_get_arch() which in turn is required to
extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.

Signed-off-by: Dmitry V. Levin 
Acked-by: Vineet Gupta 
---
v2: added Acked-by to [PATCH 02/13 v2]

 arch/arc/include/asm/elf.h  | 6 +-
 include/uapi/linux/elf-em.h | 2 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arc/include/asm/elf.h b/arch/arc/include/asm/elf.h
index aa2d6da9d187..2b80c184c9c8 100644
--- a/arch/arc/include/asm/elf.h
+++ b/arch/arc/include/asm/elf.h
@@ -10,13 +10,9 @@
 #define __ASM_ARC_ELF_H
 
 #include 
+#include 
 #include 
 
-/* These ELF defines belong to uapi but libc elf.h already defines them */
-#define EM_ARCOMPACT   93
-
-#define EM_ARCV2   195 /* ARCv2 Cores */
-
 #define EM_ARC_INUSE   (IS_ENABLED(CONFIG_ISA_ARCOMPACT) ? \
EM_ARCOMPACT : EM_ARCV2)
 
diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h
index ba3696e3d694..91b33833630b 100644
--- a/include/uapi/linux/elf-em.h
+++ b/include/uapi/linux/elf-em.h
@@ -34,6 +34,7 @@
 #define EM_M32R88  /* Renesas M32R */
 #define EM_MN10300 89  /* Panasonic/MEI MN10300, AM33 */
 #define EM_OPENRISC 92 /* OpenRISC 32-bit embedded processor */
+#define EM_ARCOMPACT   93  /* ARCompact processor */
 #define EM_BLACKFIN 106 /* ADI Blackfin Processor */
 #define EM_ALTERA_NIOS2113 /* Altera Nios II soft-core processor */
 #define EM_TI_C6000140 /* TI C6X DSPs */
@@ -42,6 +43,7 @@
 #define EM_TILEPRO 188 /* Tilera TILEPro */
 #define EM_MICROBLAZE  189 /* Xilinx MicroBlaze */
 #define EM_TILEGX  191 /* Tilera TILE-Gx */
+#define EM_ARCV2   195 /* ARCv2 Cores */
 #define EM_RISCV   243 /* RISC-V */
 #define EM_BPF 247 /* Linux BPF - in-kernel virtual machine */
 #define EM_FRV 0x5441  /* Fujitsu FR-V */
-- 
ldv

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2 07/15] arc: define syscall_get_arch()

2018-11-19 Thread Dmitry V. Levin 
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.

Signed-off-by: Dmitry V. Levin 
Acked-by: Vineet Gupta 
---
v2: added Acked-by to [PATCH 06/13 v3]

 arch/arc/include/asm/syscall.h | 10 ++
 include/uapi/linux/audit.h |  4 
 2 files changed, 14 insertions(+)

diff --git a/arch/arc/include/asm/syscall.h b/arch/arc/include/asm/syscall.h
index 29de09804306..10b2e7523bc8 100644
--- a/arch/arc/include/asm/syscall.h
+++ b/arch/arc/include/asm/syscall.h
@@ -9,6 +9,7 @@
 #ifndef _ASM_ARC_SYSCALL_H
 #define _ASM_ARC_SYSCALL_H  1
 
+#include 
 #include 
 #include 
 #include 
@@ -68,4 +69,13 @@ syscall_get_arguments(struct task_struct *task, struct 
pt_regs *regs,
}
 }
 
+static inline int syscall_get_arch(void)
+{
+   return IS_ENABLED(CONFIG_ISA_ARCOMPACT)
+   ? (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)
+   ? AUDIT_ARCH_ARCOMPACTBE : AUDIT_ARCH_ARCOMPACT)
+   : (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN)
+   ? AUDIT_ARCH_ARCV2BE : AUDIT_ARCH_ARCV2);
+}
+
 #endif
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 818ae690ab79..bedf3bf54c3a 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -375,6 +375,10 @@ enum {
 
 #define AUDIT_ARCH_AARCH64 (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
 #define AUDIT_ARCH_ALPHA   (EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
+#define AUDIT_ARCH_ARCOMPACT   (EM_ARCOMPACT|__AUDIT_ARCH_LE)
+#define AUDIT_ARCH_ARCOMPACTBE (EM_ARCOMPACT)
+#define AUDIT_ARCH_ARCV2   (EM_ARCV2|__AUDIT_ARCH_LE)
+#define AUDIT_ARCH_ARCV2BE (EM_ARCV2)
 #define AUDIT_ARCH_ARM (EM_ARM|__AUDIT_ARCH_LE)
 #define AUDIT_ARCH_ARMEB   (EM_ARM)
 #define AUDIT_ARCH_CRIS(EM_CRIS|__AUDIT_ARCH_LE)
-- 
ldv

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc