* [PATCH v4 0/3] Renesas R9A06G032 SMP enabler
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Frank Rowand,
Douglas Anderson, Maxime Ripard, Chen-Yu Tsai, Carlo Caione,
Florian Fainelli, Andreas Färber, Rajendra Nayak,
Stefan Wahren, devicetree, linux-kernel, linux-arm-kernel
*WARNING -- this requires the base R9A06G032 support patches
already posted
This patch series is for enabling the second CA7 of the R9A06G032.
It's based on a spin_table method, and it reuses the same binding
property as that driver.
v4:
+ Geert's comments adressed.
+ Renamed symbols to r9a06g032 to match the rest of patchset
+ Rebased on base patch v8
v3:
+ Removed mentions of rz/?n1d?
+ Rebased on base patch v7
v2:
+ Added suggestions from Florian Fainelli
+ Use __pa_symbol()
+ Simplified logic in prepare_cpu()
+ Reordered the patches
+ Rebased on RZN1 Base patch v5
Michel Pollet (3):
dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
arm: shmobile: Add the R9A06G032 SMP enabler driver
ARM: dts: Renesas R9A06G032 SMP enable method
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/r9a06g032.dtsi | 3 +
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 79 ++++++++++++++++++++++++++
4 files changed, 84 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Carlo Caione,
Maxime Ripard, Douglas Anderson, Kevin Hilman, Frank Rowand,
Florian Fainelli, Rajendra Nayak, Chen-Yu Tsai, Stefan Wahren,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1528198148-23308-1-git-send-email-michel.pollet@bp.renesas.com>
Add a special enable method for second CA7 of the R9A06G032
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 29e1dc5..b395d107 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -219,6 +219,7 @@ described below.
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
+ "renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Florian Fainelli,
Chen-Yu Tsai, Douglas Anderson, Andreas Färber,
Rajendra Nayak, Stefan Wahren, Frank Rowand, Carlo Caione,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1528198148-23308-1-git-send-email-michel.pollet@bp.renesas.com>
The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
requires a special enable method to get it started.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
---
arch/arm/mach-shmobile/Makefile | 1 +
arch/arm/mach-shmobile/smp-r9a06g032.c | 79 ++++++++++++++++++++++++++++++++++
2 files changed, 80 insertions(+)
create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 1939f52..d7fc98f 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
+smp-$(CONFIG_ARCH_R9A06G032) += smp-r9a06g032.o
smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
# PM objects
diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c b/arch/arm/mach-shmobile/smp-r9a06g032.c
new file mode 100644
index 0000000..cd40e6e
--- /dev/null
+++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * R9A06G032 Second CA7 enabler.
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
+ * Derived from action,s500-smp
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/smp.h>
+
+/*
+ * The second CPU is parked in ROM at boot time. It requires waking it after
+ * writing an address into the BOOTADDR register of sysctrl.
+ *
+ * So the default value of the "cpu-release-addr" corresponds to BOOTADDR...
+ *
+ * *However* the BOOTADDR register is not available when the kernel
+ * starts in NONSEC mode.
+ *
+ * So for NONSEC mode, the bootloader re-parks the second CPU into a pen
+ * in SRAM, and changes the "cpu-release-addr" of linux's DT to a SRAM address,
+ * which is not restricted.
+ */
+
+static void __iomem *cpu_bootaddr;
+
+static DEFINE_SPINLOCK(cpu_lock);
+
+static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ if (!cpu_bootaddr)
+ return -ENODEV;
+
+ spin_lock(&cpu_lock);
+
+ writel(__pa_symbol(secondary_startup), cpu_bootaddr);
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ spin_unlock(&cpu_lock);
+
+ return 0;
+}
+
+static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *dn;
+ int ret;
+ u32 bootaddr;
+
+ dn = of_get_cpu_node(1, NULL);
+ if (!dn) {
+ pr_err("CPU#1: missing device tree node\n");
+ return;
+ }
+ /*
+ * Determine the address from which the CPU is polling.
+ * The bootloader *does* change this property
+ */
+ ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
+ of_node_put(dn);
+ if (ret) {
+ pr_err("CPU#1: invalid cpu-release-addr property\n");
+ return;
+ }
+ pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
+
+ cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr));
+}
+
+static const struct smp_operations r9a06g032_smp_ops __initconst = {
+ .smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
+ .smp_boot_secondary = r9a06g032_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp", &r9a06g032_smp_ops);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Michel Pollet @ 2018-06-05 11:28 UTC (permalink / raw)
To: linux-renesas-soc, Simon Horman
Cc: phil.edworthy, Michel Pollet, Michel Pollet, Rob Herring,
Mark Rutland, Magnus Damm, Russell King, Carlo Caione,
Maxime Ripard, Andreas Färber, Frank Rowand, Rajendra Nayak,
Stefan Wahren, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1528198148-23308-1-git-send-email-michel.pollet@bp.renesas.com>
Add a special enable method for the second CA7 of the R9A06G032
as well as the default value for the "cpu-release-addr" property.
Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
---
arch/arm/boot/dts/r9a06g032.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/r9a06g032.dtsi b/arch/arm/boot/dts/r9a06g032.dtsi
index 40827bb..9d7e74a 100644
--- a/arch/arm/boot/dts/r9a06g032.dtsi
+++ b/arch/arm/boot/dts/r9a06g032.dtsi
@@ -1,3 +1,4 @@
+
// SPDX-License-Identifier: GPL-2.0
/*
* Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
@@ -30,6 +31,8 @@
compatible = "arm,cortex-a7";
reg = <1>;
clocks = <&sysctrl R9A06G032_CLK_A7MP>;
+ enable-method = "renesas,r9a06g032-smp";
+ cpu-release-addr = <0x4000c204>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] dt: bindings: add bindings for msa memory region
From: Govind Singh @ 2018-06-05 12:36 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Govind Singh
Add device tree binding documentation details of msa
memory region for ath10k qmi client for SDM845/APQ8098
SoC into "qcom,ath10k.txt".
Signed-off-by: Govind Singh <govinds-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
.../devicetree/bindings/net/wireless/qcom,ath10k.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 7fd4e8ce4149..0efc47f4ba34 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -56,6 +56,8 @@ Optional properties:
the length can vary between hw versions.
- <supply-name>-supply: handle to the regulator device tree node
optional "supply-name" is "vdd-0.8-cx-mx".
+- msa-fixed-region: phandle, specifier to children of reserved MSA memory.
+- msa-size: MSA memory size for fw internal use.
Example (to supply the calibration data alone):
@@ -133,6 +135,8 @@ wifi@18000000 {
compatible = "qcom,wcn3990-wifi";
reg = <0x18800000 0x800000>;
reg-names = "membase";
+ msa-fixed-region = <&wlan_msa_mem>;
+ msa-size = <0x100000>;
clocks = <&clock_gcc clk_aggre2_noc_clk>;
clock-names = "smmu_aggre2_noc_clk"
interrupts =
--
2.17.0
^ permalink raw reply related
* [PATCH V2] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 12:47 UTC (permalink / raw)
To: linux-kernel, jason, andrew, gregory.clement,
sebastian.hesselbarth, robh+dt, mark.rutland, linux-arm-kernel,
devicetree
Cc: Dennis Gilmore
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 315 +++++++++++++++++++++++
2 files changed, 316 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index 000000000000..16026bedc380
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x80000000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-state = "off";
+ };
+ sata3-led {
+ label = "helios4:green:ata3";
+ gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata3";
+ default-state = "off";
+ };
+ sata4-led {
+ label = "helios4:green:ata4";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata4";
+ default-state = "off";
+ };
+ usb-led {
+ label = "helios4:green:usb";
+ gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "usb-host";
+ default-state = "off";
+ };
+ };
+
+ fan1: j10-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
+ };
+
+ fan2: j17-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
+ };
+
+ usb2_phy: usb2-phy {
+ compatible = "usb-nop-xceiv";
+ vbus-regulator = <®_5p0v_usb>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ //vbus-regulator = <®_5p0v_usb>;
+ };
+
+ soc {
+ internal-regs {
+ i2c@11000 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-Board Revision bit 0 #
+ * 1-Board Revision bit 1 #
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ */
+ expander0: gpio-expander@20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655",
+ * "nxp,pca9555";
+ * but you can't do this because of
+ * the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pca0_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ board_rev_bit_0 {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-0";
+ };
+ board_rev_bit_1 {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-1";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "usb-overcurrent-status";
+ };
+ };
+
+ temp_sensor: temp@4c {
+ compatible = "ti,lm75";
+ reg = <0x4c>;
+ vcc-supply = <®_3p3v>;
+ };
+ };
+
+ i2c@11100 {
+ /*
+ * External I2C Bus for user peripheral
+ */
+ clock-frequency = <400000>;
+ pinctrl-0 = <&helios_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sata@a8000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata0: sata-port@0 {
+ reg = <0>;
+ };
+
+ sata1: sata-port@1 {
+ reg = <1>;
+ };
+ };
+
+ sata@e0000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata2: sata-port@0 {
+ reg = <0>;
+ };
+
+ sata3: sata-port@1 {
+ reg = <1>;
+ };
+ };
+
+ spi@10680 {
+ pinctrl-0 = <&spi1_pins
+ µsom_spi1_cs_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sdhci@d8000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-0 = <&helios_sdhci_pins
+ &helios_sdhci_cd_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc = <®_3p3v>;
+ wp-inverted;
+ };
+
+ usb@58000 {
+ //vcc-supply = <®_5p0v_usb>;
+ usb-phy = <&usb2_phy>;
+ status = "okay";
+ };
+
+ usb3@f0000 {
+ status = "okay";
+ };
+
+ usb3@f8000 {
+ status = "okay";
+ };
+
+ pinctrl@18000 {
+ pca0_pins: pca0-pins {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ microsom_phy0_int_pins: microsom-phy0-int-pins {
+ marvell,pins = "mpp18";
+ marvell,function = "gpio";
+ };
+ helios_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ helios_sdhci_cd_pins: helios-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+ helios_led_pins: helios-led-pins {
+ marvell,pins = "mpp24", "mpp25",
+ "mpp49", "mpp50",
+ "mpp52", "mpp53",
+ "mpp54";
+ marvell,function = "gpio";
+ };
+ helios_fan_pins: helios-fan-pins {
+ marvell,pins = "mpp41", "mpp43",
+ "mpp48", "mpp55";
+ marvell,function = "gpio";
+ };
+ microsom_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp59";
+ marvell,function = "spi1";
+ };
+ };
+ };
+ };
+};
--
2.17.1
^ permalink raw reply related
* Re: Re: [PATCH v2 00/26] arm64: allwinner: Add A64 DE2 HDMI support
From: Jagan Teki @ 2018-06-05 12:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, Jernej Skrabec, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180518095913.nzl3sr5wn6cg4ra5@flea>
On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
<maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
>> Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5.
>>
>> A64 behaviour similar to Allwinner A83T where
>> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
>> Mixer1 => TCON1 => HDMI
>> as per Display System Block DiagramAllwinner_A64_User_Manual_V1.1.pdf
>>
>> This is second patch-set followed with previous RFC[1] and first series[2]
>> and merely concentrated on HDMI pipeline through TCON1 and rest will add eventually.
>>
>> This series fixed previous version comments
>> - about documenting fallback compatibles
>> - adding new compatible for mixer1
>> - support for multiple DW HDMI PHY clock parents (thanks, to Jernej)
>>
>> Note:
>> Pine64 boards are unable to get edid by default like other A64 boards,
>> but forcing 'video=HDMI-A-1:1920x1080@60D' kernel command line can
>> create edid with display on penel.
>
> There's no point in trying to push this without the SRAM issue being
> solved. It is required, and won't be merged unless this is addressed.
is SRAM issue resolved? if so may be I will try to test it on top.
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
From: Sricharan R @ 2018-06-05 12:56 UTC (permalink / raw)
To: Vinod
Cc: bjorn.andersson, ohad, robh+dt, mark.rutland, andy.gross,
david.brown, linux-remoteproc, devicetree, linux-kernel,
linux-arm-msm, linux-soc, sibis
In-Reply-To: <20180605061919.GQ16230@vkoul-mobl>
Hi Vinod,
On 6/5/2018 11:49 AM, Vinod wrote:
> On 05-06-18, 11:12, Sricharan R wrote:
>
>> +config QCOM_Q6V5_WCSS
>> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
>> + depends on OF && ARCH_QCOM
>> + depends on QCOM_SMEM
>> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
>> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
>
> Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would
> happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM
>
RPMSG_QCOM_GLINK_SMEM=n should be for the COMPILE_TEST. Probably that
means that it should be corrected here and for ADSP, Q6V5_PIL as well.
Bjorn, is that correct ?, should it be, below ?
depends on (RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)) || (RPMSG_QCOM_GLINK_SMEM || (COMPILE_TEST && RPMSG_QCOM_GLINK_SMEM=n))
>> +/* QDSP6SS Register Offsets */
>> +#define QDSP6SS_RESET_REG 0x014
>> +#define QDSP6SS_GFMUX_CTL_REG 0x020
>> +#define QDSP6SS_PWR_CTL_REG 0x030
>> +#define QDSP6SS_MEM_PWR_CTL 0x0B0
>> +
>> +/* AXI Halt Register Offsets */
>> +#define AXI_HALTREQ_REG 0x0
>> +#define AXI_HALTACK_REG 0x4
>> +#define AXI_IDLE_REG 0x8
>> +
>> +#define HALT_ACK_TIMEOUT_MS 100
>> +
>> +/* QDSP6SS_RESET */
>> +#define Q6SS_STOP_CORE BIT(0)
>> +#define Q6SS_CORE_ARES BIT(1)
>> +#define Q6SS_BUS_ARES_ENABLE BIT(2)
>
> Wouldn't it be nice if the defines are all consistent, some of them are
> QDSP6SS_xxx, some Q6SS_ some are not
>
> Please do pick one and make it consistent :)
>
ok.
>> +/* QDSP6v56 parameters */
>> +#define QDSP6v56_LDO_BYP BIT(25)
>> +#define QDSP6v56_BHS_ON BIT(24)
>> +#define QDSP6v56_CLAMP_WL BIT(21)
>> +#define QDSP6v56_CLAMP_QMC_MEM BIT(22)
>> +#define HALT_CHECK_MAX_LOOPS 200
>> +#define QDSP6SS_XO_CBCR 0x0038
>
> GENMASK() perhaps?
>
ok.
>> +static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
>> +{
>> + int ret;
>> + u32 val;
>> + int i;
>
> int ret, i;
>
>> +static int q6v5_wcss_start(struct rproc *rproc)
>> +{
>> + struct q6v5_wcss *wcss = rproc->priv;
>> + int ret;
>> +
>> + qcom_q6v5_prepare(&wcss->q6v5);
>> +
>> + /* Release Q6 and WCSS reset */
>> + ret = reset_control_deassert(wcss->wcss_reset);
>> + if (ret) {
>> + dev_err(wcss->dev, "wcss_reset failed\n");
>> + return ret;
>> + }
>> +
>> + ret = reset_control_deassert(wcss->wcss_q6_reset);
>> + if (ret) {
>> + dev_err(wcss->dev, "wcss_q6_reset failed\n");
>> + goto wcss_reset;
>> + }
>> +
>> + /* Lithium configuration - clock gating and bus arbitration */
>> + ret = regmap_update_bits(wcss->halt_map,
>> + wcss->halt_nc + TCSR_GLOBAL_CFG0,
>> + 0x1F, 0x14);
>
> magic numbers??
>
ok, will find out what it is for this one and below.
But atleast from register map could not find out and
these are sort of hardcoded sequences coming from the hw
folks. So will have to reach out to them to find the specifics.
>> +static int q6v5_wcss_powerdown(struct q6v5_wcss *wcss)
>> +{
>> + int ret;
>> + u32 val;
>> +
>> + /* 1 - Assert WCSS/Q6 HALTREQ */
>> + q6v5_wcss_halt_axi_port(wcss, wcss->halt_map, wcss->halt_wcss);
>> +
>> + /* 2 - Enable WCSSAON_CONFIG */
>> + val = readl(wcss->rmb_base + SSCAON_CONFIG);
>> + val |= SSCAON_ENABLE;
>> + writel(val, wcss->rmb_base + SSCAON_CONFIG);
>> +
>> + /* 3 - Set SSCAON_CONFIG */
>> + val |= BIT(15);
>> + val &= ~BIT(16);
>> + val &= ~BIT(17);
>> + val &= ~BIT(18);
>
> wouldn't it be nice to define these bits?
>
>> +static int q6v5_q6_powerdown(struct q6v5_wcss *wcss)
>> +{
>> + int ret;
>> + u32 val;
>> + int i;
>
> int ret, i;
>
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH V2] ARM: dts: armada388-helios4
From: Gregory CLEMENT @ 2018-06-05 13:06 UTC (permalink / raw)
To: Dennis Gilmore
Cc: linux-kernel, jason, andrew, sebastian.hesselbarth, robh+dt,
mark.rutland, linux-arm-kernel, devicetree
In-Reply-To: <20180605124738.24844-1-dennis@ausil.us>
Hi Dennis,
On mar., juin 05 2018, Dennis Gilmore <dennis@ausil.us> wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
> https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
> I added a SPDX license line to match the clearfog it says it was based
> on and a compatible line for "kobol,helios4"
This patch looks good, I have only two remarks for now.
> + usb3_phy: usb3-phy {
> + compatible = "usb-nop-xceiv";
> + //vbus-regulator = <®_5p0v_usb>;
Why did you comment this line?
What about removing it, if you don't need it?
[...]
> +
> + usb@58000 {
> + //vcc-supply = <®_5p0v_usb>;
Same here
> + usb-phy = <&usb2_phy>;
> + status = "okay";
> + };
> +
Gregory
--
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: cpu: Add Renesas R9A06G032 SMP enable method.
From: Geert Uytterhoeven @ 2018-06-05 13:23 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Michel Pollet, Mark Rutland,
Phil Edworthy, Florian Fainelli, Rajendra Nayak,
Linux Kernel Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Maxime Ripard, Kevin Hilman, Stefan Wahren, Magnus Damm,
Russell King, Douglas Anderson, Chen-Yu Tsai, Rob Herring,
Carlo Caione <car>
In-Reply-To: <1528198148-23308-2-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> Add a special enable method for second CA7 of the R9A06G032
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-05 13:24 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Rob Herring, Mark Rutland, Magnus Damm, Russell King,
Florian Fainelli, Chen-Yu Tsai, Douglas Anderson,
Andreas Färber, Rajendra Nayak, Stefan Wahren, Frank Rowand,
Carlo Caione,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <1528198148-23308-3-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time, it
> requires a special enable method to get it started.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- /dev/null
> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * R9A06G032 Second CA7 enabler.
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + * Michel Pollet <michel.pollet@bp.renesas.com>, <buserror@gmail.com>
> + * Derived from action,s500-smp
actions
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Geert Uytterhoeven @ 2018-06-05 13:24 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Rob Herring, Mark Rutland, Magnus Damm, Russell King,
Carlo Caione, Maxime Ripard, Andreas Färber, Frank Rowand,
Rajendra Nayak, Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux ARM
In-Reply-To: <1528198148-23308-4-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> Add a special enable method for the second CA7 of the R9A06G032
> as well as the default value for the "cpu-release-addr" property.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM: dts: Renesas R9A06G032 SMP enable method
From: Geert Uytterhoeven @ 2018-06-05 13:24 UTC (permalink / raw)
To: Michel Pollet
Cc: Linux-Renesas, Simon Horman, Phil Edworthy, Michel Pollet,
Rob Herring, Mark Rutland, Magnus Damm, Russell King,
Carlo Caione, Maxime Ripard, Andreas Färber, Frank Rowand,
Rajendra Nayak, Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Linux ARM
In-Reply-To: <1528198148-23308-4-git-send-email-michel.pollet@bp.renesas.com>
On Tue, Jun 5, 2018 at 1:28 PM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> Add a special enable method for the second CA7 of the R9A06G032
> as well as the default value for the "cpu-release-addr" property.
>
> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- a/arch/arm/boot/dts/r9a06g032.dtsi
> +++ b/arch/arm/boot/dts/r9a06g032.dtsi
> @@ -1,3 +1,4 @@
> +
Bogus change
> // SPDX-License-Identifier: GPL-2.0
> /*
> * Base Device Tree Source for the Renesas RZ/N1D (R9A06G032)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Re: [PATCH v2 00/26] arm64: allwinner: Add A64 DE2 HDMI support
From: Maxime Ripard @ 2018-06-05 13:25 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Icenowy Zheng, Jernej Skrabec, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAMty3ZC13J+bCWK_=9816Lu-5ctC0UfF4-XR3yNSpHdH8q8Faw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]
On Tue, Jun 05, 2018 at 06:23:57PM +0530, Jagan Teki wrote:
> On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
> >> Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5.
> >>
> >> A64 behaviour similar to Allwinner A83T where
> >> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
> >> Mixer1 => TCON1 => HDMI
> >> as per Display System Block DiagramAllwinner_A64_User_Manual_V1.1.pdf
> >>
> >> This is second patch-set followed with previous RFC[1] and first series[2]
> >> and merely concentrated on HDMI pipeline through TCON1 and rest will add eventually.
> >>
> >> This series fixed previous version comments
> >> - about documenting fallback compatibles
> >> - adding new compatible for mixer1
> >> - support for multiple DW HDMI PHY clock parents (thanks, to Jernej)
> >>
> >> Note:
> >> Pine64 boards are unable to get edid by default like other A64 boards,
> >> but forcing 'video=HDMI-A-1:1920x1080@60D' kernel command line can
> >> create edid with display on penel.
> >
> > There's no point in trying to push this without the SRAM issue being
> > solved. It is required, and won't be merged unless this is addressed.
>
> is SRAM issue resolved? if so may be I will try to test it on top.
I'd expect the one working on this to push a solution to solve this.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v9 2/7] i2c: Add FSI-attached I2C master algorithm
From: Eddie James @ 2018-06-05 13:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Andy Shevchenko
Cc: linux-i2c, Linux Kernel Mailing List, devicetree, Wolfram Sang,
Rob Herring, Joel Stanley, Mark Rutland, Greg Kroah-Hartman,
Randy Dunlap
In-Reply-To: <7daf29f643bb0445fceef85b1a7fff71048f2aa6.camel@kernel.crashing.org>
On 06/04/2018 06:38 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2018-06-04 at 22:21 +0300, Andy Shevchenko wrote:
>>> +#define I2C_INT_ENABLE 0x0000ff80
>>> +#define I2C_INT_ERR 0x0000fcc0
>> Now it looks like a flags combinations.
>> For me as for reader would be better to see quickly a decoded line.
>>
>> My proposal is to introduce something like following
>>
>> _INT_ALL GENMASK()
>> _INT_ENABLE (_INT_ALL & ~(_FOO | _BAR))
>> _INT_ERR ... similar way as above ...
>>
>> What do you think?
> I don't think this absolutely needs to change but yes, open coding is
> error prone. However I would think it more readable to use positive
> logic and just list all the bits that are *set* even if it's a bit more
> text:
>
> #define I2C_INT_ERR (I2C_INT_INV_CMD |\
> I2C_INT_PARITY |\
> I2C_INT_BE_OVERRUN |\
> .../...)
>
> #define I2C_INT_ENABLE (I2C_INT_ERR |\
> I2C_INT_DAT_REQ |\
> I2C_INT_CMD_COMP)
>
> Note: Eddie, I notice I2C_INT_BUSY is in "ERR" but not in "ENABLE", any
> reason for that ?
Yes, we don't want to enable an interrupt if I2C gets into the busy
state, as that happens during every transfer. However it would likely
be an error condition if we get that when the transfer is supposed to be
complete. These were from the legacy driver... I just realized that
neither are actually being used in this driver, so I will drop them.
Thanks,
Eddie
>
> Cheers,
> Ben.
>
^ permalink raw reply
* Re: [PATCH v7 1/5] drm/rockchip: add transfer function for cdn-dp
From: Heiko Stübner @ 2018-06-05 13:42 UTC (permalink / raw)
To: Lin Huang
Cc: devicetree, airlied, linux-kernel, briannorris, dianders,
dri-devel, kishon, linux-rockchip, robh+dt, zyw, daniel.vetter,
linux-arm-kernel
In-Reply-To: <1527061353-16902-1-git-send-email-hl@rock-chips.com>
Hi,
Am Mittwoch, 23. Mai 2018, 09:42:29 CEST schrieb Lin Huang:
> From: Chris Zhong <zyw@rock-chips.com>
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> Reviewed-by: Sean Paul <seanpaul@chromium.org>
> Reviewed-by: Enric Balletbo <enric.balletbo@collabora.com>
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct
> device *master, void *data) dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> + dp->aux.name = "DP-AUX";
> + dp->aux.transfer = cdn_dp_aux_transfer;
> + dp->aux.dev = dev;
> +
> + ret = drm_dp_aux_register(&dp->aux);
> + if (ret)
> + return ret;
this is missing matching drm_dp_aux_unregister calls both in the error path as
well as in the unbind callback.
With the code as is, the kernel gives warnings about it trying to initialize
an already initialized object ... in cases like probe-deferrals.
Heiko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 2/2] dt-bindings: iio: dac: Add docs for AD5758 DAC
From: Stefan Popa @ 2018-06-05 13:53 UTC (permalink / raw)
To: jic23, Michael.Hennerich, lars
Cc: knaack.h, pmeerw, robh+dt, mark.rutland, mchehab, davem, gregkh,
akpm, linus.walleij, rdunlap, devicetree, linux-iio, linux-kernel,
stefan.popa
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
---
.../devicetree/bindings/iio/dac/ad5758.txt | 84 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 85 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5758.txt
diff --git a/Documentation/devicetree/bindings/iio/dac/ad5758.txt b/Documentation/devicetree/bindings/iio/dac/ad5758.txt
new file mode 100644
index 0000000..75fff6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ad5758.txt
@@ -0,0 +1,84 @@
+Analog Devices AD5758 DAC device driver
+
+Required properties for the AD5758:
+ - compatible: Must be "adi,ad5758"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: Max SPI frequency to use (< 50000000)
+ - spi-cpha: is the only mode that is supported
+
+Optional properties:
+
+ - adi,dc-dc-mode: Mode of operation of the dc-to-dc converter
+ The following values are currently supported:
+ * 0: DC-to-DC converter powered off
+ * 1: DPC current mode
+ * 2: DPC voltage mode
+ * 3: PPC current mode
+
+ - adi,dc-dc-ilim: The dc-to-dc converter current limit
+ The following values are currently supported [mA]:
+ * 150
+ * 200
+ * 250
+ * 300
+ * 350
+ * 400
+
+ - adi,slew: Array of slewrate settings should contain 3 fields:
+ 1: Should be either 0 or 1 in order to enable or disable slewrate.
+ 2: Slew rate clock:
+ Valid values for the slew rate update frequency [Hz]:
+ * 240000
+ * 200000
+ * 150000
+ * 128000
+ * 64000
+ * 32000
+ * 16000
+ * 8000
+ * 4000
+ * 2000
+ * 1000
+ * 512
+ * 256
+ * 128
+ * 64
+ * 16
+ 3: Slew rate step:
+ Defines by how much the output value changes at each update.
+ Valid values for the step size LSBs:
+ * 4
+ * 12
+ * 64
+ * 120
+ * 256
+ * 500
+ * 1820
+ * 2048
+
+ - adi,range: The output range
+ The following values are currently supported:
+ * 0: 0 V to 5 V voltage range
+ * 1: 0 V to 10 V voltage range
+ * 2: ±5 V voltage range
+ * 3: ±10 V voltage range
+ * 8: 0 mA to 20 mA current range
+ * 9: 0 mA to 24 mA current range
+ * 10: 4 mA to 20 mA current range
+ * 11: ±20 mA current range
+ * 12: ±24 mA current range
+ * 13: −1 mA to +22 mA current range
+
+AD5758 Example:
+
+ ad5758@0 {
+ compatible = "adi,ad5758";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ spi-cpha;
+
+ adi,dc-dc-mode = <2>;
+ adi,dc-dc-ilim = <200>;
+ adi,slew = <1 200000 12>;
+ adi,range = <1>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1993779..f640146 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -808,6 +808,7 @@ L: linux-iio@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/dac/ad5758.c
+F: Documentation/devicetree/bindings/iio/dac/ad5758.txt
ANALOG DEVICES INC AD9389B DRIVER
M: Hans Verkuil <hans.verkuil@cisco.com>
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Richard Cochran @ 2018-06-05 13:57 UTC (permalink / raw)
To: Y.b. Lu
Cc: netdev@vger.kernel.org, Madalin-cristian Bucur, Rob Herring,
Shawn Guo, David S . Miller, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR0401MB2536376432EC481473A5B4A3F8660@DB6PR0401MB2536.eurprd04.prod.outlook.com>
On Tue, Jun 05, 2018 at 03:35:28AM +0000, Y.b. Lu wrote:
> [Y.b. Lu] Actually these timestamping codes affected DPAA networking performance in our previous performance test.
> That's why we used ifdef for it.
How much does time stamping hurt performance?
If the time stamping is compiled in but not enabled at run time, does
it still affect performace?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH v3 6/6] regulator: bd71837: BD71837 PMIC regulator driver
From: Andy Shevchenko @ 2018-06-05 13:58 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Lee Jones, Liam Girdwood, Mark Brown, mazziesaccount, linux-clk,
devicetree, Linux Kernel Mailing List, mikko.mutanen,
heikki.haikola
In-Reply-To: <68b0cf2c7ab5578eef2f71a33315bc8ab9a68a39.1527587295.git.matti.vaittinen@fi.rohmeurope.com>
On Tue, May 29, 2018 at 1:02 PM, Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:
> Support for controlling the 8 bucks and 7 LDOs the PMIC contains.
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
One of these is redundant.
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/driver.h>
> +#include <linux/regulator/machine.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/gpio.h>
> +#include <linux/mfd/bd71837.h>
> +#include <linux/regulator/of_regulator.h>
Can you keep the list ordered?
> + dev_dbg(&(pmic->pdev->dev), "Buck[%d] Set Ramp = %d\n", id + 1,
> + ramp_delay);
Redundant parens.
> +static int bd71837_regulator_set_regmap(struct regulator_dev *rdev, int set)
> +{
> + int ret = -EINVAL;
Redundant assignment.
> + if (!set)
> + ret = regulator_disable_regmap(rdev);
> + else
> + ret = regulator_enable_regmap(rdev);
> + return ret;
> +}
> +static int bd71837_probe(struct platform_device *pdev)
> +{
> + pmic = devm_kzalloc(&pdev->dev, sizeof(struct bd71837_pmic),
> + GFP_KERNEL);
sizeof(*pmic) and one line as result?
> + if (!pmic)
> + return -ENOMEM;
> + if (!pmic->mfd) {
> + dev_err(&pdev->dev, "No MFD driver data\n");
> + err = -EINVAL;
> + goto err;
Plain return?
> + }
> + dev_dbg(&pmic->pdev->dev, "%s: Unlocked lock register 0x%x\n",
> + __func__, BD71837_REG_REGLOCK);
__func__ part is redundant.
> + for (i = 0; i < ARRAY_SIZE(pmic_regulator_inits); i++) {
> +
Redundant blank line.
> + rdev = devm_regulator_register(&pdev->dev, desc, &config);
> + if (IS_ERR(rdev)) {
> + dev_err(pmic->mfd->dev,
> + "failed to register %s regulator\n",
> + desc->name);
> + err = PTR_ERR(rdev);
> + goto err;
Plain return ...
> +err:
> + return err;
Redundant.
> +}
> +static struct platform_driver bd71837_regulator = {
> + .driver = {
> + .name = "bd71837-pmic",
> + .owner = THIS_MODULE,
This done by macro you are using below. Thus, redundant.
> + },
> + .probe = bd71837_probe,
> +};
> +
> +module_platform_driver(bd71837_regulator);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v2 00/26] arm64: allwinner: Add A64 DE2 HDMI support
From: Icenowy Zheng @ 2018-06-05 13:58 UTC (permalink / raw)
To: Maxime Ripard, Jagan Teki
Cc: Chen-Yu Tsai, Jernej Skrabec, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, David Airlie, dri-devel,
Michael Turquette, Stephen Boyd, linux-clk, Michael Trimarchi,
linux-arm-kernel, devicetree, linux-kernel, linux-sunxi
In-Reply-To: <20180605132539.m54xwfzfs6btrmtc@flea>
于 2018年6月5日 GMT+08:00 下午9:25:39, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
>On Tue, Jun 05, 2018 at 06:23:57PM +0530, Jagan Teki wrote:
>> On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
>> <maxime.ripard@bootlin.com> wrote:
>> > On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
>> >> Allwinner A64 has display engine pipeline like other Allwinner
>SOC's A83T/H3/H5.
>> >>
>> >> A64 behaviour similar to Allwinner A83T where
>> >> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
>> >> Mixer1 => TCON1 => HDMI
>> >> as per Display System Block
>DiagramAllwinner_A64_User_Manual_V1.1.pdf
>> >>
>> >> This is second patch-set followed with previous RFC[1] and first
>series[2]
>> >> and merely concentrated on HDMI pipeline through TCON1 and rest
>will add eventually.
>> >>
>> >> This series fixed previous version comments
>> >> - about documenting fallback compatibles
>> >> - adding new compatible for mixer1
>> >> - support for multiple DW HDMI PHY clock parents (thanks, to
>Jernej)
>> >>
>> >> Note:
>> >> Pine64 boards are unable to get edid by default like other A64
>boards,
>> >> but forcing 'video=HDMI-A-1:1920x1080@60D' kernel command line can
>> >> create edid with display on penel.
>> >
>> > There's no point in trying to push this without the SRAM issue
>being
>> > solved. It is required, and won't be merged unless this is
>addressed.
>>
>> is SRAM issue resolved? if so may be I will try to test it on top.
>
>I'd expect the one working on this to push a solution to solve this.
I'll do it soon. Currently I'm a little busy.
>
>Maxime
^ permalink raw reply
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Rob Herring @ 2018-06-05 14:05 UTC (permalink / raw)
To: Nishanth Menon
Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel@vger.kernel.org, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla
In-Reply-To: <20180605060510.32473-1-nm@ti.com>
On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of this SoC are:
> * Quad ARMv8 A53 cores split over two clusters
> * GICv3 compliant GIC500
> * Configurable L3 Cache and IO-coherent architecture
> * Dual lock-step capable R5F uC for safety-critical applications
> * High data throughput capable distributed DMA architecture under NAVSS
> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
> PRUs and dual RTUs
> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
> * Centralized System Controller for Security, Power, and Resource
> management.
> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
> * Flash subystem with OSPI and Hyperbus interfaces
> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
> GPIO
>
> See AM65x Technical Reference Manual (SPRUID7, April 2018)
> for further details: http://www.ti.com/lit/pdf/spruid7
>
> We introduce the Kconfig symbol for the SoC along with this patch since
> it is logically relevant point, however the usage is in subsequent
> patches.
>
> NOTE: AM654 is the first of the device variants, hence we introduce a
> generic am6.dtsi.
>
> Signed-off-by: Benjamin Fair <b-fair@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> MAINTAINERS | 1 +
> arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++
> drivers/soc/ti/Kconfig | 14 ++++
> 4 files changed, 276 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cfb35b252ac7..5f5c4eddec7a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Supported
> F: Documentation/devicetree/bindings/arm/ti/k3.txt
> +F: arch/arm64/boot/dts/ti/k3-*
>
> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
> M: Santosh Shilimkar <ssantosh@kernel.org>
> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
> new file mode 100644
> index 000000000000..cdfa12173aac
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM6 SoC Family
> + *
> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM654 SoC";
> + compatible = "ti,am654";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &wkup_uart0;
> + serial1 = &mcu_uart0;
> + serial2 = &main_uart0;
> + serial3 = &main_uart1;
> + serial4 = &main_uart2;
> + };
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + soc0: soc0 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
Really need 64-bit addresses and sizes? Use ranges to limit the
address space if possible.
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,armv8-pmuv3";
> + /* Recommendation from GIC500 TRM Table A.3 */
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
These 2 nodes aren't on the bus, so move them up a level.
> +
> + gic: interrupt-controller@1800000 {
> + compatible = "arm,gic-v3";
gic-500?
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + /*
> + * NOTE: we are NOT gicv2 backward compat, so no GICC,
> + * GICH or GICV
The compatible should imply this.
> + */
> + reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */
> + <0x0 0x01880000 0x0 0x90000>; /* GICR */
> +
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: gic-its@1000000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x0 0x1820000 0x0 0x10000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + wkup_uart0: serial@42300000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x42300000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + mcu_uart0: serial@40a00000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x40a00000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <96000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart0: serial@2800000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02800000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart1: serial@2810000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02810000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> +
> + main_uart2: serial@2820000 {
> + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
> + reg = <0x0 0x02820000 0x0 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + status = "disabled";
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> new file mode 100644
> index 000000000000..d9b70081daba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM6 SoC family in Quad core configuration
> + *
> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include "k3-am6.dtsi"
> +
> +/ {
> + cpus: cpus {
Really need a label?
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu-map {
IIRC, this goes at the top level.
> + cluster0: cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> +
> + cluster1: cluster1 {
> + core0 {
> + cpu = <&cpu2>;
> + };
> +
> + core1 {
> + cpu = <&cpu3>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53","arm,armv8";
space between compatibles.
> + reg = <0x000>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
All this should be discoverable.
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x001>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu2: cpu@100 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x100>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_1>;
> + };
> +
> + cpu3: cpu@101 {
> + compatible = "arm,cortex-a53","arm,armv8";
> + reg = <0x101>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_1>;
> + };
> + };
> +};
> +
> +&soc0 {
> + L2_0: l2-cache0 {
> + compatible = "cache";
Is this documented?
> + cache-level = <2>;
> + cache-size = <0x80000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
Discoverable?
> + next-level-cache = <&msmc_l3>;
> + };
> +
> + L2_1: l2-cache1 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x80000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
> + next-level-cache = <&msmc_l3>;
> + };
> +
> + msmc_l3: l3-cache0 {
> + compatible = "cache";
Is this something TI specific or follows the (ARM) architecture?
> + cache-level = <3>;
> + };
> +};
> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
> index 92770d84a288..be4570baad96 100644
> --- a/drivers/soc/ti/Kconfig
> +++ b/drivers/soc/ti/Kconfig
> @@ -1,3 +1,17 @@
> +# 64-bit ARM SoCs from TI
> +if ARM64
> +
> +if ARCH_K3
> +
> +config ARCH_K3_AM6_SOC
This should be in another patch (or dropped?).
> + bool "K3 AM6 SoC"
> + help
> + Enable support for TI's AM6 SoC Family support
> +
> +endif
> +
> +endif
> +
> #
> # TI SOC drivers
> #
> --
> 2.15.1
>
^ permalink raw reply
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Tony Lindgren @ 2018-06-05 14:14 UTC (permalink / raw)
To: Rob Herring
Cc: Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel@vger.kernel.org, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Vignesh R, Tero Kristo, Russell King, Sudeep Holla
In-Reply-To: <CAL_JsqJusWTvr4A_-Bk81meYddMHBMJ4=Fch6L0MFoF7HfBW2w@mail.gmail.com>
* Rob Herring <robh+dt@kernel.org> [180605 14:08]:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote:
> > + soc0: soc0 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
>
> Really need 64-bit addresses and sizes? Use ranges to limit the
> address space if possible.
And in addition to using ranges, please set up separate bus instances
for the interconnects. This will then allow you to probe WKUP or
similar instance first and the other bus instances after. And that
pretty much allows you to get rid of the annoying -EPROBE_DEFER
ping pong and allows making clocks proper device drivers ;)
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Maxime Ripard @ 2018-06-05 14:50 UTC (permalink / raw)
To: Bob Ham
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <313a74ea-0be6-cff1-6b2f-06a4b0b7ba8d-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
On Mon, Jun 04, 2018 at 06:33:02PM +0100, Bob Ham wrote:
> On 04/06/18 09:13, Maxime Ripard wrote:
> > On Sat, Jun 02, 2018 at 05:03:13PM +0100, Bob Ham wrote:
>
> >> + * 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.
>
> >> + * The above copyright notice and this permission notice shall be
> >> + * included in all copies or substantial portions of the Software.
>
> > And this is redundant with the SPDX header.
>
> The X11 license notice states explicitly that the notice has to be
> included in the file. Wouldn't removing it be a violation of the license?
The SPDX header is explicitly here to remove the license text and
create a tag that is in a indirect reference to the license text in
LICENSES. It's not going away.
> >> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> >
> > Each step should increase the perceived brightness by roughly 1/Nth, N
> > being the number of steps. Usually PWM backlights don't work like that.
>
> FYI, this was copied from another .dts file. All of the other
> brightness-levels settings in sun{4,5,7}i .dts files follow similar
> patterns:
>
> sun4i-a10-dserve-dsrv9703c.dts: brightness-levels = <0 10
> 20 30 40 50 60 70 80 90 100>;
> sun4i-a10-inet1.dts: brightness-levels = <0 10 20 30 40 50 60
> 70 80 90 100>;
> sun4i-a10-pov-protab2-ips9.dts: brightness-levels = <0 10
> 20 30 40 50 60 70 80 90 100>;
> sun5i-a13-empire-electronix-d709.dts: brightness-levels = <0 10
> 20 30 40 50 60 70 80 90 100>;
> sun5i-a13-utoo-p66.dts: brightness-levels = <0 30 40 50 60 70 80
> 90 100>;
> sun5i-gr8-evb.dts: brightness-levels = <0 10 20 30 40 50 60
> 70 80 90 100>;
> sun7i-a20-wexler-tab7200.dts: brightness-levels = <0 10 20 30 40
> 50 60 70 80 90 100>;
I never said we were perfect reviewers. Feel free to help in the process.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v10 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC
From: Valentin Schneider @ 2018-06-05 14:59 UTC (permalink / raw)
To: Li Wei, robh+dt, mark.rutland, catalin.marinas, will.deacon,
vinholikatti, jejb, martin.petersen, khilman, arnd,
gregory.clement, thomas.petazzoni, yamada.masahiro, riku.voipio,
treding, krzk, devicetree, linux-kernel, linux-arm-kernel,
linux-scsi
Cc: zangleigang, gengjianfeng, guodong.xu, puck.chen, john.stultz,
fengbaopeng
In-Reply-To: <20180525091712.37227-1-liwei213@huawei.com>
Hi,
On 25/05/18 10:17, Li Wei wrote:
> This patchset adds driver support for UFS for Hi3660 SoC. It is verified on HiKey960 board.
>
> Li Wei (5):
> scsi: ufs: add Hisilicon ufs driver code
> dt-bindings: scsi: ufs: add document for hisi-ufs
> arm64: dts: add ufs dts node
> arm64: defconfig: enable configs for Hisilicon ufs
> arm64: defconfig: enable f2fs and squashfs
>
> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 41 ++
> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 +-
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 18 +
> arch/arm64/configs/defconfig | 11 +
> drivers/scsi/ufs/Kconfig | 9 +
> drivers/scsi/ufs/Makefile | 1 +
> drivers/scsi/ufs/ufs-hisi.c | 619 +++++++++++++++++++++
> drivers/scsi/ufs/ufs-hisi.h | 115 ++++
> 8 files changed, 821 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> create mode 100644 drivers/scsi/ufs/ufs-hisi.c
> create mode 100644 drivers/scsi/ufs/ufs-hisi.h
>
> Major changes in v10:
> - solve review comments from Rob Herring.
> *Modify the "reset-names" describe in ufs-hisi.txt binding file.
> *List clocks in ufs-hisi.txt binding file.
> *remove the "arst" and keep only "rst" in the binging files.
> *remove the "arst" member from both dts and c code.
> Major changes in v9:
> - solve review comments from Rob Herring.
> *remove freq-table-hz in ufs-hisi.txt binding file.
> *Move the rst to the ufshcd_pltfm.txt common binding file.
> *Modify the member "assert" of UFS host structure to "arst".
> Major changes in v8:
> - solve review comments from zhangfei.
> *Add Version history.
> - solve review comments from Rob Herring.
> *remove freq-table-hz.
> - solve review comments from Riku Voipio.
> *Add MODULE_DEVICE_TABLE for ufs driver.
>
Tested on top of linux-next (4.17.0-next-20180605), I can reliably load
my debian userspace flashed on the 'system' fastboot partition.
Tested-by: Valentin Schneider <valentin.schneider@arm.com>
^ permalink raw reply
* Re: [PATCH 0/2] Add Mediatek X20 Development Board support
From: Matthias Brugger @ 2018-06-05 15:15 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh+dt, linux-arm-kernel, linux-mediatek, devicetree,
linux-kernel, taiten.peng, daniel.thompson, amit.kucheria,
manivannanece23, Mars Cheng, Saber Rezvani
In-Reply-To: <20180529072719.GA5529@Mani-XPS-13-9360>
On 29/05/18 09:27, Manivannan Sadhasivam wrote:
> Hi Matthias,
>
> On Tue, May 29, 2018 at 08:38:27AM +0200, Matthias Brugger wrote:
>> Hi Manivannan,
>>
>> it's nice to see that someone at Linaro cares about upstreaming the 96 board.
>> From what I can see, your patches add the very same support to the board as
>> does the mt6797 evaluation board. Do you have plans to upstream more drivers for
>> the board? Do you have a roadmap or something?
>>
>> I'm asking becuase I don't want to have just another dead devicetree in the
>> kernel which does nothing but provides a boot to rootfs. Especially as this can
>> be achieved on the same board with the EVB dts.
>>
>
> I can understand your concern here. I do have plans to add more drivers
> in the future for this board but I can't give you any roadmap for that
> since it mostly falls under the spare time work and I have been doing a
> similar kind of work for the Bubblegum-96 board in parallel.
>
> At most I can guarentee that this board's functionality will be added
> gradually in upcoming days.
>
Sounds good. Fancy to send a v2 with the comments from Rob?
Regards,
Matthias
> Thanks,
> Mani
>
>> Regards,
>> Matthias
>>
>> On 29/05/18 06:52, Manivannan Sadhasivam wrote:
>>> Add devicetree support for Mediatek X20 Development Board by Archermind.
>>> This board is based on the Deca-Core MT6797 SoC from Mediatek and is
>>> one of the 96Boards Consumer Edition platform.
>>>
>>> With this devicetree change, board can boot into initramfs.
>>>
>>> More information about this board can be found in 96Boards product page:
>>> https://www.96boards.org/product/mediatek-x20/
>>>
>>> Manivannan Sadhasivam (2):
>>> dt-bindings: Add vendor prefix for ArcherMind
>>> arm64: dts: Add Mediatek X20 Development Board support
>>>
>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>> arch/arm64/boot/dts/mediatek/Makefile | 1 +
>>> .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++++++++++++++++++
>>> 3 files changed, 35 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
>>>
^ 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