* [PATCH] bpf, arm32: Correct check_imm24
From: Wang YanQing @ 2018-05-10 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510075656.GS16141@n2100.armlinux.org.uk>
On Thu, May 10, 2018 at 08:56:57AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote:
> > imm24 is signed, so the right range is:
> > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
>
> 2 << (24 - 1) is the same as 1 << 24.
>
> > -#define check_imm(bits, imm) do { \
> > - if ((((imm) > 0) && ((imm) >> (bits))) || \
> > - (((imm) < 0) && (~(imm) >> (bits)))) { \
> > - pr_info("[%2d] imm=%d(0x%x) out of range\n", \
> > - i, imm, imm); \
> > +#define check_imm_range(min, max, imm) do { \
> > + if (imm < min || imm > max) { \
> > + pr_info("[%2d] imm=%d is out of range\n", \
> > + i, imm); \
> > return -EINVAL; \
> > } \
> > } while (0)
> > -#define check_imm24(imm) check_imm(24, imm)
> > +#define check_imm24(imm) check_imm_range(-16777216, 16777215, imm)
>
> How is this any different?
>
> If imm is 16777216, then "imm > max" in your version is true.
> In the original version, "imm > 0" is true, so we then test for
> "16777216 >> 24" being non-zero. That's also true, so the test
> condition fires.
>
> If imm is 16777215, then "imm > max" is false in your version.
> In the original version, the conditions also evaluate to false.
>
> For the -16777217 case, "imm < min" in your version is true.
> In the original version, "imm < 0" is true, so we then test for
> "~(-16777217) >> 24" being non-zero. This is the same as
> "16777216 >> 24" being non-zero, which is true so the condition
> fires.
>
> With -16777216, the same thing happens, both end up evaluating
> to false.
>
> So, the two cases end up producing identical results, and there
> is no actual effect from this change.
>
> However, your commit message is correct - there is a bug here.
> That's obvious when you mask the "imm" value with 0x00ffffff,
> and realise that an imm value of -16777216 ends up having the
> same value in the instruction as an imm value of 0. So, the
> range of "imm" is _half_ that.
>
> #define check_imm(bits, imm) do { \
> - if ((((imm) > 0) && ((imm) >> (bits))) || \
> - (((imm) < 0) && (~(imm) >> (bits)))) { \
> + if ((((imm) > 0) && ((imm) >> (bits - 1))) || \
> + (((imm) < 0) && (~(imm) >> (bits - 1)))) { \
> pr_info("[%2d] imm=%d(0x%x) out of range\n", \
> i, imm, imm); \
>
> would fix it. Alternatively:
>
> #define check_imm(bits, imm) do { \
> - if ((((imm) > 0) && ((imm) >> (bits))) || \
> - (((imm) < 0) && (~(imm) >> (bits)))) { \
> + if ((imm) >= (1 << ((bits) - 1)) || \
> + (imm) < -(1 << ((bits) - 1))) { \
> pr_info("[%2d] imm=%d(0x%x) out of range\n", \
> i, imm, imm); \
>
> would also fix it.
Hi!
Sorry for confusion, I make a mistake here, the real fix I want to
submit is [8388607, -8388608], this range has the same effect as your
suggestion.
Will you fix it? or I resend another version?
Thanks.
^ permalink raw reply
* [PATCH] arm64: msm8916: fix gic_irq_domain_translate warnings
From: Amit Kucheria @ 2018-05-10 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180418163415.21646-1-srinivas.kandagatla@linaro.org>
On Wed, Apr 18, 2018 at 7:34 PM, <srinivas.kandagatla@linaro.org> wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> Remove the usage of IRQ_TYPE_NONE to fix loud warnings from
> patch (83a86fbb5b56b "irqchip/gic: Loudly complain about
> the use of IRQ_TYPE_NONE").
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Tested-by: Amit Kucheria <amit.kucheria@linaro.org>
(boot report here:
https://storage.kernelci.org/qcom-lt/integration-linux-qcomlt/v4.17-rc4-247-gbe94bee41bf6/arm64/defconfig/lab-bjorn/boot-apq8016-sbc.txt)
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index cfbd72186762..5d66a575c7e1 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -180,7 +180,7 @@
>
> pmu {
> compatible = "arm,cortex-a53-pmu";
> - interrupts = <GIC_PPI 7 GIC_CPU_MASK_SIMPLE(4)>;
> + interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4)| IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> thermal-zones {
> @@ -513,7 +513,7 @@
> blsp_i2c2: i2c at 78b6000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078b6000 0x500>;
> - interrupts = <GIC_SPI 96 0>;
> + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
> clock-names = "iface", "core";
> @@ -528,7 +528,7 @@
> blsp_i2c4: i2c at 78b8000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078b8000 0x500>;
> - interrupts = <GIC_SPI 98 0>;
> + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP4_I2C_APPS_CLK>;
> clock-names = "iface", "core";
> @@ -543,7 +543,7 @@
> blsp_i2c6: i2c at 78ba000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078ba000 0x500>;
> - interrupts = <GIC_SPI 100 0>;
> + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP6_I2C_APPS_CLK>;
> clock-names = "iface", "core";
> @@ -575,7 +575,7 @@
> "mi2s-bit-clk3";
> #sound-dai-cells = <1>;
>
> - interrupts = <0 160 0>;
> + interrupts = <0 160 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "lpass-irq-lpaif";
> reg = <0x07708000 0x10000>;
> reg-names = "lpass-lpaif";
> @@ -595,7 +595,7 @@
> reg = <0x07824900 0x11c>, <0x07824000 0x800>;
> reg-names = "hc_mem", "core_mem";
>
> - interrupts = <0 123 0>, <0 138 0>;
> + interrupts = <0 123 IRQ_TYPE_LEVEL_HIGH>, <0 138 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "hc_irq", "pwr_irq";
> clocks = <&gcc GCC_SDCC1_APPS_CLK>,
> <&gcc GCC_SDCC1_AHB_CLK>,
> @@ -612,7 +612,7 @@
> reg = <0x07864900 0x11c>, <0x07864000 0x800>;
> reg-names = "hc_mem", "core_mem";
>
> - interrupts = <0 125 0>, <0 221 0>;
> + interrupts = <0 125 IRQ_TYPE_LEVEL_HIGH>, <0 221 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "hc_irq", "pwr_irq";
> clocks = <&gcc GCC_SDCC2_APPS_CLK>,
> <&gcc GCC_SDCC2_AHB_CLK>,
> @@ -819,7 +819,7 @@
> iommu-ctx at 2000 {
> compatible = "qcom,msm-iommu-v1-ns";
> reg = <0x2000 0x1000>;
> - interrupts = <GIC_SPI 242 0>;
> + interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> @@ -864,7 +864,7 @@
> "bus_clk",
> "vsync_clk";
>
> - interrupts = <0 72 0>;
> + interrupts = <0 72 IRQ_TYPE_LEVEL_HIGH>;
>
> interrupt-controller;
> #interrupt-cells = <1>;
> --
> 2.16.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: use phandles to extend nodes
From: Sekhar Nori @ 2018-05-10 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507123721.9264-1-aford173@gmail.com>
On Monday 07 May 2018 06:07 PM, Adam Ford wrote:
> Many node labels in the device tree (like serial0, serial1, etc) are being
> redefined, so let's modernize the device tree by using phandles to
> extend the existing nodes. This helps reduce the whitespace.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
I applied this without the pmic changes. I am not convinced about those.
The tps node is already being referred to as phandle. I am not sure
referring to each individual regulator using phandle is needed. Other
files like am335x-evm.dts don't do it as well.
Another thing is whether we really need the tp6507x.dtsi file. It does
not seem to contain much and also da850-evm.dts is the only file
including it. So it seems pretty pointless to me.
Here is what I committed.
Thanks,
Sekhar
---8<---
commit ae62a32d6019a8225e2c32e631b8b0d039151131 (refs/heads/v4.18/dt)
Author: Adam Ford <aford173@gmail.com>
AuthorDate: Mon May 7 07:37:21 2018 -0500
Commit: Sekhar Nori <nsekhar@ti.com>
CommitDate: Thu May 10 14:01:15 2018 +0530
ARM: dts: da850-evm: use phandles to extend nodes
Many node labels in the device tree (like serial0, serial1, etc) are being
redefined, so let's modernize the device tree by using phandles to
extend the existing nodes. This helps reduce the whitespace.
Signed-off-by: Adam Ford <aford173@gmail.com>
[nsekhar at ti.com: drop tps6507x related changes]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 339cae353302..9389f95f4094 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,143 +27,6 @@
spi0 = &spi1;
};
- soc at 1c00000 {
- pmx_core: pinmux at 14120 {
- status = "okay";
-
- mcasp0_pins: pinmux_mcasp0_pins {
- pinctrl-single,bits = <
- /*
- * AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
- * AFSR, AMUTE
- */
- 0x00 0x11111111 0xffffffff
- /* AXR11, AXR12 */
- 0x04 0x00011000 0x000ff000
- >;
- };
- nand_pins: nand_pins {
- pinctrl-single,bits = <
- /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[4], EMA_CS[3] */
- 0x1c 0x10110110 0xf0ff0ff0
- /*
- * EMA_D[0], EMA_D[1], EMA_D[2],
- * EMA_D[3], EMA_D[4], EMA_D[5],
- * EMA_D[6], EMA_D[7]
- */
- 0x24 0x11111111 0xffffffff
- /* EMA_A[1], EMA_A[2] */
- 0x30 0x01100000 0x0ff00000
- >;
- };
- };
- serial0: serial at 42000 {
- status = "okay";
- };
- serial1: serial at 10c000 {
- status = "okay";
- };
- serial2: serial at 10d000 {
- status = "okay";
- };
- rtc0: rtc at 23000 {
- status = "okay";
- };
- i2c0: i2c at 22000 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- tps: tps at 48 {
- reg = <0x48>;
- };
- tlv320aic3106: tlv320aic3106 at 18 {
- #sound-dai-cells = <0>;
- compatible = "ti,tlv320aic3106";
- reg = <0x18>;
- status = "okay";
-
- /* Regulators */
- IOVDD-supply = <&vdcdc2_reg>;
- /* Derived from VBAT: Baseboard 3.3V / 1.8V */
- AVDD-supply = <&vbat>;
- DRVDD-supply = <&vbat>;
- DVDD-supply = <&vbat>;
- };
- tca6416: gpio at 20 {
- compatible = "ti,tca6416";
- reg = <0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- };
- };
- wdt: wdt at 21000 {
- status = "okay";
- };
- mmc0: mmc at 40000 {
- max-frequency = <50000000>;
- bus-width = <4>;
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins>;
- };
- spi1: spi at 30e000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;
- flash: m25p80 at 0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "m25p64";
- spi-max-frequency = <30000000>;
- m25p,fast-read;
- reg = <0>;
- partition at 0 {
- label = "U-Boot-SPL";
- reg = <0x00000000 0x00010000>;
- read-only;
- };
- partition at 1 {
- label = "U-Boot";
- reg = <0x00010000 0x00080000>;
- read-only;
- };
- partition at 2 {
- label = "U-Boot-Env";
- reg = <0x00090000 0x00010000>;
- read-only;
- };
- partition at 3 {
- label = "Kernel";
- reg = <0x000a0000 0x00280000>;
- };
- partition at 4 {
- label = "Filesystem";
- reg = <0x00320000 0x00400000>;
- };
- partition at 5 {
- label = "MAC-Address";
- reg = <0x007f0000 0x00010000>;
- read-only;
- };
- };
- };
- mdio: mdio at 224000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mdio_pins>;
- bus_freq = <2200000>;
- };
- eth0: ethernet at 220000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mii_pins>;
- };
- gpio: gpio at 226000 {
- status = "okay";
- };
- };
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -200,6 +63,153 @@
};
};
+&pmx_core {
+ status = "okay";
+
+ mcasp0_pins: pinmux_mcasp0_pins {
+ pinctrl-single,bits = <
+ /*
+ * AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
+ * AFSR, AMUTE
+ */
+ 0x00 0x11111111 0xffffffff
+ /* AXR11, AXR12 */
+ 0x04 0x00011000 0x000ff000
+ >;
+ };
+ nand_pins: nand_pins {
+ pinctrl-single,bits = <
+ /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[4], EMA_CS[3] */
+ 0x1c 0x10110110 0xf0ff0ff0
+ /*
+ * EMA_D[0], EMA_D[1], EMA_D[2],
+ * EMA_D[3], EMA_D[4], EMA_D[5],
+ * EMA_D[6], EMA_D[7]
+ */
+ 0x24 0x11111111 0xffffffff
+ /* EMA_A[1], EMA_A[2] */
+ 0x30 0x01100000 0x0ff00000
+ >;
+ };
+};
+
+&serial0 {
+ status = "okay";
+};
+
+&serial1 {
+ status = "okay";
+};
+
+&serial2 {
+ status = "okay";
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ tps: tps at 48 {
+ reg = <0x48>;
+ };
+ tlv320aic3106: tlv320aic3106 at 18 {
+ #sound-dai-cells = <0>;
+ compatible = "ti,tlv320aic3106";
+ reg = <0x18>;
+ status = "okay";
+
+ /* Regulators */
+ IOVDD-supply = <&vdcdc2_reg>;
+ /* Derived from VBAT: Baseboard 3.3V / 1.8V */
+ AVDD-supply = <&vbat>;
+ DRVDD-supply = <&vbat>;
+ DVDD-supply = <&vbat>;
+ };
+ tca6416: gpio at 20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;
+ flash: m25p80 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p64";
+ spi-max-frequency = <30000000>;
+ m25p,fast-read;
+ reg = <0>;
+ partition at 0 {
+ label = "U-Boot-SPL";
+ reg = <0x00000000 0x00010000>;
+ read-only;
+ };
+ partition at 1 {
+ label = "U-Boot";
+ reg = <0x00010000 0x00080000>;
+ read-only;
+ };
+ partition at 2 {
+ label = "U-Boot-Env";
+ reg = <0x00090000 0x00010000>;
+ read-only;
+ };
+ partition at 3 {
+ label = "Kernel";
+ reg = <0x000a0000 0x00280000>;
+ };
+ partition at 4 {
+ label = "Filesystem";
+ reg = <0x00320000 0x00400000>;
+ };
+ partition at 5 {
+ label = "MAC-Address";
+ reg = <0x007f0000 0x00010000>;
+ read-only;
+ };
+ };
+};
+
+&mdio {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ bus_freq = <2200000>;
+};
+
+ð0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mii_pins>;
+};
+
+&gpio {
+ status = "okay";
+};
+
/include/ "tps6507x.dtsi"
&tps {
^ permalink raw reply related
* [PATCH v1 0/5] Add sdmmc UHS support to ROC-RK3328-CC board.
From: djw at t-chip.com.cn @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Levin Du <djw@t-chip.com.cn>
Hi all, this is an attemp to add sdmmc UHS support to the
ROC-RK3328-CC board.
This patch series adds a new compatible `rockchip,gpio-syscon` to
the gpio-syscon driver for general Rockchip SoC usage..
A new gpio controller named `gpio_syscon10` is defined in
rk3328.dtsi so that all rk3328 boards has access to it.
The ROC-RK3328-CC board use the new gpio <&gpio_syscon10 1> in
gpio-regulator to control the signal voltage of the sdmmc.
It is essential for UHS support which requires 1.8V signal voltage.
Many thanks to Heiko's great advice!
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt .
- Split into small patches.
- Add gpio-syscon10 to rk3328 for general use.
- Sort dts properties in sdmmc node.
Heiko Stuebner (1):
gpio: syscon: allow fetching syscon from parent node
Levin Du (4):
gpio: syscon: Add gpio-syscon for rockchip
arm64: dts: rockchip: Add gpio-syscon10 to rk3328
arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
.../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 30 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 ++++
drivers/gpio/gpio-syscon.c | 32 +++++++++++++++++
4 files changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
--
2.7.4
^ permalink raw reply
* [reset-control] How to initialize hardware state with the shared reset line?
From: Masahiro Yamada @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi.
The previous thread was:
"usb: dwc3: support clocks and resets for DWC3 core"
https://patchwork.kernel.org/patch/10349623/
I changed the subject because
I think this is rather reset-control topic than USB.
I am searching for a good way to initialize hardware devices
in the following situation:
- two or more hardware devices share the same reset line
- those devices are not reset before booting the kernel
(i.e. flip flops in RTL are random state at driver probe)
- the hardware IP is used by various SoCs,
and this issue only appears only on some.
Specifically, the DWC3 USB IP case is in my mind,
but this should apply to any hardware in general.
Issue in detail
---------------
The DWC3 USB IP is very popular and used by various SoCs
as you see in drivers/usb/dwc3/.
SoCs are using the same RTL as provided by Synopsys.
(SoC vendors could tweak the RTL if they like,
but it would rarely happen because it would just be troublesome)
So, let's assume we use the same IP with the same RTL version.
It is *compatible* in terms of device tree.
In this case, we should avoid differentiating the driver code per-SoC.
In fact, we ended up with
commit ff0a632 ("usb: dwc3: of-simple: add support for shared and
pulsed reset lines")
commit e8284db ("usb: dwc3: of-simple: add support for the Amlogic
Meson GXL and AXG SoCs")
This means, the difference that comes from the reset _provider_
must be implemented in the reset _consumer_.
This is unfortunate.
So, I wonder if we can support it in sub-system level somehow
instead of messing up the reset consumer driver.
- The reset topology is SoC-dependent.
A reset line is dedicated for single hardware for some SoCs,
and shared by multiple hardware for others.
- The reset policy (pulse reset, level reset, or both of them)
are SoC-dependent (reset controller dependent).
RTL generally contains state machines.
The initial state of flip flops are undefined on power-on
hence the initial state of state machines are also undefined.
So, digital circuits needs explicit reset in general.
In some cases, the reset is performed before booting the kernel.
- power-on reset
(FFs are put into defined state on power-on automatically)
- a reset controller assert reset lines by default
(FFs are fixed to defined state. If a reset consumer
driver deasserts the reset line, HW starts from the define state)
- Firmware may reset the hardware before booting the kernel
If nothing above is done, and the reset line is shared by multiple devices,
we do not have a good way to put the hardware into the sane state.
Reset consumers choose the required reset type:
- Shared reset:
reset_control_assert / reset_control_deassert work like
clock_disable / clock_enable.
The consumer must be tolerant to the situation where the HW may
not reset-asserted.
- Exclusive reset:
It is guaranteed reset_control_assert() really asserts the reset line,
but only one reset consumer grabs the reset line at the same time.
As above, the state machines in digital circuits must start from a
defined state.
So, we want exclusive reset to reset the FFs.
However, this is too much requirement
since it is a reset line is often shared.
How to save such an Amlogic case?
Hogging solve the problem?
--------------------------
I was thinking of a solution.
I may be missing something, but
one solution might be reset hogging on the
reset provider side. This allows us to describe
the initial state of reset lines in the reset controller.
The idea for "reset-hog" is similar to:
- "gpio-hog" defined in
Documentation/devicetree/bindings/gpio/gpio.txt
- "assigned-clocks" defined in
Documetation/devicetree/bindings/clock/clock-bindings.txt
For example,
reset-controller {
....
line_a {
reset-hog;
resets = <1>;
reset-assert;
};
}
When the reset controller is registered,
the reset ID '1' is asserted.
So, all reset consumers that share the reset line '1'
will start from the asserted state
(i.e. defined state machine state).
>From the discussion with Martin Blumenstingl
(https://lkml.org/lkml/2018/4/28/115),
the problem for Amlogic is that
the reset line is "de-asserted" by default.
If so, the 'reset-hog' would fix the problem,
and DWC3 driver would be able to use
shared, level reset, I think.
I think something may be missing from my mind,
but I hope this will prompt the discussion,
and we will find a better idea.
Thanks.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v1 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: djw at t-chip.com.cn @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
which do not belong to the general pinctrl.
Adding gpio-syscon support makes controlling regulator or
LED using these special pins very easy by reusing existing
drivers, such as gpio-regulator and led-gpio.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
.../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
drivers/gpio/gpio-syscon.c | 30 ++++++++++++++++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
new file mode 100644
index 0000000..e4c1650
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
@@ -0,0 +1,41 @@
+* Rockchip GPIO support for GRF_SOC_CON registers
+
+Required properties:
+- compatible: Should contain "rockchip,gpio-syscon".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+ 0 = Active high,
+ 1 = Active low.
+- gpio,syscon-dev: Should contain <grf_phandle syscon_offset 0>.
+ If declared as child of the grf node, the grf_phandle can be 0.
+
+Example:
+
+1. As child of grf node:
+
+ grf: syscon at ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+
+ gpio_syscon10: gpio-syscon10 {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <0 0x0428 0>;
+ };
+ };
+
+
+2. Not child of grf node:
+
+ grf: syscon at ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+ //...
+ };
+
+ gpio_syscon10: gpio-syscon10 {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <&grf 0x0428 0>;
+ };
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 7325b86..e24b408 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -135,6 +135,32 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio = {
.dat_bit_offset = 0x40 * 8 + 8,
};
+static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+ struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
+ unsigned int offs;
+ u8 bit;
+ u32 data;
+ int ret;
+
+ offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
+ bit = offs % SYSCON_REG_BITS;
+ data = (val ? BIT(bit) : 0) | BIT(bit + 16);
+ ret = regmap_write(priv->syscon,
+ (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
+ data);
+ if (ret < 0)
+ dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
+}
+
+static const struct syscon_gpio_data rockchip_gpio_syscon = {
+ /* Rockchip GRF_SOC_CON Bits 0-15 */
+ .flags = GPIO_SYSCON_FEAT_OUT,
+ .bit_count = 16,
+ .set = rockchip_gpio_set,
+};
+
#define KEYSTONE_LOCK_BIT BIT(0)
static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
@@ -175,6 +201,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
.compatible = "ti,keystone-dsp-gpio",
.data = &keystone_dsp_gpio,
},
+ {
+ .compatible = "rockchip,gpio-syscon",
+ .data = &rockchip_gpio_syscon,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
--
2.7.4
^ permalink raw reply related
* [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328
From: djw at t-chip.com.cn @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
access to the pins defined in the syscon GRF_SOC_CON10.
Boards using these special pins to control regulators or LEDs, can now
utilize existing drivers like gpio-regulator and leds-gpio.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v1:
- Split from V0 and add to rk3328.dtsi for general use.
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index b8e9da1..73a822d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -309,6 +309,12 @@
mode-loader = <BOOT_BL_DOWNLOAD>;
};
+ gpio_syscon10: gpio-syscon10 {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <0 0x0428 0>;
+ };
};
uart0: serial at ff110000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v1 4/5] arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
It is necessary for the io domain setting of the SoC to match
the voltage supplied by the regulators.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v1:
- Split from V0.
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..b983abd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -208,6 +208,18 @@
};
};
+&io_domains {
+ status = "okay";
+
+ vccio1-supply = <&vcc_io>;
+ vccio2-supply = <&vcc18_emmc>;
+ vccio3-supply = <&vcc_io>;
+ vccio4-supply = <&vcc_18>;
+ vccio5-supply = <&vcc_io>;
+ vccio6-supply = <&vcc_io>;
+ pmuio-supply = <&vcc_io>;
+};
+
&pinctrl {
pmic {
pmic_int_l: pmic-int-l {
--
2.7.4
^ permalink raw reply related
* [PATCH v1 4/5] arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-10 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
It is necessary for the io domain setting of the SoC to match
the voltage supplied by the regulators.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v1:
- Split from V0.
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..b983abd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -208,6 +208,18 @@
};
};
+&io_domains {
+ status = "okay";
+
+ vccio1-supply = <&vcc_io>;
+ vccio2-supply = <&vcc18_emmc>;
+ vccio3-supply = <&vcc_io>;
+ vccio4-supply = <&vcc_18>;
+ vccio5-supply = <&vcc_io>;
+ vccio6-supply = <&vcc_io>;
+ pmuio-supply = <&vcc_io>;
+};
+
&pinctrl {
pmic {
pmic_int_l: pmic-int-l {
--
2.7.4
^ permalink raw reply related
* [PATCH v1 5/5] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-10 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be reference as <&gpio_syscon10 1>, thanks
to the gpio-syscon driver, which makes writing regulator-gpio possible.
If the signal voltage changes, the io domain needs to change
correspondingly.
To use this feature, the following options are required in kernel config:
- CONFIG_GPIO_SYSCON=y
- CONFIG_POWER_AVS=y
- CONFIG_ROCKCHIP_IODOMAIN=y
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v1:
- Split into small patches
- Sort dts properties in sdmmc node
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b983abd..3f33e42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -41,6 +41,19 @@
vin-supply = <&vcc_io>;
};
+ vcc_sdio: sdmmcio-regulator {
+ compatible = "regulator-gpio";
+ gpios = <&gpio_syscon10 1 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1
+ 3300000 0x0>;
+ regulator-name = "vcc_sdio";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -213,7 +226,7 @@
vccio1-supply = <&vcc_io>;
vccio2-supply = <&vcc18_emmc>;
- vccio3-supply = <&vcc_io>;
+ vccio3-supply = <&vcc_sdio>;
vccio4-supply = <&vcc_18>;
vccio5-supply = <&vcc_io>;
vccio6-supply = <&vcc_io>;
@@ -242,7 +255,12 @@
max-frequency = <150000000>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vcc_sdio>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: juno: Fix "debounce-interval" property misspelling
From: Liviu Dudau @ 2018-05-10 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525884291-18851-1-git-send-email-sudeep.holla@arm.com>
On Wed, May 09, 2018 at 05:44:49PM +0100, Sudeep Holla wrote:
> "debounce_interval" was never supported in the bindings. It should be
> "debounce-interval". Moreover, latest DTC complains the following:
>
> Warning (property_name_chars_strict): debounce_interval: Character '_' not recommended in property name
>
> This patch fixes the above warning by using the correct property as
> per the bindings.
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> index 69804c5f1197..4b38195a8bea 100644
> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> @@ -58,42 +58,42 @@
> compatible = "gpio-keys";
>
> power-button {
> - debounce_interval = <50>;
> + debounce-interval = <50>;
> wakeup-source;
> linux,code = <116>;
> label = "POWER";
> gpios = <&iofpga_gpio0 0 0x4>;
> };
> home-button {
> - debounce_interval = <50>;
> + debounce-interval = <50>;
> wakeup-source;
> linux,code = <102>;
> label = "HOME";
> gpios = <&iofpga_gpio0 1 0x4>;
> };
> rlock-button {
> - debounce_interval = <50>;
> + debounce-interval = <50>;
> wakeup-source;
> linux,code = <152>;
> label = "RLOCK";
> gpios = <&iofpga_gpio0 2 0x4>;
> };
> vol-up-button {
> - debounce_interval = <50>;
> + debounce-interval = <50>;
> wakeup-source;
> linux,code = <115>;
> label = "VOL+";
> gpios = <&iofpga_gpio0 3 0x4>;
> };
> vol-down-button {
> - debounce_interval = <50>;
> + debounce-interval = <50>;
> wakeup-source;
> linux,code = <114>;
> label = "VOL-";
> gpios = <&iofpga_gpio0 4 0x4>;
> };
> nmi-button {
> - debounce_interval = <50>;
> + debounce-interval = <50>;
> wakeup-source;
> linux,code = <99>;
> label = "NMI";
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH 2/3] arm64: dts: juno: replace '_' with '-' in node names
From: Liviu Dudau @ 2018-05-10 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525884291-18851-2-git-send-email-sudeep.holla@arm.com>
On Wed, May 09, 2018 at 05:44:50PM +0100, Sudeep Holla wrote:
> The latest DTC throws warnings for character '_' in the node names.
>
> Warning (node_name_chars_strict): /thermal-zones/big_cluster: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /thermal-zones/little_cluster: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /smb at 8000000/motherboard/gpio_keys: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /pmu_a57: Character '_' not recommended in node name
> Warning (node_name_chars_strict): /pmu_a53: Character '_' not recommended in node name
>
> The general recommendation is to use character '-' for all the node names.
> This patch fixes the warnings following the recommendation.
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 4 ++--
> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 2 +-
> arch/arm64/boot/dts/arm/juno-r1.dts | 4 ++--
> arch/arm64/boot/dts/arm/juno-r2.dts | 4 ++--
> arch/arm64/boot/dts/arm/juno.dts | 4 ++--
> 5 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index b2fedaab3fcc..b74e462c6658 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -572,14 +572,14 @@
> thermal-sensors = <&scpi_sensors0 3>;
> };
>
> - big_cluster_thermal_zone: big_cluster {
> + big_cluster_thermal_zone: big-cluster {
> polling-delay = <1000>;
> polling-delay-passive = <100>;
> thermal-sensors = <&scpi_sensors0 21>;
> status = "disabled";
> };
>
> - little_cluster_thermal_zone: little_cluster {
> + little_cluster_thermal_zone: little-cluster {
> polling-delay = <1000>;
> polling-delay-passive = <100>;
> thermal-sensors = <&scpi_sensors0 22>;
> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> index 4b38195a8bea..70e3409d86a3 100644
> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> @@ -54,7 +54,7 @@
> regulator-always-on;
> };
>
> - gpio_keys {
> + gpio-keys {
> compatible = "gpio-keys";
>
> power-button {
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> index c52c5c40dede..2c5db03f226c 100644
> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -201,7 +201,7 @@
> };
> };
>
> - pmu_a57 {
> + pmu-a57 {
> compatible = "arm,cortex-a57-pmu";
> interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>;
> @@ -209,7 +209,7 @@
> <&A57_1>;
> };
>
> - pmu_a53 {
> + pmu-a53 {
> compatible = "arm,cortex-a53-pmu";
> interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
> diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
> index a90982ceda35..c51950f4a1b6 100644
> --- a/arch/arm64/boot/dts/arm/juno-r2.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r2.dts
> @@ -201,7 +201,7 @@
> };
> };
>
> - pmu_a72 {
> + pmu-a72 {
> compatible = "arm,cortex-a72-pmu";
> interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>;
> @@ -209,7 +209,7 @@
> <&A72_1>;
> };
>
> - pmu_a53 {
> + pmu-a53 {
> compatible = "arm,cortex-a53-pmu";
> interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
> diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
> index c9236c4b967d..2b2bf39c30ef 100644
> --- a/arch/arm64/boot/dts/arm/juno.dts
> +++ b/arch/arm64/boot/dts/arm/juno.dts
> @@ -200,7 +200,7 @@
> };
> };
>
> - pmu_a57 {
> + pmu-a57 {
> compatible = "arm,cortex-a57-pmu";
> interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>;
> @@ -208,7 +208,7 @@
> <&A57_1>;
> };
>
> - pmu_a53 {
> + pmu-a53 {
> compatible = "arm,cortex-a53-pmu";
> interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH 3/3] arm64: dts: juno/rtsm: re-structure motherboard includes
From: Liviu Dudau @ 2018-05-10 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525884291-18851-3-git-send-email-sudeep.holla@arm.com>
On Wed, May 09, 2018 at 05:44:51PM +0100, Sudeep Holla wrote:
> It is a bit unorthodox to just include a file in the middle of a another
> DTS file, it breaks the pattern from other device trees and also makes
> it really hard to reference things across the files with phandles.
>
> Restructure the include for the Juno/RTSM motherboards to happen at the
> top of the file, reference the target nodes directly, and indent the
> motherboard .dtsi files to reflect their actual depth in the hierarchy.
>
> This is a purely syntactic change that result in the same DTB files from
> the DTS/DTSI files. This is based on similar patch from Linus Walleij
> for ARM Vexpress platforms.
A bit of bikeshedding here: the reason I've used the DT /include/
here was that on decompilation of the DTB the nodes would have been in
the natural order and easier to look for issues. Those were the early
days and I can accept that the general practice has changed and we're
using now the C preprocessor more. I don't have any strong feelings on
how the DT looks nowadays, so:
>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 3 +--
> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 4 ++++
> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 4 ++--
> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 5 ++++-
> 4 files changed, 11 insertions(+), 5 deletions(-)
>
> Hi,
>
> Posting this patch with -b(aka ignore-spaces option for review purpose.
>
> Regards,
> Sudeep
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index b74e462c6658..ce56a4acda4f 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -1,5 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> #include "juno-clocks.dtsi"
> +#include "juno-motherboard.dtsi"
>
> / {
> /*
> @@ -795,8 +796,6 @@
> <0 0 10 &gic 0 0 0 167 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 11 &gic 0 0 0 168 IRQ_TYPE_LEVEL_HIGH>,
> <0 0 12 &gic 0 0 0 169 IRQ_TYPE_LEVEL_HIGH>;
> -
> - /include/ "juno-motherboard.dtsi"
> };
>
> site2: tlx at 60000000 {
> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> index 70e3409d86a3..1792b074e9a3 100644
> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
> @@ -7,6 +7,8 @@
> *
> */
>
> +/ {
> + smb at 8000000 {
> mb_clk24mhz: clk24mhz {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> @@ -287,3 +289,5 @@
> };
> };
> };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts b/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> index 06c8117e812a..602f63f72c37 100644
> --- a/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> +++ b/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> @@ -12,6 +12,8 @@
>
> /memreserve/ 0x80000000 0x00010000;
>
> +#include "rtsm_ve-motherboard.dtsi"
> +
> / {
> model = "RTSM_VE_AEMv8A";
> compatible = "arm,rtsm_ve,aemv8a", "arm,vexpress";
> @@ -162,7 +164,5 @@
> <0 0 40 &gic 0 40 4>,
> <0 0 41 &gic 0 41 4>,
> <0 0 42 &gic 0 42 4>;
> -
> - /include/ "rtsm_ve-motherboard.dtsi"
> };
> };
> diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> index 1134e5d8df18..d2dbc3f39263 100644
> --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> @@ -7,7 +7,8 @@
> *
> * VEMotherBoard.lisa
> */
> -
> +/ {
> + smb at 8000000 {
> motherboard {
> arm,v2m-memory-map = "rs1";
> compatible = "arm,vexpress,v2m-p1", "simple-bus";
> @@ -274,3 +275,5 @@
> };
> };
> };
> + };
> +};
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH 0/2] Revert explicit support for Renesas R-Car Gen 3 r8a779[56] SoCs
From: Rafael J. Wysocki @ 2018-05-10 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502095806.30341-1-horms+renesas@verge.net.au>
On Wednesday, May 2, 2018 11:58:04 AM CEST Simon Horman wrote:
> Revert commits that added explicit support for Renesas R-Car Gen 3
> r8a779[56] SoCs to the generic cpufreq driver.
>
> This is no longer needed since the flowing commit and to the best of my
> knowledge is not relied on by any upstream DTS: edeec420de24 ("cpufreq:
> dt-platdev: Automatically create cpufreq device with OPP v2")
>
> Simon Horman (2):
> Revert "cpufreq: dt: Add r8a7796 support to to use generic cpufreq
> driver"
> Revert "cpufreq: rcar: Add support for R8A7795 SoC"
>
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 --
> 1 file changed, 2 deletions(-)
>
>
Am I expected to pick up this series?
Thanks,
Rafael
^ permalink raw reply
* [PATCH 3/8] firmware: arm_scmi: rename get_transition_latency and add_opps_to_device
From: Sudeep Holla @ 2018-05-10 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0ixZPB8aZs0xc9-3JMrWfRC7+7mzYWNaCj1o_q6VSqEJA@mail.gmail.com>
On Thu, May 10, 2018 at 10:29:48AM +0200, Rafael J. Wysocki wrote:
> On Wed, May 9, 2018 at 7:07 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > Most of the scmi code follows the suggestion from Greg KH on a totally
> > different thread[0] to have the subsystem name first, followed by the
> > noun and finally the verb with couple of these exceptions.
> >
> > This patch fixes them so that all the functions names are aligned to
> > on practice.
> >
> > [0] https://www.spinics.net/lists/arm-kernel/msg583673.html
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
> ACK for the cpufreq driver changes and I'm assuming this to go in via the arch.
>
Thanks, yes I plan to send it via ARM-SoC.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 3/3] arm64: dts: juno/rtsm: re-structure motherboard includes
From: Sudeep Holla @ 2018-05-10 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510094901.GR1027@e110455-lin.cambridge.arm.com>
On 10/05/18 10:49, Liviu Dudau wrote:
> On Wed, May 09, 2018 at 05:44:51PM +0100, Sudeep Holla wrote:
>> It is a bit unorthodox to just include a file in the middle of a another
>> DTS file, it breaks the pattern from other device trees and also makes
>> it really hard to reference things across the files with phandles.
>>
>> Restructure the include for the Juno/RTSM motherboards to happen at the
>> top of the file, reference the target nodes directly, and indent the
>> motherboard .dtsi files to reflect their actual depth in the hierarchy.
>>
>> This is a purely syntactic change that result in the same DTB files from
>> the DTS/DTSI files. This is based on similar patch from Linus Walleij
>> for ARM Vexpress platforms.
>
> A bit of bikeshedding here: the reason I've used the DT /include/
> here was that on decompilation of the DTB the nodes would have been in
> the natural order and easier to look for issues. Those were the early
> days and I can accept that the general practice has changed and we're
> using now the C preprocessor more. I don't have any strong feelings on
> how the DT looks nowadays, so:
>
I can understand. After this patch applied, I did hit an issue with
timer registration. I just posted a patch [1]
>>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>
> Acked-by: Liviu Dudau <liviu.dudau@arm.com>
>
Thanks for all the acks.
--
Regards,
Sudeep
[1]
https://lkml.kernel.org/r/1525881728-4858-1-git-send-email-sudeep.holla at arm.com
^ permalink raw reply
* [PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.
From: Mark Rutland @ 2018-05-10 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525941385-12766-1-git-send-email-hoeun.ryu@lge.com.com>
Hi,
On Thu, May 10, 2018 at 05:36:17PM +0900, Hoeun Ryu wrote:
> From: Hoeun Ryu <hoeun.ryu@lge.com>
>
> On some SoCs like i.MX6DL/QL have only one muxed SPI for multi-core system.
> On the systems, a CPU can be interrupted by overflow irq but it is possible that
> the overflow actually occurs on another CPU.
Muxing the PMU IRQs is a really broken system design, and there's no
good way of supporting it.
What we should do for such systems is:
* Add a flag to the DT to describe that the IRQs are muxed, as this
cannot be probed.
* Add hrtimer code to periodically update the counters, to avoid
overflow (e.g. as we do in the l2x0 PMU).
* Reject sampling for such systems, as this cannot be done reliably or
efficiently.
NAK to broadcasting the IRQ -- there are a number of issues with the
general approach.
We should update the PMU probing code to warn when we have fewer IRQs
than CPUs, and fail gracefully to the above.
[...]
> static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
> {
> + /* smp_call_function cannot be called with irq disabled */
> + local_irq_enable();
> + preempt_disable();
> + smp_call_function_many(&mask, __armpmu_handle_irq, dev, 0);
> + preempt_enable();
> + local_irq_disable();
For many reasons, this sequence is not safe.
It is not safe to enable IRQs in irq handlers. Please never do this.
Thus it's also never safe to call smp_call_function*() in IRQ handlers.
Futher, If you ever encounter a case where you need to avoid preemption
across enabling IRQs, preemption must be disabled *before* enabling
IRQs.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm_pmu: simplify arm_pmu::handle_irq
From: Mark Rutland @ 2018-05-10 10:35 UTC (permalink / raw)
To: linux-arm-kernel
The arm_pmu::handle_irq() callback has the same prototype as a generic
IRQ handler, taking the IRQ number and a void pointer argument which it
must convert to an arm_pmu pointer.
This means that all arm_pmu::handle_irq() take an IRQ number they never
use, and all must explicitly cast the void pointer to an arm_pmu
pointer.
Instead, let's change arm_pmu::handle_irq to take an arm_pmu pointer,
allowing these casts to be removed. The redundant IRQ number parameter
is also removed.
Suggested-by: Hoeun Ryu <hoeun.ryu@lge.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/perf_event_v6.c | 4 +---
arch/arm/kernel/perf_event_v7.c | 3 +--
arch/arm/kernel/perf_event_xscale.c | 6 ++----
arch/arm64/kernel/perf_event.c | 3 +--
drivers/perf/arm_pmu.c | 2 +-
include/linux/perf/arm_pmu.h | 2 +-
6 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 1d7061a38922..be42c4f66a40 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -303,12 +303,10 @@ static void armv6pmu_enable_event(struct perf_event *event)
}
static irqreturn_t
-armv6pmu_handle_irq(int irq_num,
- void *dev)
+armv6pmu_handle_irq(struct arm_pmu *cpu_pmu)
{
unsigned long pmcr = armv6_pmcr_read();
struct perf_sample_data data;
- struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
struct pt_regs *regs;
int idx;
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 870b66c1e4ef..57f01e059f39 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -946,11 +946,10 @@ static void armv7pmu_disable_event(struct perf_event *event)
raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
}
-static irqreturn_t armv7pmu_handle_irq(int irq_num, void *dev)
+static irqreturn_t armv7pmu_handle_irq(struct arm_pmu *cpu_pmu)
{
u32 pmnc;
struct perf_sample_data data;
- struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
struct pt_regs *regs;
int idx;
diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
index fcf218da660e..88d1a76f5367 100644
--- a/arch/arm/kernel/perf_event_xscale.c
+++ b/arch/arm/kernel/perf_event_xscale.c
@@ -142,11 +142,10 @@ xscale1_pmnc_counter_has_overflowed(unsigned long pmnc,
}
static irqreturn_t
-xscale1pmu_handle_irq(int irq_num, void *dev)
+xscale1pmu_handle_irq(struct arm_pmu *cpu_pmu)
{
unsigned long pmnc;
struct perf_sample_data data;
- struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
struct pt_regs *regs;
int idx;
@@ -489,11 +488,10 @@ xscale2_pmnc_counter_has_overflowed(unsigned long of_flags,
}
static irqreturn_t
-xscale2pmu_handle_irq(int irq_num, void *dev)
+xscale2pmu_handle_irq(struct arm_pmu *cpu_pmu)
{
unsigned long pmnc, of_flags;
struct perf_sample_data data;
- struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
struct pt_regs *regs;
int idx;
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 85a251b6dfa8..33147aacdafd 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -670,11 +670,10 @@ static void armv8pmu_disable_event(struct perf_event *event)
raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
}
-static irqreturn_t armv8pmu_handle_irq(int irq_num, void *dev)
+static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
{
u32 pmovsr;
struct perf_sample_data data;
- struct arm_pmu *cpu_pmu = (struct arm_pmu *)dev;
struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
struct pt_regs *regs;
int idx;
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 1a0d340b65cf..a6347d487635 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -339,7 +339,7 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
return IRQ_NONE;
start_clock = sched_clock();
- ret = armpmu->handle_irq(irq, armpmu);
+ ret = armpmu->handle_irq(armpmu);
finish_clock = sched_clock();
perf_sample_event_took(finish_clock - start_clock);
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 40036a57d072..ad5444491975 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -78,7 +78,7 @@ struct arm_pmu {
struct pmu pmu;
cpumask_t supported_cpus;
char *name;
- irqreturn_t (*handle_irq)(int irq_num, void *dev);
+ irqreturn_t (*handle_irq)(struct arm_pmu *pmu);
void (*enable)(struct perf_event *event);
void (*disable)(struct perf_event *event);
int (*get_event_idx)(struct pmu_hw_events *hw_events,
--
2.11.0
^ permalink raw reply related
* [PATCH] CNS3xxx: Cosmetic: Fix misc register usage
From: Krzysztof Hałasa @ 2018-05-10 10:37 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -395,7 +395,7 @@ static void __init cns3xxx_init(void)
dn = of_find_compatible_node(NULL, NULL, "cavium,cns3420-sdhci");
if (of_device_is_available(dn)) {
- u32 __iomem *gpioa = IOMEM(CNS3XXX_MISC_BASE_VIRT + 0x0014);
+ u32 __iomem *gpioa = IOMEM(MISC_GPIOA_PIN_ENABLE_REG);
u32 gpioa_pins = __raw_readl(gpioa);
/* MMC/SD pins share with GPIOA */
diff --git a/arch/arm/mach-cns3xxx/devices.c b/arch/arm/mach-cns3xxx/devices.c
index 7da78a2451f1..daafbe764a96 100644
--- a/arch/arm/mach-cns3xxx/devices.c
+++ b/arch/arm/mach-cns3xxx/devices.c
@@ -97,7 +97,7 @@ static struct platform_device cns3xxx_sdhci_pdev = {
void __init cns3xxx_sdhci_init(void)
{
- u32 __iomem *gpioa = IOMEM(CNS3XXX_MISC_BASE_VIRT + 0x0014);
+ u32 __iomem *gpioa = IOMEM(MISC_GPIOA_PIN_ENABLE_REG);
u32 gpioa_pins = __raw_readl(gpioa);
/* MMC/SD pins share with GPIOA */
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
^ permalink raw reply related
* [PATCH] CNS3xxx: Add SMP support
From: Krzysztof Hałasa @ 2018-05-10 10:41 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Krzysztof Ha?asa <khalasa@piap.pl>
--- a/arch/arm/mach-cns3xxx/Kconfig
+++ b/arch/arm/mach-cns3xxx/Kconfig
@@ -3,6 +3,9 @@ menuconfig ARCH_CNS3XXX
bool "Cavium Networks CNS3XXX family"
depends on ARCH_MULTI_V6
select ARM_GIC
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD
+ select HAVE_SMP
help
Support for Cavium Networks CNS3XXX platform.
--- a/arch/arm/mach-cns3xxx/Makefile
+++ b/arch/arm/mach-cns3xxx/Makefile
@@ -4,3 +4,4 @@ cns3xxx-y += core.o pm.o
cns3xxx-$(CONFIG_ATAGS) += devices.o
cns3xxx-$(CONFIG_PCI) += pcie.o
cns3xxx-$(CONFIG_MACH_CNS3420VB) += cns3420vb.o
+cns3xxx-$(CONFIG_SMP) += platsmp.o headsmp.o
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -251,5 +251,6 @@ MACHINE_START(CNS3420VB, "Cavium Networks CNS3420 Validation Board")
.init_time = cns3xxx_timer_init,
.init_machine = cns3420_init,
.init_late = cns3xxx_pcie_init_late,
+ .smp = smp_ops(cns3xxx_smp_ops),
.restart = cns3xxx_restart,
MACHINE_END
--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <linux/usb/ehci_pdriver.h>
#include <linux/usb/ohci_pdriver.h>
+#include <asm/smp_twd.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
@@ -26,6 +27,8 @@
#include "core.h"
#include "pm.h"
+#define IRQ_LOCALTIMER 29
+
static struct map_desc cns3xxx_io_desc[] __initdata = {
{
.virtual = CNS3XXX_TC11MP_SCU_BASE_VIRT,
@@ -198,6 +201,15 @@ static struct irqaction cns3xxx_timer_irq = {
.handler = cns3xxx_timer_interrupt,
};
+static void __init cns3xxx_init_twd(void)
+{
+ static DEFINE_TWD_LOCAL_TIMER(cns3xx_twd_local_timer,
+ CNS3XXX_TC11MP_TWD_BASE,
+ IRQ_LOCALTIMER);
+
+ twd_local_timer_register(&cns3xx_twd_local_timer);
+}
+
/*
* Set up the clock source and clock events devices
*/
@@ -251,6 +263,7 @@ static void __init __cns3xxx_timer_init(unsigned int timer_irq)
setup_irq(timer_irq, &cns3xxx_timer_irq);
cns3xxx_clockevents_init(timer_irq);
+ cns3xxx_init_twd();
}
void __init cns3xxx_timer_init(void)
--- a/arch/arm/mach-cns3xxx/core.h
+++ b/arch/arm/mach-cns3xxx/core.h
@@ -13,6 +13,7 @@
#include <linux/reboot.h>
+extern struct smp_operations cns3xxx_smp_ops;
extern void cns3xxx_timer_init(void);
#ifdef CONFIG_CACHE_L2X0
--- /dev/null
+++ b/arch/arm/mach-cns3xxx/headsmp.S
@@ -0,0 +1,39 @@
+/*
+ * Cloned from linux/arch/arm/mach-exynos/headsmp.S
+ *
+ * Copyright (c) 2003 ARM Limited
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+/*
+ * CNS3XXX specific entry point for secondary CPUs. This provides
+ * a "holding pen" into which all secondary cores are held until we're
+ * ready for them to initialise.
+ */
+ENTRY(cns3xxx_secondary_startup)
+ mrc p15, 0, r0, c0, c0, 5
+ and r0, r0, #15
+ adr r4, 1f
+ ldmia r4, {r5, r6}
+ sub r4, r4, r5
+ add r6, r6, r4
+pen: ldr r7, [r6]
+ cmp r7, r0
+ bne pen
+
+ /*
+ * we've been released from the holding pen: secondary_stack
+ * should now contain the SVC stack for this core
+ */
+ b secondary_startup
+ENDPROC(cns3xxx_secondary_startup)
+
+ .align 2
+1: .long .
+ .long pen_release
--- /dev/null
+++ b/arch/arm/mach-cns3xxx/platsmp.c
@@ -0,0 +1,151 @@
+/*
+ * linux/arch/arm/mach-cns3xxx/platsmp.c
+ *
+ * Copyright (C) 2002 ARM Ltd.
+ * Copyright 2012 Gateworks Corporation
+ * Chris Lang <clang@gateworks.com>
+ * Tim Harvey <tharvey@gateworks.com>
+ *
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/jiffies.h>
+#include <linux/smp.h>
+#include <linux/io.h>
+#include <asm/cacheflush.h>
+#include <asm/smp_scu.h>
+#include <asm/unified.h>
+#include "cns3xxx.h"
+
+extern void cns3xxx_secondary_startup(void);
+
+#define SCU_CPU_STATUS 0x08
+#define SCU_BASE ((void __iomem *)CNS3XXX_TC11MP_SCU_BASE_VIRT)
+
+/*
+ * Write pen_release in a way that is guaranteed to be visible to all
+ * observers, irrespective of whether they're taking part in coherency
+ * or not. This is necessary for the hotplug code to work reliably.
+ */
+static void write_pen_release(int val)
+{
+ pen_release = val;
+ smp_wmb();
+ __cpuc_flush_dcache_area((void *)&pen_release, sizeof(pen_release));
+ outer_clean_range(__pa(&pen_release), __pa(&pen_release + 1));
+}
+
+static DEFINE_SPINLOCK(boot_lock);
+
+static void cns3xxx_secondary_init(unsigned int cpu)
+{
+ /*
+ * let the primary processor know we're out of the
+ * pen, then head off into the C entry point
+ */
+ write_pen_release(-1);
+
+ /*
+ * Synchronise with the boot thread.
+ */
+ spin_lock(&boot_lock);
+ spin_unlock(&boot_lock);
+}
+
+static int cns3xxx_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ unsigned long timeout;
+
+ /*
+ * Set synchronisation state between this boot processor
+ * and the secondary one
+ */
+ spin_lock(&boot_lock);
+
+ /*
+ * The secondary processor is waiting to be released from
+ * the holding pen - release it, then wait for it to flag
+ * that it has been released by resetting pen_release.
+ *
+ * Note that "pen_release" is the hardware CPU ID, whereas
+ * "cpu" is Linux's internal ID.
+ */
+ write_pen_release(cpu);
+
+ /*
+ * Send the secondary CPU a soft interrupt, thereby causing
+ * the boot monitor to read the system wide flags register,
+ * and branch to the address found there.
+ */
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ timeout = jiffies + (1 * HZ);
+ while (time_before(jiffies, timeout)) {
+ smp_rmb();
+ if (pen_release == -1)
+ break;
+
+ udelay(10);
+ }
+
+ /*
+ * now the secondary core is starting up let it run its
+ * calibrations, then wait for it to finish
+ */
+ spin_unlock(&boot_lock);
+
+ return pen_release != -1 ? -ENOSYS : 0;
+}
+
+/*
+ * Initialise the CPU possible map early - this describes the CPUs
+ * which may be present or become present in the system.
+ */
+static void __init cns3xxx_smp_init_cpus(void)
+{
+ unsigned int i, ncores;
+ unsigned int status;
+
+ /* SCU_CPU_STATUS must be examined instead of SCU_CONFIGURATION
+ * used in scu_get_core_count
+ */
+ status = __raw_readl(SCU_BASE + SCU_CPU_STATUS);
+ for (i = 0; i < NR_CPUS + 1; i++) {
+ if (((status >> (i * 2)) & 0x3) == 0)
+ set_cpu_possible(i, true);
+ else
+ break;
+ }
+ ncores = i;
+}
+
+static void __init cns3xxx_smp_prepare_cpus(unsigned int max_cpus)
+{
+ /*
+ * enable SCU
+ */
+ scu_enable(SCU_BASE);
+
+ /*
+ * Write the address of secondary startup into the
+ * system-wide flags register. The boot monitor waits
+ * until it receives a soft interrupt, and then the
+ * secondary CPU branches to this address.
+ */
+ __raw_writel(virt_to_phys(cns3xxx_secondary_startup),
+ (void __iomem *)(CNS3XXX_MISC_BASE_VIRT + 0x0600));
+}
+
+struct smp_operations cns3xxx_smp_ops __initdata = {
+ .smp_init_cpus = cns3xxx_smp_init_cpus,
+ .smp_prepare_cpus = cns3xxx_smp_prepare_cpus,
+ .smp_secondary_init = cns3xxx_secondary_init,
+ .smp_boot_secondary = cns3xxx_boot_secondary,
+};
--
Krzysztof Halasa
Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
^ permalink raw reply
* [PATCH v5 0/9] Add support for SAMA5D2 touchscreen
From: Eugen Hristev @ 2018-05-10 10:45 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This patch series is a rework of my previous series named:
[PATCH 00/14] iio: triggers: add consumer support
This is the version 5 of the series, and addresses the received feedback
on the v2 series named:
[PATCH v2 00/10] Add support for SAMA5D2 touchscreen
and the v3 series named
[PATCH v3 00/11] Add support for SAMA5D2 touchscreen
and the v4 series named
[PATCH v4 0/9] Add support for SAMA5D2 touchscreen
This series applies on top of fixes-togreg branch of iio.git,
specifically on top of commit:
"f0c8d1f" : iio: adc: at91-sama5d2_adc:
fix channel configuration for differential channels
Changes in v3, v4 and v5 are presented at the end of the cover letter below.
Thanks everyone for the feedback. Below is the original v2 cover letter:
In few words, this is the implementation of splitting the functionality
of the IP block ADC device in SAMA5D2 SoC from ADC with touchscreen
support. In order to avoid having a MFD device, two separate
drivers that would work on same register base and split the IRQ,etc,
as advised on the mailing list, I created a consumer driver for the
channels, that will connect to the ADC as described in the device tree.
I have collected feedback from everyone and here is the result:
I have added a new generic resistive touchscreen driver, which acts
as a iio consumer for the given channels and will create an input
device and report the events. It uses a callback buffer to register
to the IIO device and waits for data to be pushed.
Inside the IIO device, I have kept a similar approach with the first version
of the series, except that now the driver can take multiple buffers, and
will configure the touchscreen part of the hardware device if the specific
channels are requested.
The SAMA5D2 ADC driver registers three new channels: two for the
position on the X and Y axis, and one for the touch pressure.
When channels are requested, it will check if the touchscreen channel mask
includes the requested channels (it is possible that the consumer driver
will not request pressure for example). If it's the case, it will work
in touchscreen mode, and will refuse to do usual analog-digital conversion,
because we have a single trigger and the touchscreen needs it.
When the scan mask will include only old channels, the driver will function
in the same way as before. If the scan mask somehow is a mix of the two (the
masks intersect), the driver will refuse to work whatsoever (cannot have both
in the same time).
The driver allows reading raw data for the new channels, if claim direct
mode works: no touchscreen driver requested anything. The new channels can
act like the old ones. However, when requesting these channels, the usual
trigger will not work and will not be enabled. The touchscreen channels
require special trigger and irq configuration: pen detect, no pen detect
and a periodic trigger to sample the touchscreen position and pressure.
If the user attempts to use another trigger while there is a buffer
that already requested the touchscreen channels (thus the trigger), the
driver will refuse to comply.
In order to have defines for the channel numbers, I added a bindings include
file that goes on a separate commit :
dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer info
This should go in the same tree with the following commits :
ARM: dts: at91: sama5d2: add channel cells for ADC device
ARM: dts: at91: sama5d2: Add resistive touch device
as build will break because these commits depend on the binding one
which creates the included header file.
V5 update: After discussing with Alexandre Belloni on Mailing list, the two
DTS patches are to be taken in the next version after bindings reach mainline.
Changes in v5:
- renamed property touchscreen-threshold-pressure to touchscreen-min-pressure
- added one return in touchscreen driver
Changes in v4:
- removed patch for inkern module get/set kref
- addressed feedback on both the ADC and the touchscreen driver. each
patch has a history inside the patch file for the specific changes.
- patch that fixes the channel fix
[PATCH v3 01/11] iio: adc: at91-sama5d2_adc:
fix channel configuration for differential channels
was accepted in fixes-togreg branch thus removed from this series.
- added Reviewed-by for the bindings by Rob Herring
Changes in v3:
- changed input driver name according to feedback and reworked in commits
to adapt to binding changes and new name.
- moved channel index fix in at91-sama5d2_adc at the beginning of the series
(PATCH 01/11)
- created a new optional binding for the touchscreen as a separate commit
and added it to the series :
[PATCH v3 04/11] dt-bindings: input: touchscreen: add pressure
threshold touchscreen property
- changed at91-sama5d2_adc driver patch to address the comments. Exact changes
are in the patch file for the driver source file.
Eugen Hristev (9):
MAINTAINERS: add generic resistive touchscreen adc
iio: Add channel for Position Relative
dt-bindings: input: touchscreen: add minimum pressure touchscreen
property
dt-bindings: input: touchscreen: resistive-adc-touch: create bindings
iio: adc: at91-sama5d2_adc: add support for position and pressure
channels
input: touchscreen: resistive-adc-touch: add generic resistive ADC
touchscreen
dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer
info
ARM: dts: at91: sama5d2: add channel cells for ADC device
ARM: dts: at91: sama5d2: Add resistive touch device
Documentation/ABI/testing/sysfs-bus-iio | 12 +
.../bindings/iio/adc/at91-sama5d2_adc.txt | 9 +
.../input/touchscreen/resistive-adc-touch.txt | 30 +
.../bindings/input/touchscreen/touchscreen.txt | 3 +
MAINTAINERS | 6 +
arch/arm/boot/dts/sama5d2.dtsi | 12 +
drivers/iio/adc/at91-sama5d2_adc.c | 609 +++++++++++++++++++--
drivers/iio/industrialio-core.c | 1 +
drivers/input/touchscreen/Kconfig | 13 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/resistive-adc-touch.c | 201 +++++++
include/dt-bindings/iio/adc/at91-sama5d2_adc.h | 16 +
include/uapi/linux/iio/types.h | 1 +
tools/iio/iio_event_monitor.c | 2 +
14 files changed, 858 insertions(+), 58 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
create mode 100644 drivers/input/touchscreen/resistive-adc-touch.c
create mode 100644 include/dt-bindings/iio/adc/at91-sama5d2_adc.h
--
2.7.4
^ permalink raw reply
* [PATCH v5 1/9] MAINTAINERS: add generic resistive touchscreen adc
From: Eugen Hristev @ 2018-05-10 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525949114-29263-1-git-send-email-eugen.hristev@microchip.com>
Add MAINTAINERS entry for generic resistive touchscreen adc
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v3:
- Changed source file name
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3bdc260..ce9720f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5943,6 +5943,12 @@ F: drivers/base/power/domain*.c
F: include/linux/pm_domain.h
F: Documentation/devicetree/bindings/power/power_domain.txt
+GENERIC RESISTIVE TOUCHSCREEN ADC DRIVER
+M: Eugen Hristev <eugen.hristev@microchip.com>
+L: linux-input at vger.kernel.org
+S: Maintained
+F: drivers/input/touchscreen/resistive-adc-touch.c
+
GENERIC UIO DRIVER FOR PCI DEVICES
M: "Michael S. Tsirkin" <mst@redhat.com>
L: kvm at vger.kernel.org
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/9] iio: Add channel for Position Relative
From: Eugen Hristev @ 2018-05-10 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525949114-29263-1-git-send-email-eugen.hristev@microchip.com>
Add new channel type for relative position on a pad.
These type of analog sensor offers the position of a pen
on a touchpad, and is represented as a voltage, which can be
converted to a position on X and Y axis on the pad.
The channel will hand the relative position on the pad in both directions.
The channel can then be consumed by a touchscreen driver or
read as-is for a raw indication of the touchpen on a touchpad.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v2:
- modified channel name to relative position as suggested.
- modified kernel version to 4.18 (presumable)
Documentation/ABI/testing/sysfs-bus-iio | 12 ++++++++++++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
tools/iio/iio_event_monitor.c | 2 ++
4 files changed, 16 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 6a5f34b..42a9287 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -190,6 +190,18 @@ Description:
but should match other such assignments on device).
Units after application of scale and offset are m/s^2.
+What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
+KernelVersion: 4.18
+Contact: linux-iio at vger.kernel.org
+Description:
+ Relative position in direction x or y on a pad (may be
+ arbitrarily assigned but should match other such assignments on
+ device).
+ Units after application of scale and offset are milli percents
+ from the pad's size in both directions. Should be calibrated by
+ the consumer.
+
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_raw
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 19bdf3d..14bf3d24 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -85,6 +85,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_COUNT] = "count",
[IIO_INDEX] = "index",
[IIO_GRAVITY] = "gravity",
+ [IIO_POSITIONRELATIVE] = "positionrelative",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 4213cdf..033c7d2 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -44,6 +44,7 @@ enum iio_chan_type {
IIO_COUNT,
IIO_INDEX,
IIO_GRAVITY,
+ IIO_POSITIONRELATIVE,
};
enum iio_modifier {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index b61245e..148f69d 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -58,6 +58,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_PH] = "ph",
[IIO_UVINDEX] = "uvindex",
[IIO_GRAVITY] = "gravity",
+ [IIO_POSITIONRELATIVE] = "positionrelative",
};
static const char * const iio_ev_type_text[] = {
@@ -151,6 +152,7 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_PH:
case IIO_UVINDEX:
case IIO_GRAVITY:
+ case IIO_POSITIONRELATIVE:
break;
default:
return false;
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/9] dt-bindings: input: touchscreen: add minimum pressure touchscreen property
From: Eugen Hristev @ 2018-05-10 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525949114-29263-1-git-send-email-eugen.hristev@microchip.com>
Add a common touchscreen optional property that will specify
the minimum pressure applied to the screen that is needed
such that the driver will report the touch event.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v5:
- Modified property name to touchscreen-min-pressure from
touchscreen-threshold-property
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
index 537643e..d092d5d 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -7,6 +7,9 @@ Optional properties for Touchscreens:
(in pixels)
- touchscreen-max-pressure : maximum reported pressure (arbitrary range
dependent on the controller)
+ - touchscreen-min-pressure : minimum pressure on the touchscreen to be
+ achieved in order for the touchscreen
+ driver to report a touch event.
- touchscreen-fuzz-x : horizontal noise value of the absolute input
device (in pixels)
- touchscreen-fuzz-y : vertical noise value of the absolute input
--
2.7.4
^ permalink raw reply related
* [PATCH v5 4/9] dt-bindings: input: touchscreen: resistive-adc-touch: create bindings
From: Eugen Hristev @ 2018-05-10 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525949114-29263-1-git-send-email-eugen.hristev@microchip.com>
Added bindings for generic resistive touchscreen ADC.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v5:
- changed property name touchscreen-threshold-pressure to
touchscreen-min-pressure
Changes in v3:
- renamed file and compatible to exclude "generic" keyword
- removed the pressure threshold property, added it as a common
touchscreen property in the touchscreen common bindings in a separate
commit.
Changes in v2:
- modified bindings to have a generic resistive touchscreen adc driver
instead of specific architecture one.
.../input/touchscreen/resistive-adc-touch.txt | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
new file mode 100644
index 0000000..51456c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
@@ -0,0 +1,30 @@
+Generic resistive touchscreen ADC
+
+Required properties:
+
+ - compatible: must be "resistive-adc-touch"
+The device must be connected to an ADC device that provides channels for
+position measurement and optional pressure.
+Refer to ../iio/iio-bindings.txt for details
+ - iio-channels: must have at least two channels connected to an ADC device.
+These should correspond to the channels exposed by the ADC device and should
+have the right index as the ADC device registers them. These channels
+represent the relative position on the "x" and "y" axes.
+ - iio-channel-names: must have all the channels' names. Mandatory channels
+are "x" and "y".
+
+Optional properties:
+ - iio-channels: The third channel named "pressure" is optional and can be
+used if the ADC device also measures pressure besides position.
+If this channel is missing, pressure will be ignored and the touchscreen
+will only report position.
+ - iio-channel-names: optional channel named "pressure".
+
+Example:
+
+ resistive_touch: resistive_touch {
+ compatible = "resistive-adc-touch";
+ touchscreen-min-pressure = <50000>;
+ io-channels = <&adc 24>, <&adc 25>, <&adc 26>;
+ io-channel-names = "x", "y", "pressure";
+ };
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox