* [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
From: Ingo Molnar @ 2018-05-05 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505112817.ihrb726i37bwm4cj@tardis>
* Boqun Feng <boqun.feng@gmail.com> wrote:
> > May I suggest the patch below? No change in functionality, but it documents the
> > lack of the cmpxchg_release() APIs and maps them explicitly to the full cmpxchg()
> > version. (Which the generic code does now in a rather roundabout way.)
> >
>
> Hmm.. cmpxchg_release() is actually lwsync() + cmpxchg_relaxed(), but
> you just make it sync() + cmpxchg_relaxed() + sync() with the fallback,
> and sync() is much heavier, so I don't think the fallback is correct.
Indeed!
The bit I missed previously is that PowerPC provides its own __atomic_op_release()
method:
#define __atomic_op_release(op, args...) \
({ \
__asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
op##_relaxed(args); \
})
... which maps to LWSYNC as you say, and my patch made that worse.
> I think maybe you can move powerpc's __atomic_op_{acqurie,release}()
> from atomic.h to cmpxchg.h (in arch/powerpc/include/asm), and
>
> #define cmpxchg_release __atomic_op_release(cmpxchg, __VA_ARGS__);
> #define cmpxchg64_release __atomic_op_release(cmpxchg64, __VA_ARGS__);
>
> I put a diff below to say what I mean (untested).
>
> > Also, the change to arch/powerpc/include/asm/atomic.h has no functional effect
> > right now either, but should anyone add a _relaxed() variant in the future, with
> > this change atomic_cmpxchg_release() and atomic64_cmpxchg_release() will pick that
> > up automatically.
> >
>
> You mean with your other modification in include/linux/atomic.h, right?
> Because with the unmodified include/linux/atomic.h, we already pick that
> autmatically. If so, I think that's fine.
>
> Here is the diff for the modification for cmpxchg_release(), the idea is
> we generate them in asm/cmpxchg.h other than linux/atomic.h for ppc, so
> we keep the new linux/atomic.h working. Because if I understand
> correctly, the next linux/atomic.h only accepts that
>
> 1) architecture only defines fully ordered primitives
>
> or
>
> 2) architecture only defines _relaxed primitives
>
> or
>
> 3) architecture defines all four (fully, _relaxed, _acquire,
> _release) primitives
>
> So powerpc needs to define all four primitives in its only
> asm/cmpxchg.h.
Correct, although the new logic is still RFC, PeterZ didn't like the first version
I proposed and might NAK them.
Thanks for the patch - I have created the patch below from it and added your
Signed-off-by.
The only change I made beyond a trivial build fix is that I also added the release
atomics variants explicitly:
+#define atomic_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
+#define atomic64_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
It has passed a PowerPC cross-build test here, but no runtime tests.
Does this patch look good to you?
(Still subject to PeterZ's Ack/NAK.)
Thanks,
Ingo
======================>
From: Boqun Feng <boqun.feng@gmail.com>
Date: Sat, 5 May 2018 19:28:17 +0800
Subject: [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
Move PowerPC's __op_{acqurie,release}() from atomic.h to
cmpxchg.h (in arch/powerpc/include/asm), plus use them to
define these two methods:
#define cmpxchg_release __op_release(cmpxchg, __VA_ARGS__);
#define cmpxchg64_release __op_release(cmpxchg64, __VA_ARGS__);
... the idea is to generate all these methods in cmpxchg.h and to define the full
array of atomic primitives, including the cmpxchg_release() methods which were
defined by the generic code before.
Also define the atomic[64]_() variants explicitly.
This ensures that all these low level cmpxchg APIs are defined in
PowerPC headers, with no generic header fallbacks.
No change in functionality or code generation.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: aryabinin at virtuozzo.com
Cc: catalin.marinas at arm.com
Cc: dvyukov at google.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: will.deacon at arm.com
Link: http://lkml.kernel.org/r/20180505112817.ihrb726i37bwm4cj at tardis
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/powerpc/include/asm/atomic.h | 22 ++++------------------
arch/powerpc/include/asm/cmpxchg.h | 24 ++++++++++++++++++++++++
2 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
index 682b3e6a1e21..4e06955ec10f 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -13,24 +13,6 @@
#define ATOMIC_INIT(i) { (i) }
-/*
- * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
- * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
- * on the platform without lwsync.
- */
-#define __atomic_op_acquire(op, args...) \
-({ \
- typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
- __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
- __ret; \
-})
-
-#define __atomic_op_release(op, args...) \
-({ \
- __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
- op##_relaxed(args); \
-})
-
static __inline__ int atomic_read(const atomic_t *v)
{
int t;
@@ -213,6 +195,8 @@ static __inline__ int atomic_dec_return_relaxed(atomic_t *v)
cmpxchg_relaxed(&((v)->counter), (o), (n))
#define atomic_cmpxchg_acquire(v, o, n) \
cmpxchg_acquire(&((v)->counter), (o), (n))
+#define atomic_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
@@ -519,6 +503,8 @@ static __inline__ long atomic64_dec_if_positive(atomic64_t *v)
cmpxchg_relaxed(&((v)->counter), (o), (n))
#define atomic64_cmpxchg_acquire(v, o, n) \
cmpxchg_acquire(&((v)->counter), (o), (n))
+#define atomic64_cmpxchg_release(v, o, n) \
+ cmpxchg_release(&((v)->counter), (o), (n))
#define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic64_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
diff --git a/arch/powerpc/include/asm/cmpxchg.h b/arch/powerpc/include/asm/cmpxchg.h
index 9b001f1f6b32..e27a612b957f 100644
--- a/arch/powerpc/include/asm/cmpxchg.h
+++ b/arch/powerpc/include/asm/cmpxchg.h
@@ -8,6 +8,24 @@
#include <asm/asm-compat.h>
#include <linux/bug.h>
+/*
+ * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
+ * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
+ * on the platform without lwsync.
+ */
+#define __atomic_op_acquire(op, args...) \
+({ \
+ typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
+ __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
+ __ret; \
+})
+
+#define __atomic_op_release(op, args...) \
+({ \
+ __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
+ op##_relaxed(args); \
+})
+
#ifdef __BIG_ENDIAN
#define BITOFF_CAL(size, off) ((sizeof(u32) - size - off) * BITS_PER_BYTE)
#else
@@ -512,6 +530,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
(unsigned long)_o_, (unsigned long)_n_, \
sizeof(*(ptr))); \
})
+
+#define cmpxchg_release(...) __atomic_op_release(cmpxchg, __VA_ARGS__)
+
#ifdef CONFIG_PPC64
#define cmpxchg64(ptr, o, n) \
({ \
@@ -533,6 +554,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
cmpxchg_acquire((ptr), (o), (n)); \
})
+
+#define cmpxchg64_release(...) __atomic_op_release(cmpxchg64, __VA_ARGS__)
+
#else
#include <asm-generic/cmpxchg-local.h>
#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
^ permalink raw reply related
* [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
From: Boqun Feng @ 2018-05-05 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505132751.gwzu2vbzibr2risd@gmail.com>
On Sat, May 05, 2018 at 03:27:51PM +0200, Ingo Molnar wrote:
>
> * Boqun Feng <boqun.feng@gmail.com> wrote:
>
> > > May I suggest the patch below? No change in functionality, but it documents the
> > > lack of the cmpxchg_release() APIs and maps them explicitly to the full cmpxchg()
> > > version. (Which the generic code does now in a rather roundabout way.)
> > >
> >
> > Hmm.. cmpxchg_release() is actually lwsync() + cmpxchg_relaxed(), but
> > you just make it sync() + cmpxchg_relaxed() + sync() with the fallback,
> > and sync() is much heavier, so I don't think the fallback is correct.
>
> Indeed!
>
> The bit I missed previously is that PowerPC provides its own __atomic_op_release()
> method:
>
> #define __atomic_op_release(op, args...) \
> ({ \
> __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
> op##_relaxed(args); \
> })
>
> ... which maps to LWSYNC as you say, and my patch made that worse.
>
> > I think maybe you can move powerpc's __atomic_op_{acqurie,release}()
> > from atomic.h to cmpxchg.h (in arch/powerpc/include/asm), and
> >
> > #define cmpxchg_release __atomic_op_release(cmpxchg, __VA_ARGS__);
> > #define cmpxchg64_release __atomic_op_release(cmpxchg64, __VA_ARGS__);
> >
> > I put a diff below to say what I mean (untested).
> >
> > > Also, the change to arch/powerpc/include/asm/atomic.h has no functional effect
> > > right now either, but should anyone add a _relaxed() variant in the future, with
> > > this change atomic_cmpxchg_release() and atomic64_cmpxchg_release() will pick that
> > > up automatically.
> > >
> >
> > You mean with your other modification in include/linux/atomic.h, right?
> > Because with the unmodified include/linux/atomic.h, we already pick that
> > autmatically. If so, I think that's fine.
> >
> > Here is the diff for the modification for cmpxchg_release(), the idea is
> > we generate them in asm/cmpxchg.h other than linux/atomic.h for ppc, so
> > we keep the new linux/atomic.h working. Because if I understand
> > correctly, the next linux/atomic.h only accepts that
> >
> > 1) architecture only defines fully ordered primitives
> >
> > or
> >
> > 2) architecture only defines _relaxed primitives
> >
> > or
> >
> > 3) architecture defines all four (fully, _relaxed, _acquire,
> > _release) primitives
> >
> > So powerpc needs to define all four primitives in its only
> > asm/cmpxchg.h.
>
> Correct, although the new logic is still RFC, PeterZ didn't like the first version
> I proposed and might NAK them.
>
Understood. From my side, I don't have strong feelings for either way.
But since powerpc gets affected with the new logic, so I'm glad I could
help.
> Thanks for the patch - I have created the patch below from it and added your
> Signed-off-by.
>
Thanks ;-)
> The only change I made beyond a trivial build fix is that I also added the release
> atomics variants explicitly:
>
> +#define atomic_cmpxchg_release(v, o, n) \
> + cmpxchg_release(&((v)->counter), (o), (n))
> +#define atomic64_cmpxchg_release(v, o, n) \
> + cmpxchg_release(&((v)->counter), (o), (n))
>
> It has passed a PowerPC cross-build test here, but no runtime tests.
>
Do you have the commit at any branch in tip tree? I could pull it and
cross-build and check the assembly code of lib/atomic64_test.c, that way
I could verify whether we mess something up.
> Does this patch look good to you?
>
Yep!
Regards,
Boqun
> (Still subject to PeterZ's Ack/NAK.)
>
> Thanks,
>
> Ingo
>
> ======================>
> From: Boqun Feng <boqun.feng@gmail.com>
> Date: Sat, 5 May 2018 19:28:17 +0800
> Subject: [PATCH] locking/atomics/powerpc: Move cmpxchg helpers to asm/cmpxchg.h and define the full set of cmpxchg APIs
>
> Move PowerPC's __op_{acqurie,release}() from atomic.h to
> cmpxchg.h (in arch/powerpc/include/asm), plus use them to
> define these two methods:
>
> #define cmpxchg_release __op_release(cmpxchg, __VA_ARGS__);
> #define cmpxchg64_release __op_release(cmpxchg64, __VA_ARGS__);
>
> ... the idea is to generate all these methods in cmpxchg.h and to define the full
> array of atomic primitives, including the cmpxchg_release() methods which were
> defined by the generic code before.
>
> Also define the atomic[64]_() variants explicitly.
>
> This ensures that all these low level cmpxchg APIs are defined in
> PowerPC headers, with no generic header fallbacks.
>
> No change in functionality or code generation.
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: aryabinin at virtuozzo.com
> Cc: catalin.marinas at arm.com
> Cc: dvyukov at google.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: will.deacon at arm.com
> Link: http://lkml.kernel.org/r/20180505112817.ihrb726i37bwm4cj at tardis
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
> arch/powerpc/include/asm/atomic.h | 22 ++++------------------
> arch/powerpc/include/asm/cmpxchg.h | 24 ++++++++++++++++++++++++
> 2 files changed, 28 insertions(+), 18 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
> index 682b3e6a1e21..4e06955ec10f 100644
> --- a/arch/powerpc/include/asm/atomic.h
> +++ b/arch/powerpc/include/asm/atomic.h
> @@ -13,24 +13,6 @@
>
> #define ATOMIC_INIT(i) { (i) }
>
> -/*
> - * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
> - * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
> - * on the platform without lwsync.
> - */
> -#define __atomic_op_acquire(op, args...) \
> -({ \
> - typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
> - __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
> - __ret; \
> -})
> -
> -#define __atomic_op_release(op, args...) \
> -({ \
> - __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
> - op##_relaxed(args); \
> -})
> -
> static __inline__ int atomic_read(const atomic_t *v)
> {
> int t;
> @@ -213,6 +195,8 @@ static __inline__ int atomic_dec_return_relaxed(atomic_t *v)
> cmpxchg_relaxed(&((v)->counter), (o), (n))
> #define atomic_cmpxchg_acquire(v, o, n) \
> cmpxchg_acquire(&((v)->counter), (o), (n))
> +#define atomic_cmpxchg_release(v, o, n) \
> + cmpxchg_release(&((v)->counter), (o), (n))
>
> #define atomic_xchg(v, new) (xchg(&((v)->counter), new))
> #define atomic_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
> @@ -519,6 +503,8 @@ static __inline__ long atomic64_dec_if_positive(atomic64_t *v)
> cmpxchg_relaxed(&((v)->counter), (o), (n))
> #define atomic64_cmpxchg_acquire(v, o, n) \
> cmpxchg_acquire(&((v)->counter), (o), (n))
> +#define atomic64_cmpxchg_release(v, o, n) \
> + cmpxchg_release(&((v)->counter), (o), (n))
>
> #define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
> #define atomic64_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
> diff --git a/arch/powerpc/include/asm/cmpxchg.h b/arch/powerpc/include/asm/cmpxchg.h
> index 9b001f1f6b32..e27a612b957f 100644
> --- a/arch/powerpc/include/asm/cmpxchg.h
> +++ b/arch/powerpc/include/asm/cmpxchg.h
> @@ -8,6 +8,24 @@
> #include <asm/asm-compat.h>
> #include <linux/bug.h>
>
> +/*
> + * Since *_return_relaxed and {cmp}xchg_relaxed are implemented with
> + * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
> + * on the platform without lwsync.
> + */
> +#define __atomic_op_acquire(op, args...) \
> +({ \
> + typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
> + __asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory"); \
> + __ret; \
> +})
> +
> +#define __atomic_op_release(op, args...) \
> +({ \
> + __asm__ __volatile__(PPC_RELEASE_BARRIER "" : : : "memory"); \
> + op##_relaxed(args); \
> +})
> +
> #ifdef __BIG_ENDIAN
> #define BITOFF_CAL(size, off) ((sizeof(u32) - size - off) * BITS_PER_BYTE)
> #else
> @@ -512,6 +530,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
> (unsigned long)_o_, (unsigned long)_n_, \
> sizeof(*(ptr))); \
> })
> +
> +#define cmpxchg_release(...) __atomic_op_release(cmpxchg, __VA_ARGS__)
> +
> #ifdef CONFIG_PPC64
> #define cmpxchg64(ptr, o, n) \
> ({ \
> @@ -533,6 +554,9 @@ __cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
> BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
> cmpxchg_acquire((ptr), (o), (n)); \
> })
> +
> +#define cmpxchg64_release(...) __atomic_op_release(cmpxchg64, __VA_ARGS__)
> +
> #else
> #include <asm-generic/cmpxchg-local.h>
> #define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180505/fec9a4cc/attachment-0001.sig>
^ permalink raw reply
* [arm-platforms:irq/level-msi 11/13] drivers/irqchip/irq-gic-v3-mbi.c:77:13: error: passing argument 1 of 'mutex_lock_nested' from incompatible pointer type
From: kbuild test robot @ 2018-05-05 15:14 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/level-msi
head: 899ce68260999a53b26b3ba17836a080882e0e08
commit: 37b3cc58b06bf28420f0bff0b20fddf21b9c6b01 [11/13] irqchip/gic-v3: Add support for Message Based Interrupts as an MSI controller
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 37b3cc58b06bf28420f0bff0b20fddf21b9c6b01
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/irqchip/irq-gic-v3-mbi.c:26:8: error: unknown type name 'mutex_t'
static mutex_t mbi_lock;
^~~~~~~
In file included from include/linux/kernfs.h:13:0,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from include/linux/dma-mapping.h:7,
from include/linux/dma-iommu.h:24,
from drivers/irqchip/irq-gic-v3-mbi.c:9:
drivers/irqchip/irq-gic-v3-mbi.c: In function 'mbi_free_msi':
>> drivers/irqchip/irq-gic-v3-mbi.c:77:13: error: passing argument 1 of 'mutex_lock_nested' from incompatible pointer type [-Werror=incompatible-pointer-types]
mutex_lock(&mbi_lock);
^
include/linux/mutex.h:169:44: note: in definition of macro 'mutex_lock'
#define mutex_lock(lock) mutex_lock_nested(lock, 0)
^~~~
include/linux/mutex.h:160:13: note: expected 'struct mutex *' but argument is of type 'int *'
extern void mutex_lock_nested(struct mutex *lock, unsigned int subclass);
^~~~~~~~~~~~~~~~~
drivers/irqchip/irq-gic-v3-mbi.c:80:15: error: passing argument 1 of 'mutex_unlock' from incompatible pointer type [-Werror=incompatible-pointer-types]
mutex_unlock(&mbi_lock);
^
In file included from include/linux/kernfs.h:13:0,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from include/linux/dma-mapping.h:7,
from include/linux/dma-iommu.h:24,
from drivers/irqchip/irq-gic-v3-mbi.c:9:
include/linux/mutex.h:200:13: note: expected 'struct mutex *' but argument is of type 'int *'
extern void mutex_unlock(struct mutex *lock);
^~~~~~~~~~~~
drivers/irqchip/irq-gic-v3-mbi.c: In function 'mbi_irq_domain_alloc':
drivers/irqchip/irq-gic-v3-mbi.c:89:13: error: passing argument 1 of 'mutex_lock_nested' from incompatible pointer type [-Werror=incompatible-pointer-types]
mutex_lock(&mbi_lock);
^
include/linux/mutex.h:169:44: note: in definition of macro 'mutex_lock'
#define mutex_lock(lock) mutex_lock_nested(lock, 0)
^~~~
include/linux/mutex.h:160:13: note: expected 'struct mutex *' but argument is of type 'int *'
extern void mutex_lock_nested(struct mutex *lock, unsigned int subclass);
^~~~~~~~~~~~~~~~~
drivers/irqchip/irq-gic-v3-mbi.c:99:15: error: passing argument 1 of 'mutex_unlock' from incompatible pointer type [-Werror=incompatible-pointer-types]
mutex_unlock(&mbi_lock);
^
In file included from include/linux/kernfs.h:13:0,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from include/linux/dma-mapping.h:7,
from include/linux/dma-iommu.h:24,
from drivers/irqchip/irq-gic-v3-mbi.c:9:
include/linux/mutex.h:200:13: note: expected 'struct mutex *' but argument is of type 'int *'
extern void mutex_unlock(struct mutex *lock);
^~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/mutex_lock_nested +77 drivers/irqchip/irq-gic-v3-mbi.c
8
> 9 #include <linux/dma-iommu.h>
10 #include <linux/irq.h>
11 #include <linux/irqdomain.h>
12 #include <linux/kernel.h>
13 #include <linux/msi.h>
14 #include <linux/of_address.h>
15 #include <linux/slab.h>
16 #include <linux/spinlock.h>
17
18 #include <linux/irqchip/arm-gic-v3.h>
19
20 struct mbi_range {
21 u32 spi_start;
22 u32 nr_spis;
23 unsigned long *bm;
24 };
25
26 static mutex_t mbi_lock;
27 static phys_addr_t mbi_phys_base;
28 static struct mbi_range *mbi_ranges;
29 static unsigned int mbi_range_nr;
30
31 static struct irq_chip mbi_irq_chip = {
32 .name = "MBI",
33 .irq_mask = irq_chip_mask_parent,
34 .irq_unmask = irq_chip_unmask_parent,
35 .irq_eoi = irq_chip_eoi_parent,
36 .irq_set_type = irq_chip_set_type_parent,
37 .irq_set_affinity = irq_chip_set_affinity_parent,
38 };
39
40 static int mbi_irq_gic_domain_alloc(struct irq_domain *domain,
41 unsigned int virq,
42 irq_hw_number_t hwirq)
43 {
44 struct irq_fwspec fwspec;
45 struct irq_data *d;
46 int err;
47
48 /*
49 * Using ACPI? There is no MBI support in the spec, you
50 * shouldn't even be here.
51 */
52 if (!is_of_node(domain->parent->fwnode))
53 return -EINVAL;
54
55 /*
56 * Let's default to edge. This is consistent with traditional
57 * MSIs, and systems requiring level signaling will just
58 * enforce the trigger on their own.
59 */
60 fwspec.fwnode = domain->parent->fwnode;
61 fwspec.param_count = 3;
62 fwspec.param[0] = 0;
63 fwspec.param[1] = hwirq - 32;
64 fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
65
66 err = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
67 if (err)
68 return err;
69
70 d = irq_domain_get_irq_data(domain->parent, virq);
71 return d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
72 }
73
74 static void mbi_free_msi(struct mbi_range *mbi, unsigned int hwirq,
75 int nr_irqs)
76 {
> 77 mutex_lock(&mbi_lock);
78 bitmap_release_region(mbi->bm, hwirq - mbi->spi_start,
79 get_count_order(nr_irqs));
80 mutex_unlock(&mbi_lock);
81 }
82
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 65221 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180505/bb91a61a/attachment-0001.gz>
^ permalink raw reply
* [PATCH V6 7/7] ARM: dts: imx6sx-sabreauto: add egalax touch screen support
From: Fabio Estevam @ 2018-05-05 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525508963-7986-7-git-send-email-Anson.Huang@nxp.com>
On Sat, May 5, 2018 at 5:29 AM, Anson Huang <Anson.Huang@nxp.com> wrote:
> &iomuxc {
> + pinctrl_egalax_int: egalax-intgrp {
> + fsl,pins = <
> + MX6SX_PAD_SD4_RESET_B__GPIO6_IO_22 0x80000000
Please avoid using 0x80000000 and use the real IOMUX value instead.
^ permalink raw reply
* [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Thomas Petazzoni @ 2018-05-05 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504172337.GC13899@kwain>
Hello,
On Fri, 4 May 2018 19:23:37 +0200, Antoine Tenart wrote:
> On Fri, May 04, 2018 at 10:04:48AM -0700, Florian Fainelli wrote:
> > On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> > > SFP connectors can be solder on a board without having any of their pins
> > > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> > > and the overall link status reporting is left to other layers.
> > >
> > > In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> > > This mode is set when it is not possible for the SFP code to get the
> > > link status and as a result the link status is reported to be always UP
> > > from the SFP point of view.
> >
> > Why represent the SFP in Device Tree then? Why not just declare this is
> > a fixed link which would avoid having to introduce this "unknown" state.
>
> The other solution would have been to represent this as a fixed-link.
> But such a representation would report the link as being up all the
> time, which is something we wanted to avoid as the GoP in PPv2 can
> report some link status. This is achieved using SFP+phylink+PPv2.
>
> And representing the SFP cage in the device tree, although it's a
> "dummy" one, helps describing the hardware.
Just to add to this: the board physically has a SFP cage, and a cable
can be connected to it, or not. So it is absolutely not a fixed link
(cable can be connected or not) and it really is a SFP cage.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Andrew Lunn @ 2018-05-05 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505173945.0754d0df@windsurf>
On Sat, May 05, 2018 at 05:39:45PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 4 May 2018 19:23:37 +0200, Antoine Tenart wrote:
>
> > On Fri, May 04, 2018 at 10:04:48AM -0700, Florian Fainelli wrote:
> > > On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> > > > SFP connectors can be solder on a board without having any of their pins
> > > > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> > > > and the overall link status reporting is left to other layers.
> > > >
> > > > In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> > > > This mode is set when it is not possible for the SFP code to get the
> > > > link status and as a result the link status is reported to be always UP
> > > > from the SFP point of view.
> > >
> > > Why represent the SFP in Device Tree then? Why not just declare this is
> > > a fixed link which would avoid having to introduce this "unknown" state.
> >
> > The other solution would have been to represent this as a fixed-link.
> > But such a representation would report the link as being up all the
> > time, which is something we wanted to avoid as the GoP in PPv2 can
> > report some link status. This is achieved using SFP+phylink+PPv2.
> >
> > And representing the SFP cage in the device tree, although it's a
> > "dummy" one, helps describing the hardware.
>
> Just to add to this: the board physically has a SFP cage, and a cable
> can be connected to it, or not. So it is absolutely not a fixed link
> (cable can be connected or not) and it really is a SFP cage.
Hi Thomas
What i have heard on the rumour mill is that the hardware design is
FUBAR. The i2c-mux and i2c-gpio expanders are using the same
addresses. Or something like that. So the data plane from the MAC to
the SFP works. But the control plane is broken.
I don't really have a problem listing an SFP in device tree. As you
say, it physically exists on the boards. But because of the FUBAR
hardware, it cannot be controlled. phylink is all about the control
plane, and there is no control plane for this hardware. So connecting
this sfp to phylink seems very wrong. When we have no control plain,
we use a fixed-link.
Isn't this hardware a reference design? It is not a real product. If
it is an RDK, i'm sure Marvell are telling people it is FUBAR, don't
copy it. There will be a new RDK sometime which has the problems
fixed. So how much effort should we put into supporting a broken RDK,
which nobody will copy into a real product? To me, KISS is the right
approach and document it in the device tree what the issue is.
If a real product comes to market which is equally FUBAR, we can then
consider how to get the best out of the hardware. We can extend
phylink to support a fixed link PHY, but still ask the MAC about its
link status.
Andrew
^ permalink raw reply
* [GIT PULL] one bug fix and few other fixes for v4.17-rc cycle
From: Tony Lindgren @ 2018-05-05 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <pull-1525448974-362873@atomide.com>
* Tony Lindgren <tony@atomide.com> [180504 15:51]:
> From: "Tony Lindgren" <tony@atomide.com>
>
> The following changes since commit fb289e3ab10c16834741bb02be740fa9d025fde0:
>
> Merge branch 'omap-for-v4.17/fixes-ti-sysc' into omap-for-v4.17/fixes (2018-04-19 15:48:46 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.17/fixes-rc3
>
> for you to fetch changes up to 647efef69de483f1dd7944ede31b4cae16acb124:
>
> ARM: dts: correct missing "compatible" entry for ti81xx SoCs (2018-05-03 10:07:47 -0700)
>
> ----------------------------------------------------------------
> Fixes for omap variants for v4.17-rc cycle
>
> This series of patches contains one BUG fix for trace if
> CONFIG_DEBUG_PREEMPT is enabled and a regression fix for omap1
> FIQ handling on ams-delta. Then there's a dts fix for missing SoC
> compatible on ti81xx board dts files that did matter until we added
> the clkctrl clocks and without that some clocks are now not found.
>
> Then there are three minor logicpd-som-lv specific dts fixes that
> fix misconfigured pins for WLAN, audio and USB.
>
> ----------------------------------------------------------------
> Adam Ford (3):
> ARM: dts: logicpd-som-lv: Fix WL127x Startup Issues
> ARM: dts: logicpd-som-lv: Fix Audio Mute
> ARM: dts: logicpd-som-lv: Fix pinmux controller references
Adam emailled that one of these has a side effect for breaking
USB. So let's not use this pull request if not yet merged, I'll
send an updated pull request early next week.
Regards,
Tony
^ permalink raw reply
* Motorola Droid 4 progress, power consumption
From: Tony Lindgren @ 2018-05-05 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504214723.GA8010@amd>
* Pavel Machek <pavel@ucw.cz> [180504 21:49]:
> > > Battery is not user-replacable (and this will recalibrate itself on
> > > charge/discharge cycle) so.. I don't think keying is strictly
> > > neccessary for D4.
> >
> > Yeah right, that can be added later on if needed if you just
> > plan accordingly. It's replaceable with a T5 after you peel off the
> > sticker from the corners :)
>
> Aha, I wanted to ask what kind of phone T5 is, and T5 is probably torx
> 5 screwdriver, right? Well, I don't have second battery, so these
> experiments will have to wait.
Yes torx 5 is needed to swap the battery.
Regards,
Tony
^ permalink raw reply
* [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Florian Fainelli @ 2018-05-05 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504171425.GA17233@lunn.ch>
On May 4, 2018 10:14:25 AM PDT, Andrew Lunn <andrew@lunn.ch> wrote:
>On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
>> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
>> > In case no Tx disable pin is available the SFP modules will always
>be
>> > emitting. This could be an issue when using modules using laser as
>their
>> > light source as we would have no way to disable it when the fiber
>is
>> > removed. This patch adds a warning when registering an SFP cage
>which do
>> > not have its tx_disable pin wired or available.
>>
>> Is this something that was done in a possibly earlier revision of a
>> given board design and which was finally fixed? Nothing wrong with
>the
>> patch, but this seems like a pretty serious board design mistake,
>that
>> needs to be addressed.
>
>Hi Florian
>
>Zii Devel B is like this. Only the "Signal Detect" pin is wired to a
>GPIO.
Good point, indeed. BTW what do you think about exposing the SFF's EEPROM and diagnostics through the standard ethtool operations even if we have to keep the description of the SFF as a fixed link in Device Tree because of the unfortunate wiring?
--
Florian
^ permalink raw reply
* [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
From: Andrew Lunn @ 2018-05-05 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <44545AF4-64E3-4772-B5BA-43CCF2321025@gmail.com>
On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote:
> On May 4, 2018 10:14:25 AM PDT, Andrew Lunn <andrew@lunn.ch> wrote:
> >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
> >> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
> >> > In case no Tx disable pin is available the SFP modules will always
> >be
> >> > emitting. This could be an issue when using modules using laser as
> >their
> >> > light source as we would have no way to disable it when the fiber
> >is
> >> > removed. This patch adds a warning when registering an SFP cage
> >which do
> >> > not have its tx_disable pin wired or available.
> >>
> >> Is this something that was done in a possibly earlier revision of a
> >> given board design and which was finally fixed? Nothing wrong with
> >the
> >> patch, but this seems like a pretty serious board design mistake,
> >that
> >> needs to be addressed.
> >
> >Hi Florian
> >
> >Zii Devel B is like this. Only the "Signal Detect" pin is wired to a
> >GPIO.
>
> Good point, indeed. BTW what do you think about exposing the SFF's
> EEPROM and diagnostics through the standard ethtool operations even
> if we have to keep the description of the SFF as a fixed link in
> Device Tree because of the unfortunate wiring?
I believe in Antoine case, all the control plane is broken. He cannot
read the EEPROM, nor any of the modules pins via GPIOs.
For Zii Devel B, the EEPROM is accessible, and so is the SD pin. What
is missing is transmit disable. So i would expose it as an SFF module.
Andrew
^ permalink raw reply
* Handling lm3559 flash on Motorola Droid 4 and others
From: Pavel Machek @ 2018-05-05 21:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
It seems lm3559 flash driver is available on github (
https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/tree/master/linux/modules/camera/drivers/media/i2c
) but there'll be some fun getting it cleaned up and merged.
Did anyone start doing anything in that area? Is there possibly better
source to start from?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180505/afcb1700/attachment.sig>
^ permalink raw reply
* [GIT PULL] one bug fix and few other fixes for v4.17-rc cycle
From: Adam Ford @ 2018-05-05 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505194326.GI98604@atomide.com>
On Sat, May 5, 2018 at 2:43 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [180504 15:51]:
>> From: "Tony Lindgren" <tony@atomide.com>
>>
>> The following changes since commit fb289e3ab10c16834741bb02be740fa9d025fde0:
>>
>> Merge branch 'omap-for-v4.17/fixes-ti-sysc' into omap-for-v4.17/fixes (2018-04-19 15:48:46 -0700)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.17/fixes-rc3
>>
>> for you to fetch changes up to 647efef69de483f1dd7944ede31b4cae16acb124:
>>
>> ARM: dts: correct missing "compatible" entry for ti81xx SoCs (2018-05-03 10:07:47 -0700)
>>
>> ----------------------------------------------------------------
>> Fixes for omap variants for v4.17-rc cycle
>>
>> This series of patches contains one BUG fix for trace if
>> CONFIG_DEBUG_PREEMPT is enabled and a regression fix for omap1
>> FIQ handling on ams-delta. Then there's a dts fix for missing SoC
>> compatible on ti81xx board dts files that did matter until we added
>> the clkctrl clocks and without that some clocks are now not found.
>>
>> Then there are three minor logicpd-som-lv specific dts fixes that
>> fix misconfigured pins for WLAN, audio and USB.
>>
>> ----------------------------------------------------------------
>> Adam Ford (3):
>> ARM: dts: logicpd-som-lv: Fix WL127x Startup Issues
>> ARM: dts: logicpd-som-lv: Fix Audio Mute
>> ARM: dts: logicpd-som-lv: Fix pinmux controller references
>
> Adam emailled that one of these has a side effect for breaking
> USB. So let's not use this pull request if not yet merged, I'll
> send an updated pull request early next week.
>
The WL127x and Audio patches are good, but pinmux controller fails on
cold-boot, so I'd like to revert that one.
adam
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Greeting !""
From: Paul Williams @ 2018-05-06 1:50 UTC (permalink / raw)
To: linux-arm-kernel
I 'm Paul Williams from USA,its my great pleasure to come across your contact today.If you wouldn't mind,can we chat on facebook or what's up for an important discussion that will project good image to our future.
^ permalink raw reply
* [RFC PATCH] locking/atomics/powerpc: Introduce optimized cmpxchg_release() family of APIs for PowerPC
From: Benjamin Herrenschmidt @ 2018-05-06 1:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505100055.yc4upauxo5etq5ud@gmail.com>
On Sat, 2018-05-05 at 12:00 +0200, Ingo Molnar wrote:
> This clearly suggests that PPC_RELEASE_BARRIER is in active use and 'lwsync' is
> the 'release barrier' instruction, if I interpreted that right.
The closest to one we got.
The semantics are that it orders all load/store pairs to cachable
storage except store+load.
Cheers,
Ben.
^ permalink raw reply
* [PATCH V6 7/7] ARM: dts: imx6sx-sabreauto: add egalax touch screen support
From: Anson Huang @ 2018-05-06 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5D1H4+w=FGh+8icBziunDzM4jN7peA=mirGb9RBHHqMsg@mail.gmail.com>
Hi, Fabio
Anson Huang
Best Regards!
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Saturday, May 5, 2018 7:56 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Haibo Chen <haibo.chen@freescale.com>; Andy Duan
> <fugang.duan@nxp.com>; A.s. Dong <aisheng.dong@nxp.com>; Robin Gong
> <yibin.gong@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-kernel
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH V6 7/7] ARM: dts: imx6sx-sabreauto: add egalax touch
> screen support
>
> Hi Anson,
>
> On Sat, May 5, 2018 at 5:29 AM, Anson Huang <Anson.Huang@nxp.com>
> wrote:
> > Add egalax touch screen support on i2c2 bus.
> >
> > Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
>
> Is Haibo the author of this patch? If so, his name should appear in the From field.
I made this patch based on NXP kernel tree, Haibo is the original author of this
feature, but the original patch can NOT be applied directly, I have to refine the patch
to meet the upstream requirement, so I added him as another signed-off tag,
to avoid confuse, I can remove this sign-off in next patch version. Same story
for other patches in this series.
>
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > changes since V5:
> > improve pinctrl node name and touchscreen node name.
> > arch/arm/boot/dts/imx6sx-sabreauto.dts | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > b/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > index 1dc5b58..3fe41d3 100644
> > --- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > +++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > @@ -122,6 +122,12 @@
> > };
> >
> > &iomuxc {
> > + pinctrl_egalax_int: egalax-intgrp {
> > + fsl,pins = <
> > + MX6SX_PAD_SD4_RESET_B__GPIO6_IO_22
> 0x80000000
> > + >;
> > + };
> > +
> > pinctrl_enet1: enet1grp {
> > fsl,pins = <
> > MX6SX_PAD_ENET1_MDIO__ENET1_MDIO
> 0xa0b1
> > @@ -264,6 +270,16 @@
> > pinctrl-0 = <&pinctrl_i2c2>;
> > status = "okay";
> >
> > + egalax_touchscreen at 4 {
>
> Should be touchscreen at 4.
Will improve it in next patch version.
Anson.
^ permalink raw reply
* [PATCH V6 4/7] ARM: dts: imx6sx-sabreauto: add fec support
From: Anson Huang @ 2018-05-06 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5B8xrnjyoPoj0J_+WM6TBbE1Gbq8HChdTCQ=UpKYyRBmQ@mail.gmail.com>
Hi, Fabio
Anson Huang
Best Regards!
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Saturday, May 5, 2018 8:11 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Haibo Chen <haibo.chen@freescale.com>; Andy Duan
> <fugang.duan@nxp.com>; A.s. Dong <aisheng.dong@nxp.com>; Robin Gong
> <yibin.gong@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-kernel
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH V6 4/7] ARM: dts: imx6sx-sabreauto: add fec support
>
> On Sat, May 5, 2018 at 5:29 AM, Anson Huang <Anson.Huang@nxp.com>
> wrote:
> > Add FEC support on i.MX6SX Sabre Auto board.
> >
> > Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
>
> Again, it is not clear who is the author here. Is it Fugang or yourself?
Same story explained in patch V6 7/7.
>
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > changes since V5:
> > use "gpios" instead of "enable-gpio".
> > arch/arm/boot/dts/imx6sx-sabreauto.dts | 80
> > ++++++++++++++++++++++++++++++++++
> > 1 file changed, 80 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > b/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > index 4d41b4d..7dda741 100644
> > --- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > +++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
> > @@ -18,6 +18,17 @@
> > reg = <0x80000000 0x80000000>;
> > };
> >
> > + reg_fec: fec_io_supply {
> > + compatible = "regulator-gpio";
> > + regulator-name = "1.8V_1.5V_FEC";
> > + regulator-min-microvolt = <1500000>;
> > + regulator-max-microvolt = <1800000>;
> > + states = <1500000 0x0 1800000 0x1>;
> > + gpios = <&max7322 0 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&sw2_reg>;
> > + enable-active-high;
> > + };
>
> I still find this confusing.
>
> There is no consumer for reg_fec in, so it seems you are relying on the fact that
> the kernel regulator core will disable reg_fec to put the regulator in the state
> you require.
Adding consumer for reg_fec in NOT available in this patch, as FEC driver itself
does NOT support setting IO voltage based on setting of dtb, so if want to add
consumer, need to patch FEC driver as well.
As I explained before, this reg is for adjusting IO voltage between 1.5V and 1.8V,
and FEC driver can work on both of them, current FEC driver can work well no matter
if it is 1.5V or 1.8V, to avoid confusion, I think I can remove this reg_fec in this patch series,
let FEC driver work with default setting of this GPIO regulator, we can add reg_fec support
after FEC driver supports adjusting IO voltage. Thanks.
Anson.
^ permalink raw reply
* [PATCH V6 7/7] ARM: dts: imx6sx-sabreauto: add egalax touch screen support
From: Anson Huang @ 2018-05-06 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5A7bf1qcHrWjM1mr31Nkz+oDJ=fQo3rjksp1YY-HhPM9A@mail.gmail.com>
Hi, Fabio
Anson Huang
Best Regards!
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Saturday, May 5, 2018 11:18 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Haibo Chen <haibo.chen@freescale.com>; Andy Duan
> <fugang.duan@nxp.com>; A.s. Dong <aisheng.dong@nxp.com>; Robin Gong
> <yibin.gong@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-kernel
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH V6 7/7] ARM: dts: imx6sx-sabreauto: add egalax touch
> screen support
>
> On Sat, May 5, 2018 at 5:29 AM, Anson Huang <Anson.Huang@nxp.com>
> wrote:
>
> > &iomuxc {
> > + pinctrl_egalax_int: egalax-intgrp {
> > + fsl,pins = <
> > + MX6SX_PAD_SD4_RESET_B__GPIO6_IO_22
> 0x80000000
>
> Please avoid using 0x80000000 and use the real IOMUX value instead.
Will use the expected pad settings in next version. Thanks.
Anson.
^ permalink raw reply
* [PATCH V7 1/7] ARM: dts: imx6sx-sabreauto: add PMIC support
From: Anson Huang @ 2018-05-06 6:28 UTC (permalink / raw)
To: linux-arm-kernel
Add pfuze100 support on i.MX6SX Sabre Auto board.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since V6:
remove unnecessary sign-off.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 116 +++++++++++++++++++++++++++++++++
1 file changed, 116 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 87ffe2c..1d8cf0f 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -66,6 +66,13 @@
};
&iomuxc {
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6SX_PAD_GPIO1_IO03__I2C2_SDA 0x4001b8b1
+ MX6SX_PAD_GPIO1_IO02__I2C2_SCL 0x4001b8b1
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO04__UART1_TX 0x1b0b1
@@ -139,3 +146,112 @@
>;
};
};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ pfuze100: pmic at 8 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ regulator-always-on;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH V7 2/7] ARM: dts: imx6sx-sabreauto: add max7322 IO expander support
From: Anson Huang @ 2018-05-06 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
Add MAX7322 IO expander support.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since V6:
remove unnecessary sign-off.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 1d8cf0f..ae253af 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -254,4 +254,11 @@
};
};
};
+
+ max7322: gpio at 68 {
+ compatible = "maxim,max7322";
+ reg = <0x68>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
--
2.7.4
^ permalink raw reply related
* [PATCH V7 3/7] ARM: dts: imx6sx-sabreauto: add IO expander max7310 support
From: Anson Huang @ 2018-05-06 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
i.MX6SX Sabre Auto board has two max7310 IO expander on I2C3 bus, add
support for them.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since V6:
remove unnecessary sign-off.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index ae253af..4d41b4d 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -73,6 +73,13 @@
>;
};
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6SX_PAD_KEY_ROW4__I2C3_SDA 0x4001b8b1
+ MX6SX_PAD_KEY_COL4__I2C3_SCL 0x4001b8b1
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO04__UART1_TX 0x1b0b1
@@ -262,3 +269,24 @@
#gpio-cells = <2>;
};
};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ max7310_a: gpio at 30 {
+ compatible = "maxim,max7310";
+ reg = <0x30>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ max7310_b: gpio at 32 {
+ compatible = "maxim,max7310";
+ reg = <0x32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH V7 4/7] ARM: dts: imx6sx-sabreauto: add fec support
From: Anson Huang @ 2018-05-06 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
Add FEC support on i.MX6SX Sabre Auto board.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since V6:
remove unnecessary sign-off and remove unused regulator for adjusting fec IO voltage.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 69 ++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 4d41b4d..fff0081 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -34,6 +34,39 @@
clock-frequency = <24576000>;
};
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+
+ ethphy1: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+};
+
+&fec2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet2>;
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ fsl,magic-packet;
+ status = "okay";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
@@ -66,6 +99,42 @@
};
&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6SX_PAD_ENET1_MDIO__ENET1_MDIO 0xa0b1
+ MX6SX_PAD_ENET1_MDC__ENET1_MDC 0xa0b1
+ MX6SX_PAD_RGMII1_TXC__ENET1_RGMII_TXC 0xa0b9
+ MX6SX_PAD_RGMII1_TD0__ENET1_TX_DATA_0 0xa0b1
+ MX6SX_PAD_RGMII1_TD1__ENET1_TX_DATA_1 0xa0b1
+ MX6SX_PAD_RGMII1_TD2__ENET1_TX_DATA_2 0xa0b1
+ MX6SX_PAD_RGMII1_TD3__ENET1_TX_DATA_3 0xa0b1
+ MX6SX_PAD_RGMII1_TX_CTL__ENET1_TX_EN 0xa0b1
+ MX6SX_PAD_RGMII1_RXC__ENET1_RX_CLK 0x3081
+ MX6SX_PAD_RGMII1_RD0__ENET1_RX_DATA_0 0x3081
+ MX6SX_PAD_RGMII1_RD1__ENET1_RX_DATA_1 0x3081
+ MX6SX_PAD_RGMII1_RD2__ENET1_RX_DATA_2 0x3081
+ MX6SX_PAD_RGMII1_RD3__ENET1_RX_DATA_3 0x3081
+ MX6SX_PAD_RGMII1_RX_CTL__ENET1_RX_EN 0x3081
+ >;
+ };
+
+ pinctrl_enet2: enet2grp {
+ fsl,pins = <
+ MX6SX_PAD_RGMII2_TXC__ENET2_RGMII_TXC 0xa0b9
+ MX6SX_PAD_RGMII2_TD0__ENET2_TX_DATA_0 0xa0b1
+ MX6SX_PAD_RGMII2_TD1__ENET2_TX_DATA_1 0xa0b1
+ MX6SX_PAD_RGMII2_TD2__ENET2_TX_DATA_2 0xa0b1
+ MX6SX_PAD_RGMII2_TD3__ENET2_TX_DATA_3 0xa0b1
+ MX6SX_PAD_RGMII2_TX_CTL__ENET2_TX_EN 0xa0b1
+ MX6SX_PAD_RGMII2_RXC__ENET2_RX_CLK 0x3081
+ MX6SX_PAD_RGMII2_RD0__ENET2_RX_DATA_0 0x3081
+ MX6SX_PAD_RGMII2_RD1__ENET2_RX_DATA_1 0x3081
+ MX6SX_PAD_RGMII2_RD2__ENET2_RX_DATA_2 0x3081
+ MX6SX_PAD_RGMII2_RD3__ENET2_RX_DATA_3 0x3081
+ MX6SX_PAD_RGMII2_RX_CTL__ENET2_RX_EN 0x3081
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO03__I2C2_SDA 0x4001b8b1
--
2.7.4
^ permalink raw reply related
* [PATCH V7 5/7] ARM: dts: imx6sx-sabreauto: add wdog external reset
From: Anson Huang @ 2018-05-06 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
i.MX6SX Sabre Auto board has GPIO1_IO13 pin can be
MUXed as WDOG output to reset PMIC, add this function
support.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
no change.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index fff0081..146d5ab 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -221,6 +221,12 @@
MX6SX_PAD_KEY_COL1__GPIO2_IO_11 0x17059
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6SX_PAD_GPIO1_IO13__WDOG1_WDOG_ANY 0x30b0
+ >;
+ };
};
&i2c2 {
@@ -359,3 +365,9 @@
#gpio-cells = <2>;
};
};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH V7 6/7] ARM: dts: imx6sx-sabreauto: add debug LED support
From: Anson Huang @ 2018-05-06 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
There is a debug LED(D11) connected to GPIO1_IO24,
add support for it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
no change.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 146d5ab..8e6bd9d 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,18 @@
reg = <0x80000000 0x80000000>;
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+
+ user {
+ label = "debug";
+ gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
vcc_sd3: regulator-vcc-sd3 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -149,6 +161,12 @@
>;
};
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX6SX_PAD_CSI_PIXCLK__GPIO1_IO_24 0x17059
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6SX_PAD_GPIO1_IO04__UART1_TX 0x1b0b1
--
2.7.4
^ permalink raw reply related
* [PATCH V7 7/7] ARM: dts: imx6sx-sabreauto: add egalax touch screen support
From: Anson Huang @ 2018-05-06 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525588093-29994-1-git-send-email-Anson.Huang@nxp.com>
Add egalax touch screen support on i2c2 bus.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since V6:
remove unnecessary sign-off, improve node name and add PAD setting value.
arch/arm/boot/dts/imx6sx-sabreauto.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 8e6bd9d..bfbcf70 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -111,6 +111,12 @@
};
&iomuxc {
+ pinctrl_egalax_int: egalax-intgrp {
+ fsl,pins = <
+ MX6SX_PAD_SD4_RESET_B__GPIO6_IO_22 0x10b0
+ >;
+ };
+
pinctrl_enet1: enet1grp {
fsl,pins = <
MX6SX_PAD_ENET1_MDIO__ENET1_MDIO 0xa0b1
@@ -253,6 +259,16 @@
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
+ touchscreen at 4 {
+ compatible = "eeti,egalax_ts";
+ reg = <0x04>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_egalax_int>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-gpios = <&gpio6 22 GPIO_ACTIVE_HIGH>;
+ };
+
pfuze100: pmic at 8 {
compatible = "fsl,pfuze100";
reg = <0x08>;
--
2.7.4
^ permalink raw reply related
* Handling lm3559 flash on Motorola Droid 4 and others
From: Pavel Machek @ 2018-05-06 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180505213951.GA4530@amd>
Hi!
> It seems lm3559 flash driver is available on github (
> https://github.com/ZenfoneArea/android_kernel_asus_zenfone5/tree/master/linux/modules/camera/drivers/media/i2c
> ) but there'll be some fun getting it cleaned up and merged.
>
> Did anyone start doing anything in that area? Is there possibly better
> source to start from?
It turned out to be easier than expected. Of course, using flash w/o
v4l will not be easy, but that's generic problem.
Pavel
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index bdf73cb..45305e8 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -271,6 +271,34 @@
};
};
+&i2c3 {
+ rearcam: camera at 36 {
+ compatible = "micron,ov8820";
+ reg = <0x36>;
+ clocks = <&auxclk1_ck>;
+ clock-names = "xvclk";
+ clock-frequency = <24000000>;
+ power-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>, // gpio48
+ <&gpio3 19 GPIO_ACTIVE_HIGH>, // gpio83
+ <&gpio5 23 GPIO_ACTIVE_HIGH>; // gpio151
+ };
+ frontcam: camera at 48 {
+ compatible = "ovti,mt9m114";
+ reg = <0x48>;
+ clocks = <&auxclk2_ck>;
+ clock-names = "extclk";
+ clock-frequency = <24000000>;
+ power-gpios = <&gpio6 11 GPIO_ACTIVE_HIGH>, // gpio171
+ <&gpio2 5 GPIO_ACTIVE_HIGH>; // gpio37
+ };
+ flashlight: flash at 53 {
+ compatible = "ti,lm3559";
+ reg = <0x53>;
+ };
+};
+
+
+
&keypad {
keypad,num-rows = <8>;
keypad,num-columns = <8>;
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index b600e03a..a9b2ba2 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -17,6 +17,8 @@
* General Public License for more details.
*/
+// Probably compatible with lm3559, too.
+
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/i2c.h>
@@ -395,6 +397,22 @@ static int lm3560_init_device(struct lm3560_flash *flash)
return rval;
/* reset faults */
rval = regmap_read(flash->regmap, REG_FLAG, ®_val);
+
+ printk("lm3560: Device initialized\n");
+
+ flash->led_mode = V4L2_FLASH_LED_MODE_TORCH;
+ rval = lm3560_mode_ctrl(flash);
+ rval = lm3560_torch_brt_ctrl(flash, 0, LM3560_TORCH_BRT_MIN);
+ rval = lm3560_torch_brt_ctrl(flash, 1, LM3560_TORCH_BRT_MIN);
+
+ mdelay(1000);
+
+ rval = lm3560_torch_brt_ctrl(flash, 0, 0);
+ rval = lm3560_torch_brt_ctrl(flash, 1, 0);
+
+ flash->led_mode = V4L2_FLASH_LED_MODE_NONE;
+ rval = lm3560_mode_ctrl(flash);
+
return rval;
}
@@ -405,6 +423,8 @@ static int lm3560_probe(struct i2c_client *client,
struct lm3560_platform_data *pdata = dev_get_platdata(&client->dev);
int rval;
+ printk("3560: probe\n");
+
flash = devm_kzalloc(&client->dev, sizeof(*flash), GFP_KERNEL);
if (flash == NULL)
return -ENOMEM;
@@ -417,17 +437,19 @@ static int lm3560_probe(struct i2c_client *client,
/* if there is no platform data, use chip default value */
if (pdata == NULL) {
+ printk("3560: no pdata\n");
+
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
if (pdata == NULL)
return -ENODEV;
- pdata->peak = LM3560_PEAK_3600mA;
- pdata->max_flash_timeout = LM3560_FLASH_TOUT_MAX;
+ pdata->peak = LM3560_PEAK_1600mA;
+ pdata->max_flash_timeout = LM3560_FLASH_TOUT_MIN;
/* led 1 */
- pdata->max_flash_brt[LM3560_LED0] = LM3560_FLASH_BRT_MAX;
- pdata->max_torch_brt[LM3560_LED0] = LM3560_TORCH_BRT_MAX;
+ pdata->max_flash_brt[LM3560_LED0] = LM3560_FLASH_BRT_MIN;
+ pdata->max_torch_brt[LM3560_LED0] = LM3560_TORCH_BRT_MIN;
/* led 2 */
- pdata->max_flash_brt[LM3560_LED1] = LM3560_FLASH_BRT_MAX;
- pdata->max_torch_brt[LM3560_LED1] = LM3560_TORCH_BRT_MAX;
+ pdata->max_flash_brt[LM3560_LED1] = LM3560_FLASH_BRT_MIN;
+ pdata->max_torch_brt[LM3560_LED1] = LM3560_TORCH_BRT_MIN;
}
flash->pdata = pdata;
flash->dev = &client->dev;
@@ -466,6 +488,8 @@ static int lm3560_remove(struct i2c_client *client)
static const struct i2c_device_id lm3560_id_table[] = {
{LM3560_NAME, 0},
+ {"lm3559", 0},
+ {"ti,lm3559", 0},
{}
};
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180506/96bdf4cf/attachment.sig>
^ permalink raw reply related
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