* [PATCH 2/3] powerpc: make copyuser_power7.S 64-byte cacheline friendly
From: Kim Phillips @ 2015-03-24 22:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood, Joel Stanley, Anton Blanchard, Paul Bolle,
Jiri Kosina, Ulrich Weigand, Alexander Graf, Stewart Smith,
Kyle Moffett
Cc: linux-api, linuxppc-dev, Shuah Khan, linux-kernel
The innermost copyloops were optimized for POWER7's 128-byte cacheline.
This patch adds optimization for the e6500, which has a 64-byte
cacheline.
We basically do this by stripping loop bodies using L1_CACHE_BYTES
ifdeferry, replace 128 with L1_CACHE_BYTES, and 7's with L1_CACHE_SHIFTs.
We also add an e6500 copyuser to copyloops tests, which requires we copy
asm/cache.h into copyloops, just to satisfy the #include: We define
the define symbols manually in the testing makefile.
Includes a minor spelling fix: desination->destination.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Cc: Shuah Khan <shuahkh@osg.samsung.com> [SELFTESTS]
Cc: linux-api@vger.kernel.org [SELFTESTS]
---
arch/powerpc/lib/copyuser_power7.S | 74 +++++++++++++------
tools/testing/selftests/powerpc/copyloops/Makefile | 11 ++-
.../selftests/powerpc/copyloops/asm/cache.h | 84 ++++++++++++++++++++++
3 files changed, 144 insertions(+), 25 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/copyloops/asm/cache.h
diff --git a/arch/powerpc/lib/copyuser_power7.S b/arch/powerpc/lib/copyuser_power7.S
index 92ee840..2d22e58 100644
--- a/arch/powerpc/lib/copyuser_power7.S
+++ b/arch/powerpc/lib/copyuser_power7.S
@@ -18,6 +18,7 @@
* Author: Anton Blanchard <anton@au.ibm.com>
*/
#include <asm/ppc_asm.h>
+#include <asm/cache.h>
#ifdef __BIG_ENDIAN__
#define LVS(VRT,RA,RB) lvsl VRT,RA,RB
@@ -137,7 +138,7 @@ err1; stw r0,0(r3)
addi r3,r3,4
3: sub r5,r5,r6
- cmpldi r5,128
+ cmpldi r5,L1_CACHE_BYTES
blt 5f
mflr r0
@@ -153,10 +154,10 @@ err1; stw r0,0(r3)
std r22,STK_REG(R22)(r1)
std r0,STACKFRAMESIZE+16(r1)
- srdi r6,r5,7
+ srdi r6,r5,L1_CACHE_SHIFT
mtctr r6
- /* Now do cacheline (128B) sized loads and stores. */
+ /* Now do cacheline sized loads and stores. */
.align 5
4:
err2; ld r0,0(r4)
@@ -167,6 +168,7 @@ err2; ld r9,32(r4)
err2; ld r10,40(r4)
err2; ld r11,48(r4)
err2; ld r12,56(r4)
+#if L1_CACHE_BYTES >= 128
err2; ld r14,64(r4)
err2; ld r15,72(r4)
err2; ld r16,80(r4)
@@ -175,7 +177,8 @@ err2; ld r18,96(r4)
err2; ld r19,104(r4)
err2; ld r20,112(r4)
err2; ld r21,120(r4)
- addi r4,r4,128
+#endif
+ addi r4,r4,L1_CACHE_BYTES
err2; std r0,0(r3)
err2; std r6,8(r3)
err2; std r7,16(r3)
@@ -184,6 +187,7 @@ err2; std r9,32(r3)
err2; std r10,40(r3)
err2; std r11,48(r3)
err2; std r12,56(r3)
+#if L1_CACHE_BYTES >= 128
err2; std r14,64(r3)
err2; std r15,72(r3)
err2; std r16,80(r3)
@@ -192,10 +196,11 @@ err2; std r18,96(r3)
err2; std r19,104(r3)
err2; std r20,112(r3)
err2; std r21,120(r3)
- addi r3,r3,128
+#endif
+ addi r3,r3,L1_CACHE_BYTES
bdnz 4b
- clrldi r5,r5,(64-7)
+ clrldi r5,r5,(64-L1_CACHE_SHIFT)
ld r14,STK_REG(R14)(r1)
ld r15,STK_REG(R15)(r1)
@@ -208,10 +213,11 @@ err2; std r21,120(r3)
ld r22,STK_REG(R22)(r1)
addi r1,r1,STACKFRAMESIZE
- /* Up to 127B to go */
+ /* Up to L1_CACHE_BYTES - 1 to go */
5: srdi r6,r5,4
mtocrf 0x01,r6
+#if L1_CACHE_BYTES >= 128
6: bf cr7*4+1,7f
err1; ld r0,0(r4)
err1; ld r6,8(r4)
@@ -231,6 +237,7 @@ err1; std r10,40(r3)
err1; std r11,48(r3)
err1; std r12,56(r3)
addi r3,r3,64
+#endif
/* Up to 63B to go */
7: bf cr7*4+2,8f
@@ -377,11 +384,11 @@ err3; std r0,0(r3)
4: sub r5,r5,r6
- /* Get the desination 128B aligned */
+ /* Get the destination L1_CACHE_BYTES aligned */
neg r6,r3
srdi r7,r6,4
mtocrf 0x01,r7
- clrldi r6,r6,(64-7)
+ clrldi r6,r6,(64-L1_CACHE_SHIFT)
li r9,16
li r10,32
@@ -401,7 +408,9 @@ err3; stvx vr1,r0,r3
err3; stvx vr0,r3,r9
addi r3,r3,32
-6: bf cr7*4+1,7f
+6:
+#if L1_CACHE_BYTES >= 128
+ bf cr7*4+1,7f
err3; lvx vr3,r0,r4
err3; lvx vr2,r4,r9
err3; lvx vr1,r4,r10
@@ -412,9 +421,10 @@ err3; stvx vr2,r3,r9
err3; stvx vr1,r3,r10
err3; stvx vr0,r3,r11
addi r3,r3,64
+#endif
7: sub r5,r5,r6
- srdi r6,r5,7
+ srdi r6,r5,L1_CACHE_SHIFT
std r14,STK_REG(R14)(r1)
std r15,STK_REG(R15)(r1)
@@ -437,31 +447,36 @@ err4; lvx vr7,r0,r4
err4; lvx vr6,r4,r9
err4; lvx vr5,r4,r10
err4; lvx vr4,r4,r11
+#if L1_CACHE_BYTES >= 128
err4; lvx vr3,r4,r12
err4; lvx vr2,r4,r14
err4; lvx vr1,r4,r15
err4; lvx vr0,r4,r16
- addi r4,r4,128
+#endif
+ addi r4,r4,L1_CACHE_BYTES
err4; stvx vr7,r0,r3
err4; stvx vr6,r3,r9
err4; stvx vr5,r3,r10
err4; stvx vr4,r3,r11
+#if L1_CACHE_BYTES >= 128
err4; stvx vr3,r3,r12
err4; stvx vr2,r3,r14
err4; stvx vr1,r3,r15
err4; stvx vr0,r3,r16
- addi r3,r3,128
+#endif
+ addi r3,r3,L1_CACHE_BYTES
bdnz 8b
ld r14,STK_REG(R14)(r1)
ld r15,STK_REG(R15)(r1)
ld r16,STK_REG(R16)(r1)
- /* Up to 127B to go */
- clrldi r5,r5,(64-7)
+ /* Up to L1_CACHE_BYTES - 1 to go */
+ clrldi r5,r5,(64-L1_CACHE_SHIFT)
srdi r6,r5,4
mtocrf 0x01,r6
+#if L1_CACHE_BYTES >= 128
bf cr7*4+1,9f
err3; lvx vr3,r0,r4
err3; lvx vr2,r4,r9
@@ -473,6 +488,7 @@ err3; stvx vr2,r3,r9
err3; stvx vr1,r3,r10
err3; stvx vr0,r3,r11
addi r3,r3,64
+#endif
9: bf cr7*4+2,10f
err3; lvx vr1,r0,r4
@@ -550,11 +566,11 @@ err3; stw r7,4(r3)
4: sub r5,r5,r6
- /* Get the desination 128B aligned */
+ /* Get the destination L1_CACHE_BYTES aligned */
neg r6,r3
srdi r7,r6,4
mtocrf 0x01,r7
- clrldi r6,r6,(64-7)
+ clrldi r6,r6,(64-L1_CACHE_SHIFT)
li r9,16
li r10,32
@@ -582,7 +598,9 @@ err3; stvx vr8,r0,r3
err3; stvx vr9,r3,r9
addi r3,r3,32
-6: bf cr7*4+1,7f
+6:
+#if L1_CACHE_BYTES >= 128
+ bf cr7*4+1,7f
err3; lvx vr3,r0,r4
VPERM(vr8,vr0,vr3,vr16)
err3; lvx vr2,r4,r9
@@ -597,9 +615,10 @@ err3; stvx vr9,r3,r9
err3; stvx vr10,r3,r10
err3; stvx vr11,r3,r11
addi r3,r3,64
+#endif
7: sub r5,r5,r6
- srdi r6,r5,7
+ srdi r6,r5,L1_CACHE_SHIFT
std r14,STK_REG(R14)(r1)
std r15,STK_REG(R15)(r1)
@@ -626,6 +645,10 @@ err4; lvx vr5,r4,r10
VPERM(vr10,vr6,vr5,vr16)
err4; lvx vr4,r4,r11
VPERM(vr11,vr5,vr4,vr16)
+#if L1_CACHE_BYTES == 64
+err4; lvx vr0,r4,r11
+ VPERM(vr11,vr5,vr0,vr16)
+#else
err4; lvx vr3,r4,r12
VPERM(vr12,vr4,vr3,vr16)
err4; lvx vr2,r4,r14
@@ -634,27 +657,31 @@ err4; lvx vr1,r4,r15
VPERM(vr14,vr2,vr1,vr16)
err4; lvx vr0,r4,r16
VPERM(vr15,vr1,vr0,vr16)
- addi r4,r4,128
+#endif
+ addi r4,r4,L1_CACHE_BYTES
err4; stvx vr8,r0,r3
err4; stvx vr9,r3,r9
err4; stvx vr10,r3,r10
err4; stvx vr11,r3,r11
+#if L1_CACHE_BYTES >= 128
err4; stvx vr12,r3,r12
err4; stvx vr13,r3,r14
err4; stvx vr14,r3,r15
err4; stvx vr15,r3,r16
- addi r3,r3,128
+#endif
+ addi r3,r3,L1_CACHE_BYTES
bdnz 8b
ld r14,STK_REG(R14)(r1)
ld r15,STK_REG(R15)(r1)
ld r16,STK_REG(R16)(r1)
- /* Up to 127B to go */
- clrldi r5,r5,(64-7)
+ /* Up to L1_CACHE_BYTES - 1 to go */
+ clrldi r5,r5,(64-L1_CACHE_SHIFT)
srdi r6,r5,4
mtocrf 0x01,r6
+#if L1_CACHE_BYTES >= 128
bf cr7*4+1,9f
err3; lvx vr3,r0,r4
VPERM(vr8,vr0,vr3,vr16)
@@ -670,6 +697,7 @@ err3; stvx vr9,r3,r9
err3; stvx vr10,r3,r10
err3; stvx vr11,r3,r11
addi r3,r3,64
+#endif
9: bf cr7*4+2,10f
err3; lvx vr1,r0,r4
diff --git a/tools/testing/selftests/powerpc/copyloops/Makefile b/tools/testing/selftests/powerpc/copyloops/Makefile
index 6f2d3be..eb912c5 100644
--- a/tools/testing/selftests/powerpc/copyloops/Makefile
+++ b/tools/testing/selftests/powerpc/copyloops/Makefile
@@ -6,18 +6,25 @@ CFLAGS += -D SELFTEST
# Use our CFLAGS for the implicit .S rule
ASFLAGS = $(CFLAGS)
-PROGS := copyuser_64 copyuser_power7 memcpy_64 memcpy_power7
+PROGS := copyuser_64 copyuser_power7 copyuser_e6500 memcpy_64 memcpy_power7
EXTRA_SOURCES := validate.c ../harness.c
all: $(PROGS)
copyuser_64: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_base
-copyuser_power7: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_power7
+copyuser_power7: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_power7 \
+ -D CONFIG_PPC_BOOK3S_64 -D L1_CACHE_SHIFT=7 \
+ -D L1_CACHE_BYTES=128
memcpy_64: CPPFLAGS += -D COPY_LOOP=test_memcpy
memcpy_power7: CPPFLAGS += -D COPY_LOOP=test_memcpy_power7
$(PROGS): $(EXTRA_SOURCES)
+copyuser_e6500: copyuser_power7.S
+ $(CC) $(CFLAGS) -D COPY_LOOP=test___copy_tofrom_user_power7 \
+ -D CONFIG_PPC_BOOK3E_64 -D L1_CACHE_SHIFT=6 \
+ -D L1_CACHE_BYTES=64 copyuser_power7.S $(EXTRA_SOURCES) -o $@
+
run_tests: all
@-for PROG in $(PROGS); do \
./$$PROG; \
diff --git a/tools/testing/selftests/powerpc/copyloops/asm/cache.h b/tools/testing/selftests/powerpc/copyloops/asm/cache.h
new file mode 100644
index 0000000..34a05a1
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/asm/cache.h
@@ -0,0 +1,84 @@
+#ifndef _ASM_POWERPC_CACHE_H
+#define _ASM_POWERPC_CACHE_H
+
+#ifdef __KERNEL__
+
+#include <asm/reg.h>
+
+/* bytes per L1 cache line */
+#if defined(CONFIG_8xx) || defined(CONFIG_403GCX)
+#define L1_CACHE_SHIFT 4
+#define MAX_COPY_PREFETCH 1
+#elif defined(CONFIG_PPC_E500MC)
+#define L1_CACHE_SHIFT 6
+#define MAX_COPY_PREFETCH 4
+#elif defined(CONFIG_PPC32)
+#define MAX_COPY_PREFETCH 4
+#if defined(CONFIG_PPC_47x)
+#define L1_CACHE_SHIFT 7
+#else
+#define L1_CACHE_SHIFT 5
+#endif
+#else /* CONFIG_PPC64 */
+#define L1_CACHE_SHIFT 7
+#endif
+
+#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
+
+#define SMP_CACHE_BYTES L1_CACHE_BYTES
+
+#if defined(__powerpc64__) && !defined(__ASSEMBLY__)
+struct ppc64_caches {
+ u32 dsize; /* L1 d-cache size */
+ u32 dline_size; /* L1 d-cache line size */
+ u32 log_dline_size;
+ u32 dlines_per_page;
+ u32 isize; /* L1 i-cache size */
+ u32 iline_size; /* L1 i-cache line size */
+ u32 log_iline_size;
+ u32 ilines_per_page;
+};
+
+extern struct ppc64_caches ppc64_caches;
+
+static inline void logmpp(u64 x)
+{
+ asm volatile(PPC_LOGMPP(R1) : : "r" (x));
+}
+
+#endif /* __powerpc64__ && ! __ASSEMBLY__ */
+
+#if defined(__ASSEMBLY__)
+/*
+ * For a snooping icache, we still need a dummy icbi to purge all the
+ * prefetched instructions from the ifetch buffers. We also need a sync
+ * before the icbi to order the the actual stores to memory that might
+ * have modified instructions with the icbi.
+ */
+#define PURGE_PREFETCHED_INS \
+ sync; \
+ icbi 0,r3; \
+ sync; \
+ isync
+
+#else
+#define __read_mostly __attribute__((__section__(".data..read_mostly")))
+
+#ifdef CONFIG_6xx
+extern long _get_L2CR(void);
+extern long _get_L3CR(void);
+extern void _set_L2CR(unsigned long);
+extern void _set_L3CR(unsigned long);
+#else
+#define _get_L2CR() 0L
+#define _get_L3CR() 0L
+#define _set_L2CR(val) do { } while(0)
+#define _set_L3CR(val) do { } while(0)
+#endif
+
+extern void cacheable_memzero(void *p, unsigned int nb);
+extern void *cacheable_memcpy(void *, const void *, unsigned int);
+
+#endif /* !__ASSEMBLY__ */
+#endif /* __KERNEL__ */
+#endif /* _ASM_POWERPC_CACHE_H */
--
2.3.3
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* Re: [PATCH] Add virtio gpu driver.
From: Daniel Stone @ 2015-03-24 22:50 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: virtio-dev-sDuHXQ4OtrM4h7I2RyI4rWD2FQJk+8+b, Michael S. Tsirkin,
open list:ABI/API, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET..., Dave Airlie
In-Reply-To: <1427213239-8775-1-git-send-email-kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi,
On 24 March 2015 at 16:07, Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> +{
> + return -EINVAL;
> +}
I'm not going to lie, I was really hoping the 5th (?) GPU option for
Qemu would support pageflipping. Daniel's comment about conversion to
atomic is relevant, but: do you have a mechanism which allows you to
post updates (e.g. 'start displaying this buffer now please') that
allows you to get events back when they have actually been displayed?
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers
From: Mark Brown @ 2015-03-24 22:53 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: linux-arm-kernel, Maxime Ripard, Rob Herring, Kumar Gala,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd
In-Reply-To: <1427236208-18667-1-git-send-email-srinivas.kandagatla@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Tue, Mar 24, 2015 at 10:30:08PM +0000, Srinivas Kandagatla wrote:
> +static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr,
> + char *buf, loff_t offset, size_t count)
> +{
> + struct device *dev = container_of(kobj, struct device, kobj);
> + struct eeprom_device *eeprom = to_eeprom(dev);
> + int rc;
> +
> + if (offset > eeprom->size)
> + return -EINVAL;
> +
> + if (offset + count > eeprom->size)
> + count = eeprom->size - offset;
> +
> + rc = regmap_bulk_write(eeprom->regmap, offset,
> + buf, count/eeprom->stride);
Are you sure that this and the read interface should be using the bulk
interface and not the raw interface - do we want the byte swapping that
the bulk interface provides?
I'm also not entirely able to convince myself that the above error
checks and code line up with what I'd expect the userspace ABI to be, we
seem to be treating offset as both a byte offset into the data (which is
what I'd expect the userspace ABI to do) and a word based index into the
data (which is what the regmap API is doing). For example with 16 bit
words offset 2 will start at the 5th byte of data but if userspace seeks
to offset 5 it will get the 11th byte and onwards.
The stride and the word size are separate, they will frequently line up
for memory mapped devices but typically won't for other devices. I
think you need more data mangling to handle this robustly.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/9] regmap: Introduce regmap_get_max_register.
From: Srinivas Kandagatla @ 2015-03-24 23:05 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel, Maxime Ripard, Rob Herring, Kumar Gala,
Greg Kroah-Hartman, linux-api, linux-kernel, devicetree,
linux-arm-msm, arnd, sboyd
In-Reply-To: <20150324223637.GB28997@sirena.org.uk>
On 24/03/15 22:36, Mark Brown wrote:
> On Tue, Mar 24, 2015 at 10:29:39PM +0000, Srinivas Kandagatla wrote:
>
>> This patch introduces regmap_get_max_register() function which would be
>> used by the infrastructures like eeprom framework built on top of
>> regmap.
>
> In what way would it be used?
Its used in 2 purposes
1> It is used for sanity check purposes of the register ranges provided
via DT/non-DT eeprom data cells.
2> To stop user reading when eeprom binary from /sys/class/eeprom/*/eeprom
>
>> +int regmap_get_max_register(struct regmap *map)
>> +{
>> + return map->max_register ? : -EINVAL;
>> +}
>
> Please write the logic out properly, don't abuse the ternery operator.
Am happy to change it to your preference in next version, but this GNU
extensions widely used in the kernel
$ grep -rR "return.*? :" ./linux | wc -l
115
>
^ permalink raw reply
* Re: [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride.
From: Srinivas Kandagatla @ 2015-03-24 23:07 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Rob Herring, Kumar Gala, Greg Kroah-Hartman,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <20150324223745.GC28997-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 24/03/15 22:37, Mark Brown wrote:
> On Tue, Mar 24, 2015 at 10:30:00PM +0000, Srinivas Kandagatla wrote:
>
>> + /* regmap_get_reg_stride(): Report the register address stride
>> + *
>> + * Report the register address stride, mainly intended to for use by
>> + * generic infrastructure built on top of regmap.
>> + */
>> +int regmap_get_reg_stride(struct regmap *map)
>
> Please fix the indentation for the comment block and add kerneldoc for
> the argument. This is an exported function so it should also be /** not
> /*
>
My bad.. I will fix it in next version.
^ permalink raw reply
* Re: [PATCH v3 1/9] regmap: Introduce regmap_get_max_register.
From: Joe Perches @ 2015-03-24 23:23 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Mark Brown, linux-arm-kernel, Maxime Ripard, Rob Herring,
Kumar Gala, Greg Kroah-Hartman, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd
In-Reply-To: <5511EDD7.40202@linaro.org>
On Tue, 2015-03-24 at 23:05 +0000, Srinivas Kandagatla wrote:
> On 24/03/15 22:36, Mark Brown wrote:
> >> +int regmap_get_max_register(struct regmap *map)
> >> +{
> >> + return map->max_register ? : -EINVAL;
> >> +}
> >
> > Please write the logic out properly, don't abuse the ternery operator.
> Am happy to change it to your preference in next version, but this GNU
> extensions widely used in the kernel
>
> $ grep -rR "return.*? :" ./linux | wc -l
> 115
Double that when you add the ?: variants
$ git grep -E "return.*\?\s*:" | wc -l
253
There are ~530 uses like:
return <foo> ? <foo> :
^ permalink raw reply
* Re: [PATCH] Add virtio gpu driver.
From: Dave Airlie @ 2015-03-25 0:00 UTC (permalink / raw)
To: Daniel Stone
Cc: Gerd Hoffmann, virtio-dev-sDuHXQ4OtrM4h7I2RyI4rWD2FQJk+8+b,
Michael S. Tsirkin, open list:ABI/API, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET..., Dave Airlie
In-Reply-To: <CAPj87rN4pXHukDRD-e=ZrO1hcts04cSz1Hr9TNAgicGVWE5_-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 25 March 2015 at 08:50, Daniel Stone <daniel-rLtY4a/8tF1rovVCs/uTlw@public.gmane.org> wrote:
> Hi,
>
> On 24 March 2015 at 16:07, Gerd Hoffmann <kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
>> + struct drm_framebuffer *fb,
>> + struct drm_pending_vblank_event *event,
>> + uint32_t flags)
>> +{
>> + return -EINVAL;
>> +}
>
> I'm not going to lie, I was really hoping the 5th (?) GPU option for
> Qemu would support pageflipping. Daniel's comment about conversion to
> atomic is relevant, but: do you have a mechanism which allows you to
> post updates (e.g. 'start displaying this buffer now please') that
> allows you to get events back when they have actually been displayed?
Page flip is implemented in a later patch,
https://www.kraxel.org/cgit/linux/commit/?h=virtio-gpu&id=1e167e8e964f8e08100d315dd354cc0a4b090841
Since its a long way from an actual display, finding out when
something is actually displayed is hard,
but when we've posted it to the frontbuffer should be fine.
Dave.
^ permalink raw reply
* Re: [PATCH] audit.h: remove the macro AUDIT_ARCH_ARMEB definition
From: Li RongQing @ 2015-03-25 0:01 UTC (permalink / raw)
To: Paul Moore
Cc: Eric Paris, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAHC9VhTbxf_u2FXkcdqofkhywbgrrjjUo_W7yqWXFm=wSJBOAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Mar 25, 2015 at 5:16 AM, Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> wrote:
> [NOTE: Adding the linux-arm folks to this thread just in case they are
> interested.]
>
> I'm not an ARM expert, but the kernel #define for AUDIT_ARCH_ARMEB
> (below) seems reasonable to me based on the other audit machine
> definitions. There is clearly a mismatch between the kernel and the
> audit userspace, but I wonder if the issue should be addressed in the
> userspace tools. Further, you mention kernel 3.14, what happens with
> kernel 3.19 and the most recent audit userspace tools?
>
> > grep "AUDIT_ARCH_ARMEB" include/uapi/linux/audit.h
> #define AUDIT_ARCH_ARMEB (EM_ARM)
1.
if no the below commit, audit-2.3.2 is working;
but after the below commit, audit-2.3.2 is not working.
commit 2f978366984a418f38fcf44137be1fbc5a89cfd9
Author: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Date: Fri May 4 17:53:52 2012 +0100
ARM: 7412/1: audit: use only AUDIT_ARCH_ARM regardless of endianness
The machine endianness has no direct correspondence to the syscall ABI,
so use only AUDIT_ARCH_ARM when identifying the ABI to the audit tools
in userspace.
Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index d8dbe9c..9650c14 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -906,12 +906,6 @@ long arch_ptrace(struct task_struct *child, long request,
return ret;
}
-#ifdef __ARMEB__
-#define AUDIT_ARCH_NR AUDIT_ARCH_ARMEB
-#else
-#define AUDIT_ARCH_NR AUDIT_ARCH_ARM
-#endif
-
asmlinkage int syscall_trace(int why, struct pt_regs *regs, int scno)
{
unsigned long ip;
@@ -919,7 +913,7 @@ asmlinkage int syscall_trace(int why, struct
pt_regs *regs, int scno)
if (why)
audit_syscall_exit(regs);
else
- audit_syscall_entry(AUDIT_ARCH_NR, scno, regs->ARM_r0,
+ audit_syscall_entry(AUDIT_ARCH_ARM, scno, regs->ARM_r0,
regs->ARM_r1, regs->ARM_r2, regs->ARM_r3);
if (!test_thread_flag(TIF_SYSCALL_TRACE))
2.
The latest audit has the changeset of 931 [Improve ARM and AARCH64 support],
so audit can work again.
-Roy
^ permalink raw reply related
* Re: [PATCH v3 8/9] eeprom: qfprom: Add bindings for qfprom
From: Bjorn Andersson @ 2015-03-25 0:28 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: linux-arm-kernel@lists.infradead.org, Maxime Ripard, Rob Herring,
Kumar Gala, Mark Brown, Greg Kroah-Hartman, linux-api,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-msm, Arnd Bergmann, Stephen Boyd
In-Reply-To: <1427236268-18882-1-git-send-email-srinivas.kandagatla@linaro.org>
On Tue, Mar 24, 2015 at 11:31 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
> is based on simple eeprom framework.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../devicetree/bindings/eeprom/qfprom.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt
>
> diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt b/Documentation/devicetree/bindings/eeprom/qfprom.txt
> new file mode 100644
> index 0000000..d5baed6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
> @@ -0,0 +1,23 @@
> += Qualcomm QFPROM device tree bindings =
> +
> +This binding is intended to represent QFPROM which is found in most QCOM SOCs.
> +
> +Required properties:
> +- compatible: should be "qcom,qfprom"
> +- reg: Should contain registers location and length
> +
> += Data cells =
> +Are child nodes of qfprom, bindings of which as described in
> +bindings/eeprom/eeprom.txt
> +
> +Example:
> +
> + qfprom: qfprom@00700000 {
> + compatible = "qcom,qfprom";
> + reg = <0x00700000 0x1000>;
The qfprom block starts at 0x700000 and is 0x8000 long.
The registers at the beginning of this block are raw R/W fuse bits and
should not be read directly. Instead there is an ecc corrected shadow
copy of these registers at 0x4000.
> + ...
> + /* Data cells */
> + tsens_calibration: calib@404 {
> + reg = <0x404 0x10>;
> + };
> + };
Regards,
Bjorn
^ permalink raw reply
* Re: bpf+tracing next steps. Was: [PATCH v9 tip 3/9] tracing: attach BPF programs to kprobes
From: Alexei Starovoitov @ 2015-03-25 0:40 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Daniel Borkmann, Peter Zijlstra, linux-api, netdev, linux-kernel
In-Reply-To: <550FDC8A.5010100@hitachi.com>
On 3/23/15 2:27 AM, Masami Hiramatsu wrote:
> (2015/03/23 13:57), Alexei Starovoitov wrote:
>> On 3/22/15 7:17 PM, Masami Hiramatsu wrote:
>>> (2015/03/23 3:03), Alexei Starovoitov wrote:
>>>
>>>> User space tools that will compile ktap/dtrace scripts into bpf might
>>>> use build-id for their own purpose, but that's a different discussion.
>>>
>>> Agreed.
>>> I'd like to discuss it since kprobe event interface may also have same
>>> issue.
>>
>> I'm not sure what 'issue' you're seeing. My understanding is that
>> build-ids are used by perf to associate binaries with their debug info
>> and by systemtap to make sure that probes actually match the kernel
>> they were compiled for. In bpf case it probably will be perf way only.
>
> Ah, I see. So perftools can check the build-id if needed, right?
yes. of course.
>> Are you interested in doing something with bpf ? ;)
>
> Of course :)
Great :)
>> I know that Jovi is working on clang-based front-end, He Kuang is doing
>> something fancy and I'm going to focus on 'tcp instrumentation' once
>> bpf+kprobes is in. I think these efforts will help us make it
>> concrete and will establish a path towards bpf+tracepoints
>> (debug tracepoints or trace markers) and eventual integration with perf.
>> Here is the wish-list (for kernel and userspace) inspired by Brendan:
>> - access to pid, uid, tid, comm, etc
>> - access to kernel stack trace
>> - access to user-level stack trace
>> - kernel debuginfo for walking kernel structs, and accessing kprobe
>> entry args as variables
>
> perf probe can provide this to bpf.
I was thinking about deeper integration with perf actually.
perf has all the right infra to find debug info in kernel and user
binaries, to extract and understand all the dwarf stuff.
The future tracing language can use more of it.
The programs should be able refer to names of in-kernel variables
and arguments natively.
When I'm writing a program that attaches to blk_update_request()
I would like to write:
bpf_printk("req %p bytes %d\n", req->q, nr_bytes);
and perf with debug info should be able to figure out that 'req'
is the first function argument, then find out offset of '->q'
within the struct and that 'nr_bytes' is the 3rd argument in
appropriate register. Then generate llvm ir on the fly,
compile it, load into kernel and attach to kprobe event at
this blk_update_request() function. All seamlessly.
>> - tracing of uprobes
>> - tracing of user markers
>
> I'm working on the perf-cache which will also support SDT (based on Hemant Kumar's work).
yep. waiting for SDT stuff to finalize. Would be nice to
have 'follow' button for interesting patches :)
^ permalink raw reply
* Re: [PATCH v4] Add virtio-input driver.
From: Rusty Russell @ 2015-03-25 3:21 UTC (permalink / raw)
To: virtio-dev, virtualization
Cc: mst, David Herrmann, Dmitry Torokhov, Gerd Hoffmann, open list,
open list:ABI/API, Vojtech Pavlik
In-Reply-To: <1427198927-1745-1-git-send-email-kraxel@redhat.com>
Gerd Hoffmann <kraxel@redhat.com> writes:
> virtio-input is basically evdev-events-over-virtio, so this driver isn't
> much more than reading configuration from config space and forwarding
> incoming events to the linux input layer.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Is the input layer sane? I've never dealt with it, so I don't know.
What's it used for?
Imagine a future virtio standard which incorporates this. And a Windows
or FreeBSD implementation of the device and or driver. How ugly would
they be?
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 1/5] of: unittest: overlay: Keep track of created overlays
From: Rob Herring @ 2015-03-25 4:53 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Grant Likely, Andrew Morton, Matt Porter, Koen Kooi,
Guenter Roeck, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pantelis Antoniou
In-Reply-To: <1426624257-23003-2-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou
<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> During the course of the overlay selftests some of them remain
> applied. While this does not pose a real problem, make sure you track
> them and destroy them at the end of the test.
This is going to need to be rebased on my tree as there has been some
selftest->unitest renaming.
Rob
>
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
> drivers/of/unittest.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 4e60682..c711534 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -23,6 +23,8 @@
> #include <linux/i2c.h>
> #include <linux/i2c-mux.h>
>
> +#include <linux/bitops.h>
> +
> #include "of_private.h"
>
> static struct selftest_results {
> @@ -1115,6 +1117,59 @@ static const char *overlay_path(int nr)
>
> static const char *bus_path = "/testcase-data/overlay-node/test-bus";
>
> +/* it is guaranteed that overlay ids are assigned in sequence */
> +#define MAX_SELFTEST_OVERLAYS 256
> +static unsigned long overlay_id_bits[BITS_TO_LONGS(MAX_SELFTEST_OVERLAYS)];
> +static int overlay_first_id = -1;
> +
> +static void of_selftest_track_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + overlay_first_id = id;
> + id -= overlay_first_id;
> +
> + /* we shouldn't need that many */
> + BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] |= BIT_MASK(id);
> +}
> +
> +static void of_selftest_untrack_overlay(int id)
> +{
> + if (overlay_first_id < 0)
> + return;
> + id -= overlay_first_id;
> + BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> +}
> +
> +static void of_selftest_destroy_tracked_overlays(void)
> +{
> + int id, ret, defers;
> +
> + if (overlay_first_id < 0)
> + return;
> +
> + /* try until no defers */
> + do {
> + defers = 0;
> + /* remove in reverse order */
> + for (id = MAX_SELFTEST_OVERLAYS - 1; id >= 0; id--) {
> + if (!(overlay_id_bits[BIT_WORD(id)] & BIT_MASK(id)))
> + continue;
> +
> + ret = of_overlay_destroy(id + overlay_first_id);
> + if (ret != 0) {
> + defers++;
> + pr_warn("%s: overlay destroy failed for #%d\n",
> + __func__, id + overlay_first_id);
> + continue;
> + }
> +
> + overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
> + }
> + } while (defers > 0);
> +}
> +
> static int of_selftest_apply_overlay(int selftest_nr, int overlay_nr,
> int *overlay_id)
> {
> @@ -1136,6 +1191,7 @@ static int of_selftest_apply_overlay(int selftest_nr, int overlay_nr,
> goto out;
> }
> id = ret;
> + of_selftest_track_overlay(id);
>
> ret = 0;
>
> @@ -1349,6 +1405,7 @@ static void of_selftest_overlay_6(void)
> return;
> }
> ov_id[i] = ret;
> + of_selftest_track_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1373,6 +1430,7 @@ static void of_selftest_overlay_6(void)
> PDEV_OVERLAY));
> return;
> }
> + of_selftest_untrack_overlay(ov_id[i]);
> }
>
> for (i = 0; i < 2; i++) {
> @@ -1417,6 +1475,7 @@ static void of_selftest_overlay_8(void)
> return;
> }
> ov_id[i] = ret;
> + of_selftest_track_overlay(ov_id[i]);
> }
>
> /* now try to remove first overlay (it should fail) */
> @@ -1439,6 +1498,7 @@ static void of_selftest_overlay_8(void)
> PDEV_OVERLAY));
> return;
> }
> + of_selftest_untrack_overlay(ov_id[i]);
> }
>
> selftest(1, "overlay test %d passed\n", 8);
> @@ -1861,6 +1921,8 @@ static void __init of_selftest_overlay(void)
> of_selftest_overlay_i2c_cleanup();
> #endif
>
> + of_selftest_destroy_tracked_overlays();
> +
> out:
> of_node_put(bus_np);
> }
> --
> 1.7.12
>
^ permalink raw reply
* Re: [PATCH] mremap: add MREMAP_NOHOLE flag --resend
From: Shaohua Li @ 2015-03-25 5:02 UTC (permalink / raw)
To: Daniel Micay
Cc: Aliaksey Kandratsenka, Andrew Morton, linux-mm, linux-api,
Rik van Riel, Hugh Dickins, Mel Gorman, Johannes Weiner,
Michal Hocko, Andy Lutomirski, google-perftools@googlegroups.com
In-Reply-To: <55117724.6030102@gmail.com>
On Tue, Mar 24, 2015 at 10:39:32AM -0400, Daniel Micay wrote:
> On 24/03/15 01:25 AM, Aliaksey Kandratsenka wrote:
> >
> > Well, I don't have any workloads. I'm just maintaining a library that
> > others run various workloads on. Part of the problem is lack of good
> > and varied malloc benchmarks which could allow us that prevent
> > regression. So this makes me a bit more cautious on performance
> > matters.
> >
> > But I see your point. Indeed I have no evidence at all that exclusive
> > locking might cause observable performance difference.
>
> I'm sure it matters but I expect you'd need *many* cores running many
> threads before it started to outweigh the benefit of copying pages
> instead of data.
>
> Thinking about it a bit more, it would probably make sense for mremap to
> start with the optimistic assumption that the reader lock is enough here
> when using MREMAP_NOHOLE|MREMAP_FIXED. It only needs the writer lock if
> the destination mapping is incomplete or doesn't match, which is an edge
> case as holes would mean thread unsafety.
>
> An ideal allocator will toggle on PROT_NONE when overcommit is disabled
> so this assumption would be wrong. The heuristic could just be adjusted
> to assume the dest VMA will match with MREMAP_NOHOLE|MREMAP_FIXED when
> full memory accounting isn't enabled. The fallback would never ended up
> being needed in existing use cases that I'm aware of, and would just add
> the overhead of a quick lock, O(log n) check and unlock with the reader
> lock held anyway. Another flag isn't really necessary.
>
> >>> Another notable thing is how mlock effectively disables MADV_DONTNEED for
> >>> jemalloc{1,2} and tcmalloc, lowers page faults count and thus improves
> >>> runtime. It can be seen that tcmalloc+mlock on thp-less configuration is
> >>> slightly better on runtime to glibc. The later spends a ton of time in
> >>> kernel,
> >>> probably handling minor page faults, and the former burns cpu in user space
> >>> doing memcpy-s. So "tons of memcpys" seems to be competitive to what glibc
> >>> is
> >>> doing in this benchmark.
> >>
> >> mlock disables MADV_DONTNEED, so this is an unfair comparsion. With it,
> >> allocator will use more memory than expected.
> >
> > Do not agree with unfair. I'm actually hoping MADV_FREE to provide
> > most if not all of benefits of mlock in this benchmark. I believe it's
> > not too unreasonable expectation.
>
> MADV_FREE will still result in as many page faults, just no zeroing.
>
> I get ~20k requests/s with jemalloc on the ebizzy benchmark with this
> dual core ivy bridge laptop. It jumps to ~60k requests/s with MADV_FREE
> IIRC, but disabling purging via MALLOC_CONF=lg_dirty_mult:-1 leads to
> 3.5 *million* requests/s. It has a similar impact with TCMalloc.
MADV_FREE has side effect (exactly like if you use mlock), which causes
more memory are used. It's lazy memory free, so if there is no memory
pressure, you can think MADV_FREE is a nop. It's undoubt you will see
improvement in such case. But if there is memory pressure, it is
completely different story.
> >> I'm kind of confused why we talk about THP, mlock here. When application
> >> uses allocator, it doesn't need to be forced to use THP or mlock. Can we
> >> forcus on normal case?
> >
> > See my note on mlock above.
> >
> > THP it is actually "normal". I know for certain, that many production
> > workloads are run on boxes with THP enabled. Red Hat famously ships
> > it's distros with THP set to "always". And I also know that some other
> > many production workloads are run on boxes with THP disabled. Also, as
> > seen above, "teleporting" pages is more efficient with THP due to much
> > smaller overhead of moving those pages. So I felt it was important not
> > to omit THP in my runs.
>
> Yeah, it's quite normal for it to be enabled. Allocators might as well
> give up on fine-grained purging when it is though :P. I think it only
> really makes sense to purge at 2M boundaries in multiples of 2M if it's
> going to end up breaking any other purging over the long-term.
>
> I was originally only testing with THP since Arch uses "always" but I
> realized it had an enormous impact and started testing without it too.
Hmm, I didn't intend to ignore THP, but just can't understand why it's
matter. There is extra overhead when purge or mremap THP pages (if range
isn't 2M aligned in multiple of 2M), but other than that, there is no
other difference to me, but your test result doesn't suggest this. Guess
we should understand why THP makes so big difference.
Thanks,
Shaohua
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 3/5] of: overlay: Master enable switch
From: Rob Herring @ 2015-03-25 5:25 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Grant Likely, Andrew Morton, Matt Porter, Koen Kooi,
Guenter Roeck, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pantelis Antoniou
In-Reply-To: <1426624257-23003-4-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou
<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> Implement a throw once master enable switch to protect against any
> further overlay applications if the administrator desires so.
sysfs documentation?
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> ---
> drivers/of/overlay.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index f17f5ef..6688797 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -21,6 +21,7 @@
> #include <linux/err.h>
> #include <linux/idr.h>
> #include <linux/sysfs.h>
> +#include <linux/atomic.h>
>
> #include "of_private.h"
>
> @@ -55,6 +56,9 @@ struct of_overlay {
> struct kobject kobj;
> };
>
> +/* master enable switch; once set to 0 can't be re-enabled */
> +static atomic_t ov_enable = ATOMIC_INIT(1);
> +
> static int of_overlay_apply_one(struct of_overlay *ov,
> struct device_node *target, const struct device_node *overlay);
>
> @@ -345,6 +349,60 @@ static struct kobj_type of_overlay_ktype = {
>
> static struct kset *ov_kset;
>
> +static ssize_t enable_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t offset, size_t count)
> +{
> + char tbuf[3];
> +
> + if (offset < 0)
> + return -EINVAL;
> +
> + if (offset >= sizeof(tbuf))
> + return 0;
> +
> + if (count > sizeof(tbuf) - offset)
> + count = sizeof(tbuf) - offset;
> +
> + /* fill in temp */
> + tbuf[0] = '0' + atomic_read(&ov_enable);
> + tbuf[1] = '\n';
> + tbuf[2] = '\0';
> +
> + /* copy to buffer */
> + memcpy(buf, tbuf + offset, count);
> +
> + return count;
> +}
> +
> +static ssize_t enable_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t off, size_t count)
> +{
> + int new_enable;
> +
> + if (off != 0 || (buf[0] != '0' && buf[1] != '1'))
Is buf[1] correct here?
> + return -EINVAL;
> +
> + new_enable = buf[0] - '0';
> + if (new_enable != 0 && new_enable != 1)
Make unsigned just "if (new_enable > 1)".
> + return -EINVAL;
> +
> + /* NOP for same value */
> + if (new_enable == atomic_read(&ov_enable))
> + return count;
> +
> + /* if we've disabled it, no going back */
> + if (atomic_read(&ov_enable) == 0)
> + return -EPERM;
> +
> + atomic_set(&ov_enable, new_enable);
> + return count;
> +}
> +
> +/* just a single char + '\n' + '\0' */
> +static BIN_ATTR_RW(enable, 3);
> +
> /**
> * of_overlay_create() - Create and apply an overlay
> * @tree: Device node containing all the overlays
> @@ -360,6 +418,10 @@ int of_overlay_create(struct device_node *tree)
> struct of_overlay *ov;
> int err, id;
>
> + /* administratively disabled */
> + if (!atomic_read(&ov_enable))
> + return -EPERM;
> +
> /* allocate the overlay structure */
> ov = kzalloc(sizeof(*ov), GFP_KERNEL);
> if (ov == NULL)
> @@ -596,5 +658,7 @@ int of_overlay_init(void)
> if (!ov_kset)
> return -ENOMEM;
>
> - return 0;
> + rc = sysfs_create_bin_file(&ov_kset->kobj, &bin_attr_enable);
> + WARN(rc, "%s: error adding enable attribute\n", __func__);
> + return rc;
> }
> --
> 1.7.12
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/5] MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
From: Rob Herring @ 2015-03-25 5:31 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Grant Likely, Andrew Morton, Koen Kooi, Guenter Roeck,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pantelis Antoniou, Matt Porter
In-Reply-To: <1426624257-23003-6-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
On Tue, Mar 17, 2015 at 3:30 PM, Pantelis Antoniou
<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> Add me as the device tree overlays maintainer.
>
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
Applied. Thanks.
Rob
> ---
> MAINTAINERS | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0e1abe8..24aa339 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7187,6 +7187,15 @@ F: Documentation/devicetree/
> F: arch/*/boot/dts/
> F: include/dt-bindings/
>
> +OPEN FIRMWARE AND DEVICE TREE OVERLAYS
> +M: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> +L: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +S: Maintained
> +F: Documentation/devicetree/dynamic-resolution-notes.txt
> +F: Documentation/devicetree/overlay-notes.txt
> +F: drivers/of/overlay.c
> +F: drivers/of/resolver.c
> +
> OPENRISC ARCHITECTURE
> M: Jonas Bonn <jonas-A9uVI2HLR7kOP4wsBPIw7w@public.gmane.org>
> W: http://openrisc.net
> --
> 1.7.12
>
^ permalink raw reply
* Re: [PATCH v3] Add virtio-input driver.
From: Michael S. Tsirkin @ 2015-03-25 5:36 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Gerd Hoffmann, virtio-dev, virtualization, David Herrmann,
Rusty Russell, open list, open list:ABI/API
In-Reply-To: <20150324172805.GA16445@dtor-ws>
On Tue, Mar 24, 2015 at 10:28:05AM -0700, Dmitry Torokhov wrote:
> > > > > + err = input_register_device(vi->idev);
> > > > > + if (err)
> > > > > + goto err_input_register;
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > +err_input_register:
> > > >
> > > > > + input_free_device(vi->idev);
> > > >
> > > > At this point you can already get interrupts
> > > > since you called virtio_device_ready, and
> > > > getting events from a freed device likely won't
> > > > DTRT.
> > >
> > > Right. I guess you want to mark the virtio device ready only after
> > > registering input device.
> >
> > No that's broken since you can get events after this
> > point, and you won't be able to forward them.
>
> Who cares?
virtio cares: guest will crash if you attempt to
kick virtqueue before device ready call.
> What makes these events needed compared to ones sent 1 ms
> earlier before we had input device registered?
>
> But I guess if you can call virtio_device_ready/virtio_device_broken
> several times then the best option is putting them into input_dev->open
> and input_dev->close callbacks.
>
> Thanks.
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH v4] Add virtio-input driver.
From: Vojtech Pavlik @ 2015-03-25 5:36 UTC (permalink / raw)
To: Rusty Russell
Cc: Gerd Hoffmann, virtio-dev, virtualization, mst, David Herrmann,
Dmitry Torokhov, open list, open list:ABI/API
In-Reply-To: <877fu5iwxk.fsf@rustcorp.com.au>
On Wed, Mar 25, 2015 at 01:51:43PM +1030, Rusty Russell wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
> > virtio-input is basically evdev-events-over-virtio, so this driver isn't
> > much more than reading configuration from config space and forwarding
> > incoming events to the linux input layer.
> >
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>
> Is the input layer sane? I've never dealt with it, so I don't know.
I'm rather biased having designed it, but I'd say it's reasonable. It
certainly has limitations and design mistakes, but none are too bad.
One testimony to that Android has based its own Input API around it.
> What's it used for?
For all human input devices, like keyboards, mice, touchscreens, etc.
> Imagine a future virtio standard which incorporates this. And a Windows
> or FreeBSD implementation of the device and or driver. How ugly would
> they be?
A windows translation layer is fairly easy, people porting software from
Windows to Linux told me numerous times that adapting isn't hard. I also
believe that at least one of the BSD's has a compatible implementation
these days based on the fact that I was asked to allow copying the
headers in the past.
--
Vojtech Pavlik
Director SUSE Labs
^ permalink raw reply
* Re: [PATCH] Add virtio gpu driver.
From: Daniel Stone @ 2015-03-25 5:47 UTC (permalink / raw)
To: Dave Airlie
Cc: virtio-dev@lists.oasis-open.org, Michael S. Tsirkin,
open list:ABI/API, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET..., Dave Airlie
In-Reply-To: <CAPM=9tyM9AxX-RHhbO-LK+LTyQC6YjwW67pZM1XjbL35+counA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1075 bytes --]
Hi,
On Wednesday, March 25, 2015, Dave Airlie <airlied@gmail.com> wrote:
> On 25 March 2015 at 08:50, Daniel Stone <daniel@fooishbar.org
> <javascript:;>> wrote:
> > I'm not going to lie, I was really hoping the 5th (?) GPU option for
> > Qemu would support pageflipping. Daniel's comment about conversion to
> > atomic is relevant, but: do you have a mechanism which allows you to
> > post updates (e.g. 'start displaying this buffer now please') that
> > allows you to get events back when they have actually been displayed?
>
> Page flip is implemented in a later patch,
>
>
> https://www.kraxel.org/cgit/linux/commit/?h=virtio-gpu&id=1e167e8e964f8e08100d315dd354cc0a4b090841
>
> Since its a long way from an actual display, finding out when
> something is actually displayed is hard,
> but when we've posted it to the frontbuffer should be fine.
>
Oh nice. 100% exact timings aren't critical; it's more just having
something to gate to 60fps that we can actually drive Weston's repaint loop
off, as that's (not unreasonably) driven by pageflip events.
Cheers,
Daniel
[-- Attachment #1.2: Type: text/html, Size: 1630 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v10 1/12] fs: Add support FALLOC_FL_INSERT_RANGE for fallocate
From: Dave Chinner @ 2015-03-25 6:05 UTC (permalink / raw)
To: Namjae Jeon
Cc: tytso-3s7WtUTddSA, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ext4-u79uwXL29TY76Z2rM5mHXA, xfs-VZNHf3L845pBDgjK7y7TUQ,
a.sangwan-Sze3O3UU22JBDgjK7y7TUQ, bfoster-H+wXaHxf7aLQT0dZR+AlfA,
mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Namjae Jeon
In-Reply-To: <1424533554-28024-2-git-send-email-linkinjeon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sun, Feb 22, 2015 at 12:45:43AM +0900, Namjae Jeon wrote:
> From: Namjae Jeon <namjae.jeon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> FALLOC_FL_INSERT_RANGE command is the opposite command of
> FALLOC_FL_COLLAPSE_RANGE that is needed for advertisers or someone who want to
> add some data in the middle of file. FALLOC_FL_INSERT_RANGE will create space
> for writing new data within a file after shifting extents to right as given
> length. and this command also has same limitation as FALLOC_FL_COLLAPSE_RANGE,
> that is block boundary and use ftruncate(2) for crosses EOF.
>
> Signed-off-by: Namjae Jeon <namjae.jeon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Ashish Sangwan <a.sangwan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Folks, I have merged this into the xfs tree for the 4.1 merge
window. It is under the stable branch "fallocate-insert-range"
in the tree here:
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
an dis currently included in the for-next branch that is included in
the linux-next tree. I have not included the ext4 kernel support
patch in this branch (patch 3) because I have not seen any reviews
from ext4 developers for it.
Ted, if you want to include that patch in you ext4 tree, feel free
to base it on the above branch, or if you give your sob or
reviewed-by ok I can pull it into my tree. I'll leave it up to you
to determine how you want to deal with this.
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
^ permalink raw reply
* Re: [PATCH v3 5/9] eeprom: Add bindings for simple eeprom framework
From: Sascha Hauer @ 2015-03-25 7:10 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: linux-arm-msm, devicetree, arnd, Greg Kroah-Hartman, Mark Brown,
sboyd, linux-kernel, Rob Herring, Kumar Gala, Maxime Ripard,
linux-api, linux-arm-kernel
In-Reply-To: <1427236230-18751-1-git-send-email-srinivas.kandagatla@linaro.org>
On Tue, Mar 24, 2015 at 10:30:30PM +0000, Srinivas Kandagatla wrote:
> This patch adds bindings for simple eeprom framework which allows eeprom
> consumers to talk to eeprom providers to get access to eeprom cell data.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> [Maxime Ripard: intial version of eeprom framework]
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../devicetree/bindings/eeprom/eeprom.txt | 70 ++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> new file mode 100644
> index 0000000..8348d18
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -0,0 +1,70 @@
> += EEPROM Data Device Tree Bindings =
> +
> +This binding is intended to represent the location of hardware
> +configuration data stored in EEPROMs.
> +
> +On a significant proportion of boards, the manufacturer has stored
> +some data on an EEPROM-like device, for the OS to be able to retrieve
> +these information and act upon it. Obviously, the OS has to know
> +about where to retrieve these data from, and where they are stored on
> +the storage device.
> +
> +This document is here to document this.
> +
> += Data providers =
> +Contains bindings specific to provider drivers and data cells as children
> +to this node.
> +
> += Data cells =
> +These are the child nodes of the provider which contain data cell
> +information like offset and size in eeprom provider.
> +
> +Required properties:
> +reg: specifies the offset in byte within that storage device, and the length
> + in bytes of the data we care about.
> + There could be more then one offset-length pairs in this property.
> +
> +Optional properties:
> +As required by specific data parsers/interpreters.
> +
> +For example:
> +
> + /* Provider */
> + qfprom: qfprom@00700000 {
> + compatible = "qcom,qfprom";
> + reg = <0x00700000 0x1000>;
> + ...
> +
> + /* Data cells */
> + tsens_calibration: calib@404 {
> + reg = <0x404 0x10>;
> + };
> +
> + serial_number: sn {
> + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
> +
> + };
> + ...
> + };
> +
> += Data consumers =
> +Are device nodes which consume eeprom data cells.
> +
> +Required properties:
> +
> +eeproms: List of phandle and data cell the device might be interested in.
> +
> +Optional properties:
> +
> +eeprom-names: List of data cell name strings sorted in the same order
> + as the eeproms property. Consumers drivers will use
> + eeprom-names to differentiate between multiple cells,
> + and hence being able to know what these cells are for.
> +
> +For example:
> +
> + tsens {
> + ...
> + eeproms = <&tsens_calibration>;
> + eeprom-names = "calibration";
> + };
This is somewhat complicated. Also having 'eeprom' in the binding is not
nice since it could be FRAM or something else. How about:
tsens {
calibration = <&tsens_calibration>;
};
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v3 4/9] eeprom: Add a simple EEPROM framework for eeprom consumers
From: Sascha Hauer @ 2015-03-25 7:16 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Rob Herring, Kumar Gala, Mark Brown, Greg Kroah-Hartman,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1427236219-18709-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Mar 24, 2015 at 10:30:19PM +0000, Srinivas Kandagatla wrote:
> This patch adds just consumers part of the framework just to enable easy
> review.
>
> Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
> duplicate pretty much the same code to register a sysfs file, allow in-kernel
> users to access the content of the devices they were driving, etc.
>
> This was also a problem as far as other in-kernel users were involved, since
> the solutions used were pretty much different from on driver to another, there
> was a rather big abstraction leak.
>
> This introduction of this framework aims at solving this. It also introduces DT
> representation for consumer devices to go get the data they require (MAC
> Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
>
> Having regmap interface to this framework would give much better
> abstraction for eeproms on different buses.
Thanks for working on this. This is something that is missing in the
kernel, it looks very promising to me.
Some comments inline
> +static struct eeprom_cell *__eeprom_cell_get(struct device_node *cell_np,
> + const char *ename,
> + struct eeprom_block *blocks,
> + int nblocks)
> +{
> + struct eeprom_cell *cell;
> + struct eeprom_device *eeprom = NULL;
No need to initialize.
> + struct property *prop;
> + const __be32 *vp;
> + u32 pv;
> + int i, rval;
> +
> + mutex_lock(&eeprom_mutex);
> +
> + eeprom = cell_np ? of_eeprom_find(cell_np->parent) : eeprom_find(ename);
> + if (!eeprom) {
> + mutex_unlock(&eeprom_mutex);
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
> +/**
> + * of_eeprom_cell_get(): Get eeprom cell of device form a given index
> + *
> + * @dev: Device that will be interacted with
> + * @index: eeprom index in eeproms property.
> + *
> + * The return value will be an ERR_PTR() on error or a valid pointer
> + * to a struct eeprom_cell. The eeprom_cell will be freed by the
> + * eeprom_cell_put().
> + */
> +struct eeprom_cell *of_eeprom_cell_get(struct device *dev, int index)
> +{
I think the consumer API could be improved. The dev pointer is only used
to get the struct device_node out of it, so the device_node could be
passed in directly. As written in my other mail I think the binding
would be better like "calibration = <&tsens_calibration>;", so this
function could be:
of_eeprom_cell_get(struct device_node *np, const char *name)
With this we could also get eeprom cells from subnodes which do not have
a struct device bound to them.
> + struct device_node *cell_np;
> +
> + if (!dev || !dev->of_node)
> + return ERR_PTR(-EINVAL);
> +
> + cell_np = of_parse_phandle(dev->of_node, "eeproms", index);
> + if (!cell_np)
> + return ERR_PTR(-EPROBE_DEFER);
-EPROBE_DEFER is not appropriate here. If of_parse_phandle fails it
won't work next time.
> +
> + return __eeprom_cell_get(cell_np, NULL, NULL, 0);
> +}
> +EXPORT_SYMBOL_GPL(of_eeprom_cell_get);
> +
> +/**
> + * eeprom_cell_write(): Write to a given eeprom cell
> + *
> + * @cell: eeprom cell to be written.
> + * @buf: Buffer to be written.
> + * @len: length of buffer to be written to eeprom cell.
> + *
> + * The return value will be an non zero on error or a zero on successful write.
No, it returns the length.
> + */
> +int eeprom_cell_write(struct eeprom_cell *cell, const char *buf, ssize_t len)
> +{
> + struct eeprom_device *eeprom = cell->eeprom;
> + int i, rc, offset = 0;
> +
> + if (!eeprom || !eeprom->regmap || len != cell->size)
> + return -EINVAL;
> +
> + for (i = 0; i < cell->nblocks; i++) {
> + rc = regmap_bulk_write(eeprom->regmap, cell->blocks[i].offset,
> + buf + offset,
> + cell->blocks[i].count);
> +
> + if (IS_ERR_VALUE(rc))
> + return rc;
> +
> + offset += cell->blocks[i].count;
> + }
> +
> + return len;
> +}
> +EXPORT_SYMBOL_GPL(eeprom_cell_write);
> +
> +static inline char *eeprom_cell_read(struct eeprom_cell *cell, ssize_t *len)
> +{
> + return NULL;
> +}
The documentation above the real function states that this function
either returns an ERR_PTR() or a valid pointer. The wrapper should then
do the same.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/2] vt: add cursor blink interval escape sequence
From: Greg Kroah-Hartman @ 2015-03-25 11:19 UTC (permalink / raw)
To: Scot Doyle
Cc: Jiri Slaby, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Michael Kerrisk, Pavel Machek, Geert Uytterhoeven, linux-kernel,
linux-fbdev, linux-api, linux-man
In-Reply-To: <alpine.LNX.2.11.1502271911380.4248@localhost>
On Fri, Feb 27, 2015 at 07:13:48PM +0000, Scot Doyle wrote:
> Add an escape sequence to specify the current console's cursor blink
> interval. The interval is specified as a number of milliseconds until
> the next cursor display state toggle, from 50 to 65535. /proc/loadavg
> did not show a difference with a one msec interval, but the lower
> bound is set to 50 msecs since slower hardware wasn't tested.
>
> Store the interval in the vc_data structure for later access by fbcon,
> initializing the value to fbcon's current hardcoded value of 200 msecs.
>
> Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> ---
> drivers/tty/vt/vt.c | 9 +++++++++
> include/linux/console_struct.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 6e00572..ab1f173 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -135,6 +135,7 @@ const struct consw *conswitchp;
> */
> #define DEFAULT_BELL_PITCH 750
> #define DEFAULT_BELL_DURATION (HZ/8)
> +#define DEFAULT_CURSOR_BLINK_MS 200
>
> struct vc vc_cons [MAX_NR_CONSOLES];
>
> @@ -1590,6 +1591,13 @@ static void setterm_command(struct vc_data *vc)
> case 15: /* activate the previous console */
> set_console(last_console);
> break;
> + case 16: /* set cursor blink duration in msec */
Where is this now documented? Is this a "standard" ASCII command
somewhere? Adding new userspace apis have to be documented properly.
Without that, I can't take this series, sorry.
greg k-h
^ permalink raw reply
* Re: bpf+tracing next steps. Was: [PATCH v9 tip 3/9] tracing: attach BPF programs to kprobes
From: Masami Hiramatsu @ 2015-03-25 12:07 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Daniel Borkmann, Peter Zijlstra, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5512040B.3020605-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
(2015/03/25 9:40), Alexei Starovoitov wrote:
> On 3/23/15 2:27 AM, Masami Hiramatsu wrote:
>> (2015/03/23 13:57), Alexei Starovoitov wrote:
>>> On 3/22/15 7:17 PM, Masami Hiramatsu wrote:
>>>> (2015/03/23 3:03), Alexei Starovoitov wrote:
>>>>
>>>>> User space tools that will compile ktap/dtrace scripts into bpf might
>>>>> use build-id for their own purpose, but that's a different discussion.
>>>>
>>>> Agreed.
>>>> I'd like to discuss it since kprobe event interface may also have same
>>>> issue.
>>>
>>> I'm not sure what 'issue' you're seeing. My understanding is that
>>> build-ids are used by perf to associate binaries with their debug info
>>> and by systemtap to make sure that probes actually match the kernel
>>> they were compiled for. In bpf case it probably will be perf way only.
>>
>> Ah, I see. So perftools can check the build-id if needed, right?
>
> yes. of course.
>
>>> Are you interested in doing something with bpf ? ;)
>>
>> Of course :)
>
> Great :)
>
>>> I know that Jovi is working on clang-based front-end, He Kuang is doing
>>> something fancy and I'm going to focus on 'tcp instrumentation' once
>>> bpf+kprobes is in. I think these efforts will help us make it
>>> concrete and will establish a path towards bpf+tracepoints
>>> (debug tracepoints or trace markers) and eventual integration with perf.
>>> Here is the wish-list (for kernel and userspace) inspired by Brendan:
>>> - access to pid, uid, tid, comm, etc
>>> - access to kernel stack trace
>>> - access to user-level stack trace
>>> - kernel debuginfo for walking kernel structs, and accessing kprobe
>>> entry args as variables
>>
>> perf probe can provide this to bpf.
>
> I was thinking about deeper integration with perf actually.
> perf has all the right infra to find debug info in kernel and user
> binaries, to extract and understand all the dwarf stuff.
> The future tracing language can use more of it.
> The programs should be able refer to names of in-kernel variables
> and arguments natively.
> When I'm writing a program that attaches to blk_update_request()
> I would like to write:
> bpf_printk("req %p bytes %d\n", req->q, nr_bytes);
> and perf with debug info should be able to figure out that 'req'
> is the first function argument, then find out offset of '->q'
> within the struct and that 'nr_bytes' is the 3rd argument in
> appropriate register. Then generate llvm ir on the fly,
> compile it, load into kernel and attach to kprobe event at
> this blk_update_request() function. All seamlessly.
Yes, that is what perf probe providing now. I think it is easy
to do that with probe-finder.c. :)
>>> - tracing of uprobes
>>> - tracing of user markers
>>
>> I'm working on the perf-cache which will also support SDT (based on Hemant Kumar's work).
>
> yep. waiting for SDT stuff to finalize. Would be nice to
> have 'follow' button for interesting patches :)
:)
Thank you!
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH v3 4/9] eeprom: Add a simple EEPROM framework for eeprom consumers
From: Srinivas Kandagatla @ 2015-03-25 12:29 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-arm-kernel, Maxime Ripard, Rob Herring, Kumar Gala,
Mark Brown, Greg Kroah-Hartman, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd
In-Reply-To: <20150325071630.GW9742@pengutronix.de>
On 25/03/15 07:16, Sascha Hauer wrote:
> On Tue, Mar 24, 2015 at 10:30:19PM +0000, Srinivas Kandagatla wrote:
>> This patch adds just consumers part of the framework just to enable easy
>> review.
>>
>> Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
>> duplicate pretty much the same code to register a sysfs file, allow in-kernel
>> users to access the content of the devices they were driving, etc.
>>
>> This was also a problem as far as other in-kernel users were involved, since
>> the solutions used were pretty much different from on driver to another, there
>> was a rather big abstraction leak.
>>
>> This introduction of this framework aims at solving this. It also introduces DT
>> representation for consumer devices to go get the data they require (MAC
>> Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.
>>
>> Having regmap interface to this framework would give much better
>> abstraction for eeproms on different buses.
>
> Thanks for working on this. This is something that is missing in the
> kernel, it looks very promising to me.
>
> Some comments inline
>
>> +static struct eeprom_cell *__eeprom_cell_get(struct device_node *cell_np,
>> + const char *ename,
>> + struct eeprom_block *blocks,
>> + int nblocks)
>> +{
>> + struct eeprom_cell *cell;
>> + struct eeprom_device *eeprom = NULL;
>
> No need to initialize.
Sure.. Will fix it.
>
>> + struct property *prop;
>> + const __be32 *vp;
>> + u32 pv;
>> + int i, rval;
>> +
>> + mutex_lock(&eeprom_mutex);
>> +
>> + eeprom = cell_np ? of_eeprom_find(cell_np->parent) : eeprom_find(ename);
>> + if (!eeprom) {
>> + mutex_unlock(&eeprom_mutex);
>> + return ERR_PTR(-EPROBE_DEFER);
>> + }
>> +
>
>> +/**
>> + * of_eeprom_cell_get(): Get eeprom cell of device form a given index
>> + *
>> + * @dev: Device that will be interacted with
>> + * @index: eeprom index in eeproms property.
>> + *
>> + * The return value will be an ERR_PTR() on error or a valid pointer
>> + * to a struct eeprom_cell. The eeprom_cell will be freed by the
>> + * eeprom_cell_put().
>> + */
>> +struct eeprom_cell *of_eeprom_cell_get(struct device *dev, int index)
>> +{
>
> I think the consumer API could be improved. The dev pointer is only used
> to get the struct device_node out of it, so the device_node could be
> passed in directly. As written in my other mail I think the binding
> would be better like "calibration = <&tsens_calibration>;", so this
> function could be:
>
> of_eeprom_cell_get(struct device_node *np, const char *name)
>
> With this we could also get eeprom cells from subnodes which do not have
> a struct device bound to them.
>
Its a good point, I will give it a try and see.
>> + struct device_node *cell_np;
>> +
>> + if (!dev || !dev->of_node)
>> + return ERR_PTR(-EINVAL);
>> +
>> + cell_np = of_parse_phandle(dev->of_node, "eeproms", index);
>> + if (!cell_np)
>> + return ERR_PTR(-EPROBE_DEFER);
>
> -EPROBE_DEFER is not appropriate here. If of_parse_phandle fails it
> won't work next time.
>
That's right, if it cant parse it now, it would also fail next time too.
Will fix it in next version.
>> +
>> + return __eeprom_cell_get(cell_np, NULL, NULL, 0);
>> +}
>> +EXPORT_SYMBOL_GPL(of_eeprom_cell_get);
>> +
>> +/**
>> + * eeprom_cell_write(): Write to a given eeprom cell
>> + *
>> + * @cell: eeprom cell to be written.
>> + * @buf: Buffer to be written.
>> + * @len: length of buffer to be written to eeprom cell.
>> + *
>> + * The return value will be an non zero on error or a zero on successful write.
>
> No, it returns the length.
>
Yes, thats true, will fix it in next version.
>> + */
>> +int eeprom_cell_write(struct eeprom_cell *cell, const char *buf, ssize_t len)
>> +{
>> + struct eeprom_device *eeprom = cell->eeprom;
>> + int i, rc, offset = 0;
>> +
>> + if (!eeprom || !eeprom->regmap || len != cell->size)
>> + return -EINVAL;
>> +
>> + for (i = 0; i < cell->nblocks; i++) {
>> + rc = regmap_bulk_write(eeprom->regmap, cell->blocks[i].offset,
>> + buf + offset,
>> + cell->blocks[i].count);
>> +
>> + if (IS_ERR_VALUE(rc))
>> + return rc;
>> +
>> + offset += cell->blocks[i].count;
>> + }
>> +
>> + return len;
>> +}
>> +EXPORT_SYMBOL_GPL(eeprom_cell_write);
>> +
>
>> +static inline char *eeprom_cell_read(struct eeprom_cell *cell, ssize_t *len)
>> +{
>> + return NULL;
>> +}
>
> The documentation above the real function states that this function
> either returns an ERR_PTR() or a valid pointer. The wrapper should then
> do the same.
>
Will fix this in next version.
> Sascha
>
>
^ permalink raw reply
* Re: [PATCH] Add virtio gpu driver.
From: Gerd Hoffmann @ 2015-03-25 14:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: virtio-dev, open list:ABI/API, Rusty Russell, open list,
open list:DRM DRIVERS, open list:VIRTIO CORE, NET..., Dave Airlie
In-Reply-To: <20150324171255-mutt-send-email-mst@redhat.com>
Hi,
> > diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> > index e894eb2..a3167fa 100644
> > --- a/drivers/virtio/virtio_pci_common.c
> > +++ b/drivers/virtio/virtio_pci_common.c
> > @@ -510,7 +510,7 @@ static int virtio_pci_probe(struct pci_dev *pci_dev,
> > goto err_enable_device;
> >
> > rc = pci_request_regions(pci_dev, "virtio-pci");
> > - if (rc)
> > + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA))
> > goto err_request_regions;
> >
> > if (force_legacy) {
>
> This is probably what you described as "the only concern?
Ahem, no, forgot that one, but it is related. With vesafb using and
registering the vga compat framebuffer bar pci_request_regions will not
succeed.
vesafb will be unregistered later on (this is what I was refering to) by
the virtio-gpu driver.
> If we only need to request specific
> regions, I think we should do exactly that, requesting only parts of
> regions that are covered by the virtio capabilities.
That should work too.
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox