* [PATCH v4 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
From: Stephen Boyd @ 2016-12-21 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220225530.96699-2-code@mmayer.net>
On 12/20, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> Add binding document for brcm,brcmstb-cpu-clk-div.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
> .../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 83 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> new file mode 100644
> index 0000000..3bc99c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> @@ -0,0 +1,83 @@
> +The CPU divider node serves as the sole clock for the CPU complex. It supports
> +power-of-2 clock division, with a divider of "1" as the default highest-speed
> +setting.
> +
> +Required properties:
> +- compatible: shall be "brcm,brcmstb-cpu-clk-div"
> +- reg: address and width of the divider configuration register
> +- #clock-cells: shall be set to 0
> +- clocks: phandle of clock provider which provides the source clock
> + (this would typically be a "fixed-clock" type PLL)
> +- div-table: list of (raw_value,divider) ordered pairs that correspond to the
> + allowed clock divider settings
> +- div-shift-width: least-significant bit position and width of divider value
> +
> +Optional properties:
> +- clocks: additional clocks can be specified if needed
> +- clock-names: clocks can be named, so they can be looked up
> +
> +Example:
> + sw_scb: sw_scb {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <432000000>;
> + };
> +
Is this a PLL?
> + fixed0: fixed0 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <54000000>;
> + };
And perhaps some sort of oscillator?
> +
> + cpu_pdiv: cpu_pdiv at f04e0008 {
> + compatible = "divider-clock";
> + #clock-cells = <0>;
> + reg = <0xf04e0008 0x4>;
> + bit-shift = <10>;
> + bit-mask = <0xf>;
> + index-starts-at-one;
> + clocks = <&fixed0>;
> + clock-names = "fixed0";
> + };
> +
> + cpu_ndiv_int: cpu_ndiv_int {
> + compatible = "fixed-factor-clock";
Ok..
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <167>;
> + clocks = <&cpu_pdiv>;
> + clock-names = "cpu_pdiv";
> + };
> +
> + cpu_mdiv_ch0: cpu_mdiv_ch0 at f04e0000 {
> + compatible = "divider-clock";
Is there a binding for this?
> + #clock-cells = <0>;
> + reg = <0xf04e0000 0x4>;
> + bit-shift = <1>;
> + bit-mask = <0xff>;
> + index-starts-at-one;
> + clocks = <&cpu_ndiv_int>;
> + clock-names = "cpu_ndiv_int";
> + };
> +
> + cpupll: cpupll at 0 {
> + #clock-cells = <0>;
> + clock-frequency = <1503000000>;
> + compatible = "fixed-clock";
> + };
> +
> + cpuclkdiv: cpu-clk-div at 0 {
Wrong unit address. Should be f03e257c?
> + #clock-cells = <0>;
> + clock-names = "cpupll",
> + "cpu_mdiv_ch0",
> + "cpu_ndiv_int",
> + "sw_scb";
> + clocks = <&cpupll,
> + &cpu_mdiv_ch0,
> + &cpu_ndiv_int,
> + &sw_scb>;
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;
> + div-table = <0x00 1>;
> + div-shift-width = <0 5>;
This entire DT design seems wrong. We don't put these sorts of
register level details into DT. There should be a driver that
knows the type of device that is present and how to drive that
hardware.
>From what I can tell there's something like a mux controller at
0xf04e0000 and then there's some sort of divider controller at
0xf03e0000. Perhaps those are two different devices that need
independent drivers? My wild guess is the PLL control is in those
register regions too, but we're not exposing control of them.
That's ok, but don't put the PLL into the DT as a fixed clock.
Just register it from the driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481725348-860-1-git-send-email-gabriel.fernandez@st.com>
On 12/14, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Clock and reset controller use same compatible strings (same IP).
>
> Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
> clocks") the OF core flags clock controllers registered with the
> CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
> compatible string will not be registered.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/3] clk: zte: add audio clocks for zx296718
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481873207-22929-4-git-send-email-shawnguo@kernel.org>
On 12/16, Shawn Guo wrote:
> From: Jun Nie <jun.nie@linaro.org>
>
> The audio related clock support is missing from the existing zx296718
> clock driver. Let's add it, so that the upstream ZX SPDIF driver can
> work for HDMI audio support.
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Applied to clk-next + I added static to some more structures.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: zx296718-clk: add compatible for audio clock controller
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481873207-22929-3-git-send-email-shawnguo@kernel.org>
On 12/16, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> It adds the compatible string for zx296718 audio clock controller.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/3] clk: zx296718: do not panic on failure
From: Stephen Boyd @ 2016-12-21 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481873207-22929-2-git-send-email-shawnguo@kernel.org>
On 12/16, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> Instead of using panic, we should give an error message and return error
> code when of_clk_add_hw_provider() call fails.
>
> Since we have error prompt for failures, the "init over" pr_info output
> isn't really necessary but becomes a debug noise. So let's clean it up
> along the way.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: Stephen Boyd @ 2016-12-21 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481781493-6188-3-git-send-email-zhangfei.gao@linaro.org>
On 12/15, Zhangfei Gao wrote:
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Add some commit text here?
> diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c
> new file mode 100644
> index 0000000..42ca47d
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3660.c
> @@ -0,0 +1,601 @@
> +/*
> + * Copyright (c) 2016-2017 Linaro Ltd.
> + * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
> + *
> + * This program 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.
> + */
> +
> +#include <dt-bindings/clock/hi3660-clock.h>
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
This isn't needed.
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk.h"
> +
[...]
> +
> +static int hi3660_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = pdev->dev.of_node;
> + const struct of_device_id *of_id;
> + enum hi3660_clk_type type;
> +
> + of_id = of_match_device(hi3660_clk_match_table, dev);
> + if (!of_id)
> + return -EINVAL;
> +
> + type = (enum hi3660_clk_type)of_id->data;
Use of_device_get_match_data() instead please.
> +
> + switch (type) {
> + case HI3660_CRGCTRL:
> + hi3660_clk_crgctrl_init(np);
> + break;
> + case HI3660_PCTRL:
> + hi3660_clk_pctrl_init(np);
> + break;
> + case HI3660_PMUCTRL:
> + hi3660_clk_pmuctrl_init(np);
> + break;
> + case HI3660_SCTRL:
> + hi3660_clk_sctrl_init(np);
> + break;
> + case HI3660_IOMCU:
> + hi3660_clk_iomcu_init(np);
> + break;
This "multi-device" driver design is sort of odd. Why not have
different files and struct drivers for the different devices in
the system that are clock controllers? I don't really understand
why we're controlling the devices with one struct driver
instance. Is something shared between the devices?
> + default:
> + break;
> + }
> + return 0;
> +}
[...]
> +
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hi3660-clk");
> +MODULE_DESCRIPTION("HiSilicon Hi3660 Clock Driver");
You can drop these MODULE_* things as they're not going to be
used in builtin only code.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 0/2] mark driver as non-removable
From: Russell King - ARM Linux @ 2016-12-21 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-1-alexander.stein@systec-electronic.com>
On Wed, Dec 21, 2016 at 04:03:38PM +0100, Alexander Stein wrote:
> Changes in v2;
> * Instead of adding a remove function which is unused otherwise, mark the driver
> as non-remoable
>
> Using DEBUG_TEST_DRIVER_REMOVE every driver gets probed, removed and probed
> again. This breaks drivers without removal function, e.g. arm perf
> resulting in the following dump:
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x6c/0x7c
> sysfs: cannot create duplicate filename '/devices/armv7_cortex_a7'
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0+ #212
> Hardware name: Freescale LS1021A
> Backtrace:
> [<8020c044>] (dump_backtrace) from [<8020c2f0>] (show_stack+0x18/0x1c)
> r7:00000009 r6:60000013 r5:80c1776c r4:00000000
> [<8020c2d8>] (show_stack) from [<8046ead8>] (dump_stack+0x94/0xa8)
> [<8046ea44>] (dump_stack) from [<8021ecd0>] (__warn+0xec/0x104)
> r7:00000009 r6:8092efc8 r5:00000000 r4:bf04bd80
> [<8021ebe4>] (__warn) from [<8021ed28>] (warn_slowpath_fmt+0x40/0x48)
> r9:80a32848 r8:00000000 r7:00000000 r6:bf0ab780 r5:8091d590 r4:bf0df000
> [<8021ecec>] (warn_slowpath_fmt) from [<8036d53c>] (sysfs_warn_dup+0x6c/0x7c)
> r3:bf0df000 r2:8092ef94
> [<8036d4d0>] (sysfs_warn_dup) from [<8036d628>] (sysfs_create_dir_ns+0x8c/0x9c)
> r6:bf0ab780 r5:bf20ee08 r4:ffffffef
> [<8036d59c>] (sysfs_create_dir_ns) from [<80471860>] (kobject_add_internal+0xa8/0x34c)
> r6:bf0aa198 r5:00000000 r4:bf20ee08
> [<804717b8>] (kobject_add_internal) from [<80471b54>] (kobject_add+0x50/0x94)
> r7:00000000 r6:00000000 r5:00000000 r4:bf20ee08
> [<80471b08>] (kobject_add) from [<80524590>] (device_add+0xe4/0x590)
> r3:00000000 r2:00000000
> r6:bf20ee00 r5:00000000 r4:bf20ee08
> [<805244ac>] (device_add) from [<802a38a8>] (pmu_dev_alloc+0x88/0xd8)
> r10:00000091 r9:80a32848 r8:00000000 r7:80a32840 r6:80c0ed3c r5:00000000
> r4:bf1fe800
> [<802a3820>] (pmu_dev_alloc) from [<80a0cd20>] (perf_event_sysfs_init+0x5c/0xb4)
> r7:80a32840 r6:00000000 r5:bf1fe800 r4:80c0ede0
> [<80a0ccc4>] (perf_event_sysfs_init) from [<80201778>] (do_one_initcall+0x48/0x178)
> r6:80c45000 r5:80a0ccc4 r4:00000006
> [<80201730>] (do_one_initcall) from [<80a00ecc>] (kernel_init_freeable+0x168/0x20c)
> r8:80a00610 r7:80a32840 r6:80c45000 r5:80c45000 r4:00000006
> [<80a00d64>] (kernel_init_freeable) from [<806febcc>] (kernel_init+0x10/0x11c)
> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:806febbc
> r4:00000000
> [<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c)
> r5:806febbc r4:00000000
> ---[ end trace 9d251d389382804f ]---
Please consider putting some of the above in patch 2's description, so
the reason for the patch doesn't get lost. If you want to reduce the
commit message, you could consider cutting the registers from the
backtrace (which are only useful when doing in-depth debugging, not for
illustrating the callpath.)
I'd like to see acks on both of these before I take patch 2, but I'm not
expecting that to happen until the new year.
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 02/11] clk: bcm2835: Register the DSI0/DSI1 pixel clocks.
From: Stephen Boyd @ 2016-12-21 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161214194621.16499-3-eric@anholt.net>
On 12/14, Eric Anholt wrote:
>
> /* the gates */
>
> @@ -1890,8 +1976,18 @@ static int bcm2835_clk_probe(struct platform_device *pdev)
> if (IS_ERR(cprman->regs))
> return PTR_ERR(cprman->regs);
>
> - cprman->osc_name = of_clk_get_parent_name(dev->of_node, 0);
> - if (!cprman->osc_name)
> + for (i = 0; i < ARRAY_SIZE(cprman_parent_names); i++) {
> + cprman->real_parent_names[i] =
> + of_clk_get_parent_name(dev->of_node, i);
> + }
Can we use of_clk_parent_fill() here? Or do we need to support
holes in the parent array? If it's the latter please add a
comment so we don't mistakenly change this later.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] arm64: Don't trace __switch_to if function graph tracer is enabled
From: Joel Fernandes @ 2016-12-21 22:44 UTC (permalink / raw)
To: linux-arm-kernel
Function graph tracer shows negative time (wrap around) when tracing
__switch_to if the nosleep-time trace option is enabled.
Time compensation for nosleep-time is done by an ftrace probe on
sched_switch. This doesn't work well for the following events (with
letters representing timestamps):
A - sched switch probe called for task T switch out
B - __switch_to calltime is recorded
C - sched_switch probe called for task T switch in
D - __switch_to rettime is recorded
If C - A > D - B, then we end up over compensating for the time spent in
__switch_to giving rise to negative times in the trace output.
On x86, __switch_to is not traced if function graph tracer is enabled.
Do the same for arm64 as well.
Cc: Todd Kjos <tkjos@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Joel Fernandes <joelaf@google.com>
---
arch/arm64/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 01753cd..e84ee27 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -324,7 +324,7 @@ void uao_thread_switch(struct task_struct *next)
/*
* Thread switching.
*/
-struct task_struct *__switch_to(struct task_struct *prev,
+__notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *next)
{
struct task_struct *last;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Maxime Ripard @ 2016-12-21 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-3-icenowy@aosc.xyz>
On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote:
> Lichee Pi One is a low-cost Allwinner A13-based development board, with
> an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
> RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
> headers and two MicroSD card slots (connected to mmc0 and mmc2, both
> bootable).
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/1e2e9f64/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi
From: Maxime Ripard @ 2016-12-21 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
On Thu, Dec 22, 2016 at 04:02:33AM +0800, Icenowy Zheng wrote:
> Lichee Pi is a new "Pi"-named development board series.
>
> Currently available device, Lichee Pi One, is by only one person as
> night job, so the device series name is chosen to be the vendor prefix.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/ec2af551/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: dts: sun5i: add a pinctrl node for 4bit mmc2
From: Maxime Ripard @ 2016-12-21 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-2-icenowy@aosc.xyz>
On Thu, Dec 22, 2016 at 04:02:34AM +0800, Icenowy Zheng wrote:
> Some board only use 4bit mode of mmc2.
>
> Add a pinctrl node for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/09ffae89/attachment.sig>
^ permalink raw reply
* Mainline Patch Enable Can support in sunxi-a20.dtsi
From: Maxime Ripard @ 2016-12-21 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1737278812.179886.1482137303825@email.1und1.de>
Hi Christian,
On Mon, Dec 19, 2016 at 09:48:23AM +0100, Christian Waldeck wrote:
> <!DOCTYPE html>
> <html><head>
> <meta charset="UTF-8">
> </head><body><p>Hello Maxime and Chen-Yu, <br></p><p><br></p><p>I`am currently working with an A20 Board from In-Circuit. <br></p><p>It took us quite some time to fetch all information about enabling the can pins on tha device. <br></p><p>Now we have working solution. <br></p><p><br></p><p>Attached to this email is a patch file which enables can-bus at the sunxi-A20.dtsi file<br></p><p>and the corresponding sun7i-a20-icnova-swac.dts BSP description. <br></p><p><br></p><p>Hopefully you can integrate this piece of configuration<br></p><p>to save time for other users, that are trying to work with the can-bus fram A20 SoC. <br></p><p><br></p><p class="io-ox-signature">Best regards, <br> <br>Christian Waldeck<br> <br>Green Digit GmbH<br>Zeppelinstr. 5<br>82205 Gilching<br><br>fon: +49 (0) 8105 39989-78<br>fax: +49 (0) 8105 39989-77<br><br>http://www.greendigit.de<br><br>Amtsgericht München, HRB 180693<br>Geschäftsführer: Volker Werbus</p></body></html>
Thanks a lot for your patch.
However, it has a number of things that prevent it from being applied as is.
The two majors flaws are that you sent it in HTML format, which
prevents it from being applied. Your patch also lacks a Signed-off-by
tag, which is used to know that you have the legal right to submit the
patch.
You can have more documentation on how to send your first patch here
https://kernelnewbies.org/FirstKernelPatch#head-dc6a8aa0be0d0e8ed9dc03726d0b5a1fb0f65e1f
and in Documentation/SubmittingPatches in the kernel source code.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/b203bf31/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: dts: msm8996: Add required memory carveouts
From: Stephen Boyd @ 2016-12-21 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482357822-20823-1-git-send-email-andy.gross@linaro.org>
On 12/21/2016 02:03 PM, Andy Gross wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> This patch adds required memory carveouts so that the kernel does not
> access memory that is in use or has been reserved for use by other remote
> processors.
Thanks,
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index cde4114..25e11dc 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -64,6 +64,16 @@
> reg = <0x0 0x86000000 0x0 0x200000>;
> no-map;
> };
> +
> + memory at 85800000 {
> + reg = <0x0 0x85800000 0x0 0x800000>;
> + no-map;
> + };
> +
> + memory at 86200000 {
> + reg = <0x0 0x86200000 0x0 0x2600000>;
> + no-map;
> + };
> };
>
> cpus {
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] arm64: dts: msm8996: Add required memory carveouts
From: Andy Gross @ 2016-12-21 22:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Boyd <sboyd@codeaurora.org>
This patch adds required memory carveouts so that the kernel does not
access memory that is in use or has been reserved for use by other remote
processors.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index cde4114..25e11dc 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -64,6 +64,16 @@
reg = <0x0 0x86000000 0x0 0x200000>;
no-map;
};
+
+ memory at 85800000 {
+ reg = <0x0 0x85800000 0x0 0x800000>;
+ no-map;
+ };
+
+ memory at 86200000 {
+ reg = <0x0 0x86200000 0x0 0x2600000>;
+ no-map;
+ };
};
cpus {
--
1.9.1
^ permalink raw reply related
* [PATCH] dmaengine: ipu: Make sure the interrupt routine checks all interrupts.
From: Magnus Lilja @ 2016-12-21 21:13 UTC (permalink / raw)
To: linux-arm-kernel
Commit 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers")
consolidated the two interrupts routines into one, but the remaining
interrupt routine only checks the status of the error interrupts, not the
normal interrupts.
This patch fixes that problem (tested on i.MX31 PDK board).
Fixes: 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers")
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: <stable@vger.kernel.org> # 4.1.x
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
---
drivers/dma/ipu/ipu_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index dd184b5..2846278 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -272,7 +272,7 @@ static void ipu_irq_handler(struct irq_desc *desc)
u32 status;
int i, line;
- for (i = IPU_IRQ_NR_FN_BANKS; i < IPU_IRQ_NR_BANKS; i++) {
+ for (i = 0; i < IPU_IRQ_NR_BANKS; i++) {
struct ipu_irq_bank *bank = irq_bank + i;
raw_spin_lock(&bank_lock);
--
2.7.4
^ permalink raw reply related
* [PATCHv2] crypto: testmgr: Use heap buffer for acomp test input
From: Laura Abbott @ 2016-12-21 20:32 UTC (permalink / raw)
To: linux-arm-kernel
Christopher Covington reported a crash on aarch64 on recent Fedora
kernels:
kernel BUG at ./include/linux/scatterlist.h:140!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162
Hardware name: linux,dummy-virt (DT)
task: ffff80007c650080 task.stack: ffff800008910000
PC is at sg_init_one+0xa0/0xb8
LR is at sg_init_one+0x24/0xb8
...
[<ffff000008398db8>] sg_init_one+0xa0/0xb8
[<ffff000008350a44>] test_acomp+0x10c/0x438
[<ffff000008350e20>] alg_test_comp+0xb0/0x118
[<ffff00000834f28c>] alg_test+0x17c/0x2f0
[<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
[<ffff0000080dac70>] kthread+0xf8/0x128
[<ffff000008082ec0>] ret_from_fork+0x10/0x50
The test vectors used for input are part of the kernel image. These
inputs are passed as a buffer to sg_init_one which eventually blows up
with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
false for the kernel image since virt_to_page will not return the
correct page. Fix this by copying the input vectors to heap buffer
before setting up the scatterlist.
Reported-by: Christopher Covington <cov@codeaurora.org>
Fixes: d7db7a882deb ("crypto: acomp - update testmgr with support for acomp")
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
crypto/testmgr.c | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f616ad7..44e888b 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1461,16 +1461,25 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
for (i = 0; i < ctcount; i++) {
unsigned int dlen = COMP_BUF_SIZE;
int ilen = ctemplate[i].inlen;
+ void *input_vec;
+ input_vec = kmalloc(ilen, GFP_KERNEL);
+ if (!input_vec) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ memcpy(input_vec, ctemplate[i].input, ilen);
memset(output, 0, dlen);
init_completion(&result.completion);
- sg_init_one(&src, ctemplate[i].input, ilen);
+ sg_init_one(&src, input_vec, ilen);
sg_init_one(&dst, output, dlen);
req = acomp_request_alloc(tfm);
if (!req) {
pr_err("alg: acomp: request alloc failed for %s\n",
algo);
+ kfree(input_vec);
ret = -ENOMEM;
goto out;
}
@@ -1483,6 +1492,7 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
if (ret) {
pr_err("alg: acomp: compression failed on test %d for %s: ret=%d\n",
i + 1, algo, -ret);
+ kfree(input_vec);
acomp_request_free(req);
goto out;
}
@@ -1491,6 +1501,7 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
pr_err("alg: acomp: Compression test %d failed for %s: output len = %d\n",
i + 1, algo, req->dlen);
ret = -EINVAL;
+ kfree(input_vec);
acomp_request_free(req);
goto out;
}
@@ -1500,26 +1511,37 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
i + 1, algo);
hexdump(output, req->dlen);
ret = -EINVAL;
+ kfree(input_vec);
acomp_request_free(req);
goto out;
}
+ kfree(input_vec);
acomp_request_free(req);
}
for (i = 0; i < dtcount; i++) {
unsigned int dlen = COMP_BUF_SIZE;
int ilen = dtemplate[i].inlen;
+ void *input_vec;
+
+ input_vec = kmalloc(ilen, GFP_KERNEL);
+ if (!input_vec) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ memcpy(input_vec, dtemplate[i].input, ilen);
memset(output, 0, dlen);
init_completion(&result.completion);
- sg_init_one(&src, dtemplate[i].input, ilen);
+ sg_init_one(&src, input_vec, ilen);
sg_init_one(&dst, output, dlen);
req = acomp_request_alloc(tfm);
if (!req) {
pr_err("alg: acomp: request alloc failed for %s\n",
algo);
+ kfree(input_vec);
ret = -ENOMEM;
goto out;
}
@@ -1532,6 +1554,7 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
if (ret) {
pr_err("alg: acomp: decompression failed on test %d for %s: ret=%d\n",
i + 1, algo, -ret);
+ kfree(input_vec);
acomp_request_free(req);
goto out;
}
@@ -1540,6 +1563,7 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
pr_err("alg: acomp: Decompression test %d failed for %s: output len = %d\n",
i + 1, algo, req->dlen);
ret = -EINVAL;
+ kfree(input_vec);
acomp_request_free(req);
goto out;
}
@@ -1549,10 +1573,12 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
i + 1, algo);
hexdump(output, req->dlen);
ret = -EINVAL;
+ kfree(input_vec);
acomp_request_free(req);
goto out;
}
+ kfree(input_vec);
acomp_request_free(req);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Fabio Estevam @ 2016-12-21 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1bec9023-1869-2847-bea6-adebc5af0093@mleia.com>
On Wed, Dec 21, 2016 at 6:24 PM, Vladimir Zapolskiy <vz@mleia.com> wrote:
> Correct, I would recommend to postpone adding any extensions to the driver
> platform data, which by the way is found in include/linux/mfd/mc13xxx.h
>
> The extension can be added only when it becomes needed.
Yes, I agree.
> FWIW I ran the v4.9-rc kernel with device trees on i.MX31 Lite board
> with MC13783, and what I can confirm is that in my case the proposed
> change is not needed at all. Thus I'm going to verify shortly that
> the commit does not break the currently correct runtime behaviour on
> my board.
Nice to see imx31 with dt support :-)
^ permalink raw reply
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Vladimir Zapolskiy @ 2016-12-21 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=E1R7mBa7PSyshR+VwbeCqqDytkTknNksWQmf3Yk2r0_nHZw@mail.gmail.com>
Hi,
On 12/21/2016 09:41 PM, Magnus Lilja wrote:
> Hi,
>
> On 21 December 2016 at 07:00, Alexander Shiyan <shc_work@mail.ru> wrote:
>>> ???????, 20 ??????? 2016, 22:35 +03:00 ?? Magnus Lilja <lilja.magnus@gmail.com>:
>>>
>>> On 20 December 2016 at 06:20, Alexander Shiyan < shc_work@mail.ru > wrote:
>>>>> ???????, 20 ??????? 2016, 0:28 +03:00 ?? Magnus Lilja < lilja.magnus@gmail.com >:
>>>>>
>>>>> All supported mc13xxx devices have active high interrupt outputs. Make sure
>>>>> to configure the interrupt as active high by passing the IRQF_TRIGGER_HIGH
>>>>> flag. This is required at least on the i.MX31 PDK board.
>>>>>
>>>>> Signed-off-by: Magnus Lilja < lilja.magnus@gmail.com >
>>>>> ---
>>>>>
>>>>> drivers/mfd/mc13xxx-core.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
>>>>> index d7f54e4..4cbe6b7 100644
>>>>> --- a/drivers/mfd/mc13xxx-core.c
>>>>> +++ b/drivers/mfd/mc13xxx-core.c
>>>>> @@ -440,7 +440,7 @@ int mc13xxx_common_init(struct device *dev)
>>>>> mc13xxx->irq_chip.irqs = mc13xxx->irqs;
>>>>> mc13xxx->irq_chip.num_irqs = ARRAY_SIZE(mc13xxx->irqs);
>>>>>
>>>>> -ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT,
>>>>> +ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
>>>>> 0, &mc13xxx->irq_chip, &mc13xxx->irq_data);
>>>>> if (ret)
>>>>> return ret;
>>>>
>>>> IRQ line can be passed through inverter to IC.
>>>> On my opinion the best way to handle all possible situations is parse
>>>> devicetree IRQ flags and pass to the driver.
>>>
>>> My guess is that most boards follow the evaluation boards/kits and
>>> don't have an inverter so I think the default should be TRIG_HIGH
>>> since that will make most boards work automatically. But I can have a
>>> look at making it configurable (with and without the use of device
>>> tree), but for the device tree stuff I would need pointers to similar
>>> code since my experience with that is none.
>>> Any pointers to similar code?
>>
>> Hello.
>>
>> Perhaps I'm wrong and the desired active level has setup at the IRQ code level.
>
> Don't think I understand what you mean here.
>
>> Otherwise, I think you need to use something like the following:
>>
>> unsigned flags = irqd_get_trigger_type(irq_get_irq_data(irq));
>> flags = (flags == IRQ_TYPE_NONE) ? IRQF_TRIGGER_HIGH : flags;
>> ret = regmap_add_irq_chip(..., IRQF_ONESHOT | flags, ...);
>
> That would work but I don't know how one would set the trigger type in
> case of not using device trees.
you may look at drivers/mfd/palmas.c and include/linux/mfd/palmas.h
to get an idea how irq flags are passed through the platform data in
a similar case.
> But that would only be a problem if a board really has an inverter on
> the IRQ line so that can be solved later,
Correct, I would recommend to postpone adding any extensions to the driver
platform data, which by the way is found in include/linux/mfd/mc13xxx.h
The extension can be added only when it becomes needed.
> and might be not necessary to solve if mx31 boards are converted to
> device tree usage.
>
> I guess that get trigger_type can be set via the device tree magic
> when using device trees.
>
FWIW I ran the v4.9-rc kernel with device trees on i.MX31 Lite board
with MC13783, and what I can confirm is that in my case the proposed
change is not needed at all. Thus I'm going to verify shortly that
the commit does not break the currently correct runtime behaviour on
my board.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Magnus Lilja @ 2016-12-21 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CmEL_gW6pXM3XDY+VR9q2MmqV5Q905PJjf0-W4jUBFbg@mail.gmail.com>
Hi
On 21 December 2016 at 21:10, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Magnus,
>
> On Mon, Dec 19, 2016 at 7:28 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
>> All supported mc13xxx devices have active high interrupt outputs. Make sure
>> to configure the interrupt as active high by passing the IRQF_TRIGGER_HIGH
>> flag. This is required at least on the i.MX31 PDK board.
>>
>> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
>
> What is the commit that caused the breakage in the driver? Please
> specify in the commit log, add a Fixes tag and Cc: stable like
> mentioned on patch 1/2.
Will add that info and cc: stable.
And while investigating which commit that caused this I noticed that
the prior to that commit IRQF_TRIGGER_HIGH was always passed without
possibility to change so I wonder if it really is necessary to support
any inverters in the IRQ line..
Thanks, Magnus
^ permalink raw reply
* [PATCH 1/2] i.MX31: ipu: Make sure the interrupt routine checks all interrupts.
From: Magnus Lilja @ 2016-12-21 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C61gfL95sW=r5RLxFaDSeb34FuFSx8Pj=J2-WqYD1qaw@mail.gmail.com>
Hi Fabio,
On 21 December 2016 at 21:08, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Magnus,
>
> On Mon, Dec 19, 2016 at 7:28 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
>> Commit 3d8cc00073d6750ffe883685e49b2e4a0f596370 consolidated the two
>
> The standard form to specify a commit is 3d8cc00073d6 ("dmaengine:
> ipu: Consolidate duplicated irq handlers")
>
>> interrupts routines into one, but the remaining interrupt routine only
>> checks the status of the error interrupts, not the normal interrupts.
>>
>> This patch fixes that problem (tested on i.MX31 PDK board).
>>
>> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
>
> Patch looks good, but I have some suggestions:
>
> - Subject should start with dmaengine, so something like:
> Subject: dmaengine: ipu: Make sure the ....
>
> - You sent these two patches on a series, but as they touch different
> subsystems they could be sent separately, each one to the proper
> maintainer. For dmaengine the maintainer is Vinod. Hint: you can run
> ./scripts/get_maintainer.pl on your patch and it will list the
> maintainer and lists the patches should be sent to.
>
> You should also add a Fixes tag above your Signed-off-by like this:
> Fixes: 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers")
> Cc: <stable@vger.kernel.org> # 4.3.x
Thanks for review. I will add take care of your comments and send a
new standalone patch.
Regards, Magnus
^ permalink raw reply
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Fabio Estevam @ 2016-12-21 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482182934-18559-3-git-send-email-lilja.magnus@gmail.com>
Hi Magnus,
On Mon, Dec 19, 2016 at 7:28 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> All supported mc13xxx devices have active high interrupt outputs. Make sure
> to configure the interrupt as active high by passing the IRQF_TRIGGER_HIGH
> flag. This is required at least on the i.MX31 PDK board.
>
> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
What is the commit that caused the breakage in the driver? Please
specify in the commit log, add a Fixes tag and Cc: stable like
mentioned on patch 1/2.
^ permalink raw reply
* [PATCH 1/2] i.MX31: ipu: Make sure the interrupt routine checks all interrupts.
From: Fabio Estevam @ 2016-12-21 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482182934-18559-2-git-send-email-lilja.magnus@gmail.com>
Hi Magnus,
On Mon, Dec 19, 2016 at 7:28 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> Commit 3d8cc00073d6750ffe883685e49b2e4a0f596370 consolidated the two
The standard form to specify a commit is 3d8cc00073d6 ("dmaengine:
ipu: Consolidate duplicated irq handlers")
> interrupts routines into one, but the remaining interrupt routine only
> checks the status of the error interrupts, not the normal interrupts.
>
> This patch fixes that problem (tested on i.MX31 PDK board).
>
> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
Patch looks good, but I have some suggestions:
- Subject should start with dmaengine, so something like:
Subject: dmaengine: ipu: Make sure the ....
- You sent these two patches on a series, but as they touch different
subsystems they could be sent separately, each one to the proper
maintainer. For dmaengine the maintainer is Vinod. Hint: you can run
./scripts/get_maintainer.pl on your patch and it will list the
maintainer and lists the patches should be sent to.
You should also add a Fixes tag above your Signed-off-by like this:
Fixes: 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers")
Cc: <stable@vger.kernel.org> # 4.3.x
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Icenowy Zheng @ 2016-12-21 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
Lichee Pi One is a low-cost Allwinner A13-based development board, with
an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
headers and two MicroSD card slots (connected to mmc0 and mmc2, both
bootable).
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun5i-a13-licheepi-one.dts | 224 +++++++++++++++++++++++++++
2 files changed, 225 insertions(+)
create mode 100644 arch/arm/boot/dts/sun5i-a13-licheepi-one.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb557b6..5902d4ca7138 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -781,6 +781,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a13-empire-electronix-m712.dtb \
sun5i-a13-hsg-h702.dtb \
sun5i-a13-inet-98v-rev2.dtb \
+ sun5i-a13-licheepi-one.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
sun5i-a13-q8-tablet.dtb \
diff --git a/arch/arm/boot/dts/sun5i-a13-licheepi-one.dts b/arch/arm/boot/dts/sun5i-a13-licheepi-one.dts
new file mode 100644
index 000000000000..566cda91a66b
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-a13-licheepi-one.dts
@@ -0,0 +1,224 @@
+/*
+ * Copyright 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun5i-a13-olinuxino.dts, which is
+ * Copyright 2012 Maxime Ripard <maxime.ripard@free-electrons.com>
+ * Copyright 2013 Hans de Goede <hdegoede@redhat.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.
+ *
+ * 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 "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Lichee Pi One";
+ compatible = "licheepi,licheepi-one", "allwinner,sun5i-a13";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ red {
+ label ="licheepi:red:usr";
+ gpios = <&pio 2 5 GPIO_ACTIVE_LOW>;
+ };
+
+ green {
+ label ="licheepi:green:usr";
+ gpios = <&pio 2 19 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ blue {
+ label ="licheepi:blue:usr";
+ gpios = <&pio 2 4 GPIO_ACTIVE_LOW>;
+ };
+
+ };
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic at 34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "disabled";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "disabled";
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button at 984 {
+ label = "Home";
+ linux,code = <KEY_HOMEPAGE>;
+ channel = <0>;
+ voltage = <984126>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ broken-cd;
+ status = "okay";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_4bit_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ broken-cd;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+®_ldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "csi-1.8v";
+};
+
+®_ldo4 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "csi-2.8v";
+};
+
+®_usb0_vbus {
+ gpio = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_b>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
+ usb0_vbus_det-gpio = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_vcc5v0>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: sun5i: add a pinctrl node for 4bit mmc2
From: Icenowy Zheng @ 2016-12-21 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
Some board only use 4bit mode of mmc2.
Add a pinctrl node for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun5i.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 54170147040f..c058d37d5433 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -594,6 +594,14 @@
bias-pull-up;
};
+ mmc2_4bit_pins_a: mmc2-4bit at 0 {
+ pins = "PC6", "PC7", "PC8", "PC9",
+ "PC10", "PC11";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
spi2_pins_a: spi2 at 0 {
pins = "PE1", "PE2", "PE3";
function = "spi2";
--
2.11.0
^ 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