* Re: [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 11:32 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Jean-Christophe Plagniol-Villard, linux-arm-kernel,
devicetree
In-Reply-To: <81d5b553-38db-5137-2eac-145cb2f76578@axentia.se>
On 10/01/2017 at 12:21:42 +0100, Peter Rosin wrote :
> On 2017-01-10 11:42, Alexandre Belloni wrote:
> > On 10/01/2017 at 10:52:56 +0100, Peter Rosin wrote :
> >> On 2017-01-10 10:29, Alexandre Belloni wrote:
> >>> Hi,
> >>>
> >>> This needs a commit message, please add one.
> >>
> >> There's not all that much to say, but ok, I'll add something.
> >>
> >
> > It doesn't have to be long but it has to be present.
>
> Does it really? There are quite a few examples to contradict that,
> and checkpatch doesn't complain. That's no proof of course...
>
> As I said, I'll add something.
>
There is public shaming for maintainers taking patches without a commit
message, that's enough for me to require a commit message ;)
https://lwn.net/Articles/560392/
> >>> On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
> >> There's also the benefit of the increased chances of me getting
> >> notified of changes. I don't mind...
> >>
> >
> > Do you expect changes coming from third parties? I'm fine with it
> > anyway.
>
> Ok, I'll remember this and blame you for everything :-)
>
Well, you can let it there, I was just not sure whether you were
expecting to see patches or just trying to make checkpatch happy. As
said, I'm fine with it.
> >>>> +&main {
> >>>> + clock-frequency = <12000000>;
> >>>> +};
> >>>> +
> >>>
> >>> I don't think this is needed
> >>>
> >>>
> >>
> >> "this"? The &main frequency, or all of them?
> >>
> >
> > I meant just main
>
> Ok, I'll test with that change and then resend. Thanks!
>
> Cheers,
> peda
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] of: base: add support to get the number of cache levels
From: Sudeep Holla @ 2017-01-10 11:41 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. This patch adds the support for the
same.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 22 ++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..f7a2b47b3c77 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2268,6 +2268,28 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_count_cache_levels - Find the total number of cache levels for the
+ * given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which cache levels is being counted
+ *
+ * Returns the total number of cache levels for the given logical cpu
+ */
+int of_count_cache_levels(unsigned int cpu)
+{
+ int level = 0;
+ struct device_node *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ level++;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ return level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..c8597ae71ff3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_count_cache_levels(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Sudeep Holla @ 2017-01-10 11:41 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
In-Reply-To: <1484048479-19767-1-git-send-email-sudeep.holla@arm.com>
The cache hierarchy can be identified through Cache Level ID(CLIDR)
architected system register. However in some cases it will provide
only the number of cache levels that are integrated into the processor
itself. In other words, it can't provide any information about the
caches that are external and/or transparent.
Some platforms require to export the information about all such external
caches to the userspace applications via the sysfs interface.
This patch adds support to override the cache levels using device tree
to take such external non-architected caches into account.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/cacheinfo.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 9617301f76b5..fe7738a8c5b1 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves;
+ unsigned int ctype, level, leaves, of_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
+ of_level = of_count_cache_levels(cpu);
+ if (level < of_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+ * the information may be available in the device tree
+ * only unified external caches are considered here
+ */
+ leaves += (of_level - level);
+ level = of_level;
+ }
+
this_cpu_ci->num_levels = level;
this_cpu_ci->num_leaves = leaves;
return 0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] of: base: add support to get the number of cache levels
From: Sudeep Holla @ 2017-01-10 11:56 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
In-Reply-To: <1484048479-19767-1-git-send-email-sudeep.holla@arm.com>
On 10/01/17 11:41, Sudeep Holla wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. This patch adds the support for the
> same.
>
> It will be used on ARM64 platform where the device tree provides the
> information for the additional non-architected/transparent/external
> last level caches that are not integrated with the processors.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/of/base.c | 22 ++++++++++++++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 23 insertions(+)
>
I seem to have missed to generate patch after I fixed the build error.
I will send updated version of this patch.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 1/2][UPDATE] of: base: add support to get the number of cache levels
From: Sudeep Holla @ 2017-01-10 12:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
In-Reply-To: <1484048479-19767-1-git-send-email-sudeep.holla@arm.com>
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. This patch adds the support for the
same.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 23 +++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..80e557eca858 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -25,6 +25,7 @@
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
@@ -2268,6 +2269,28 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_count_cache_levels - Find the total number of cache levels for the
+ * given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which cache levels is being counted
+ *
+ * Returns the total number of cache levels for the given logical cpu
+ */
+int of_count_cache_levels(unsigned int cpu)
+{
+ int level = 0;
+ struct device_node *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ level++;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ return level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..c8597ae71ff3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_count_cache_levels(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: kbuild test robot @ 2017-01-10 12:07 UTC (permalink / raw)
Cc: kbuild-all, mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg, andi.shyti, hverkuil, sean, ivo.g.dimitrov.75,
linux-media, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1484039631-25120-3-git-send-email-sean.wang@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]
Hi Sean,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10-rc3 next-20170110]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Documentation-devicetree-Add-document-bindings-for-mtk-cir/20170110-193357
base: git://linuxtv.org/media_tree.git master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function devm_rc_allocate_device
drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
>> drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 'devm_rc_allocate_device'
ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/media/rc/mtk-cir.c:22:0:
include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
^~~~~~~~~~~~~~~~~~~~~~~
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function devm_rc_allocate_device
drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 'devm_rc_allocate_device'
ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/media/rc/mtk-cir.c:22:0:
include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
^~~~~~~~~~~~~~~~~~~~~~~
vim +/devm_rc_allocate_device +215 drivers/media/rc/mtk-cir.c
209 ir->base = devm_ioremap_resource(dev, res);
210 if (IS_ERR(ir->base)) {
211 dev_err(dev, "failed to map registers\n");
212 return PTR_ERR(ir->base);
213 }
214
> 215 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
216 if (!ir->rc) {
217 dev_err(dev, "failed to allocate device\n");
218 return -ENOMEM;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 57747 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: exynos5433: add DECON_TV node
From: Andi Shyti @ 2017-01-10 12:37 UTC (permalink / raw)
To: Andrzej Hajda
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andi Shyti, Chanwoo Choi
In-Reply-To: <1483958437-6572-1-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hi Andrzej,
On Mon, Jan 09, 2017 at 11:40:35AM +0100, Andrzej Hajda wrote:
> DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
> or 2nd DSI path.
>
> Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
>
> Hi Krzysztof,
>
> These patches are based on latest patches separating tm2 and tm2e and
> touchscreen patches. I hope this is good base.
> Thanks all for quick response/review.
All the three patches look good to me and they all apply on
Krzysztof's branch and next branch.
If you want you can add my review tag on all of them.
Andi
--
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
* [PATCH v6 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2017-01-10 13:18 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi!
changes v5 -> v6
- drop the &main clock-frequency
- add some text to the commit messages
- make config additions modules
changes v4 -> v5
- comment from Rob about the memory node made me look closer and
the memory size is actually updated by the bootloader, and that
hid the fact that the entry was always faulty. This version
specifies the correct memory size from the start, which is 64MB.
- ack from Rob
changes v3 -> v4
- rename files arch/arm/boot/dts/axentia-* to .../at91-*
- remove bootargs from at91-tse850-3.dts
- depend on the atmel ssc to register as a sound dai by itself
- bump copyright years
changes v2 -> v3
- document the new compatible strings prefixed with "axentia,".
changes v1 -> v2
- squash the fixup into the correct patch, sorry for the noise.
After finally having all essintial drivers upstreamed I would
like to have the dts and the defconfig also upstreamed.
The atmel-ssc/sound-dai change depends on a change that has been
sitting in the ASoC tree since mid-december, and I have been waiting
for it to hit linux-next before sending this, but it seems to take
longer than I anticipated. So, since I do not want this to in
turn miss the next merge window because of that wait I therefore
request that this is taken now even though it doesn't really work
w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course
builds cleanly even w/o those ASoC changes. That effectively means
that noone besides me should notice the inconsistency (I currently
have all affected devices under my control).
Cheers,
peda
[1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel
Peter Rosin (2):
ARM: dts: at91: add devicetree for the Axentia TSE-850
ARM: sama5_defconfig: add support for the Axentia TSE-850 board
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
arch/arm/configs/sama5_defconfig | 7 +-
6 files changed, 357 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
--
2.1.4
--
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
* [PATCH v6 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2017-01-10 13:18 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484054314-6244-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
The Axentia TSE-850 is a SAMA5D3-based device designed to generate
FM subcarrier signals.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
5 files changed, 351 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt
new file mode 100644
index 000000000000..ea3fb96ae465
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axentia.txt
@@ -0,0 +1,19 @@
+Device tree bindings for Axentia ARM devices
+============================================
+
+Linea CPU module
+----------------
+
+Required root node properties:
+compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from atmel-at91.txt for a sama5d31 SoC.
+
+
+TSE-850 v3 board
+----------------
+
+Required root node properties:
+compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from above for the axentia,linea CPU module.
diff --git a/MAINTAINERS b/MAINTAINERS
index 97b78cc5aa51..5c2ea6e9cd7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2346,6 +2346,14 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/axentia.txt
+F: arch/arm/boot/dts/at91-linea.dtsi
+F: arch/arm/boot/dts/at91-tse850-3.dts
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab-JsYNTwtnfakRB7SZvlqPiA@public.gmane.org>
M: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9a7375c388a8..7632849866de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ at91-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
new file mode 100644
index 000000000000..0721c8472509
--- /dev/null
+++ b/arch/arm/boot/dts/at91-linea.dtsi
@@ -0,0 +1,49 @@
+/*
+ * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom@51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
new file mode 100644
index 000000000000..669a2c6bdefc
--- /dev/null
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -0,0 +1,274 @@
+/*
+ * at91-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include "at91-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ pinctrl@fffff200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ <AT91_PIOC 31
+ AT91_PERIPH_GPIO
+ AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ watchdog@fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "sck";
+ };
+
+ reg_3v3: regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "3v3-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ana: reg-ana {
+ compatible = "pwm-regulator";
+
+ regulator-name = "ANA";
+
+ pwms = <&pwm0 2 1000 PWM_POLARITY_INVERTED>;
+ pwm-dutycycle-unit = <1000>;
+ pwm-dutycycle-range = <100 1000>;
+
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <20000000>;
+ regulator-ramp-delay = <1000>;
+ };
+
+ sound {
+ compatible = "axentia,tse850-pcm5142";
+
+ axentia,cpu-dai = <&ssc0>;
+ axentia,audio-codec = <&pcm5142>;
+
+ axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
+ axentia,loop1-gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ axentia,loop2-gpios = <&pioA 11 GPIO_ACTIVE_LOW>;
+
+ axentia,ana-supply = <&ana>;
+ };
+
+ dac: dpot-dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&pioA>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "comp";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ch1-red {
+ label = "ch-1:red";
+ gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
+ };
+ ch1-green {
+ label = "ch-1:green";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ };
+ ch2-red {
+ label = "ch-2:red";
+ gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
+ };
+ ch2-green {
+ label = "ch-2:green";
+ gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
+ };
+ data-red {
+ label = "data:red";
+ gpios = <&pioA 19 GPIO_ACTIVE_LOW>;
+ };
+ data-green {
+ label = "data:green";
+ gpios = <&pioA 18 GPIO_ACTIVE_LOW>;
+ };
+ alarm-red {
+ label = "alarm:red";
+ gpios = <&pioA 17 GPIO_ACTIVE_LOW>;
+ };
+ alarm-green {
+ label = "alarm:green";
+ gpios = <&pioA 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&nand0 {
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ barebox@40000 {
+ label = "bootloader";
+ reg = <0x40000 0x60000>;
+ };
+
+ bareboxenv@c0000 {
+ label = "bareboxenv";
+ reg = <0xc0000 0x40000>;
+ };
+
+ bareboxenv2@100000 {
+ label = "bareboxenv2";
+ reg = <0x100000 0x40000>;
+ };
+
+ oftree@180000 {
+ label = "oftree";
+ reg = <0x180000 0x20000>;
+ };
+
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x500000>;
+ };
+
+ rootfs@800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+
+ ovlfs@10000000 {
+ label = "ovlfs";
+ reg = <0x10000000 0x10000000>;
+ };
+};
+
+&ssc0 {
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ jc42@18 {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x18>;
+ };
+
+ dpot: mcp4651-104@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+
+ pcm5142: pcm5142@4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+
+ eeprom@50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&usart0 {
+ status = "okay";
+
+ atmel,use-dma-rx;
+};
+
+&pwm0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_pwm0_pwml2_1>;
+ pinctrl-names = "default";
+};
+
+&macb1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@3 {
+ reg = <3>;
+
+ interrupt-parent = <&pioE>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 31 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ status = "okay";
+
+ num-ports = <1>;
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ atmel,oc-gpio = <&pioC 15 GPIO_ACTIVE_LOW>;
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
--
2.1.4
--
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 related
* [PATCH v6 2/2] ARM: sama5_defconfig: add support for the Axentia TSE-850 board
From: Peter Rosin @ 2017-01-10 13:18 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard, linux-arm-kernel, devicetree
In-Reply-To: <1484054314-6244-1-git-send-email-peda@axentia.se>
The Axentia TSE-850 is a SAMA5D3-based device designed to generate
FM subcarrier signals.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
arch/arm/configs/sama5_defconfig | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index aca8625b6fc9..777c9e986425 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -131,7 +131,7 @@ CONFIG_GPIO_SYSFS=y
CONFIG_POWER_SUPPLY=y
CONFIG_BATTERY_ACT8945A=y
CONFIG_POWER_RESET=y
-# CONFIG_HWMON is not set
+CONFIG_SENSORS_JC42=m
CONFIG_WATCHDOG=y
CONFIG_AT91SAM9X_WATCHDOG=y
CONFIG_SAMA5D4_WATCHDOG=y
@@ -142,6 +142,7 @@ CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_ACT8865=y
CONFIG_REGULATOR_ACT8945A=y
+CONFIG_REGULATOR_PWM=m
CONFIG_MEDIA_SUPPORT=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_V4L_PLATFORM_DRIVERS=y
@@ -164,6 +165,7 @@ CONFIG_SND_ATMEL_SOC=y
CONFIG_SND_ATMEL_SOC_WM8904=y
# CONFIG_HID_GENERIC is not set
CONFIG_SND_ATMEL_SOC_PDMIC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=m
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_EHCI_HCD=y
@@ -199,6 +201,9 @@ CONFIG_AT_XDMAC=y
CONFIG_IIO=y
CONFIG_AT91_ADC=y
CONFIG_AT91_SAMA5D2_ADC=y
+CONFIG_ENVELOPE_DETECTOR=m
+CONFIG_DPOT_DAC=m
+CONFIG_MCP4531=m
CONFIG_PWM=y
CONFIG_PWM_ATMEL=y
CONFIG_PWM_ATMEL_HLCDC_PWM=y
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v6 0/2] Support for Axentia TSE-850
From: Nicolas Ferre @ 2017-01-10 13:24 UTC (permalink / raw)
To: Peter Rosin, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Russell King, Alexandre Belloni,
Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484054314-6244-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Le 10/01/2017 à 14:18, Peter Rosin a écrit :
> Hi!
>
> changes v5 -> v6
> - drop the &main clock-frequency
> - add some text to the commit messages
> - make config additions modules
Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
for the whole series.
Thanks, best regards,
> changes v4 -> v5
> - comment from Rob about the memory node made me look closer and
> the memory size is actually updated by the bootloader, and that
> hid the fact that the entry was always faulty. This version
> specifies the correct memory size from the start, which is 64MB.
> - ack from Rob
>
> changes v3 -> v4
> - rename files arch/arm/boot/dts/axentia-* to .../at91-*
> - remove bootargs from at91-tse850-3.dts
> - depend on the atmel ssc to register as a sound dai by itself
> - bump copyright years
>
> changes v2 -> v3
> - document the new compatible strings prefixed with "axentia,".
>
> changes v1 -> v2
> - squash the fixup into the correct patch, sorry for the noise.
>
> After finally having all essintial drivers upstreamed I would
> like to have the dts and the defconfig also upstreamed.
>
> The atmel-ssc/sound-dai change depends on a change that has been
> sitting in the ASoC tree since mid-december, and I have been waiting
> for it to hit linux-next before sending this, but it seems to take
> longer than I anticipated. So, since I do not want this to in
> turn miss the next merge window because of that wait I therefore
> request that this is taken now even though it doesn't really work
> w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course
> builds cleanly even w/o those ASoC changes. That effectively means
> that noone besides me should notice the inconsistency (I currently
> have all affected devices under my control).
>
> Cheers,
> peda
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel
>
> Peter Rosin (2):
> ARM: dts: at91: add devicetree for the Axentia TSE-850
> ARM: sama5_defconfig: add support for the Axentia TSE-850 board
>
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
> arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
> arch/arm/configs/sama5_defconfig | 7 +-
> 6 files changed, 357 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>
--
Nicolas Ferre
--
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
* [PATCH 0/3] arm64: dts: Fix DTC warnings for Exynos boards
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
Hello Krzysztof,
This trivial series contains fixes for DTC warnings caused by mismatches
between unit names and reg properties in device tree nodes.
The patches shouldn't cause a functional change but have been just build
tested. I compared the generated DTB though to make sure that only these
nodes changed.
Best regards,
Javier
Javier Martinez Canillas (3):
arm64: dts: Add missing unit name to Exynos7 SoC node
arm64: dts: Add missing unit name to Exynos5433 SoC node
arm64: dts: Remove unneeded unit names in Exynos5433 nodes
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] arm64: dts: Add missing unit name to Exynos7 SoC node
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484054866-3988-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 80aa60e38237..0d2fedc6ac2f 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -69,7 +69,7 @@
method = "smc";
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: Add missing unit name to Exynos5433 SoC node
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484054866-3988-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e5851c..3695ddaf2e04 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -241,7 +241,7 @@
mask = <0x1>;
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: Remove unneeded unit names in Exynos5433 nodes
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484054866-3988-1-git-send-email-javier@osg.samsung.com>
The "samsung,exynos5433-mipi-video-phy" and "samsung,exynos5250-dwusb3"
DT bindings don't specify a reg property for these nodes, so having a
unit name leads to the following DTC warnings:
Node /soc/video-phy@105c0710 has a unit name, but no reg property
Node /soc/usb@15400000 has a unit name, but no reg property
Node /soc/usb@15a00000 has a unit name, but no reg property
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 3695ddaf2e04..17e5dafd392c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -706,7 +706,7 @@
interrupts = <GIC_PPI 9 0xf04>;
};
- mipi_phy: video-phy@105c0710 {
+ mipi_phy: video-phy {
compatible = "samsung,exynos5433-mipi-video-phy";
#phy-cells = <1>;
samsung,pmu-syscon = <&pmu_system_controller>;
@@ -1285,7 +1285,7 @@
status = "disabled";
};
- usbdrd30: usb@15400000 {
+ usbdrd30: usb-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
<&cmu_fsys CLK_SCLK_USBDRD30>;
@@ -1332,7 +1332,7 @@
status = "disabled";
};
- usbhost30: usb@15a00000 {
+ usbhost30: usb-1 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBHOST30>,
<&cmu_fsys CLK_SCLK_USBHOST30>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/1] ARM: dts: add Armadeus Systems OPOS6UL and OPOS6ULDEV support
From: Sébastien Szymanski @ 2017-01-10 13:32 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Russell King, linux-kernel, Rob Herring,
Sascha Hauer, Fabio Estevam, Julien Boibessot, Shawn Guo
OPOS6UL is an i.MX6UL based SoM.
OPOS6ULDev is a carrier board for the OPOS6UL SoM.
For more details see:
http://www.opossom.com/english/products-processor_boards-opos6ul.html
http://www.opossom.com/english/products-development_boards-opos6ul_dev.html
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
---
Changes since v1:
- use "and" instead of "AND" in the subject patch.
- use "uart-has-rtscts" instead of "fsl,uart-has-rtscts".
- use "backlight" instead of "lcd_backlight".
- use hyphen for node names.
- sort correctly pwm3 node and pwm3grp node.
- drop "fsl,spi-num-chipselects" property.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-opos6ul.dtsi | 192 +++++++++++++++
arch/arm/boot/dts/imx6ul-opos6uldev.dts | 412 ++++++++++++++++++++++++++++++++
3 files changed, 605 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-opos6ul.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-opos6uldev.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..f839c75 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -435,6 +435,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
imx6ul-geam-kit.dtb \
imx6ul-liteboard.dtb \
+ imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-opos6ul.dtsi b/arch/arm/boot/dts/imx6ul-opos6ul.dtsi
new file mode 100644
index 0000000..51095df
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-opos6ul.dtsi
@@ -0,0 +1,192 @@
+/*
+ * Copyright 2017 Armadeus Systems <support@armadeus.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ memory {
+ reg = <0x80000000 0>; /* will be filled by U-Boot */
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-reset-duration = <1>;
+ phy-reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
+ phy-handle = <ðphy1>;
+ phy-supply = <®_3v3>;
+ status = "okay";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+ status = "okay";
+ };
+ };
+};
+
+/* Bluetooth */
+&uart8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart8>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ bus-width = <4>;
+ no-1-8-v;
+ non-removable;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcmf: bcrmf@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "host-wake";
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x130b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x130b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x130b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x130b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ /* INT# */
+ MX6UL_PAD_NAND_DQS__GPIO4_IO16 0x1b0b0
+ /* RST# */
+ MX6UL_PAD_NAND_DATA00__GPIO4_IO02 0x130b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart8: uart8grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_TX_EN__UART8_DCE_RX 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA1__UART8_DCE_TX 0x1b0b0
+ MX6UL_PAD_ENET2_RX_ER__UART8_DCE_RTS 0x1b0b0
+ MX6UL_PAD_ENET2_TX_CLK__UART8_DCE_CTS 0x1b0b0
+ /* BT_REG_ON */
+ MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10 0x130b0
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ MX6UL_PAD_NAND_READY_B__USDHC1_DATA4 0x17059
+ MX6UL_PAD_NAND_CE0_B__USDHC1_DATA5 0x17059
+ MX6UL_PAD_NAND_CE1_B__USDHC1_DATA6 0x17059
+ MX6UL_PAD_NAND_CLE__USDHC1_DATA7 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_DATA18__USDHC2_CMD 0x1b0b0
+ MX6UL_PAD_LCD_DATA19__USDHC2_CLK 0x100b0
+ MX6UL_PAD_LCD_DATA20__USDHC2_DATA0 0x1b0b0
+ MX6UL_PAD_LCD_DATA21__USDHC2_DATA1 0x1b0b0
+ MX6UL_PAD_LCD_DATA22__USDHC2_DATA2 0x1b0b0
+ MX6UL_PAD_LCD_DATA23__USDHC2_DATA3 0x1b0b0
+ /* WL_REG_ON */
+ MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 0x130b0
+ /* WL_IRQ */
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x1b0b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-opos6uldev.dts b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
new file mode 100644
index 0000000..0e59ee5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
@@ -0,0 +1,412 @@
+/*
+ * Copyright 2017 Armadeus Systems <support@armadeus.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6ul-opos6ul.dtsi"
+
+/ {
+ model = "Armadeus Systems OPOS6UL SoM on OPOS6ULDev board";
+ compatible = "armadeus,opos6uldev", "armadeus,opos6ul", "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm3 0 191000>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ power-supply = <®_5v>;
+ status = "okay";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ user-button {
+ label = "User button";
+ gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_MISC>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ user-led {
+ label = "User";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+ gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ onewire {
+ compatible = "w1-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_w1>;
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbotg1_vbus: regulator-usbotg1vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usbotg1vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1_vbus>;
+ gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usbotg2_vbus: regulator-usbotg2vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usbotg2vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg2_vbus>;
+ gpio = <&gpio5 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&adc1 {
+ vref-supply = <®_3v3>;
+ status = "okay";
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_5v>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ xceiver-supply = <®_5v>;
+ status = "okay";
+};
+
+&ecspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi4>;
+ cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>, <&gpio4 3 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ spidev0: spi@0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ };
+
+ spidev1: spi@1 {
+ compatible = "spidev";
+ reg = <1>;
+ spi-max-frequency = <5000000>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock_frequency = <400000>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock_frequency = <400000>;
+ status = "okay";
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ display = <&display0>;
+ lcd-supply = <®_3v3>;
+ status = "okay";
+
+ display0: display0 {
+ bits-per-pixel = <32>;
+ bus-width = <18>;
+
+ display-timings {
+ timing0: timing0 {
+ clock-frequency = <33000033>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <96>;
+ hfront-porch = <96>;
+ vback-porch = <20>;
+ vfront-porch = <21>;
+ hsync-len = <64>;
+ vsync-len = <4>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "disabled";
+};
+
+&tsc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc>;
+ xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+ measure-delay-time = <0xffff>;
+ pre-charge-time = <0xffff>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1_id>;
+ vbus-supply = <®_usbotg1_vbus>;
+ dr_mode = "otg";
+ disable-over-current;
+ status = "okay";
+};
+
+&usbotg2 {
+ vbus-supply = <®_usbotg2_vbus>;
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpios>;
+
+ pinctrl_ecspi4: ecspi4grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_DATA04__ECSPI4_SCLK 0x1b0b0
+ MX6UL_PAD_NAND_DATA05__ECSPI4_MOSI 0x1b0b0
+ MX6UL_PAD_NAND_DATA06__ECSPI4_MISO 0x1b0b0
+ MX6UL_PAD_NAND_DATA01__GPIO4_IO03 0x1b0b0
+ MX6UL_PAD_NAND_DATA07__GPIO4_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART3_CTS_B__FLEXCAN1_TX 0x0b0b0
+ MX6UL_PAD_UART3_RTS_B__FLEXCAN1_RX 0x0b0b0
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX 0x0b0b0
+ MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX 0x0b0b0
+ >;
+ };
+
+ pinctrl_gpios: gpiosgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x0b0b0
+ MX6UL_PAD_UART3_RX_DATA__GPIO1_IO25 0x0b0b0
+ MX6UL_PAD_UART3_TX_DATA__GPIO1_IO24 0x0b0b0
+ MX6UL_PAD_NAND_RE_B__GPIO4_IO00 0x0b0b0
+ MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0x0b0b0
+ MX6UL_PAD_UART1_CTS_B__GPIO1_IO18 0x0b0b0
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x0b0b0
+ MX6UL_PAD_NAND_WE_B__GPIO4_IO01 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x0b0b0
+ >;
+ };
+
+ pinctrl_gpio_keys: gpiokeysgrp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x0b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+ MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
+ MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
+ >;
+ };
+
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x100b1
+ MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x100b1
+ MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x100b1
+ MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x100b1
+ MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x100b1
+ MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x100b1
+ MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x100b1
+ MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x100b1
+ MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x100b1
+ MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x100b1
+ MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x100b1
+ MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x100b1
+ MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x100b1
+ MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x100b1
+ MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x100b1
+ MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x100b1
+ MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x100b1
+ MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x100b1
+ MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x100b1
+ MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x100b1
+ MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x100b1
+ MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x100b1
+ >;
+ };
+
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_RESET__GPIO3_IO04 0x0b0b0
+ >;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_ALE__PWM3_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_tsc: tscgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0xb0
+ MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0
+ MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0xb0
+ MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0xb0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_TX_DATA__UART2_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART2_RX_DATA__UART2_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg1_id: usbotg1idgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID 0x1b0b0
+ >;
+ };
+
+ pinctrl_usbotg1_vbus: usbotg1vbusgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO05__GPIO1_IO05 0x1b0b0
+ >;
+ };
+
+ pinctrl_usbotg2_vbus: usbotg2vbusgrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_w1: w1grp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x0b0b0
+ >;
+ };
+};
--
2.7.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: add BananaPi-M64 support
From: kbuild test robot @ 2017-01-10 13:37 UTC (permalink / raw)
To: Andre Przywara
Cc: kbuild-all-JC7UmRfGjtg, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484011353-21480-4-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
Hi Andre,
[auto build test ERROR on mripard/sunxi/for-next]
[also build test ERROR on next-20170110]
[cannot apply to robh/for-next v4.10-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andre-Przywara/arm64-dts-A64-board-MMC-support/20170110-124554
base: https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git sunxi/for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts:80.1-6 Label or path mmc0 not found
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts:91.1-6 Label or path mmc1 not found
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts:100.1-6 Label or path mmc2 not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33694 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: da850: Add the cppi41 dma node
From: Alexandre Bailon @ 2017-01-10 13:45 UTC (permalink / raw)
To: Sergei Shtylyov, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0, david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <811adb6b-00e4-bbc4-d6f5-7bf3ba85ab63-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On 01/09/2017 07:26 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 01/09/2017 07:24 PM, Alexandre Bailon wrote:
>
>> This adds the device tree node for the cppi41 dma
>> used by the usb otg controller present in the da850 family of SoC's.
>>
>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 104155d..d6b406a 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -403,6 +403,22 @@
>> phy-names = "usb-phy";
>> status = "disabled";
>> };
>> + cppi41dma: dma-controller@201000 {
>> + compatible = "ti,da8xx-cppi41";
>> + reg = <0x200000 0x1000
>
> I don't remember any DA8xx glue regs having to do with the CPPI 4.1...
The CPPI 4.1 driver need it to manage the IRQ.
>
>> + 0x201000 0x1000
>> + 0x202000 0x1000
>> + 0x204000 0x4000>;
>> + reg-names = "glue", "controller",
>> + "scheduler", "queuemgr";
>> + interrupts = <58>;
>> + interrupt-names = "glue";
>> + #dma-cells = <2>;
>> + #dma-channels = <4>;
>> + #dma-requests = <256>;
>> + status = "disabled";
>
> Why disabled? It doesn't use any external pins...
Will fix it.
>
> [...]
>
> MBR, Sergei
>
--
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 v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang @ 2017-01-10 13:59 UTC (permalink / raw)
To: Sean Young
Cc: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg, andi.shyti, hverkuil, ivo.g.dimitrov.75,
linux-media, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede
In-Reply-To: <20170110110943.GA24889@gofer.mess.org>
On Tue, 2017-01-10 at 11:09 +0000, Sean Young wrote:
> > +#include <linux/clk.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/module.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/reset.h>
> > +#include <media/rc-core.h>
> > +
> > +#define MTK_IR_DEV KBUILD_MODNAME
>
> You could remove this #define and just use KBUILD_MODNAME
I preferred to use MTK_IR_DEV internally that helps
renaming in the future if necessary.
>
> > +
> > +/* Register to enable PWM and IR */
> > +#define MTK_CONFIG_HIGH_REG 0x0c
> > +/* Enable IR pulse width detection */
> > +#define MTK_PWM_EN BIT(13)
> > +/* Enable IR hardware function */
> > +#define MTK_IR_EN BIT(0)
> > +
> > +/* Register to setting sample period */
> > +#define MTK_CONFIG_LOW_REG 0x10
> > +/* Field to set sample period */
> > +#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
> > + MTK_IR_CLK_PERIOD)
> > +#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> > +#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
> > +
> > +/* Register to clear state of state machine */
> > +#define MTK_IRCLR_REG 0x20
> > +/* Bit to restart IR receiving */
> > +#define MTK_IRCLR BIT(0)
> > +
> > +/* Register containing pulse width data */
> > +#define MTK_CHKDATA_REG(i) (0x88 + 4 * (i))
> > +#define MTK_WIDTH_MASK (GENMASK(7, 0))
> > +
> > +/* Register to enable IR interrupt */
> > +#define MTK_IRINT_EN_REG 0xcc
> > +/* Bit to enable interrupt */
> > +#define MTK_IRINT_EN BIT(0)
> > +
> > +/* Register to ack IR interrupt */
> > +#define MTK_IRINT_CLR_REG 0xd0
> > +/* Bit to clear interrupt status */
> > +#define MTK_IRINT_CLR BIT(0)
> > +
> > +/* Maximum count of samples */
> > +#define MTK_MAX_SAMPLES 0xff
> > +/* Indicate the end of IR message */
> > +#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
> > +/* Number of registers to record the pulse width */
> > +#define MTK_CHKDATA_SZ 17
> > +/* Source clock frequency */
> > +#define MTK_IR_BASE_CLK 273000000
> > +/* Frequency after IR internal divider */
> > +#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
> > +static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
> > +{
> > + struct mtk_ir *ir = dev_id;
> > + u8 wid = 0;
> > + u32 i, j, val;
> > + DEFINE_IR_RAW_EVENT(rawir);
> > +
> > + mtk_irq_disable(ir, MTK_IRINT_EN);
>
> The kernel guarantees that calls to the interrupt handler are serialised,
> no need to disable the interrupt in the handler.
agreed. I will save the mtk irq disable/enable and retest again.
> > +
> > + /* Reset decoder state machine */
> > + ir_raw_event_reset(ir->rc);
>
> Not needed.
two reasons I added the line here
1)
I thought it is possible the decoder goes to the
middle state when getting the data not belonged
to the protocol. If so, that would cause the decoding
fails in the next time receiving the valid protocol data.
2)
the mtk hardware register always contains the start of
IR message. So force to sync the state between
HW and ir-core.
> > +
> > + /* First message must be pulse */
> > + rawir.pulse = false;
>
> pulse = true?
becasue of rawir.pulse = !rawir.pulse does as below
so the initial value is set as false.
> > +
> > + /* Handle all pulse and space IR controller captures */
> > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > +
> > + for (j = 0 ; j < 4 ; j++) {
> > + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> > + rawir.pulse = !rawir.pulse;
> > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > + }
>
> In v1 you would break out of the loop if the ir message was shorter, but
> now you are always passing on 68 pulses and spaces. Is that right?
as I asked in the previous mail list as below i copied from it, so i
made some changes ...
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> I had another question. I found multiple and same IR messages being
> received when using SONY remote controller. Should driver needs to
> report each message or only one of these to the upper layer ?
In general the driver shouldn't try to change any IR message, this
should be done in rc-core if necessary.
rc-core should handle this correctly. If the same key is received twice
within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
layer.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
for example:
the 68 pulse/spaces might contains 2.x IR messages when I
pressed one key on SONY remote control.
the v1 proposed is passing only one IR message into ir-core ;
the v2 done is passing all IR messages even including the last
incomplete message into ir-core.
But I was still afraid the state machine can't go back to initial state
after receiving these incomplete data.
So the ir_raw_event_reset() call in the beginning of ISR seems becoming
more important.
> > + }
> > +
> > + /* The maximum number of edges the IR controller can
> > + * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
> > + * is over the limit, the last incomplete IR message would
> > + * be appended trailing space and still would be sent into
> > + * ir-rc-raw to decode. That helps it is possible that it
> > + * has enough information to decode a scancode even if the
> > + * trailing end of the message is missing.
> > + */
> > + if (!MTK_IR_END(wid, rawir.pulse)) {
> > + rawir.pulse = false;
> > + rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > + }
> > +
> > + ir_raw_event_handle(ir->rc);
> > +
> > + /* Restart controller for the next receive */
> > + mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
> > +
> > + /* Clear interrupt status */
> > + mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
> > +
> > + /* Enable interrupt */
> > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int mtk_ir_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *dn = dev->of_node;
> > + struct resource *res;
> > + struct mtk_ir *ir;
> > + u32 val;
> > + int ret = 0;
> > + const char *map_name;
> > +
> > + ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
> > + if (!ir)
> > + return -ENOMEM;
> > +
> > + ir->dev = dev;
> > +
> > + if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
> > + return -ENODEV;
> > +
> > + ir->clk = devm_clk_get(dev, "clk");
> > + if (IS_ERR(ir->clk)) {
> > + dev_err(dev, "failed to get a ir clock.\n");
> > + return PTR_ERR(ir->clk);
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + ir->base = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(ir->base)) {
> > + dev_err(dev, "failed to map registers\n");
> > + return PTR_ERR(ir->base);
> > + }
> > +
> > + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> > + if (!ir->rc) {
> > + dev_err(dev, "failed to allocate device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + ir->rc->priv = ir;
> > + ir->rc->input_name = MTK_IR_DEV;
> > + ir->rc->input_phys = MTK_IR_DEV "/input0";
> > + ir->rc->input_id.bustype = BUS_HOST;
> > + ir->rc->input_id.vendor = 0x0001;
> > + ir->rc->input_id.product = 0x0001;
> > + ir->rc->input_id.version = 0x0001;
> > + map_name = of_get_property(dn, "linux,rc-map-name", NULL);
> > + ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
> > + ir->rc->dev.parent = dev;
> > + ir->rc->driver_name = MTK_IR_DEV;
> > + ir->rc->allowed_protocols = RC_BIT_ALL;
> > + ir->rc->rx_resolution = MTK_IR_SAMPLE;
> > + ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > +
> > + ret = devm_rc_register_device(dev, ir->rc);
>
> Here you do devm_rc_register_device()
does it have problem ?
> > + if (ret) {
> > + dev_err(dev, "failed to register rc device\n");
> > + return ret;
> > + }
> > +
> > + platform_set_drvdata(pdev, ir);
> > +
> > + ir->irq = platform_get_irq(pdev, 0);
> > + if (ir->irq < 0) {
> > + dev_err(dev, "no irq resource\n");
> > + return -ENODEV;
> > + }
> > +
> > + /* Enable interrupt after proper hardware
> > + * setup and IRQ handler registration
> > + */
> > + if (clk_prepare_enable(ir->clk)) {
> > + dev_err(dev, "try to enable ir_clk failed\n");
> > + ret = -EINVAL;
> > + goto exit_clkdisable_clk;
> > + }
> > +
> > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > +
> > + ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
> > + if (ret) {
> > + dev_err(dev, "failed request irq\n");
> > + goto exit_clkdisable_clk;
> > + }
> > +
> > + /* Enable IR and PWM */
> > + val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
> > + val |= MTK_PWM_EN | MTK_IR_EN;
> > + mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
> > +
> > + /* Setting sample period */
> > + mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
> > + MTK_CONFIG_LOW_REG);
> > +
> > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > +
> > + dev_info(dev, "Initialized MT7623 IR driver, sample period = %luus\n",
> > + DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
> > +
> > + return 0;
> > +
> > +exit_clkdisable_clk:
> > + clk_disable_unprepare(ir->clk);
> > +
> > + return ret;
> > +}
> > +
> > +static int mtk_ir_remove(struct platform_device *pdev)
> > +{
> > + struct mtk_ir *ir = platform_get_drvdata(pdev);
> > +
> > + /* Avoid contention between remove handler and
> > + * IRQ handler so that disabling IR interrupt and
> > + * waiting for pending IRQ handler to complete
> > + */
> > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > + synchronize_irq(ir->irq);
> > +
> > + clk_disable_unprepare(ir->clk);
> > +
> > + rc_unregister_device(ir->rc);
>
> Yet here you explicitly call rc_unregister_device(). Since it was registered
> with the devm call, this call is not needed and will lead to double frees etc
bug :( . I will fix it ..
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id mtk_ir_match[] = {
> > + { .compatible = "mediatek,mt7623-cir" },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_ir_match);
> > +
> > +static struct platform_driver mtk_ir_driver = {
> > + .probe = mtk_ir_probe,
> > + .remove = mtk_ir_remove,
> > + .driver = {
> > + .name = MTK_IR_DEV,
> > + .of_match_table = mtk_ir_match,
> > + },
> > +};
> > +
> > +module_platform_driver(mtk_ir_driver);
> > +
> > +MODULE_DESCRIPTION("Mediatek IR Receiver Controller Driver");
> > +MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.7.4
> >
^ permalink raw reply
* Re: [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: Maxime Ripard @ 2017-01-10 14:06 UTC (permalink / raw)
To: André Przywara
Cc: Rob Herring, Ulf Hansson, Chen-Yu Tsai, Hans De Goede,
Icenowy Zheng, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87b26848-4f86-f2d2-3f82-db0937c572e2-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]
On Thu, Jan 05, 2017 at 11:33:28PM +0000, André Przywara wrote:
> On 05/01/17 17:57, Maxime Ripard wrote:
> > Hi Rob,
> >
> > On Wed, Jan 04, 2017 at 08:07:50AM -0600, Rob Herring wrote:
> >> On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
> >>> From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >>>
> >>> Unlike the A64 user manual reports, the third MMC controller on the
> >>> A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
> >>> DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
> >>> This does not affect the other two controllers, so introduce a new
> >>> DT compatible string to let the driver use different settings for that
> >>> particular device. This will also help to enable the high-speed transfer
> >>> modes of that controller later.
> >>>
> >>> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> >>> ---
> >>> Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
> >>> drivers/mmc/host/sunxi-mmc.c | 7 +++++++
> >>> 2 files changed, 8 insertions(+)
> >>
> >> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > Some kind of a digression on this: we have three MMC controllers on
> > this SoC. Like this patch shows, the third one is clearly different,
> > and supports both more modes, a wider bus, and specific quirks. We
> > need a new compatible for this one, everything's perfect.
> >
> > However, the other two are mostly the same, but seems to need
> > different tuning parameters to get more performances out of the
> > controller (but this is unclear yet). How do we usually deal with
> > that?
>
> I guess you wanted to hear Rob's opinion ;-), but "get more performance"
> sounds like we add one (or more) properties to tune those values.
> If I get this right, it works with default values, but is sub-optimal?
That would be my understanding too, at least, it works in a decent way
without fiddling with those parameters.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Geert Uytterhoeven @ 2017-01-10 14:08 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linus Walleij, Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Linux-Renesas
In-Reply-To: <20161227172003.6517-2-tony@atomide.com>
Hi Tony,
On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren <tony@atomide.com> wrote:
> Having the pin control framework call pin controller functions
> before it's probe has finished is not nice as the pin controller
> device driver does not yet have struct pinctrl_dev handle.
>
> Let's fix this issue by adding deferred work for late init. This is
> needed to be able to add pinctrl generic helper functions that expect
> to know struct pinctrl_dev handle. Note that we now need to call
> create_pinctrl() directly as we don't want to add the pin controller
> to the list of controllers until the hogs are claimed. We also need
> to pass the pinctrl_dev to the device tree parser functions as they
> otherwise won't find the right controller at this point.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
I believe this patch causes a regression on r8a7740/armadillo, where the
pin controller is also a GPIO controller, and lcd0 needs a hog
(cfr. arch/arm/boot/dts/r8a7740-armadillo800eva.dts):
-GPIO line 176 (lcd0) hogged as output/high
-sh-pfc e6050000.pfc: r8a7740_pfc handling gpio 0 -> 211
+gpiochip_add_data: GPIOs 0..211 (r8a7740_pfc) failed to register
+sh-pfc e6050000.pfc: failed to init GPIO chip, ignoring...
sh-pfc e6050000.pfc: r8a7740_pfc support registered
Hence all drivers using GPIOs fail to initialize because their GPIOs never
become available.
Adding debug prints to the failure paths shows that the call to
of_pinctrl_get() in of_gpiochip_add_pin_range() fails with -EPROBE_DEFER.
Adding a debug print to the top of gpiochip_add_data() makes the problem go
away, presumably because it introduces a delay that allows the delayed work
to kick in...
Jon's fix ("pinctrl: core: Fix panic when pinctrl devices with hogs are
unregistered") doesn't help, as it affects unregistration only.
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -1800,32 +1847,10 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
> goto out_err;
> }
>
> - mutex_lock(&pinctrldev_list_mutex);
> - list_add_tail(&pctldev->node, &pinctrldev_list);
> - mutex_unlock(&pinctrldev_list_mutex);
> -
> - pctldev->p = pinctrl_get(pctldev->dev);
> -
> - if (!IS_ERR(pctldev->p)) {
> - pctldev->hog_default =
> - pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
> - if (IS_ERR(pctldev->hog_default)) {
> - dev_dbg(dev, "failed to lookup the default state\n");
> - } else {
> - if (pinctrl_select_state(pctldev->p,
> - pctldev->hog_default))
> - dev_err(dev,
> - "failed to select default state\n");
> - }
> -
> - pctldev->hog_sleep =
> - pinctrl_lookup_state(pctldev->p,
> - PINCTRL_STATE_SLEEP);
> - if (IS_ERR(pctldev->hog_sleep))
> - dev_dbg(dev, "failed to lookup the sleep state\n");
> - }
> -
> - pinctrl_init_device_debugfs(pctldev);
> + if (pinctrl_dt_has_hogs(pctldev))
Changing the above line to "if (0 && pinctrl_dt_has_hogs(pctldev))"
fixes the issue for me.
> + schedule_delayed_work(&pctldev->late_init, 0);
> + else
> + pinctrl_late_init(&pctldev->late_init.work);
>
> return pctldev;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 0/2] Support for Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 15:17 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Russell King, Nicolas Ferre, Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484054314-6244-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 10/01/2017 at 14:18:32 +0100, Peter Rosin wrote :
> Hi!
>
> changes v5 -> v6
> - drop the &main clock-frequency
> - add some text to the commit messages
> - make config additions modules
>
> changes v4 -> v5
> - comment from Rob about the memory node made me look closer and
> the memory size is actually updated by the bootloader, and that
> hid the fact that the entry was always faulty. This version
> specifies the correct memory size from the start, which is 64MB.
> - ack from Rob
>
> changes v3 -> v4
> - rename files arch/arm/boot/dts/axentia-* to .../at91-*
> - remove bootargs from at91-tse850-3.dts
> - depend on the atmel ssc to register as a sound dai by itself
> - bump copyright years
>
> changes v2 -> v3
> - document the new compatible strings prefixed with "axentia,".
>
> changes v1 -> v2
> - squash the fixup into the correct patch, sorry for the noise.
>
> After finally having all essintial drivers upstreamed I would
> like to have the dts and the defconfig also upstreamed.
>
> The atmel-ssc/sound-dai change depends on a change that has been
> sitting in the ASoC tree since mid-december, and I have been waiting
> for it to hit linux-next before sending this, but it seems to take
> longer than I anticipated. So, since I do not want this to in
> turn miss the next merge window because of that wait I therefore
> request that this is taken now even though it doesn't really work
> w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course
> builds cleanly even w/o those ASoC changes. That effectively means
> that noone besides me should notice the inconsistency (I currently
> have all affected devices under my control).
>
> Cheers,
> peda
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel
>
> Peter Rosin (2):
> ARM: dts: at91: add devicetree for the Axentia TSE-850
> ARM: sama5_defconfig: add support for the Axentia TSE-850 board
>
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
> arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
> arch/arm/configs/sama5_defconfig | 7 +-
> 6 files changed, 357 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>
Both applied, thanks!
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 08/11] dmaengine: cppi41: Implement the glue for da8xx
From: Alexandre Bailon @ 2017-01-10 15:22 UTC (permalink / raw)
To: Sekhar Nori, Grygorii Strashko, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <53a40635-2652-64fc-b20d-1cd6d813eacb-l0cyMroinI0@public.gmane.org>
On 01/10/2017 11:05 AM, Sekhar Nori wrote:
> On Tuesday 10 January 2017 03:08 PM, Alexandre Bailon wrote:
>> On 01/09/2017 07:08 PM, Grygorii Strashko wrote:
>>>
>>>
>>> On 01/09/2017 10:06 AM, Alexandre Bailon wrote:
>>>> The da8xx has a cppi41 dma controller.
>>>> This is add the glue layer required to make it work on da8xx,
>>>> as well some changes in driver (e.g to manage clock).
>>>>
>>>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>> drivers/dma/cppi41.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 95 insertions(+)
>>>>
>>>> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
>>>> index 939398e..4318e53 100644
>>>> --- a/drivers/dma/cppi41.c
>>>> +++ b/drivers/dma/cppi41.c
>>>> @@ -1,3 +1,4 @@
>>>> +#include <linux/clk.h>
>>>> #include <linux/delay.h>
>>>> #include <linux/dmaengine.h>
>>>> #include <linux/dma-mapping.h>
>>>> @@ -86,10 +87,19 @@
>>>>
>>>> #define USBSS_IRQ_PD_COMP (1 << 2)
>>>>
>>>> +/* USB DA8XX */
>>>> +#define DA8XX_INTR_SRC_MASKED 0x38
>>>> +#define DA8XX_END_OF_INTR 0x3c
>>>> +
>>>> +#define DA8XX_QMGR_PENDING_MASK (0xf << 24)
>>>> +
>>>> +
>>>> +
>>>> /* Packet Descriptor */
>>>> #define PD2_ZERO_LENGTH (1 << 19)
>>>>
>>>> #define AM335X_CPPI41 0
>>>> +#define DA8XX_CPPI41 1
>>>>
>>>> struct cppi41_channel {
>>>> struct dma_chan chan;
>>>> @@ -158,6 +168,9 @@ struct cppi41_dd {
>>>>
>>>> /* context for suspend/resume */
>>>> unsigned int dma_tdfdq;
>>>> +
>>>> + /* da8xx clock */
>>>> + struct clk *clk;
>>>> };
>>>>
>>>> static struct chan_queues am335x_usb_queues_tx[] = {
>>>> @@ -232,6 +245,20 @@ static const struct chan_queues am335x_usb_queues_rx[] = {
>>>> [29] = { .submit = 30, .complete = 155},
>>>> };
>>>>
>>>> +static const struct chan_queues da8xx_usb_queues_tx[] = {
>>>> + [0] = { .submit = 16, .complete = 24},
>>>> + [1] = { .submit = 18, .complete = 24},
>>>> + [2] = { .submit = 20, .complete = 24},
>>>> + [3] = { .submit = 22, .complete = 24},
>>>> +};
>>>> +
>>>> +static const struct chan_queues da8xx_usb_queues_rx[] = {
>>>> + [0] = { .submit = 1, .complete = 26},
>>>> + [1] = { .submit = 3, .complete = 26},
>>>> + [2] = { .submit = 5, .complete = 26},
>>>> + [3] = { .submit = 7, .complete = 26},
>>>> +};
>>>> +
>>>> struct cppi_glue_infos {
>>>> irqreturn_t (*isr)(int irq, void *data);
>>>> const struct chan_queues *queues_rx;
>>>> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq, void *data)
>>>> return cppi41_irq(cdd);
>>>> }
>>>>
>>>> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
>>>> +{
>>>> + struct cppi41_dd *cdd = data;
>>>> + u32 status;
>>>> + u32 usbss_status;
>>>> +
>>>> + status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
>>>> + if (status & DA8XX_QMGR_PENDING_MASK)
>>>> + cppi41_irq(cdd);
>>>> + else
>>>> + return IRQ_NONE;
>>>> +
>>>> + /* Re-assert IRQ if there no usb core interrupts pending */
>>>> + usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
>>>> + if (!usbss_status)
>>>> + cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
>>>> +
>>>> + return IRQ_HANDLED;
>>>> +}
>>>> +
>>>> static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
>>>> {
>>>> dma_cookie_t cookie;
>>>> @@ -972,8 +1019,19 @@ static const struct cppi_glue_infos am335x_usb_infos = {
>>>> .platform = AM335X_CPPI41,
>>>> };
>>>>
>>>> +static const struct cppi_glue_infos da8xx_usb_infos = {
>>>> + .isr = da8xx_cppi41_irq,
>>>> + .queues_rx = da8xx_usb_queues_rx,
>>>> + .queues_tx = da8xx_usb_queues_tx,
>>>> + .td_queue = { .submit = 31, .complete = 0 },
>>>> + .first_completion_queue = 24,
>>>> + .qmgr_num_pend = 2,
>>>> + .platform = DA8XX_CPPI41,
>>>> +};
>>>> +
>>>> static const struct of_device_id cppi41_dma_ids[] = {
>>>> { .compatible = "ti,am3359-cppi41", .data = &am335x_usb_infos},
>>>> + { .compatible = "ti,da8xx-cppi41", .data = &da8xx_usb_infos},
>>>> {},
>>>> };
>>>> MODULE_DEVICE_TABLE(of, cppi41_dma_ids);
>>>> @@ -995,6 +1053,13 @@ static int is_am335x_cppi41(struct device *dev)
>>>> return cdd->platform == AM335X_CPPI41;
>>>> }
>>>>
>>>> +static int is_da8xx_cppi41(struct device *dev)
>>>> +{
>>>> + struct cppi41_dd *cdd = dev_get_drvdata(dev);
>>>> +
>>>> + return cdd->platform == DA8XX_CPPI41;
>>>> +}
>>>> +
>>>> #define CPPI41_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
>>>> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
>>>> BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
>>>> @@ -1058,6 +1123,21 @@ static int cppi41_dma_probe(struct platform_device *pdev)
>>>> cdd->first_completion_queue = glue_info->first_completion_queue;
>>>> cdd->platform = glue_info->platform;
>>>>
>>>> + if (is_da8xx_cppi41(dev)) {
>>>> + cdd->clk = devm_clk_get(&pdev->dev, "usb20");
>>>> + ret = PTR_ERR_OR_ZERO(cdd->clk);
>>>> + if (ret) {
>>>> + dev_err(&pdev->dev, "failed to get clock\n");
>>>> + goto err_clk_en;
>>>> + }
>>>> +
>>>> + ret = clk_prepare_enable(cdd->clk);
>>>> + if (ret) {
>>>> + dev_err(dev, "failed to enable clock\n");
>>>> + goto err_clk_en;
>>>> + }
>>>> + }
>>>
>>> if this is functional clock then why not to use ./arch/arm/mach-davinci/pm_domain.c ?
>>> wouldn't it work for use if you will just rename "usb20" -> "fck" -
>>> so PM runtime should manage this clock for you?
>> As is, I don't think it will work.
>> The usb20 is shared by the cppi41 and the usb otg.
>> So, if we rename "usb20" to "fck", clk_get() won't be able to find the
>> clock.
>> But may be adding "usb20" to "con_ids" in
>> arch/arm/mach-davinci/pm_domain.c could work.
>> But I think it will require some changes in da8xx musb driver.
>> I will take look.
>
> On DA8xx, CPPI 4.1 DMAengine is not an independent system resource, but
> embedded within the USB 2.0 controller. So, I think all that is needed
> is for MUSB DA8xx glue to trigger probe of CPPI 4.1 dmaengine driver
> when it is ready. I am not sure all this DA850-specific clock handling
> is really necessary.
Actually, we have a circular dependency.
USB core tries to get DMA channels during the probe, which fails because
CPPI 4.1 driver is not ready.
But it will never be ready because the USB clock must be enabled before
DMA driver probe, what will not happen because USB driver have disabled
the clock when probe failed.
Someone in the office suggested me to use the component API,
that could help me to probe the DMA from the USB probe.
Another way to workaround the dependency would be to do defer the
function calls that access to hardware to avoid to control clock from
DMA driver.
>
> Even in DT, the CPPI 4.1 node should be a child node of USB 2.0 node.
I agree, it should a child but it would require some changes in CPPI 4.1
driver. But except to have a better hardware description, I don't see
any benefit to do it.
>
> Thanks,
> sekhar
>
Thanks,
Alexandre
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH 0/2] iio: distance: srf08: add IIO driver for us ranger
From: Andreas Klinger @ 2017-01-10 15:26 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
trivial, mranostay, linux-i2c, devicetree
Cc: ak
This patch series adds IIO driver support for srf08 ultrasonic ranger
devices.
The first patch add a trivial device tree binding for the device together
with a new vendor devantech.
The second patch is the IIO driver which in turn is using I2C to talk to
the device.
Documentation about the sensor can be found here:
http://www.robot-electronics.co.uk/htm/srf08tech.html
Andreas Klinger (2):
iio: distance: srf08: add trivial DT binding
iio: distance: srf08: add IIO driver for srf08
.../devicetree/bindings/i2c/trivial-devices.txt | 1 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/proximity/Kconfig | 15 +
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/srf08.c | 345 +++++++++++++++++++++
5 files changed, 363 insertions(+)
create mode 100644 drivers/iio/proximity/srf08.c
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] iio: distance: srf08: add trivial DT binding
From: Andreas Klinger @ 2017-01-10 15:27 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
trivial, mranostay, linux-i2c, devicetree
Cc: ak
Add DT binding for devantech,srf08
Add vendor devantech to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 539874490492..86c6930c3c91 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -36,6 +36,7 @@ dallas,ds1775 Tiny Digital Thermometer and Thermostat
dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
dallas,ds75 Digital Thermometer and Thermostat
+devantech,srf08 Devantech SRF08 ultrasonic ranger
dlg,da9053 DA9053: flexible system level PMIC with multicore support
dlg,da9063 DA9063: system PMIC for quad-core application processors
epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4696bb5c2198..80325e602403 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -65,6 +65,7 @@ dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
denx Denx Software Engineering
+devantech Devantech, Ltd.
digi Digi International Inc.
digilent Diglent, Inc.
dlg Dialog Semiconductor
--
2.1.4
^ 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