* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: AKASHI Takahiro @ 2016-11-02 4:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102044959.11954-1-takahiro.akashi@linaro.org>
Add memblock_cap_memory_range() which will remove all the memblock regions
except the range specified in the arguments.
This function, like memblock_mem_limit_remove_map(), will not remove
memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
later as "device memory."
See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
address the mem limit issue").
This function is used, in a succeeding patch in the series of arm64 kdump
suuport, to limit the range of usable memory, System RAM, on crash dump
kernel.
(Please note that "mem=" parameter is of little use for this purpose.)
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: linux-mm at kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/memblock.h | 1 +
mm/memblock.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9..0e770af 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -334,6 +334,7 @@ phys_addr_t memblock_start_of_DRAM(void);
phys_addr_t memblock_end_of_DRAM(void);
void memblock_enforce_memory_limit(phys_addr_t memory_limit);
void memblock_mem_limit_remove_map(phys_addr_t limit);
+void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
bool memblock_is_memory(phys_addr_t addr);
int memblock_is_map_memory(phys_addr_t addr);
int memblock_is_region_memory(phys_addr_t base, phys_addr_t size);
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..eb53876 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1544,6 +1544,34 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
(phys_addr_t)ULLONG_MAX);
}
+void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
+{
+ int start_rgn, end_rgn;
+ int i, ret;
+
+ if (!size)
+ return;
+
+ ret = memblock_isolate_range(&memblock.memory, base, size,
+ &start_rgn, &end_rgn);
+ if (ret)
+ return;
+
+ /* remove all the MAP regions */
+ for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ for (i = start_rgn - 1; i >= 0; i--)
+ if (!memblock_is_nomap(&memblock.memory.regions[i]))
+ memblock_remove_region(&memblock.memory, i);
+
+ /* truncate the reserved regions */
+ memblock_remove_range(&memblock.reserved, 0, base);
+ memblock_remove_range(&memblock.reserved,
+ base + size, (phys_addr_t)ULLONG_MAX);
+}
+
static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
{
unsigned int left = 0, right = type->cnt;
--
2.10.0
^ permalink raw reply related
* [PATCH v27 0/9] arm64: add kdump support
From: AKASHI Takahiro @ 2016-11-02 4:49 UTC (permalink / raw)
To: linux-arm-kernel
v27-specific note: In this version, the change made in v26 was reverted
because I've got a comment that /reserved-memory DT property should
not be used on UEFI/ACPI systems, even though it is workable under
the current implementation. I've also confirmed that Rob doesn't argue
any more against using "linux,usable-memory-range".
So v27 is essentially the same as v25.
This patch series adds kdump support on arm64.
To load a crash-dump kernel to the systems, a series of patches to
kexec-tools[1] are also needed. Please use the latest one, v4 [2].
To examine vmcore (/proc/vmcore) on a crash-dump kernel, you can use
- crash utility (v7.1.6 or later) [3]
[1] https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
[1] http://lists.infradead.org/pipermail/kexec/2016-November/017555.html
[2] https://github.com/crash-utility/crash.git
Changes for v27 (Nov 2, 2016)
o rebased to Linux-v4.9-rc3
o revert v26 change, i.e. revive "linux,usable-memory-range" property
(patch #2/#3, updating patch #9)
o minor fixes per review comments (patch #3/#4/#6/#8)
o re-order patches and improve commit messages for readability
Changes for v26 (Sep 7, 2016):
o Use /reserved-memory instead of "linux,usable-memory-range" property
(dropping v25's patch#2 and #3, updating ex-patch#9.)
Changes for v25 (Aug 29, 2016):
o Rebase to Linux-4.8-rc4
o Use memremap() instead of ioremap_cache() [patch#5]
Changes for v24 (Aug 9, 2016):
o Rebase to Linux-4.8-rc1
o Update descriptions about newly added DT proerties
Changes for v23 (July 26, 2016):
o Move memblock_reserve() to a single place in reserve_crashkernel()
o Use cpu_park_loop() in ipi_cpu_crash_stop()
o Always enforce ARCH_LOW_ADDRESS_LIMIT to the memory range of crash kernel
o Re-implement fdt_enforce_memory_region() to remove non-reserve regions
(for ACPI) from usable memory at crash kernel
Changes for v22 (July 12, 2016):
o Export "crashkernel-base" and "crashkernel-size" via device-tree,
and add some descriptions about them in chosen.txt
o Rename "usable-memory" to "usable-memory-range" to avoid inconsistency
with powerpc's "usable-memory"
o Make cosmetic changes regarding "ifdef" usage
o Correct some wordings in kdump.txt
Changes for v21 (July 6, 2016):
o Remove kexec patches.
o Rebase to arm64's for-next/core (Linux-4.7-rc4 based).
o Clarify the description about kvm in kdump.txt.
See the following link [3] for older changes:
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438780.html
AKASHI Takahiro (8):
memblock: add memblock_cap_memory_range()
arm64: limit memory regions based on DT property, usable-memory-range
arm64: kdump: reserve memory for crash dump kernel
arm64: kdump: implement machine_crash_shutdown()
arm64: kdump: add VMCOREINFO's for user-space tools
arm64: kdump: provide /proc/vmcore file
arm64: kdump: enable kdump in defconfig
Documentation: kdump: describe arm64 port
James Morse (1):
Documentation: dt: chosen properties for arm64 kdump
Documentation/devicetree/bindings/chosen.txt | 50 +++++++
Documentation/kdump/kdump.txt | 16 ++-
arch/arm64/Kconfig | 11 ++
arch/arm64/configs/defconfig | 1 +
arch/arm64/include/asm/hardirq.h | 2 +-
arch/arm64/include/asm/kexec.h | 42 +++++-
arch/arm64/include/asm/smp.h | 2 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/crash_dump.c | 71 ++++++++++
arch/arm64/kernel/machine_kexec.c | 67 ++++++++-
arch/arm64/kernel/setup.c | 7 +-
arch/arm64/kernel/smp.c | 63 +++++++++
arch/arm64/mm/init.c | 199 +++++++++++++++++++++++++++
include/linux/memblock.h | 1 +
mm/memblock.c | 28 ++++
15 files changed, 554 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/kernel/crash_dump.c
--
2.10.0
^ permalink raw reply
* [PATCH v3 0/4] PXA cpufreq conversion to clock API
From: Viresh Kumar @ 2016-11-02 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477943696-23477-1-git-send-email-robert.jarzmik@free.fr>
On 31-10-16, 20:54, Robert Jarzmik wrote:
> Hi,
>
> This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
> API, next iteration.
>
> The first 3 patches are review and merge material :
> - patch 1/4 for Viresh and Rafael
> - patches 2/4 and 3/4 for me
>
> The 4th on is for review but not merge, as the clock changes must be fully
> reviewed and go in first as a prequisite
>
> Since previous iteration, 2 and 3 were amended per Viresh's suggestion.
>
> Robert Jarzmik (4):
> cpufreq: pxa: use generic platdev driver for device-tree
> ARM: dts: pxa: add pxa25x cpu operating points
> ARM: dts: pxa: add pxa27x cpu operating points
> cpufreq: pxa: convert to clock API
>
> arch/arm/boot/dts/pxa25x.dtsi | 25 +++++
> arch/arm/boot/dts/pxa27x.dtsi | 40 ++++++++
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
> drivers/cpufreq/pxa2xx-cpufreq.c | 191 +++++++----------------------------
> 4 files changed, 106 insertions(+), 152 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v3 3/3] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Viresh Kumar @ 2016-11-02 4:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027214131.1725-4-d-gerlach@ti.com>
On 27-10-16, 16:41, Dave Gerlach wrote:
> Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
> have different OPPs available for the MPU depending on which specific
> variant of the SoC is in use. This can be determined through use of the
> revision and an eFuse register present in the silicon. Introduce a
> ti-cpufreq driver that can read the aformentioned values and provide
> them as version matching data to the opp framework. Through this the
> opp-supported-hw dt binding that is part of the operating-points-v2
> table can be used to indicate availability of OPPs for each device.
>
> This driver also creates the "cpufreq-dt" platform_device after passing
> the version matching data to the OPP framework so that the cpufreq-dt
> handles the actual cpufreq implementation. Even without the necessary
> data to pass the version matching data the driver will still create this
> device to maintain backwards compatibility with operating-points v1
> tables.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v2-v3:
> - Use common ti compatible as described in binding and then match
> against machine type for platform data.
> - Use newly exposed dev_pm_opp_of_get_opp_desc_node to get
> operating-points-v2 table now that properties needed by driver are
> there.
> - Parse syscon properties from operating-points-v2 node rather
> than cpu node.
> - Do not make ti-cpufreq a module-platform-driver and do not allow
> building as module.
>
> drivers/cpufreq/Kconfig.arm | 11 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/ti-cpufreq.c | 288 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 300 insertions(+)
> create mode 100644 drivers/cpufreq/ti-cpufreq.c
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v3 2/3] Documentation: dt: add bindings for ti-cpufreq
From: Viresh Kumar @ 2016-11-02 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027214131.1725-3-d-gerlach@ti.com>
On 27-10-16, 16:41, Dave Gerlach wrote:
> Add the device tree bindings document for the TI CPUFreq/OPP driver
> on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us
> to provide an opp-supported-hw property for each OPP to define when
> it is available. This driver is responsible for reading and parsing
> registers to determine which OPPs can be selectively enabled based
> on the specific SoC in use by matching against the opp-supported-hw
> data.
>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> v2->v3:
> - Move ti,syscon-* properties under opp table instead of cpu node, as
> that is a better location for them.
> - For the opp table do not use platform specific compatible strings
> but instead a operating-points-v2-ti-cpu
>
> .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 132 +++++++++++++++++++++
> 1 file changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> new file mode 100644
> index 000000000000..467ad29c75c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> @@ -0,0 +1,132 @@
> +TI CPUFreq and OPP bindings
> +================================
> +
> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
> +families support different OPPs depending on the silicon variant in use.
> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
> +provide the OPP framework with supported hardware information. This is
> +used to determine which OPPs from the operating-points-v2 table get enabled
> +when it is parsed by the OPP framework.
> +
> +Required properties:
> +--------------------
> +In 'cpus' nodes:
> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
> +
> +In 'operating-points-v2' table:
> +- compatible: Should be 'operating-points-v2-ti-cpu' for am335x, am43xx,
> + and dra7xx/am57xx SoCs
> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
> + mask, and efuse register shift to get the relevant bits
> + that describe OPP availability.
> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
> +
> +Optional properties:
> +--------------------
> +For each opp entry in 'operating-points-v2' table:
> +- opp-supported-hw: Two bitfields indicating:
> + 1. Which revision of the SoC the OPP is supported by
> + 2. Which eFuse bits indicate this OPP is available
> +
> + A bitwise AND is performed against these values and if any bit
> + matches, the OPP gets enabled. Not providing the property for an
> + entry indicates that an OPP is always supported.
> +
> +Example:
> +--------
> +
> +/* From arch/arm/boot/dts/am33xx.dtsi */
> +cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu at 0 {
> + compatible = "arm,cortex-a8";
> + device_type = "cpu";
> + reg = <0>;
> +
> + operating-points-v2 = <&cpu0_opp_table>;
> +
> + clocks = <&dpll_mpu_ck>;
> + clock-names = "cpu";
> +
> + clock-latency = <300000>; /* From omap-cpufreq driver */
> + };
> +};
> +
> +/*
> + * cpu0 has different OPPs depending on SoC revision and some on revisions
> + * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
> + */
> +cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2-ti-am3352-cpu";
> + ti,syscon-efuse = <&scm_conf 0x7fc 0x1fff 0>;
> + ti,syscon-rev = <&scm_conf 0x600>;
> +
> + /*
> + * The three following nodes are marked with opp-suspend
> + * because they can not be enabled simultaneously on a
> + * single SoC.
> + */
> + opp50 at 300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <950000 931000 969000>;
> + opp-supported-hw = <0x06 0x0010>;
> + opp-suspend;
> + };
> +
> + opp100 at 275000000 {
> + opp-hz = /bits/ 64 <275000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x01 0x00FF>;
> + opp-suspend;
> + };
> +
> + opp100 at 300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + opp-microvolt = <1100000 1078000 1122000>;
> + opp-supported-hw = <0x06 0x0020>;
> + opp-suspend;
Only one OPP in the table can be marked as suspend OPP.
--
viresh
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Wenyou Yang @ 2016-11-02 3:05 UTC (permalink / raw)
To: linux-arm-kernel
The sama5d36ek CMP board is the variant of sama5d3xek board.
It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
some power rail. Its main purpose is used to measure the power
consumption.
The difference of the sama5d36ek CMP dts from sama5d36ek dts
is listed as below.
1. The USB host nodes are removed, that is, the USB host is disabled.
2. The gpio_keys node is added to wake up from the sleep.
3. The LCD isn't supported due to the pins for LCD are conflicted
with gpio_keys.
4. The adc0 node support the pinctrl sleep state to fix the over
consumption on VDDANA.
As said in errata, "When the USB host ports are used in high speed
mode (EHCI), it is not possible to suspend the ports if no device is
attached on each port. This leads to increased power consumption even
if the system is in a low power mode." That is why the the USB host
is disabled.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
Changes in v2:
- Add the pinctrl sleep state for adc0 node to fix the over
consumption on VDDANA.
- Improve the commit log.
arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
3 files changed, 482 insertions(+)
create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
new file mode 100644
index 0000000..fd6bcd6
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
@@ -0,0 +1,51 @@
+/*
+ * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "sama5d36.dtsi"
+#include "sama5d3xmb_cmp.dtsi"
+
+/ {
+ model = "Atmel SAMA5D36-EK";
+ compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ status = "okay";
+ };
+
+ ssc0: ssc at f0008000 {
+ status = "okay";
+ };
+
+ can0: can at f000c000 {
+ status = "okay";
+ };
+
+ i2c0: i2c at f0014000 {
+ status = "okay";
+ };
+
+ i2c1: i2c at f0018000 {
+ status = "okay";
+ };
+
+ macb0: ethernet at f0028000 {
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ status = "okay";
+ };
+ };
+ };
+
+ sound {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
new file mode 100644
index 0000000..77638c3
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
@@ -0,0 +1,166 @@
+/*
+ * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/ {
+ compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+ };
+
+ macb0: ethernet at f0028000 {
+ phy-mode = "rgmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy at 1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+
+ ethernet-phy at 7 {
+ reg = <0x7>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ pmic: act8865 at 5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ status = "disabled";
+
+ regulators {
+ vcc_1v8_reg: DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_1v2_reg: DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ };
+
+ vcc_3v3_reg: DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddana_reg: LDO_REG1 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddfuse_reg: LDO_REG2 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
+ };
+
+ nand0: nand at 60000000 {
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+ status = "okay";
+
+ at91bootstrap at 0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ bootloader at 40000 {
+ label = "bootloader";
+ reg = <0x40000 0x80000>;
+ };
+
+ bootloaderenv at c0000 {
+ label = "bootloader env";
+ reg = <0xc0000 0xc0000>;
+ };
+
+ dtb at 180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
+
+ kernel at 200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
+
+ rootfs at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ d2 {
+ label = "d2";
+ gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
new file mode 100644
index 0000000..62c6230
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
@@ -0,0 +1,265 @@
+/*
+ * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include "sama5d3xcm_cmp.dtsi"
+
+/ {
+ compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ mmc0: mmc at f0000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ spi0: spi at f0004000 {
+ dmas = <0>, <0>; /* Do not use DMA for spi0 */
+
+ m25p80 at 0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+ };
+
+ ssc0: ssc at f0008000 {
+ atmel,clk-from-rk-pin;
+ };
+
+ /*
+ * i2c0 conflicts with ISI:
+ * disable it to allow the use of ISI
+ * can not enable audio when i2c0 disabled
+ */
+ i2c0: i2c at f0014000 {
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck0>;
+ clock-names = "mclk";
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ ov2640: camera at 0x30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
+ resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
+ pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
+ /* use pck1 for the master clock of ov2640 */
+ clocks = <&pck1>;
+ clock-names = "xvclk";
+ assigned-clocks = <&pck1>;
+ assigned-clock-rates = <25000000>;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&isi_0>;
+ bus-width = <8>;
+ };
+ };
+ };
+ };
+
+ usart1: serial at f0020000 {
+ dmas = <0>, <0>; /* Do not use DMA for usart1 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ status = "okay";
+ };
+
+ isi: isi at f0034000 {
+ port {
+ isi_0: endpoint {
+ remote-endpoint = <&ov2640_0>;
+ bus-width = <8>;
+ vsync-active = <1>;
+ hsync-active = <1>;
+ };
+ };
+ };
+
+ mmc1: mmc at f8000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ adc0: adc at f8018000 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ >;
+ pinctrl-1 = <
+ &pinctrl_adc0_adtrg_sleep
+ &pinctrl_adc0_ad0_sleep
+ &pinctrl_adc0_ad1_sleep
+ &pinctrl_adc0_ad2_sleep
+ &pinctrl_adc0_ad3_sleep
+ &pinctrl_adc0_ad4_sleep
+ >;
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ phy-mode = "rmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy at 1 {
+ /*interrupt-parent = <&pioE>;*/
+ /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
+ reg = <1>;
+ };
+ };
+
+ pinctrl at fffff200 {
+ adc0 {
+ pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
+ atmel,pins =
+ <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD19 GPIO output 0 */
+ };
+ pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
+ atmel,pins =
+ <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD20 GPIO output 0 */
+ };
+ pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
+ atmel,pins =
+ <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD21 GPIO output 0 */
+ };
+ pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
+ atmel,pins =
+ <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD22 GPIO output 0 */
+ };
+ pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
+ atmel,pins =
+ <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD23 GPIO output 0 */
+ };
+ pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
+ atmel,pins =
+ <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD24 GPIO output 0 */
+ };
+ };
+
+ board {
+ pinctrl_gpio_keys: gpio_keys {
+ atmel,pins =
+ <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
+ };
+
+ pinctrl_mmc1_cd: mmc1_cd {
+ atmel,pins =
+ <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
+ };
+
+ pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
+ };
+
+ pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
+ atmel,pins =
+ <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
+ };
+
+ pinctrl_sensor_reset: sensor_reset-0 {
+ atmel,pins =
+ <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
+ };
+
+ pinctrl_sensor_power: sensor_power-0 {
+ atmel,pins =
+ <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
+ };
+ };
+ };
+
+ dbgu: serial at ffffee00 {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+ status = "okay";
+ };
+
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+
+ usb0: gadget at 00500000 {
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+ };
+ };
+
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
+
+ atmel,model = "wm8904 @ SAMA5D3EK";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "disabled";
+ };
+
+ /* Conflict with LCD pins */
+ gpio_keys {
+ compatible = "gpio-keys";
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ pb_user1 {
+ label = "pb_user1";
+ gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
+ linux,code = <0x100>;
+ gpio-key,wakeup;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] drm/exynos: gsc: fix spelling mistakes
From: Javier Martinez Canillas @ 2016-11-02 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102022336.32299-1-colin.king@canonical.com>
Hello Colin,
On 11/01/2016 11:23 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fixes to spelling mistakes "precalser" to "prescaler"
> in dev_err messages
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v1] iio: adc: at91: add suspend and resume callback
From: Wenyou Yang @ 2016-11-02 2:40 UTC (permalink / raw)
To: linux-arm-kernel
Add suspend/resume callback, support the pinctrl sleep state when
the system suspend as well.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/iio/adc/at91_adc.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index bbdac07..ffa81a1 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -30,6 +30,7 @@
#include <linux/iio/trigger.h>
#include <linux/iio/trigger_consumer.h>
#include <linux/iio/triggered_buffer.h>
+#include <linux/pinctrl/consumer.h>
/* Registers */
#define AT91_ADC_CR 0x00 /* Control Register */
@@ -1347,6 +1348,39 @@ static int at91_adc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int at91_adc_suspend(struct device *dev)
+{
+ struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
+ struct at91_adc_state *st = iio_priv(idev);
+
+ pinctrl_pm_select_sleep_state(dev);
+ clk_disable_unprepare(st->clk);
+
+ return 0;
+}
+
+static int at91_adc_resume(struct device *dev)
+{
+ struct iio_dev *idev = platform_get_drvdata(to_platform_device(dev));
+ struct at91_adc_state *st = iio_priv(idev);
+
+ clk_prepare_enable(st->clk);
+ pinctrl_pm_select_default_state(dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops at91_adc_pm_ops = {
+ .suspend = at91_adc_suspend,
+ .resume = at91_adc_resume,
+};
+
+#define AT91_ADC_PM_OPS (&at91_adc_pm_ops)
+#else
+#define AT91_ADC_PM_OPS NULL
+#endif
+
static struct at91_adc_caps at91sam9260_caps = {
.calc_startup_ticks = calc_startup_ticks_9260,
.num_channels = 4,
@@ -1441,6 +1475,7 @@ static struct platform_driver at91_adc_driver = {
.driver = {
.name = DRIVER_NAME,
.of_match_table = of_match_ptr(at91_adc_dt_ids),
+ .pm = AT91_ADC_PM_OPS,
},
};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: spear: Fix error handling
From: Viresh Kumar @ 2016-11-02 2:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029135839.6388-1-christophe.jaillet@wanadoo.fr>
On Sat, Oct 29, 2016 at 7:28 PM, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> 'clk_get_sys()' returns an error pointer in case of error, not NULL. So
> test it with IS_ERR.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> arch/arm/mach-spear/time.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH] drm/exynos: gsc: fix spelling mistakes
From: Colin King @ 2016-11-02 2:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fixes to spelling mistakes "precalser" to "prescaler"
in dev_err messages
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 147ef0d..9587157 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1433,7 +1433,7 @@ static int fimc_ippdrv_start(struct device *dev, enum drm_exynos_ipp_cmd cmd)
&img_pos[EXYNOS_DRM_OPS_SRC],
&img_pos[EXYNOS_DRM_OPS_DST]);
if (ret) {
- dev_err(dev, "failed to set precalser.\n");
+ dev_err(dev, "failed to set prescaler.\n");
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 52a9d26..bef5798 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1610,7 +1610,7 @@ static int gsc_ippdrv_start(struct device *dev, enum drm_exynos_ipp_cmd cmd)
&img_pos[EXYNOS_DRM_OPS_SRC],
&img_pos[EXYNOS_DRM_OPS_DST]);
if (ret) {
- dev_err(dev, "failed to set precalser.\n");
+ dev_err(dev, "failed to set prescaler.\n");
return ret;
}
--
2.9.3
^ permalink raw reply related
* [linux-sunxi] Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Chen-Yu Tsai @ 2016-11-02 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031062836.mnzdprqfezrfkx4g@rob-hp-laptop>
On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring <robh@kernel.org> wrote:
> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>
> For the binding,
>
> Acked-by: Rob Herring <robh@kernel.org>
>
> One code comment below...
>
>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++++++++++++++++++++++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>> - Video port 0 for RGB input
>> - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>> Example
>> -------
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..59781e031220 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>> #include <linux/module.h>
>> #include <linux/of_graph.h>
>> +#include <linux/regulator/consumer.h>
>>
>> #include <drm/drmP.h>
>> #include <drm/drm_atomic_helper.h>
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>> struct drm_connector connector;
>>
>> struct i2c_adapter *ddc;
>> + struct regulator *vdd;
>> };
>>
>> static inline struct dumb_vga *
>> @@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>> return 0;
>> }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> + int ret;
>> +
>> + if (!IS_ERR(vga->vdd)) {
>
> if (IS_ERR())
> return;
>
> ...will save some intentation.
I thought about that, though if someone were to add more stuff to
this, such as an enable GPIO, they might have to rework it. A standalone
block of code would be easier to work with. I'm OK either way though.
ChenYu
>
>> + ret = regulator_enable(vga->vdd);
>> +
>> + if (ret) {
>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> + return;
>> + }
>> + }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (!IS_ERR(vga->vdd))
>> + regulator_disable(vga->vdd);
>> +}
>> +
>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>> .attach = dumb_vga_attach,
>> + .enable = dumb_vga_enable,
>> + .disable = dumb_vga_disable,
>> };
>>
>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>> return -ENOMEM;
>> platform_set_drvdata(pdev, vga);
>>
>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>> + if (IS_ERR(vga->vdd)) {
>> + ret = PTR_ERR(vga->vdd);
>> + if (ret == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
>> + }
>> +
>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>> if (IS_ERR(vga->ddc)) {
>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>> --
>> 2.9.3
>>
>
> --
> 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 at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] clk: qoriq: add ls1046a support
From: Stephen Boyd @ 2016-11-02 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473220110-22159-1-git-send-email-shh.xie@gmail.com>
On 09/07, shh.xie at gmail.com wrote:
> From: Mingkai Hu <mingkai.hu@nxp.com>
>
> Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
Would have been nice to have some blurb here about the chip being
supported, but ok.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: qoriq: add ls1046a support
From: Stephen Boyd @ 2016-11-02 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473220110-22159-1-git-send-email-shh.xie@gmail.com>
On 09/07, shh.xie at gmail.com wrote:
> From: Mingkai Hu <mingkai.hu@nxp.com>
>
> Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: stm32f4: don't assume 48MHz clock is derived from primary PLL
From: Stephen Boyd @ 2016-11-02 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN8YU5MFX0cwUv34fAL3PSaRQNhgPZFO3PiXBdE+fVeLgGJ8ZQ@mail.gmail.com>
On 09/12, Andrea Merello wrote:
> On Fri, Sep 9, 2016 at 11:57 AM, Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
> > Hi Andrea,
> >
> > On 09/08/2016 09:01 AM, Andrea Merello wrote:
> >>
> >> This driver just look at the PLLs configurations set by the
> >> bootloader, but it assumes the 48MHz clock is derived from the primary
> >> PLL; however using PLLSAI is another option for generating the 48MHz
> >> clock.
> >>
> >> This patch make the driver to check for this, and eventually adjust the
> >> clock tree accordingly
> >
> >
> > Another patch-set is ongoing concerning RTC clock for stm32f4. It is
> > developed by Gabriel Fernandez (I add him directly in this reply).
> > Can you check with him how he plans to manage this RTC clock in order to
> > have something similar / coherent for SAI clocks, 48MHz ....
> >
> > Concerning this patch,
> > When I look at the clock tree I see that 48 MHz is only provided by pll
> > named "PLL". So If you use PLL SAI to provide a clock at 48 MHz, you
> > actually use SAI_A or SAI_B clock. I'm right ?
>
> No, SAI_A and SAI_B are two other clocks output, that comes from
> PLLSAI through other divisors and muxes; here I simply look at if the
> bootloader selected the "PLL48CLK" output of the SAI PLL instead of
> the "PLL48CLK" of the primary PLL.
>
> > I think we need to have something more configurable. Each special clock (SAI
> > / RTC /LCd ...) have to be configurable and each "parents" (PLL / PLLI2S /
> > PLLSAI) should be described at least in the driver.
>
> Yes, there are probably other possible clock configurations that the
> driver does not recognize yet; I just added this one because I found
> it useful in real-world scenario (USB/SDcard working and core running
> at the max speed at the same time).
>
> >
> > Gabriel,
> >
> > Can you send a draft of your patch-set for RTC clock to Andrea, in order to
> > discuss about this topic.
> >
> > Thanks
I know this is a couple months old, but the RTC patches have been
applied. Please resend this patch rebased onto clk-next and
restart this discussion if this is still important.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v4 1/1] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Stephen Boyd @ 2016-11-02 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474789673-3837-2-git-send-email-mw@semihalf.com>
On 09/25, Marcin Wojtas wrote:
> Now that we have clk_hw based provider APIs to register clks, we
> can get rid of struct clk pointers while registering clks in Armada
> CP110 system controller driver. This commit introduces new
> API and registration for all clocks in CP110 HW blocks.
>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: nxp: clk-lpc18xx-ccu: Unmap region obtained by of_iomap
From: Stephen Boyd @ 2016-11-02 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474367987-15808-1-git-send-email-arvind.yadav.cs@gmail.com>
On 09/20, Arvind Yadav wrote:
> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>
> Free memory mapping, if lpc18xx_ccu_init is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: lpc32xx: add a quirk for PWM and MS clock dividers
From: Stephen Boyd @ 2016-11-02 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475803015-4067-1-git-send-email-vz@mleia.com>
On 10/07, Vladimir Zapolskiy wrote:
> In common clock framework CLK_DIVIDER_ONE_BASED or'ed with
> CLK_DIVIDER_ALLOW_ZERO flags indicates that
> 1) a divider clock may be set to zero value,
> 2) divider's zero value is interpreted as a non-divided clock.
>
> On the LPC32xx platform clock dividers of PWM and memory card clocks
> comply with the first condition, but zero value means a gated clock,
> thus it may happen that the divider value is not updated when
> the clock is enabled and the clock remains gated.
>
> The change adds one-shot quirks, which check for zero value of divider
> on initialization and set it to a non-zero value, therefore in runtime
> a gate clock will work as expected.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: qoriq: Don't allow CPU clocks higher than starting value
From: Stephen Boyd @ 2016-11-02 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476729743-15563-1-git-send-email-oss@buserror.net>
On 10/17, Scott Wood wrote:
> The boot-time frequency of a CPU is considered its rated maximum, as we
> have no other source of such information. However, this was previously
> only used for chips with 80% restrictions on secondary PLLs. This
> usually wasn't a problem because most chips/configs boot with a divider
> of /1, with other dividers being used only for dynamic frequency
> reduction. However, at least one config (LS1021A at less than 1 GHz)
> uses a different divider for top speed. This was causing cpufreq to set
> a frequency beyond the chip's rated speed.
>
> This is fixed by applying a 100%-of-initial-speed limit to all CPU PLLs,
> similar to the existing 80% limit that only applied to some.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Cc: stable at vger.kernel.org
> ---
All silence, so I applied to clk-fixes because presumably this is
some sort of badness we need to fix quickly.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] clk: imx: clk-imx6ul: add clk support for imx6ull
From: Stephen Boyd @ 2016-11-02 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477969343-19887-4-git-send-email-peter.chen@nxp.com>
On 11/01, Peter Chen wrote:
> clks[IMX6UL_CLK_USDHC1] = imx_clk_gate2("usdhc1", "usdhc1_podf", base + 0x80, 2);
> clks[IMX6UL_CLK_USDHC2] = imx_clk_gate2("usdhc2", "usdhc2_podf", base + 0x80, 4);
> - clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
> - clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
> + if (clk_on_imx6ul()) {
> + clks[IMX6UL_CLK_SIM1] = imx_clk_gate2("sim1", "sim_sel", base + 0x80, 6);
> + clks[IMX6UL_CLK_SIM2] = imx_clk_gate2("sim2", "sim_sel", base + 0x80, 8);
> + }
> clks[IMX6UL_CLK_EIM] = imx_clk_gate2("eim", "eim_slow_podf", base + 0x80, 10);
> clks[IMX6UL_CLK_PWM8] = imx_clk_gate2("pwm8", "perclk", base + 0x80, 16);
> clks[IMX6UL_CLK_UART8_IPG] = imx_clk_gate2("uart8_ipg", "ipg", base + 0x80, 14);
> @@ -430,6 +478,7 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
> clk_set_rate(clks[IMX6UL_CLK_ENET_REF], 50000000);
> clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 50000000);
> clk_set_rate(clks[IMX6UL_CLK_CSI], 24000000);
> + clk_set_rate(clks[IMX6UL_CLK_PLL3_PFD2], 320000000);
Can you use assigned clock rates for this instead?
>
> /* keep all the clks on just for bringup */
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Stephen Boyd @ 2016-11-02 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CLMtyZStgDzdiSHo9s8BhXyiapWqDx1L_TmMpH13043g@mail.gmail.com>
On 10/28, Fabio Estevam wrote:
> On Fri, Oct 28, 2016 at 4:13 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> > The clk-fixes branch is for patches that fix problems in code
> > merged during the merge window as well as small one-liners and
> > things that are causing great pain for people on the latest
> > release. Given that this fixes a regression in v4.8 and we're
> > trying to stabilize v4.9 it looked like it could wait until
> > v4.10.
>
> The regression affects 4.8 and 4.9.
>
> > So is there something going on here where the pain is too much to
> > wait for the next merge window? If so the commit text should
>
> Yes, people reported HDMI issues because of this bug:
> https://www.spinics.net/lists/arm-kernel/msg535304.html
>
> > mention something about what's causing that pain. Perhaps by
> > referencing the commit that merged outside of clk tree that
> > caused problems.
>
> This patch clearly states that the problem is caused by ba7f4f557eb6
> ("clk: imx: correct AV PLL rate formula").
That commit isn't outside of clk tree :(
>
> Since this is a regression, I don't understand why we need to wait
> until 4.10 to get it applied.
Because we're stabilizing the 4.9-rc series and not the 4.8-rc
series and the assumption is people tested code no 4.8 before it
was released. But in cases where that doesn't happen and the bugs
cause problems with testing the latest rc series we just apply
the patch. It sounds like in this case that happened, so I'll
move this patch over to fixes.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: socfpga: updates for socfpga_defconfig
From: Alan Tull @ 2016-11-01 23:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables the following in the
socfpga_defconfig:
+CONFIG_OF_OVERLAY=y
Enable support for Device Tree Overlays
+CONFIG_FPGA_REGION=y
Enable device tree overlay support for FPGA
programming
+CONFIG_FPGA_MGR_SOCFPGA_A10=y
Enable partial reconfiguration for Altera
Arria 10 FPGA
+CONFIG_FPGA_BRIDGE=y
Enable the FPGA Bridges framework
+CONFIG_SOCFPGA_FPGA_BRIDGE=y
Enable support for SoCFPGA hardware
bridges
+CONFIG_ALTERA_FREEZE_BRIDGE=y
Enable support for the Altera Soft IP
Freeze bridges
Signed-off-by: Alan Tull <atull@opensource.altera.com>
---
arch/arm/configs/socfpga_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index f5b9bc5..18d3ec1 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -54,6 +54,7 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y
+CONFIG_OF_OVERLAY=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=8192
@@ -105,7 +106,12 @@ CONFIG_DMADEVICES=y
CONFIG_PL330_DMA=y
CONFIG_DMATEST=m
CONFIG_FPGA=y
+CONFIG_FPGA_REGION=y
CONFIG_FPGA_MGR_SOCFPGA=y
+CONFIG_FPGA_MGR_SOCFPGA_A10=y
+CONFIG_FPGA_BRIDGE=y
+CONFIG_SOCFPGA_FPGA_BRIDGE=y
+CONFIG_ALTERA_FREEZE_BRIDGE=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's
From: Joshua Clayton @ 2016-11-01 23:51 UTC (permalink / raw)
To: linux-arm-kernel
imx-weim should always set address-cells to 2,
and size_cells to 1.
On imx6, fsl,weim-cs-gpr will always be &gpr
Set these common parameters in the dtsi file,
rather than in a downstream dts.
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
arch/arm/boot/dts/imx6q-evi.dts | 3 ---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 2 --
arch/arm/boot/dts/imx6qdl.dtsi | 3 +++
arch/arm/boot/dts/imx6sl.dtsi | 3 +++
arch/arm/boot/dts/imx6sx.dtsi | 3 +++
5 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index bd0b85c..a88cbd8 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -241,10 +241,7 @@
};
&weim {
- #address-cells = <2>;
- #size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
- fsl,weim-cs-gpr = <&gpr>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_weimfpga &pinctrl_weimcs>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 8006467..52390ba 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -613,8 +613,6 @@
&weim {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
- #address-cells = <2>;
- #size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
status = "disabled"; /* pin conflict with SPI NOR */
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 1bbd36f..d7bed1f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1092,10 +1092,13 @@
};
weim: weim at 021b8000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_EIM_SLOW>;
+ fsl,weim-cs-gpr = <&gpr>;
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 02378db..c2b28c0 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -893,8 +893,11 @@
};
weim: weim at 021b8000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+ fsl,weim-cs-gpr = <&gpr>;
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 9526c38..78eb023 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -968,10 +968,13 @@
};
weim: weim at 021b8000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
compatible = "fsl,imx6sx-weim", "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_EIM_SLOW>;
+ fsl,weim-cs-gpr = <&gpr>;
};
ocotp: ocotp at 021bc000 {
--
2.7.4
^ permalink raw reply related
* [PATCH] clk: rockchip: optimize the configuration for 800MHz and 1GHz on RK3399
From: Heiko Stuebner @ 2016-11-01 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477970526-26388-1-git-send-email-zhengxing@rock-chips.com>
Am Dienstag, 1. November 2016, 11:22:06 CET schrieb Xing Zheng:
> Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399.
> But dues to the carelessly copying from RK3036 when the RK3399 bringing up,
> the refdiv == 6, it will increase the lock time, and it is not an optimal
> configuration.
>
> Please let's fix them for the lock time and jitter are lower:
> 800 MHz:
> - FVCO == 2.4 GHz, revdiv == 1.
> 1 GHz:
> - FVCO == 3 GHz, revdiv == 1.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
applied to my clk-branch for 4.10
Thanks
Heiko
^ permalink raw reply
* [PATCH v3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Bjorn Andersson @ 2016-11-01 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbipgysCjQDgvBhex7SewVaV379gL-wsZuHCY4Mz1p-aw@mail.gmail.com>
On Tue 01 Nov 04:31 PDT 2016, Linus Walleij wrote:
> On Mon, Oct 31, 2016 at 11:20 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
>
> >> + interrupt-parent = <&pm8058_gpio>;
> >> + interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
> >
> > To remove the need of resetting the interrupt-parent in each child you
> > can use the following form:
> >
> > interrupts-extended = <&pm8058_gpio 208 IRQ_TYPE_EDGE_FALLING>;
> >
> > But, if we correct the ssbi gpio driver then this would no longer be
> > interrupt 208 in this parent, right?. I believe that if you say
> > <&pmicintc 208 IRQ_TYPE_EDGE_FALLING> instead, which should work even
> > after we correct the gpio translation.
>
> Yes. It should be fixed everywhere but is not related to this
> patch. But I can do a two-patch series first fixing this and then
> adding the gyro+accelerometer on top referencing the MFD
> pmicintc as parent.
>
Sorry, I'm not sure I'm following.
What I tried to say was that before the correction of the GPIO block's
window this particular IRQ would be #208 in &pmicintc and #208 in
&pm8058_gpio. After the correction of the window the IRQ is #208 in
&pmicintc and #17 in &pm8058_gpio.
As such, using #208 from &pmicintc would make this work through the
correction of the GPIO driver. Perhaps I'm wrong about this?
Either way, it's no big deal. I'm fine with either path.
> > (Which probably means we need to get that redesigned, before we
> > introduce to many of these)
>
> What needs to happen is for the SSBI and SPMI GPIO to use a
> hierarchical irqdomain so their GPIO local line offset and hwirq
> are the same. Then we can reference the GPIO IRQ lines directly
> in a correct manner.
>
Right. Do you have any example of drivers getting this right? I did take
a quick look but didn't find one.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v8 1/3] ARM: dts: da850: Add cfgchip syscon node
From: David Lechner @ 2016-11-01 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3617c00-1f1d-5ab8-23e9-a96307a53558@ti.com>
On 11/01/2016 04:53 AM, Sekhar Nori wrote:
> Hi David,
>
> On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
>> Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
>> for the USB PHY that is part of this range of registers.
>>
>> Also have to add OF_DEV_AUXDATA() entry so that clock lookup will work for
>> the the USB PHY driver.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> For future, please do not combine device-tree addition and other C code into a
> single patch. I have applied this patch while splitting it into two as
> attached.
>
Sorry. I should know that by now. :-/
Thank you for fixing it for me.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox