* [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT
From: Sinan Kaya @ 2017-04-17 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <838d8504-b6f0-2475-f4b1-9761ecd9f573@codeaurora.org>
On 4/17/2017 5:44 PM, Sinan Kaya wrote:
> Any idea what happened to the change in this function during merge?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae7c18380495ac5c14a614fdb6c452c3bf9148ac
>
I realized that there is a V9 out there. I'm catching up with the work.
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-4.12&id=e6db07d0f3b6da1f8cfd485776bfefa4fcdbfc45
seems to be fixing the issue.
> 63a52b3 platform-msi: Make platform_msi_create_device_domain() ACPI aware
> e07b978 irqchip/gicv3-its: platform-msi: Scan MADT to create platform msi domain
> 09be1d5 irqchip/gicv3-its: platform-msi: Refactor its_pmsi_init() to prepare for ACPI
> 4e96df9 irqchip/gicv3-its: platform-msi: Refactor its_pmsi_prepare()
> e593828 irqchip/gic-v3-its: Keep the include header files in alphabetic order
> e226a74 ACPI: platform: setup MSI domain for ACPI based platform device
> 79c7533 ACPI: platform-msi: retrieve devid from IORT
> 43394c9 ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
> e6eaeae ACPI/IORT: Rename iort_node_map_rid() to make it generic
> 6acbb92 ACPI/IORT: Rework iort_match_node_callback() return value handling
> f8e2f50 ACPI/IORT: Add missing comment for iort_dev_find_its_id()
> 4b1eeee ACPI/IORT: Fix the indentation in iort_scan_node()
Apologies for the noise.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT
From: Sinan Kaya @ 2017-04-17 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484744105-53140-11-git-send-email-guohanjun@huawei.com>
On 1/18/2017 7:55 AM, Hanjun Guo wrote:
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -57,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>
> msi_info = msi_get_domain_info(domain->parent);
>
> - ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
> + iort_pmsi_get_dev_id(dev, &dev_id);
> if (ret)
> return ret;
>
Any idea what happened to the change in this function during merge?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae7c18380495ac5c14a614fdb6c452c3bf9148ac
63a52b3 platform-msi: Make platform_msi_create_device_domain() ACPI aware
e07b978 irqchip/gicv3-its: platform-msi: Scan MADT to create platform msi domain
09be1d5 irqchip/gicv3-its: platform-msi: Refactor its_pmsi_init() to prepare for ACPI
4e96df9 irqchip/gicv3-its: platform-msi: Refactor its_pmsi_prepare()
e593828 irqchip/gic-v3-its: Keep the include header files in alphabetic order
e226a74 ACPI: platform: setup MSI domain for ACPI based platform device
79c7533 ACPI: platform-msi: retrieve devid from IORT
43394c9 ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
e6eaeae ACPI/IORT: Rename iort_node_map_rid() to make it generic
6acbb92 ACPI/IORT: Rework iort_match_node_callback() return value handling
f8e2f50 ACPI/IORT: Add missing comment for iort_dev_find_its_id()
4b1eeee ACPI/IORT: Fix the indentation in iort_scan_node()
I'm getting these warnings when using the above patches on top of 4.11-rc6?
The code is basically trying to read OF attribute on an ACPI system.
[ 11.644792] ------------[ cut here ]------------
[ 11.649407] WARNING: CPU: 35 PID: 1 at /local/mnt/workspace/projects/caf/kernel/drivers/irqchip/irq-gic-v3-its-platform-msi.c:41 its_pmsi_prepare+0x9c/0xfc
[ 11.663305] Modules linked in:
[ 11.666353]
[ 11.667839] CPU: 35 PID: 1 Comm: swapper/0 Tainted: G W 4.11.0-00036-g63a52b3 #1
[ 11.676355] Hardware name: (null) (DT)
[ 11.680097] task: ffff8007dbab8000 task.stack: ffff8007dbab4000
[ 11.686009] PC is at its_pmsi_prepare+0x9c/0xfc
[ 11.690533] LR is at its_pmsi_prepare+0x5c/0xfc
[ 11.695056] pc : [<ffff000008371b68>] lr : [<ffff000008371b28>] pstate: 20400045
[ 11.702443] sp : ffff8007dbab7a40
[ 11.705750] x29: ffff8007dbab7a40 x28: 0000000000000000
[ 11.711057] x27: ffff0000092a9000 x26: 0000000000000000
[ 11.716364] x25: ffff8007df02ba00 x24: ffff000008a745a9
[ 11.721670] x23: ffff000008a7459e x22: 000000000000000b
[ 11.726976] x21: ffff8007dbab7b70 x20: ffff8007d9c48c10
[ 11.732282] x19: ffff8007dba8ba80 x18: 000000000000000a
[ 11.737588] x17: 0000000000001000 x16: 0000000000000040
[ 11.742895] x15: 000000000009bb9b x14: 0040000000000041
[ 11.748201] x13: 0140000000000000 x12: 0088000000000000
[ 11.753507] x11: ffff000008af0000 x10: ffff0000094ad000
[ 11.758814] x9 : 0000000000000000 x8 : ffff8007d977ac00
[ 11.764120] x7 : 0000000000000000 x6 : 000000000000003f
[ 11.769426] x5 : ffff8007dbab7a90 x4 : 0000000000000000
[ 11.774733] x3 : 0000000000000006 x2 : 00000000fffffffe
[ 11.780039] x1 : ffff8007df02b760 x0 : 0000000008d8fb70
[ 11.785345]
[ 11.786830] ---[ end trace 265ed4f0c6d0486b ]---
[ 11.791439] Call trace:
[ 11.793879] Exception stack(0xffff8007dbab7870 to 0xffff8007dbab79a0)
[ 11.800312] 7860: ffff8007dba8ba80 0001000000000000
[ 11.808134] 7880: ffff8007dbab7a40 ffff000008371b68 ffff7e0000000000 0000000000000004
[ 11.815956] 78a0: ffff000008af0000 0000820000000000 00000000000ff200 ffff8007dbab8000
[ 11.823779] 78c0: 00000000000ff000 ffff0000081cb6ec ffff8007dbab78e0 00000000000ff000
[ 11.831601] 78e0: 0000000000000040 ffff8007ffff2a80 ffff8007dbab7940 ffff000008166530
[ 11.839423] 7900: ffff8007dbab7960 ffff0000081984f4 0000000008d8fb70 ffff8007df02b760
[ 11.847245] 7920: 00000000fffffffe 0000000000000006 0000000000000000 ffff8007dbab7a90
[ 11.855067] 7940: 000000000000003f 0000000000000000 ffff8007d977ac00 0000000000000000
[ 11.862890] 7960: ffff0000094ad000 ffff000008af0000 0088000000000000 0140000000000000
[ 11.870712] 7980: 0040000000000041 000000000009bb9b 0000000000000040 0000000000001000
[ 11.878535] [<ffff000008371b68>] its_pmsi_prepare+0x9c/0xfc
[ 11.884101] [<ffff000008109444>] msi_domain_prepare_irqs+0x54/0x68
[ 11.890274] [<ffff0000081095a8>] msi_domain_alloc_irqs+0x30/0x14c
[ 11.896361] [<ffff0000084f00cc>] platform_msi_domain_alloc_irqs+0x54/0x8c
[ 11.903142] [<ffff0000084566d8>] hidma_probe+0x5ac/0x824
[ 11.908448] [<ffff0000084d16c0>] platform_drv_probe+0x54/0xa4
[ 11.914186] [<ffff0000084cfb20>] driver_probe_device+0x140/0x2a0
[ 11.920185] [<ffff0000084cfcf4>] __driver_attach+0x74/0xa0
[ 11.925664] [<ffff0000084ce0dc>] bus_for_each_dev+0x68/0x98
[ 11.931229] [<ffff0000084cf5b8>] driver_attach+0x20/0x28
[ 11.936534] [<ffff0000084cf16c>] bus_add_driver+0xe0/0x1ec
[ 11.942012] [<ffff0000084d05f4>] driver_register+0x90/0xdc
[ 11.947490] [<ffff0000084d161c>] __platform_driver_register+0x48/0x50
[ 11.953924] [<ffff000008b9781c>] hidma_driver_init+0x18/0x20
[ 11.959577] [<ffff00000808318c>] do_one_initcall+0x80/0x108
[ 11.965142] [<ffff000008b60d0c>] kernel_init_freeable+0x19c/0x23c
[ 11.971228] [<ffff0000087af808>] kernel_init+0x10/0xfc
[ 11.976359] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
[ 11.981746] hidma QCOM8062:17: HI-DMA engine driver registration complete
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/1] ARM: dts: meson: Extend L2 cache controller node for Meson8 and Meson8b
From: Martin Blumenstingl @ 2017-04-17 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417214244.23698-1-martin.blumenstingl@googlemail.com>
From: Carlo Caione <carlo@endlessm.com>
This patch extends the L2 cache controller node for the Amlogic Meson8
and Meson8b SoCs with some missing parameters. These are taken from the
Amlogic GPL kernel source.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
[apply the change to Meson8 and Meson8b and updated description]
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm/boot/dts/meson8.dtsi | 6 ++++++
arch/arm/boot/dts/meson8b.dtsi | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 5eaaf067c76a..6993077331c7 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -188,6 +188,12 @@
clocks = <&clk81>;
};
+&L2 {
+ arm,data-latency = <3 3 3>;
+ arm,tag-latency = <2 2 2>;
+ arm,filter-ranges = <0x100000 0xc0000000>;
+};
+
&spifc {
clocks = <&clk81>;
};
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index ef9ac974111c..d9f116a418b2 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -171,6 +171,12 @@
};
};
+&L2 {
+ arm,data-latency = <3 3 3>;
+ arm,tag-latency = <2 2 2>;
+ arm,filter-ranges = <0x100000 0xc0000000>;
+};
+
&uart_AO {
clocks = <&clkc CLKID_CLK81>;
};
--
2.12.2
^ permalink raw reply related
* [PATCH 0/1] add missing L2 cache properties for Meson8 and Meson8b
From: Martin Blumenstingl @ 2017-04-17 21:42 UTC (permalink / raw)
To: linux-arm-kernel
This adds three missing L2 cache properties for the cache controller
on Meson8 and Meson8b.
This patch was originally written by Carlo Caione, I just took it and
applied it to Meson8 as well and rebased it.
This patch is based on my previous series from [0]: "Amlogic Meson (32-bit)
.dts cleanups"
[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-April/003399.html
Carlo Caione (1):
ARM: dts: meson: Extend L2 cache controller node for Meson8 and
Meson8b
arch/arm/boot/dts/meson8.dtsi | 6 ++++++
arch/arm/boot/dts/meson8b.dtsi | 6 ++++++
2 files changed, 12 insertions(+)
--
2.12.2
^ permalink raw reply
* [PATCH 2/2] ARM: dts: meson8b: inherit meson.dtsi from meson8b.dtsi
From: Martin Blumenstingl @ 2017-04-17 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417213938.22626-1-martin.blumenstingl@googlemail.com>
Currently only meson6.dtsi and meson8.dtsi inherit the generic
meson.dtsi. However, since the Meson8b platform is basically a slightly
updated version of Meson8 we can safely inherit meson.dtsi. An indicator
for this are the nodes which are identical in meson.dtsi and
meson8b.dtsi (L2, gic, timer, uart_AO, uart_A, uart_B, uart_C).
Additionally this makes the following devices available on Meson8b which
were not avaialble before (however, since all affected drivers support
Meson6, Meson8 and the whole GX series there's no reason to assume that
they are not working):
- i2c_a and i2c_B
- the IR receiver
- SPFIC (SPI flash controller)
- the dwmac ethernet controller
Differences between Meson8 and Meson8b seem to be:
- ARM Cortex-A5 core instead of Cortex-A9 on Meson8
- dwmac on Meson8b supports RGMII
- small pinctrl updates
Inheriting meson.dtsi makes it easier to maintain by removing duplicate
definitions.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm/boot/dts/meson8b.dtsi | 210 +++++++++++++++++------------------------
1 file changed, 84 insertions(+), 126 deletions(-)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 828aa49c678c..ef9ac974111c 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -47,11 +47,9 @@
#include <dt-bindings/clock/meson8b-clkc.h>
#include <dt-bindings/gpio/meson8b-gpio.h>
#include <dt-bindings/reset/amlogic,meson8b-reset.h>
-#include "skeleton.dtsi"
+#include "meson.dtsi"
/ {
- interrupt-parent = <&gic>;
-
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -84,147 +82,107 @@
reg = <0x203>;
};
};
+}; /* end of / */
- soc {
- compatible = "simple-bus";
+&aobus {
+ pinctrl_aobus: pinctrl at 84 {
+ compatible = "amlogic,meson8b-aobus-pinctrl";
+ reg = <0x84 0xc>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
- L2: l2-cache-controller at c4200000 {
- compatible = "arm,pl310-cache";
- reg = <0xc4200000 0x1000>;
- cache-unified;
- cache-level = <2>;
+ gpio_ao: ao-bank at 14 {
+ reg = <0x14 0x4>,
+ <0x2c 0x4>,
+ <0x24 0x8>;
+ reg-names = "mux", "pull", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_aobus 0 130 16>;
};
- gic: interrupt-controller at c4301000 {
- compatible = "arm,cortex-a9-gic";
- reg = <0xc4301000 0x1000>,
- <0xc4300100 0x0100>;
- interrupt-controller;
- #interrupt-cells = <3>;
- };
-
- reset: reset-controller at c1104404 {
- compatible = "amlogic,meson8b-reset";
- reg = <0xc1104404 0x20>;
- #reset-cells = <1>;
- };
-
- wdt: watchdog at c1109900 {
- compatible = "amlogic,meson8b-wdt";
- reg = <0xc1109900 0x8>;
- interrupts = <0 0 1>;
+ uart_ao_a_pins: uart_ao_a {
+ mux {
+ groups = "uart_tx_ao_a", "uart_rx_ao_a";
+ function = "uart_ao";
+ };
};
+ };
+};
- timer at c1109940 {
- compatible = "amlogic,meson6-timer";
- reg = <0xc1109940 0x18>;
- interrupts = <0 10 1>;
- };
+&cbus {
+ clkc: clock-controller at 4000 {
+ #clock-cells = <1>;
+ compatible = "amlogic,meson8b-clkc";
+ reg = <0x8000 0x4>, <0x4000 0x460>;
+ };
- uart_AO: serial at c81004c0 {
- compatible = "amlogic,meson-uart";
- reg = <0xc81004c0 0x18>;
- interrupts = <0 90 1>;
- clocks = <&clkc CLKID_CLK81>;
- status = "disabled";
- };
+ reset: reset-controller at 4404 {
+ compatible = "amlogic,meson8b-reset";
+ reg = <0x4404 0x20>;
+ #reset-cells = <1>;
+ };
- uart_A: serial at c11084c0 {
- compatible = "amlogic,meson-uart";
- reg = <0xc11084c0 0x18>;
- interrupts = <0 26 1>;
- clocks = <&clkc CLKID_CLK81>;
- status = "disabled";
- };
+ pwm_ab: pwm at 8550 {
+ compatible = "amlogic,meson8b-pwm";
+ reg = <0x8550 0x10>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
- uart_B: serial at c11084dc {
- compatible = "amlogic,meson-uart";
- reg = <0xc11084dc 0x18>;
- interrupts = <0 75 1>;
- clocks = <&clkc CLKID_CLK81>;
- status = "disabled";
- };
+ pwm_cd: pwm at 8650 {
+ compatible = "amlogic,meson8b-pwm";
+ reg = <0x8650 0x10>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
- uart_C: serial at c1108700 {
- compatible = "amlogic,meson-uart";
- reg = <0xc1108700 0x18>;
- interrupts = <0 93 1>;
- clocks = <&clkc CLKID_CLK81>;
- status = "disabled";
- };
+ pwm_ef: pwm at 86c0 {
+ compatible = "amlogic,meson8b-pwm";
+ reg = <0x86c0 0x10>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
- clkc: clock-controller at c1104000 {
- #clock-cells = <1>;
- compatible = "amlogic,meson8b-clkc";
- reg = <0xc1108000 0x4>, <0xc1104000 0x460>;
- };
+ wdt: watchdog at 9900 {
+ compatible = "amlogic,meson8b-wdt";
+ reg = <0x9900 0x8>;
+ interrupts = <0 0 1>;
+ };
- pwm_ab: pwm at 8550 {
- compatible = "amlogic,meson8b-pwm";
- reg = <0xc1108550 0x10>;
- #pwm-cells = <3>;
- status = "disabled";
- };
+ pinctrl_cbus: pinctrl at 9880 {
+ compatible = "amlogic,meson8b-cbus-pinctrl";
+ reg = <0x9880 0x10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
- pwm_cd: pwm at 8650 {
- compatible = "amlogic,meson8b-pwm";
- reg = <0xc1108650 0x10>;
- #pwm-cells = <3>;
- status = "disabled";
+ gpio: banks at 80b0 {
+ reg = <0x80b0 0x28>,
+ <0x80e8 0x18>,
+ <0x8120 0x18>,
+ <0x8030 0x38>;
+ reg-names = "mux", "pull", "pull-enable", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_cbus 0 0 130>;
};
+ };
+};
- pwm_ef: pwm at 86c0 {
- compatible = "amlogic,meson8b-pwm";
- reg = <0xc11086c0 0x10>;
- #pwm-cells = <3>;
- status = "disabled";
- };
+&uart_AO {
+ clocks = <&clkc CLKID_CLK81>;
+};
- pinctrl_cbus: pinctrl at c1109880 {
- compatible = "amlogic,meson8b-cbus-pinctrl";
- reg = <0xc1109880 0x10>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- gpio: banks at c11080b0 {
- reg = <0xc11080b0 0x28>,
- <0xc11080e8 0x18>,
- <0xc1108120 0x18>,
- <0xc1108030 0x38>;
- reg-names = "mux", "pull", "pull-enable", "gpio";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pinctrl_cbus 0 0 130>;
- };
- };
+&uart_A {
+ clocks = <&clkc CLKID_CLK81>;
+};
- pinctrl_aobus: pinctrl at c8100084 {
- compatible = "amlogic,meson8b-aobus-pinctrl";
- reg = <0xc8100084 0xc>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- gpio_ao: ao-bank at c1108030 {
- reg = <0xc8100014 0x4>,
- <0xc810002c 0x4>,
- <0xc8100024 0x8>;
- reg-names = "mux", "pull", "gpio";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pinctrl_aobus 0 130 16>;
- };
+&uart_B {
+ clocks = <&clkc CLKID_CLK81>;
+};
- uart_ao_a_pins: uart_ao_a {
- mux {
- groups = "uart_tx_ao_a", "uart_rx_ao_a";
- function = "uart_ao";
- };
- };
- };
- };
-}; /* end of / */
+&uart_C {
+ clocks = <&clkc CLKID_CLK81>;
+};
--
2.12.2
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: meson: organize devices in their corresponding busses
From: Martin Blumenstingl @ 2017-04-17 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417213938.22626-1-martin.blumenstingl@googlemail.com>
The Amlogic Meson SoCs have most of the internal peripherals organized
in busses. Use them to make the dts easier to read and to avoid
duplicated register (bus) offset definitions.
The bus information is taken from the vendor kernel:
#define IO_CBUS_PHY_BASE 0xc1100000 ///2M
#define IO_AOBUS_PHY_BASE 0xc8100000 ///1M
There are more internal busses (such as the abp bus which seems to
contain audio, HDMI and Mali registers), but since we don't have
drivers for them yet these are not added (yet).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm/boot/dts/meson.dtsi | 180 ++++++++++++++++++++++--------------------
arch/arm/boot/dts/meson6.dtsi | 2 -
arch/arm/boot/dts/meson8.dtsi | 116 ++++++++++++++++++---------
3 files changed, 171 insertions(+), 127 deletions(-)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index 8c77c87660cd..9701bd1bc298 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -65,110 +65,116 @@
#interrupt-cells = <3>;
};
- timer at c1109940 {
- compatible = "amlogic,meson6-timer";
- reg = <0xc1109940 0x18>;
- interrupts = <0 10 1>;
- };
-
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
- wdt: watchdog at c1109900 {
- compatible = "amlogic,meson6-wdt";
- reg = <0xc1109900 0x8>;
- interrupts = <0 0 1>;
- };
-
- uart_AO: serial at c81004c0 {
- compatible = "amlogic,meson-uart";
- reg = <0xc81004c0 0x18>;
- interrupts = <0 90 1>;
- clocks = <&clk81>;
- status = "disabled";
- };
-
- uart_A: serial at c11084c0 {
- compatible = "amlogic,meson-uart";
- reg = <0xc11084c0 0x18>;
- interrupts = <0 26 1>;
- clocks = <&clk81>;
- status = "disabled";
- };
-
- uart_B: serial at c11084dc {
- compatible = "amlogic,meson-uart";
- reg = <0xc11084dc 0x18>;
- interrupts = <0 75 1>;
- clocks = <&clk81>;
- status = "disabled";
- };
-
- uart_C: serial at c1108700 {
- compatible = "amlogic,meson-uart";
- reg = <0xc1108700 0x18>;
- interrupts = <0 93 1>;
- clocks = <&clk81>;
- status = "disabled";
- };
-
- i2c_AO: i2c at c8100500 {
- compatible = "amlogic,meson6-i2c";
- reg = <0xc8100500 0x20>;
- interrupts = <0 92 1>;
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
- status = "disabled";
- };
-
- i2c_A: i2c at c1108500 {
- compatible = "amlogic,meson6-i2c";
- reg = <0xc1108500 0x20>;
- interrupts = <0 21 1>;
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
- status = "disabled";
- };
-
- i2c_B: i2c at c11087c0 {
- compatible = "amlogic,meson6-i2c";
- reg = <0xc11087c0 0x20>;
- interrupts = <0 128 1>;
- clocks = <&clk81>;
+ cbus: cbus at c1100000 {
+ compatible = "simple-bus";
+ reg = <0xc1100000 0x200000>;
#address-cells = <1>;
- #size-cells = <0>;
- status = "disabled";
+ #size-cells = <1>;
+ ranges = <0x0 0xc1100000 0x200000>;
+
+ uart_A: serial at 84c0 {
+ compatible = "amlogic,meson-uart";
+ reg = <0x84c0 0x18>;
+ interrupts = <0 26 1>;
+ status = "disabled";
+ };
+
+ uart_B: serial at 84dc {
+ compatible = "amlogic,meson-uart";
+ reg = <0x84dc 0x18>;
+ interrupts = <0 75 1>;
+ status = "disabled";
+ };
+
+ i2c_A: i2c at 8500 {
+ compatible = "amlogic,meson6-i2c";
+ reg = <0x8500 0x20>;
+ interrupts = <0 21 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ uart_C: serial at 8700 {
+ compatible = "amlogic,meson-uart";
+ reg = <0x8700 0x18>;
+ interrupts = <0 93 1>;
+ status = "disabled";
+ };
+
+ i2c_B: i2c at 87c0 {
+ compatible = "amlogic,meson6-i2c";
+ reg = <0x87c0 0x20>;
+ interrupts = <0 128 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spifc: spi at 8c80 {
+ compatible = "amlogic,meson6-spifc";
+ reg = <0x8c80 0x80>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ wdt: watchdog at 9900 {
+ compatible = "amlogic,meson6-wdt";
+ reg = <0x9900 0x8>;
+ interrupts = <0 0 1>;
+ };
+
+ timer at 9940 {
+ compatible = "amlogic,meson6-timer";
+ reg = <0x9940 0x18>;
+ interrupts = <0 10 1>;
+ };
};
- ir_receiver: ir-receiver at c8100480 {
- compatible= "amlogic,meson6-ir";
- reg = <0xc8100480 0x20>;
- interrupts = <0 15 1>;
- status = "disabled";
- };
-
- spifc: spi at c1108c80 {
- compatible = "amlogic,meson6-spifc";
- reg = <0xc1108c80 0x80>;
+ aobus: aobus at c8100000 {
+ compatible = "simple-bus";
+ reg = <0xc8100000 0x100000>;
#address-cells = <1>;
- #size-cells = <0>;
- clocks = <&clk81>;
- status = "disabled";
+ #size-cells = <1>;
+ ranges = <0x0 0xc8100000 0x100000>;
+
+ ir_receiver: ir-receiver at 480 {
+ compatible= "amlogic,meson6-ir";
+ reg = <0x480 0x20>;
+ interrupts = <0 15 1>;
+ status = "disabled";
+ };
+
+ uart_AO: serial at 4c0 {
+ compatible = "amlogic,meson-uart";
+ reg = <0x4c0 0x18>;
+ interrupts = <0 90 1>;
+ status = "disabled";
+ };
+
+ i2c_AO: i2c at 500 {
+ compatible = "amlogic,meson6-i2c";
+ reg = <0x500 0x20>;
+ interrupts = <0 92 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
ethmac: ethernet at c9410000 {
compatible = "amlogic,meson6-dwmac", "snps,dwmac";
reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
+ 0xc1108108 0x4>;
interrupts = <0 8 1>;
interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/meson6.dtsi b/arch/arm/boot/dts/meson6.dtsi
index 8b33be15af94..b0fc91ffd6a1 100644
--- a/arch/arm/boot/dts/meson6.dtsi
+++ b/arch/arm/boot/dts/meson6.dtsi
@@ -51,8 +51,6 @@
model = "Amlogic Meson6 SoC";
compatible = "amlogic,meson6";
- interrupt-parent = <&gic>;
-
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index ebc763eab195..5eaaf067c76a 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -50,8 +50,6 @@
model = "Amlogic Meson8 SoC";
compatible = "amlogic,meson8";
- interrupt-parent = <&gic>;
-
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -91,18 +89,55 @@
clock-frequency = <141666666>;
};
- pinctrl_cbus: pinctrl at c1109880 {
+}; /* end of / */
+
+&aobus {
+ pinctrl_aobus: pinctrl at 84 {
+ compatible = "amlogic,meson8-aobus-pinctrl";
+ reg = <0x84 0xc>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gpio_ao: ao-bank at 14 {
+ reg = <0x14 0x4>,
+ <0x2c 0x4>,
+ <0x24 0x8>;
+ reg-names = "mux", "pull", "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pinctrl_aobus 0 120 16>;
+ };
+
+ uart_ao_a_pins: uart_ao_a {
+ mux {
+ groups = "uart_tx_ao_a", "uart_rx_ao_a";
+ function = "uart_ao";
+ };
+ };
+
+ i2c_ao_pins: i2c_mst_ao {
+ mux {
+ groups = "i2c_mst_sck_ao", "i2c_mst_sda_ao";
+ function = "i2c_mst_ao";
+ };
+ };
+ };
+};
+
+&cbus {
+ pinctrl_cbus: pinctrl at 9880 {
compatible = "amlogic,meson8-cbus-pinctrl";
- reg = <0xc1109880 0x10>;
+ reg = <0x9880 0x10>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
- gpio: banks at c11080b0 {
- reg = <0xc11080b0 0x28>,
- <0xc11080e8 0x18>,
- <0xc1108120 0x18>,
- <0xc1108030 0x30>;
+ gpio: banks at 80b0 {
+ reg = <0x80b0 0x28>,
+ <0x80e8 0x18>,
+ <0x8120 0x18>,
+ <0x8030 0x30>;
reg-names = "mux", "pull", "pull-enable", "gpio";
gpio-controller;
#gpio-cells = <2>;
@@ -134,36 +169,41 @@
};
};
};
+};
- pinctrl_aobus: pinctrl at c8100084 {
- compatible = "amlogic,meson8-aobus-pinctrl";
- reg = <0xc8100084 0xc>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
+ðmac {
+ clocks = <&clk81>;
+ clock-names = "stmmaceth";
+};
- gpio_ao: ao-bank at c1108030 {
- reg = <0xc8100014 0x4>,
- <0xc810002c 0x4>,
- <0xc8100024 0x8>;
- reg-names = "mux", "pull", "gpio";
- gpio-controller;
- #gpio-cells = <2>;
- gpio-ranges = <&pinctrl_aobus 0 120 16>;
- };
+&i2c_AO {
+ clocks = <&clk81>;
+};
- uart_ao_a_pins: uart_ao_a {
- mux {
- groups = "uart_tx_ao_a", "uart_rx_ao_a";
- function = "uart_ao";
- };
- };
+&i2c_A {
+ clocks = <&clk81>;
+};
- i2c_ao_pins: i2c_mst_ao {
- mux {
- groups = "i2c_mst_sck_ao", "i2c_mst_sda_ao";
- function = "i2c_mst_ao";
- };
- };
- };
-}; /* end of / */
+&i2c_B {
+ clocks = <&clk81>;
+};
+
+&spifc {
+ clocks = <&clk81>;
+};
+
+&uart_AO {
+ clocks = <&clk81>;
+};
+
+&uart_A {
+ clocks = <&clk81>;
+};
+
+&uart_B {
+ clocks = <&clk81>;
+};
+
+&uart_C {
+ clocks = <&clk81>;
+};
--
2.12.2
^ permalink raw reply related
* [PATCH 0/2] Amlogic Meson (32-bit) .dts cleanups
From: Martin Blumenstingl @ 2017-04-17 21:39 UTC (permalink / raw)
To: linux-arm-kernel
This series provides a few cleanups in the 32-bit Amlogic .dts files.
The first patch introduces the actual busses so the .dts' basic structure
is similar to what we have in the 64-bit .dts files.
The second patch removes even more duplication by inheriting meson.dtsi
from meson8b.dtsi (just like meson6.dtsi and meson8.dtsi are doing).
There should not be any functional changes with these patches. However,
I was only test this on a Meson8 based device, so it would be great if
somebody could test this on a Meson8b device.
Martin Blumenstingl (2):
ARM: dts: meson: organize devices in their corresponding busses
ARM: dts: meson8b: inherit meson.dtsi from meson8b.dtsi
arch/arm/boot/dts/meson.dtsi | 180 ++++++++++++++++++-----------------
arch/arm/boot/dts/meson6.dtsi | 2 -
arch/arm/boot/dts/meson8.dtsi | 116 +++++++++++++++--------
arch/arm/boot/dts/meson8b.dtsi | 210 +++++++++++++++++------------------------
4 files changed, 255 insertions(+), 253 deletions(-)
--
2.12.2
^ permalink raw reply
* Microphone gain on N900
From: Pavel Machek @ 2017-04-17 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <defb507c-0f4b-7dfe-817b-cb488f289aa3@bitmer.com>
Hi!
> >>>> v4.10 works quite nicely on N900, but I still have problems with
> >>>> audio. Even GSM calls would be usable, if I had reasonable volume on
> >>>> microphone and speaker... but I don't.
> >>>>
> >>>> Both speaker and microphone are too quiet. I can get louder output by
> >>>> plugging headset -- good. I can hear the other side nicely, but am
> >>>> too quiet for them. Unfortunately, even if I plug in wired headset,
> >>>> internal microphone is still used.
> >>>>
> >> For me these settings provide reasonable playback and capture volumes
> >> using v4.10.1:
> >>
> >> amixer -D hw:0 set PCM 100%
> >> amixer -D hw:0 set 'Line DAC' 80% on
> >> amixer -D hw:0 set 'Line' on
> >> amixer -D hw:0 set 'Left Line Mixer DACL1' on
> >> amixer -D hw:0 set 'Right Line Mixer DACR1' on
> >> amixer -D hw:0 set 'Jack Function' 'Headphone'
> >> amixer -D hw:0 set 'TPA6130A2 Headphone' 80%
> >>
> >> amixer -D hw:0 set 'Jack Function' 'Headset'
> >> amixer -D hw:0 set 'AGC' off
> >> amixer -D hw:0 set 'Input Select' 'ADC'
> >> amixer -D hw:0 set 'Left PGA Mixer Line1L' on
> >> amixer -D hw:0 set 'Left Line1L Mux' 'differential'
> >> amixer -D hw:0 set 'Right PGA Mixer Line1L' on
> >> amixer -D hw:0 set 'Right Line1L Mux' 'differential'
> >> amixer -D hw:0 set 'ADC HPF Cut-off' '0.0045xFs' 'disabled'
> >> amixer -D hw:0 set PGA 50% on
> >> amixer -D hw:0 cset iface=MIXER,name='PGA Capture Switch',index=0 on
> >
> > This seems to correspond to volumes I have had before. They are enough
> > for phone call in quiet environment, but not really for normal usage.
> >
> > Do you have settings where microphone on wired headset works?
> >
> Those settings above. They are set after putting all volumes to 0 and
> muted. I'm using the Nokia WH-205 headset that came with the phone.
I just wanted to say thank you. I finally got to testing those
settings again, and this time headset microphone definitely works.
Loopback using arecord | aplay now produces reasonable volume of
audio. (Unfortunately, I still have some problems somewhere in the
audio<->GSM path :-( ).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170417/4432e410/attachment.sig>
^ permalink raw reply
* [PATCH v3 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Adam Ford @ 2017-04-17 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413150353.7389-4-robh@kernel.org>
On Thu, Apr 13, 2017 at 10:03 AM, Rob Herring <robh@kernel.org> wrote:
> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
>
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.
I am using pdata-quirks to drive my wl1283 Bluetooth on a DM3730. I
have the Bluetooth set to 3000000 baud in pdata quirks. Looking at
the binding, I don't see an option to set the baudrate. Is there (or
will there) be a way to set the baud rate of the Bluetooth?
adam
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: linux-bluetooth at vger.kernel.org
> ---
> v3:
> - rebase on bluetooth-next
> - Add explicit of.h include
> v2:
> - Use IS_ENABLED() to fix module build
>
> drivers/bluetooth/hci_ll.c | 262 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 261 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 02692fe30279..485e8eb04542 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -34,20 +34,24 @@
> #include <linux/sched.h>
> #include <linux/types.h>
> #include <linux/fcntl.h>
> +#include <linux/firmware.h>
> #include <linux/interrupt.h>
> #include <linux/ptrace.h>
> #include <linux/poll.h>
>
> #include <linux/slab.h>
> -#include <linux/tty.h>
> #include <linux/errno.h>
> #include <linux/string.h>
> #include <linux/signal.h>
> #include <linux/ioctl.h>
> +#include <linux/of.h>
> +#include <linux/serdev.h>
> #include <linux/skbuff.h>
> +#include <linux/ti_wilink_st.h>
>
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
> +#include <linux/gpio/consumer.h>
>
> #include "hci_uart.h"
>
> @@ -76,6 +80,12 @@ struct hcill_cmd {
> u8 cmd;
> } __packed;
>
> +struct ll_device {
> + struct hci_uart hu;
> + struct serdev_device *serdev;
> + struct gpio_desc *enable_gpio;
> +};
> +
> struct ll_struct {
> unsigned long rx_state;
> unsigned long rx_count;
> @@ -136,6 +146,9 @@ static int ll_open(struct hci_uart *hu)
>
> hu->priv = ll;
>
> + if (hu->serdev)
> + serdev_device_open(hu->serdev);
> +
> return 0;
> }
>
> @@ -164,6 +177,13 @@ static int ll_close(struct hci_uart *hu)
>
> kfree_skb(ll->rx_skb);
>
> + if (hu->serdev) {
> + struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
> + gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +
> + serdev_device_close(hu->serdev);
> + }
> +
> hu->priv = NULL;
>
> kfree(ll);
> @@ -505,9 +525,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
> return skb_dequeue(&ll->txq);
> }
>
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
> +static int read_local_version(struct hci_dev *hdev)
> +{
> + int err = 0;
> + unsigned short version = 0;
> + struct sk_buff *skb;
> + struct hci_rp_read_local_version *ver;
> +
> + skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb)) {
> + bt_dev_err(hdev, "Reading TI version information failed (%ld)",
> + PTR_ERR(skb));
> + err = PTR_ERR(skb);
> + goto out;
> + }
> + if (skb->len != sizeof(*ver)) {
> + err = -EILSEQ;
> + goto out;
> + }
> +
> + ver = (struct hci_rp_read_local_version *)skb->data;
> + if (le16_to_cpu(ver->manufacturer) != 13) {
> + err = -ENODEV;
> + goto out;
> + }
> +
> + version = le16_to_cpu(ver->lmp_subver);
> +
> +out:
> + if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
> + kfree_skb(skb);
> + return err ? err : version;
> +}
> +
> +/**
> + * download_firmware -
> + * internal function which parses through the .bts firmware
> + * script file intreprets SEND, DELAY actions only as of now
> + */
> +static int download_firmware(struct ll_device *lldev)
> +{
> + unsigned short chip, min_ver, maj_ver;
> + int version, err, len;
> + unsigned char *ptr, *action_ptr;
> + unsigned char bts_scr_name[40]; /* 40 char long bts scr name? */
> + const struct firmware *fw;
> + struct sk_buff *skb;
> + struct hci_command *cmd;
> +
> + version = read_local_version(lldev->hu.hdev);
> + if (version < 0)
> + return version;
> +
> + chip = (version & 0x7C00) >> 10;
> + min_ver = (version & 0x007F);
> + maj_ver = (version & 0x0380) >> 7;
> + if (version & 0x8000)
> + maj_ver |= 0x0008;
> +
> + snprintf(bts_scr_name, sizeof(bts_scr_name),
> + "ti-connectivity/TIInit_%d.%d.%d.bts",
> + chip, maj_ver, min_ver);
> +
> + err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
> + if (err || !fw->data || !fw->size) {
> + bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
> + err, bts_scr_name);
> + return -EINVAL;
> + }
> + ptr = (void *)fw->data;
> + len = fw->size;
> + /* bts_header to remove out magic number and
> + * version
> + */
> + ptr += sizeof(struct bts_header);
> + len -= sizeof(struct bts_header);
> +
> + while (len > 0 && ptr) {
> + bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
> + ((struct bts_action *)ptr)->size,
> + ((struct bts_action *)ptr)->type);
> +
> + action_ptr = &(((struct bts_action *)ptr)->data[0]);
> +
> + switch (((struct bts_action *)ptr)->type) {
> + case ACTION_SEND_COMMAND: /* action send */
> + bt_dev_dbg(lldev->hu.hdev, "S");
> + cmd = (struct hci_command *)action_ptr;
> + if (cmd->opcode == 0xff36) {
> + /* ignore remote change
> + * baud rate HCI VS command */
> + bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
> + break;
> + }
> + if (cmd->prefix != 1)
> + bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
> +
> + skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb)) {
> + bt_dev_err(lldev->hu.hdev, "send command failed\n");
> + goto out_rel_fw;
> + }
> + kfree_skb(skb);
> + break;
> + case ACTION_WAIT_EVENT: /* wait */
> + /* no need to wait as command was synchronous */
> + bt_dev_dbg(lldev->hu.hdev, "W");
> + break;
> + case ACTION_DELAY: /* sleep */
> + bt_dev_info(lldev->hu.hdev, "sleep command in scr");
> + mdelay(((struct bts_action_delay *)action_ptr)->msec);
> + break;
> + }
> + len -= (sizeof(struct bts_action) +
> + ((struct bts_action *)ptr)->size);
> + ptr += sizeof(struct bts_action) +
> + ((struct bts_action *)ptr)->size;
> + }
> +
> +out_rel_fw:
> + /* fw download complete */
> + release_firmware(fw);
> + return err;
> +}
> +
> +static int ll_setup(struct hci_uart *hu)
> +{
> + int err, retry = 3;
> + struct ll_device *lldev;
> + struct serdev_device *serdev = hu->serdev;
> + u32 speed;
> +
> + if (!serdev)
> + return 0;
> +
> + lldev = serdev_device_get_drvdata(serdev);
> +
> + serdev_device_set_flow_control(serdev, true);
> +
> + do {
> + /* Configure BT_EN to HIGH state */
> + gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> + msleep(5);
> + gpiod_set_value_cansleep(lldev->enable_gpio, 1);
> + msleep(100);
> +
> + err = download_firmware(lldev);
> + if (!err)
> + break;
> +
> + /* Toggle BT_EN and retry */
> + bt_dev_err(hu->hdev, "download firmware failed, retrying...");
> + } while (retry--);
> +
> + if (err)
> + return err;
> +
> + /* Operational speed if any */
> + if (hu->oper_speed)
> + speed = hu->oper_speed;
> + else if (hu->proto->oper_speed)
> + speed = hu->proto->oper_speed;
> + else
> + speed = 0;
> +
> + if (speed) {
> + struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
> + if (!IS_ERR(skb)) {
> + kfree_skb(skb);
> + serdev_device_set_baudrate(serdev, speed);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static const struct hci_uart_proto llp;
> +
> +static int hci_ti_probe(struct serdev_device *serdev)
> +{
> + struct hci_uart *hu;
> + struct ll_device *lldev;
> + u32 max_speed = 3000000;
> +
> + lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
> + if (!lldev)
> + return -ENOMEM;
> + hu = &lldev->hu;
> +
> + serdev_device_set_drvdata(serdev, lldev);
> + lldev->serdev = hu->serdev = serdev;
> +
> + lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(lldev->enable_gpio))
> + return PTR_ERR(lldev->enable_gpio);
> +
> + of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
> + hci_uart_set_speeds(hu, 115200, max_speed);
> +
> + return hci_uart_register_device(hu, &llp);
> +}
> +
> +static void hci_ti_remove(struct serdev_device *serdev)
> +{
> + struct ll_device *lldev = serdev_device_get_drvdata(serdev);
> + struct hci_uart *hu = &lldev->hu;
> + struct hci_dev *hdev = hu->hdev;
> +
> + cancel_work_sync(&hu->write_work);
> +
> + hci_unregister_dev(hdev);
> + hci_free_dev(hdev);
> + hu->proto->close(hu);
> +}
> +
> +static const struct of_device_id hci_ti_of_match[] = {
> + { .compatible = "ti,wl1831-st" },
> + { .compatible = "ti,wl1835-st" },
> + { .compatible = "ti,wl1837-st" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, hci_ti_of_match);
> +
> +static struct serdev_device_driver hci_ti_drv = {
> + .driver = {
> + .name = "hci-ti",
> + .of_match_table = of_match_ptr(hci_ti_of_match),
> + },
> + .probe = hci_ti_probe,
> + .remove = hci_ti_remove,
> +};
> +#else
> +#define ll_setup NULL
> +#endif
> +
> static const struct hci_uart_proto llp = {
> .id = HCI_UART_LL,
> .name = "LL",
> + .setup = ll_setup,
> .open = ll_open,
> .close = ll_close,
> .recv = ll_recv,
> @@ -518,10 +774,14 @@ static const struct hci_uart_proto llp = {
>
> int __init ll_init(void)
> {
> + serdev_device_driver_register(&hci_ti_drv);
> +
> return hci_uart_register_proto(&llp);
> }
>
> int __exit ll_deinit(void)
> {
> + serdev_device_driver_unregister(&hci_ti_drv);
> +
> return hci_uart_unregister_proto(&llp);
> }
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V5 2/2] thermal: broadcom: add Northstar thermal driver
From: Stefan Wahren @ 2017-04-17 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dd2617d-a8a8-d7a4-53a4-7ebcb274573c@milecki.pl>
> Rafa? Mi?ecki <rafal@milecki.pl> hat am 14. April 2017 um 14:16 geschrieben:
>
>
> On 04/07/2017 06:42 AM, Eduardo Valentin wrote:
> > On Mon, Apr 03, 2017 at 05:48:29PM +0200, Rafa? Mi?ecki wrote:
> >> From: Rafa? Mi?ecki <rafal@milecki.pl>
> >>
> >> Northstar is a SoC family commonly used in home routers. This commit
> >> adds a driver for checking CPU temperature. As Northstar Plus seems to
> >> also have this IP block this new symbol gets ARCH_BCM_IPROC dependency.
> >>
> >> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
> >> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> >
> > If no objection, I am applying this series.
>
> Cool, hopefully there aren't any more objections :) Once applied should I
> expect this in
> https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/log/?h=next
> ?
>
> That would allow me to move bcm2835_thermal.c to the broadcom subdir.
Thanks for doing this. Btw Northstar thermal driver misses a MODULE_AUTHOR.
Regards
Stefan
^ permalink raw reply
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Bjorn Helgaas @ 2017-04-17 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417174712.GA7575@localhost>
On Mon, Apr 17, 2017 at 12:47 PM, Jayachandran C
<jnair@caviumnetworks.com> wrote:
> On Fri, Apr 14, 2017 at 09:00:06PM -0500, Bjorn Helgaas wrote:
>> On Fri, Apr 14, 2017 at 4:06 PM, Jayachandran C
>> <jnair@caviumnetworks.com> wrote:
>> > On Thu, Apr 13, 2017 at 07:19:11PM -0500, Bjorn Helgaas wrote:
>> >> I tentatively applied both patches to pci/host-thunder for v4.12.
>> >>
>> >> However, I am concerned about the topology here:
>> >>
>> >> On Thu, Apr 13, 2017 at 08:30:45PM +0000, Jayachandran C wrote:
>> >> > On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the
>> >> > PCI topology is slightly unusual. For a multi-node system, it looks
>> >> > like:
>> >> >
>> >> > 00:00.0 [PCI] bridge to [bus 01-1e]
>> >> > 01:0a.0 [PCI-PCIe bridge, type 8] bridge to [bus 02-04]
>> >> > 02:00.0 [PCIe root port, type 4] bridge to [bus 03-04] (XLATE_ROOT)
>> >> > 03:00.0 PCIe Endpoint
>> >>
>> >> A root port normally has a single PCIe link leading downstream.
>> >> According to this, 02:00.0 is a root port that has the usual
>> >> downstream link leading to 03:00.0, but it also has an upstream link
>> >> to 01:0a.0.
>> >
>> > The PCI topology is a bit broken due to the way that the PCIe IP block
>> > was integrated into SoC PCI bridges and devices. The current mechanism
>> > of adding a PCI-PCIe bridge to glue these together is not ideal.
>>
>> Yeah, that's definitely broken.
>>
>> >> Maybe this example is omitting details that are not relevant to DMA
>> >> aliases? The PCIe capability only contains one set of link-related
>> >> registers, so I don't know how we could manage a single device that
>> >> has two links.
>> >
>> > The root port is standard and has just one link to the EP (or whatever
>> > is on the external PCIe slot). The fallout of the current hw design is
>> > that the PCI-PCIe bridge has a link that does not follow standard and
>> > does not have a counterpart (as you noted).
>> >
>> >> A device with two links would break things like ASPM. In
>> >> set_pcie_port_type(), for example, we have this comment:
>> >>
>> >> * A Root Port or a PCI-to-PCIe bridge is always the upstream end
>> >> * of a Link. No PCIe component has two Links. Two Links are
>> >> * connected by a Switch that has a Port on each Link and internal
>> >> * logic to connect the two Ports.
>> >>
>> >> The topology above breaks these assumptions, which will make
>> >> pdev->has_secondary_link incorrect, which means ASPM won't work
>> >> correctly.
>> >
>> > Given the current hardware, the pcieport driver seems to work reasonably
>> > for the root port at 02:00.0, with AER support. I will take a look at the
>> > ASPM part.
>>
>> I don't think pcieport itself cares much about links. ASPM does, but
>> it looks like set_pcie_port_type() actually is smart enough to know
>> that PCI-to-PCIe bridges and Root Ports always have links on their
>> secondary sides. So has_secondary_link probably does get set
>> correctly.
>>
>> But I think you'll hit the VIA "strange chipset" thing in
>> pcie_aspm_init_link_state(), which will probably prevent us from doing
>> ASPM on the link from 02:00.0 to 03:00.0.
>>
>> Could you collect "lspci -vv" output from this system? I'd like to
>> archive that as background for this IOMMU issue and the ASPM tweaks I
>> suspect we'll have to do. I *wish* we had more information about that
>> VIA thing, because I suspect we could get rid of it if we had more
>> details.
>
> The full logs are slightly large, so I have kept them at:
> https://github.com/jchandra-cavm/thunderx2/blob/master/logs/
> The lspci -vv output is lspci-vv.txt and lspci -tvn output is lspci-tvn.txt
>
> The output is from 2 socket system, the cards are not on the first slot
> like the example above, so the bus and device numbers are different.
>
> Looks like I have to spend some time on ASPM next.
Thanks, I attached these to
https://bugzilla.kernel.org/show_bug.cgi?id=195447 and added that link
to the changelogs.
01:0a.0 PCI-to-PCIe bridge to [bus 02-03]
Capabilities: [40] Express (v2) PCI/PCI-X to PCI-Express Bridge
lspci doesn't decode the "Slot Implemented" bit here. The spec (PCIe
r3.1, sec 7.8.2) isn't explicit about whether that bit is defined for
this kind of bridge, but it seems to me like this bridge contains a
Downstream Port that could lead to a slot, so we *should* decode "Slot
Implemented", and if it does indicate a slot, we should decode the
Slot Capabilities, Control, and Status registers as well.
Linux also doesn't currently believe this bridge can have a slot below
it (see pcie_cap_has_sltctl() and pcie_downstream_port()). I don't
know if your topology has actual slots there, but I think the spec
does allow it, so Linux probably should handle that.
For this port:
02:00.0 Root Port to [bus 03]
Capabilities: [ac] Express (v2) Root Port (Slot-)
I'm pretty sure there *is* a slot (currently empty), and your lspci
output shows "Slot-", which seems wrong to me. It should show "Slot+"
with Presence Detect State showing "Slot Empty", shouldn't it?
Bjorn
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301X: Add CPU thermal sensor and zone
From: Jon Mason @ 2017-04-17 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6rwR__iyPO6NcO3STtKz+aXfNiZFsNXhYwTHs27pTrrU9Q@mail.gmail.com>
On Mon, Apr 17, 2017 at 12:14 PM, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 17 April 2017 at 16:54, Jon Mason <jon.mason@broadcom.com> wrote:
>> On Fri, Apr 14, 2017 at 5:42 PM, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>>> From: Rafa? Mi?ecki <rafal@milecki.pl>
>>>
>>> This uses CPU thermal sensor available on every Northstar chipset to
>>> monitor temperature. We don't have any cooling or throttling so only a
>>> critical trip was added.
>>
>> Haha! You beat me to it (as I had a similar patch queued).
>>
>> This looks good to me.
>>
>> Acked-by: Jon Mason <jon.mason@broadcom.com>
>
> :) Thanks
>
> I'd appreciate adding thermal to NSP DT. I don't have any NSP unit to
> try it on my own.
I'm doing so right now. I have it working, I just need to clean up the patches.
^ permalink raw reply
* [PATCH net-next] drivers: net: xgene-v2: Extend ethtool statistics
From: David Miller @ 2017-04-17 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492213698-27813-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Fri, 14 Apr 2017 16:48:18 -0700
> + XGE_EXTD_STAT(rx_byte_cntr, RBYT),
> + XGE_EXTD_STAT(rx_pkt_cntr, RPKT),
> + XGE_EXTD_STAT(rx_fcs_error_cntr, RFCS),
> + XGE_EXTD_STAT(rx_multicast_pkt_cntr, RMCA),
> + XGE_EXTD_STAT(rx_broadcast_pkt_cntr, RBCA),
Do not duplicate statistics already reported via xge_get_stats64().
^ permalink raw reply
* [PATCH v3 2/2] phy: meson: add USB2 PHY support for Meson GXL and GXM
From: Martin Blumenstingl @ 2017-04-17 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417191142.26099-1-martin.blumenstingl@googlemail.com>
This adds a new driver for the USB2 PHYs found on Meson GXL and GXM SoCs
(both SoCs are using the same USB PHY register layout).
The USB2 PHY is a simple PHY which only has a few registers to configure
the mode (host/device) and a reset register (to enable/disable the PHY).
Unfortunately there are no datasheets available for this PHY. The driver
was written by reading the code from Amlogic's GPL kernel sources and
by analyzing the registers on an actual GXL and GXM device running the
kernel that was shipped on the boards I have.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/phy/Kconfig | 12 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-meson-gxl-usb2.c | 261 +++++++++++++++++++++++++++++++++++++++
3 files changed, 274 insertions(+)
create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 005cadb7a3f8..fada8354c0fe 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -511,4 +511,16 @@ config PHY_MESON8B_USB2
and GXBB SoCs.
If unsure, say N.
+config PHY_MESON_GXL_USB
+ tristate "Meson GXL and GXM USB2 PHY drivers"
+ default ARCH_MESON
+ depends on OF && (ARCH_MESON || COMPILE_TEST)
+ depends on USB_SUPPORT
+ select GENERIC_PHY
+ select REGMAP_MMIO
+ help
+ Enable this to support the Meson USB2 PHYs found in Meson
+ GXL and GXM SoCs.
+ If unsure, say N.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index dd8f3b5d2918..4f5ede46b0b9 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
+obj-$(CONFIG_PHY_MESON_GXL_USB) += phy-meson-gxl-usb2.o
diff --git a/drivers/phy/phy-meson-gxl-usb2.c b/drivers/phy/phy-meson-gxl-usb2.c
new file mode 100644
index 000000000000..f5fbd3c09542
--- /dev/null
+++ b/drivers/phy/phy-meson-gxl-usb2.c
@@ -0,0 +1,261 @@
+/*
+ * Meson GXL and GXM USB2 PHY driver
+ *
+ * Copyright (C) 2017 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* bits [31:27] are read-only */
+#define U2P_R0 0x0
+ #define U2P_R0_BYPASS_SEL BIT(0)
+ #define U2P_R0_BYPASS_DM_EN BIT(1)
+ #define U2P_R0_BYPASS_DP_EN BIT(2)
+ #define U2P_R0_TXBITSTUFF_ENH BIT(3)
+ #define U2P_R0_TXBITSTUFF_EN BIT(4)
+ #define U2P_R0_DM_PULLDOWN BIT(5)
+ #define U2P_R0_DP_PULLDOWN BIT(6)
+ #define U2P_R0_DP_VBUS_VLD_EXT_SEL BIT(7)
+ #define U2P_R0_DP_VBUS_VLD_EXT BIT(8)
+ #define U2P_R0_ADP_PRB_EN BIT(9)
+ #define U2P_R0_ADP_DISCHARGE BIT(10)
+ #define U2P_R0_ADP_CHARGE BIT(11)
+ #define U2P_R0_DRV_VBUS BIT(12)
+ #define U2P_R0_ID_PULLUP BIT(13)
+ #define U2P_R0_LOOPBACK_EN_B BIT(14)
+ #define U2P_R0_OTG_DISABLE BIT(15)
+ #define U2P_R0_COMMON_ONN BIT(16)
+ #define U2P_R0_FSEL_MASK GENMASK(19, 17)
+ #define U2P_R0_REF_CLK_SEL_MASK GENMASK(21, 20)
+ #define U2P_R0_POWER_ON_RESET BIT(22)
+ #define U2P_R0_V_ATE_TEST_EN_B_MASK GENMASK(24, 23)
+ #define U2P_R0_ID_SET_ID_DQ BIT(25)
+ #define U2P_R0_ATE_RESET BIT(26)
+ #define U2P_R0_FSV_MINUS BIT(27)
+ #define U2P_R0_FSV_PLUS BIT(28)
+ #define U2P_R0_BYPASS_DM_DATA BIT(29)
+ #define U2P_R0_BYPASS_DP_DATA BIT(30)
+
+#define U2P_R1 0x4
+ #define U2P_R1_BURN_IN_TEST BIT(0)
+ #define U2P_R1_ACA_ENABLE BIT(1)
+ #define U2P_R1_DCD_ENABLE BIT(2)
+ #define U2P_R1_VDAT_SRC_EN_B BIT(3)
+ #define U2P_R1_VDAT_DET_EN_B BIT(4)
+ #define U2P_R1_CHARGES_SEL BIT(5)
+ #define U2P_R1_TX_PREEMP_PULSE_TUNE BIT(6)
+ #define U2P_R1_TX_PREEMP_AMP_TUNE_MASK GENMASK(8, 7)
+ #define U2P_R1_TX_RES_TUNE_MASK GENMASK(10, 9)
+ #define U2P_R1_TX_RISE_TUNE_MASK GENMASK(12, 11)
+ #define U2P_R1_TX_VREF_TUNE_MASK GENMASK(16, 13)
+ #define U2P_R1_TX_FSLS_TUNE_MASK GENMASK(20, 17)
+ #define U2P_R1_TX_HSXV_TUNE_MASK GENMASK(22, 21)
+ #define U2P_R1_OTG_TUNE_MASK GENMASK(25, 23)
+ #define U2P_R1_SQRX_TUNE_MASK GENMASK(28, 26)
+ #define U2P_R1_COMP_DIS_TUNE_MASK GENMASK(31, 29)
+
+/* bits [31:14] are read-only */
+#define U2P_R2 0x8
+ #define U2P_R2_DATA_IN_MASK GENMASK(3, 0)
+ #define U2P_R2_DATA_IN_EN_MASK GENMASK(7, 4)
+ #define U2P_R2_ADDR_MASK GENMASK(11, 8)
+ #define U2P_R2_DATA_OUT_SEL BIT(12)
+ #define U2P_R2_CLK BIT(13)
+ #define U2P_R2_DATA_OUT_MASK GENMASK(17, 14)
+ #define U2P_R2_ACA_PIN_RANGE_C BIT(18)
+ #define U2P_R2_ACA_PIN_RANGE_B BIT(19)
+ #define U2P_R2_ACA_PIN_RANGE_A BIT(20)
+ #define U2P_R2_ACA_PIN_GND BIT(21)
+ #define U2P_R2_ACA_PIN_FLOAT BIT(22)
+ #define U2P_R2_CHARGE_DETECT BIT(23)
+ #define U2P_R2_DEVICE_SESSION_VALID BIT(24)
+ #define U2P_R2_ADP_PROBE BIT(25)
+ #define U2P_R2_ADP_SENSE BIT(26)
+ #define U2P_R2_SESSION_END BIT(27)
+ #define U2P_R2_VBUS_VALID BIT(28)
+ #define U2P_R2_B_VALID BIT(29)
+ #define U2P_R2_A_VALID BIT(30)
+ #define U2P_R2_ID_DIG BIT(31)
+
+#define U2P_R3 0xc
+
+#define RESET_COMPLETE_TIME 500
+
+struct phy_meson_gxl_usb2_priv {
+ struct regmap *regmap;
+ enum phy_mode mode;
+ int is_enabled;
+};
+
+static const struct regmap_config phy_meson_gxl_usb2_regmap_conf = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = U2P_R3,
+};
+
+static int phy_meson_gxl_usb2_reset(struct phy *phy)
+{
+ struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
+
+ if (!priv->is_enabled)
+ return 0;
+
+ /* reset the PHY and wait until settings are stabilized */
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET,
+ U2P_R0_POWER_ON_RESET);
+ udelay(RESET_COMPLETE_TIME);
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET, 0);
+ udelay(RESET_COMPLETE_TIME);
+
+ return 0;
+}
+
+static int phy_meson_gxl_usb2_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
+
+ switch (mode) {
+ case PHY_MODE_USB_HOST:
+ case PHY_MODE_USB_OTG:
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DM_PULLDOWN,
+ U2P_R0_DM_PULLDOWN);
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DP_PULLDOWN,
+ U2P_R0_DP_PULLDOWN);
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_ID_PULLUP, 0);
+ break;
+
+ case PHY_MODE_USB_DEVICE:
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DM_PULLDOWN,
+ 0);
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_DP_PULLDOWN,
+ 0);
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_ID_PULLUP,
+ U2P_R0_ID_PULLUP);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ phy_meson_gxl_usb2_reset(phy);
+
+ priv->mode = mode;
+
+ return 0;
+}
+
+static int phy_meson_gxl_usb2_power_off(struct phy *phy)
+{
+ struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
+
+ priv->is_enabled = 0;
+
+ /* power off the PHY by putting it into reset mode */
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET,
+ U2P_R0_POWER_ON_RESET);
+
+ return 0;
+}
+
+static int phy_meson_gxl_usb2_power_on(struct phy *phy)
+{
+ struct phy_meson_gxl_usb2_priv *priv = phy_get_drvdata(phy);
+ int ret;
+
+ priv->is_enabled = 1;
+
+ /* power on the PHY by taking it out of reset mode */
+ regmap_update_bits(priv->regmap, U2P_R0, U2P_R0_POWER_ON_RESET, 0);
+
+ ret = phy_meson_gxl_usb2_set_mode(phy, priv->mode);
+ if (ret) {
+ phy_meson_gxl_usb2_power_off(phy);
+
+ dev_err(&phy->dev, "Failed to initialize PHY with mode %d\n",
+ priv->mode);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct phy_ops phy_meson_gxl_usb2_ops = {
+ .power_on = phy_meson_gxl_usb2_power_on,
+ .power_off = phy_meson_gxl_usb2_power_off,
+ .set_mode = phy_meson_gxl_usb2_set_mode,
+ .reset = phy_meson_gxl_usb2_reset,
+ .owner = THIS_MODULE,
+};
+
+static int phy_meson_gxl_usb2_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct phy_provider *phy_provider;
+ struct resource *res;
+ struct phy_meson_gxl_usb2_priv *priv;
+ struct phy *phy;
+ void __iomem *base;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ priv->mode = PHY_MODE_USB_HOST;
+
+ priv->regmap = devm_regmap_init_mmio(dev, base,
+ &phy_meson_gxl_usb2_regmap_conf);
+ if (IS_ERR(priv->regmap))
+ return PTR_ERR(priv->regmap);
+
+ phy = devm_phy_create(dev, NULL, &phy_meson_gxl_usb2_ops);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create PHY\n");
+ return PTR_ERR(phy);
+ }
+
+ phy_set_drvdata(phy, priv);
+
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+
+ return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id phy_meson_gxl_usb2_of_match[] = {
+ { .compatible = "amlogic,meson-gxl-usb2-phy", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, phy_meson_gxl_usb2_of_match);
+
+static struct platform_driver phy_meson_gxl_usb2_driver = {
+ .probe = phy_meson_gxl_usb2_probe,
+ .driver = {
+ .name = "phy-meson-gxl-usb2",
+ .of_match_table = phy_meson_gxl_usb2_of_match,
+ },
+};
+module_platform_driver(phy_meson_gxl_usb2_driver);
+
+MODULE_AUTHOR("Martin Blumenstingl <martin.blumenstingl@googlemail.com>");
+MODULE_DESCRIPTION("Meson GXL and GXM USB2 PHY driver");
+MODULE_LICENSE("GPL v2");
--
2.12.2
^ permalink raw reply related
* [PATCH v3 1/2] Documentation: dt-bindings: Add documentation for the Meson GXL USB2 PHY
From: Martin Blumenstingl @ 2017-04-17 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417191142.26099-1-martin.blumenstingl@googlemail.com>
This adds the DT binding documentation for the USB2 PHY(s) found in the
Meson GXL and GXM SoCs.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/phy/meson-gxl-usb2-phy.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
new file mode 100644
index 000000000000..a105494a0fc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
@@ -0,0 +1,17 @@
+* Amlogic Meson GXL and GXM USB2 PHY binding
+
+Required properties:
+- compatible: Should be "amlogic,meson-gxl-usb2-phy"
+- reg: The base address and length of the registers
+- #phys-cells: must be 0 (see phy-bindings.txt in this directory)
+
+Optional properties:
+- phy-supply: see phy-bindings.txt in this directory
+
+
+Example:
+ usb2_phy0: phy at 78000 {
+ compatible = "amlogic,meson-gxl-usb2-phy";
+ #phy-cells = <0>;
+ reg = <0x0 0x78000 0x0 0x20>;
+ };
--
2.12.2
^ permalink raw reply related
* [PATCH v3 0/2] Meson GXL USB2 PHY driver
From: Martin Blumenstingl @ 2017-04-17 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170318130013.20771-1-martin.blumenstingl@googlemail.com>
This series adds a driver for the USB2 PHYs found in Amlogic Meson GXL
(and GXM) SoCs.
Devicetree changes are intentionally missing in this series because of
various other problems that need to be resolved before we get USB host
support working.
As usual we unfortunately don't have any documentation available. The
register definitions were taken from the vendor's GPL kernel sources
(see [5] if you are really interested). Translation to human readable
names is done using the "best effort" algorithm.
The USB situation on GXL and GXM is a bit special:
the SoCs include both, a dwc3 and a dwc2 controller. The dwc3 controller
IP only supports host-mode, while the dwc2 controller IP only supports
device mode.
The dwc3 controller has all USB3 ports disabled. GXL has two USB2 ports
enabled on dwc3's internal hub, while GXM has three USB2 ports enabled.
This makes the initialization a bit special: to enable any of the dwc3
controller's USB2 ports *ALL* PHYs have to be initialized (probably due
to the hub's routing logic).
The first USB2 PHY (hardware-wise) also supports OTG mode. The vendor
kernel implements this through the USB3 PHY by re-routing the first
USB2 PHY from the dwc3 controller to the dwc2 controller (which is
disabled by default, but if the USB3 PHY detects that the port should
enter device mode it enables the dwc2 controller).
To get USB host mode working the following steps are needed:
- xhci-plat must be able to manage more than one PHY for a controller,
this is work-in-progress, see [0]
- there are some DMA handling issues in dwc3 and the rest of the USB
stack, this is solved by the "sysdev" patches from [1]
- adding all USB related bits to meson-gxl.dtsi - this is work in
progress but depends on the previous TODOs, see [2] and [3]
This supersedes my previous series "Meson GXL and GXM USB support" [4].
Changes since v2:
- removed PHY mode parsing from phy_meson_gxl_usb2_probe (based on
of_usb_get_dr_mode_by_phy()) because this will not work with the
xhci-plat changes anyways. The driver now simply defaults to host
mode until a consumer uses phy_set_mode().
- fixed a stray newline in drivers/phy/Kconfig b/drivers/phy/Kconfig
(thanks for spotting this Kishon)
- simplified phy_meson_gxl_usb2_reset() by returning early (thanks
Kishon for suggesting this improvement)
Changes since v1:
- rebased to the next branch of Kishon's linux-phy tree (currently at
fe0134d071 "phy: phy-exynos-pcie: make it explicitly non-modular")
- added a missing call to phy_meson_gxl_usb2_power_off in the error
case in phy_meson_gxl_usb2_power_on - thanks to Hendrik v. Raven for
spotting this!
- moved the reset logic into a separate function and expose it through
phy_ops.reset so it can be used by consumers of this PHY.
phy_meson_gxl_usb2_set_mode still resets the PHY directly because
this PHY will be configured by xhci-plat (from which we cannot call
phy_reset() - see the discussion based on v1 of this patch: [6])
- added Rob Herring's ACK to patch #1 (the dt-binding documentation)
[0] https://www.spinics.net/lists/linux-usb/msg151837.html
[1] http://www.mail-archive.com/linux-usb at vger.kernel.org/msg87077.html
[2] https://github.com/xdarklight/linux/commit/e2b83785687fe859ae4bba8da8bb2fb2d7e32bfb
[3] https://github.com/xdarklight/linux/commit/203ab9ea5d1bea0bf066b6738010c8072b821d87
[4] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001721.html
[5] https://github.com/khadas/linux/blob/76fd19ac41bb774e396ce8009ff665f29c26c535/include/linux/amlogic/usb-gxl.h
[6] http://lists.infradead.org/pipermail/linux-amlogic/2017-March/002777.html
Martin Blumenstingl (2):
Documentation: dt-bindings: Add documentation for the Meson GXL USB2
PHY
phy: meson: add USB2 PHY support for Meson GXL and GXM
.../devicetree/bindings/phy/meson-gxl-usb2-phy.txt | 17 ++
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-meson-gxl-usb2.c | 261 +++++++++++++++++++++
4 files changed, 291 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
--
2.12.2
^ permalink raw reply
* [GIT PULL] Allwinner clock fixes for 4.11, again
From: Stephen Boyd @ 2017-04-17 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413095938.ac4zjp7ql6y76sst@lukather>
On 04/13, Maxime Ripard wrote:
> Hi Mike, Stephen,
>
> Here is another PR, without the patches that you didn't want as fixes.
>
> A few more fixes showed up in between, one of them being another build
> fix, the other one fixing random CPU crashes happening with CPUfreq
> since 4.11
>
> Please merge it for one of 4.11-rc's, thanks!
> Maxime
Thanks. Pulled into clk-fixes. I'll probably send it off in a
day or so.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] iio: adc: meson-saradc: mark all meson_sar_adc_data static and const
From: Martin Blumenstingl @ 2017-04-17 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417182820.26670-1-martin.blumenstingl@googlemail.com>
These are only passed as of_device_id.data and never modified. Thus we
can mark them as static const, just like the of_device_id instances
where they are used.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/iio/adc/meson_saradc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index cf13691009ee..8f742b71b165 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -843,31 +843,31 @@ static const struct iio_info meson_sar_adc_iio_info = {
.driver_module = THIS_MODULE,
};
-struct meson_sar_adc_data meson_sar_adc_meson8_data = {
+static const struct meson_sar_adc_data meson_sar_adc_meson8_data = {
.has_bl30_integration = false,
.resolution = 10,
.name = "meson-meson8b-saradc",
};
-struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
+static const struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
.has_bl30_integration = false,
.resolution = 10,
.name = "meson-meson8b-saradc",
};
-struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
+static const struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
.has_bl30_integration = true,
.resolution = 10,
.name = "meson-gxbb-saradc",
};
-struct meson_sar_adc_data meson_sar_adc_gxl_data = {
+static const struct meson_sar_adc_data meson_sar_adc_gxl_data = {
.has_bl30_integration = true,
.resolution = 12,
.name = "meson-gxl-saradc",
};
-struct meson_sar_adc_data meson_sar_adc_gxm_data = {
+static const struct meson_sar_adc_data meson_sar_adc_gxm_data = {
.has_bl30_integration = true,
.resolution = 12,
.name = "meson-gxm-saradc",
--
2.12.2
^ permalink raw reply related
* [PATCH 2/3] iio: adc: meson-saradc: add Meson8b SoC compatibility
From: Martin Blumenstingl @ 2017-04-17 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417182820.26670-1-martin.blumenstingl@googlemail.com>
Meson GX SoCs however use some magic bits to prevent simultaneous (=
conflicting, because only consumer should use the FIFO buffer with the
ADC results) usage by the Linux kernel and the bootloader (the BL30
bootloader uses the SAR ADC to read the CPU temperature).
This patch changes guards all BL30 functionality so it is skipped on
SoCs which don't have it. Since the hardware itself doesn't know whether
BL30 is available the internal meson_sar_adc_data is extended so this
information can be provided per of_device_id.data inside the driver.
Additionally the clocks "adc_clk" and "adc_sel" are not provided by the
clock-controller itself. "adc_sel" is not available at all. "adc_clk"
is provided by the SAR ADC IP block itself on Meson8b (and earlier).
This is already supported by the meson_saradc driver.
Finally a new of_device_id for the Meson8b SoC is added so it can be
wired up in the corresponding DT.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/iio/adc/meson_saradc.c | 80 +++++++++++++++++++++++++++++-------------
1 file changed, 56 insertions(+), 24 deletions(-)
diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index dd4190b50df6..cf13691009ee 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -220,6 +220,7 @@ enum meson_sar_adc_chan7_mux_sel {
};
struct meson_sar_adc_data {
+ bool has_bl30_integration;
unsigned int resolution;
const char *name;
};
@@ -437,19 +438,24 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
mutex_lock(&indio_dev->mlock);
- /* prevent BL30 from using the SAR ADC while we are using it */
- regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
- MESON_SAR_ADC_DELAY_KERNEL_BUSY,
- MESON_SAR_ADC_DELAY_KERNEL_BUSY);
-
- /* wait until BL30 releases it's lock (so we can use the SAR ADC) */
- do {
- udelay(1);
- regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
- } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
-
- if (timeout < 0)
- return -ETIMEDOUT;
+ if (priv->data->has_bl30_integration) {
+ /* prevent BL30 from using the SAR ADC while we are using it */
+ regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+ MESON_SAR_ADC_DELAY_KERNEL_BUSY,
+ MESON_SAR_ADC_DELAY_KERNEL_BUSY);
+
+ /*
+ * wait until BL30 releases it's lock (so we can use the SAR
+ * ADC)
+ */
+ do {
+ udelay(1);
+ regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
+ } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
+
+ if (timeout < 0)
+ return -ETIMEDOUT;
+ }
return 0;
}
@@ -458,9 +464,10 @@ static void meson_sar_adc_unlock(struct iio_dev *indio_dev)
{
struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
- /* allow BL30 to use the SAR ADC again */
- regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
- MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
+ if (priv->data->has_bl30_integration)
+ /* allow BL30 to use the SAR ADC again */
+ regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
+ MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
mutex_unlock(&indio_dev->mlock);
}
@@ -614,14 +621,16 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
*/
meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
- /*
- * leave sampling delay and the input clocks as configured by BL30 to
- * make sure BL30 gets the values it expects when reading the
- * temperature sensor.
- */
- regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
- if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
- return 0;
+ if (priv->data->has_bl30_integration) {
+ /*
+ * leave sampling delay and the input clocks as configured by
+ * BL30 to make sure BL30 gets the values it expects when
+ * reading the temperature sensor.
+ */
+ regmap_read(priv->regmap, MESON_SAR_ADC_REG3, ®val);
+ if (regval & MESON_SAR_ADC_REG3_BL30_INITIALIZED)
+ return 0;
+ }
meson_sar_adc_stop_sample_engine(indio_dev);
@@ -834,23 +843,46 @@ static const struct iio_info meson_sar_adc_iio_info = {
.driver_module = THIS_MODULE,
};
+struct meson_sar_adc_data meson_sar_adc_meson8_data = {
+ .has_bl30_integration = false,
+ .resolution = 10,
+ .name = "meson-meson8b-saradc",
+};
+
+struct meson_sar_adc_data meson_sar_adc_meson8b_data = {
+ .has_bl30_integration = false,
+ .resolution = 10,
+ .name = "meson-meson8b-saradc",
+};
+
struct meson_sar_adc_data meson_sar_adc_gxbb_data = {
+ .has_bl30_integration = true,
.resolution = 10,
.name = "meson-gxbb-saradc",
};
struct meson_sar_adc_data meson_sar_adc_gxl_data = {
+ .has_bl30_integration = true,
.resolution = 12,
.name = "meson-gxl-saradc",
};
struct meson_sar_adc_data meson_sar_adc_gxm_data = {
+ .has_bl30_integration = true,
.resolution = 12,
.name = "meson-gxm-saradc",
};
static const struct of_device_id meson_sar_adc_of_match[] = {
{
+ .compatible = "amlogic,meson8-saradc",
+ .data = &meson_sar_adc_meson8_data,
+ },
+ {
+ .compatible = "amlogic,meson8b-saradc",
+ .data = &meson_sar_adc_meson8b_data,
+ },
+ {
.compatible = "amlogic,meson-gxbb-saradc",
.data = &meson_sar_adc_gxbb_data,
}, {
--
2.12.2
^ permalink raw reply related
* [PATCH 1/3] Documentation: dt-bindings: iio: adc: add Meson8 and Meson8b support
From: Martin Blumenstingl @ 2017-04-17 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417182820.26670-1-martin.blumenstingl@googlemail.com>
The Amlogic Meson SAR ADC driver can be used on Meson8 and Meson8b
(probably on earlier SoC generations as well, but I don't have any
hardware available for testing that).
Add a separate compatible for Meson8 and Meson8b because it does not
need any of the BL30 magic (unlike the GX SoCs).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
index f9e3ff2c656e..08cee82e54c3 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -2,6 +2,8 @@
Required properties:
- compatible: depending on the SoC this should be one of:
+ - "amlogic,meson8-saradc" for Meson8
+ - "amlogic,meson8b-saradc" for Meson8b
- "amlogic,meson-gxbb-saradc" for GXBB
- "amlogic,meson-gxl-saradc" for GXL
- "amlogic,meson-gxm-saradc" for GXM
--
2.12.2
^ permalink raw reply related
* [PATCH 0/3] Meson8 / Meson8b support for the meson_saradc driver
From: Martin Blumenstingl @ 2017-04-17 18:28 UTC (permalink / raw)
To: linux-arm-kernel
The SAR ADC register layout seems to be mostly the same on older SoCs.
Thus basically all functionality is already supported by the existing
driver.
There are two small differences though:
- the adc_clk and adc_div clock are not provided by the clock-controller
on Meson8b. instead the SAR ADC provides an internal "adc_clk" (this
behavior is already supported by the driver and requires no changes)
- the newer SoCs are using some register bits only the kernel or the
BL30 (bootloader) are using the SAR ADC. This is the main change of
this series: guarding all BL30 specific code with a corresponding
"if"-block.
This also adds a new DT binding for the SAR ADC in Meson8 and Meson8b
because the driver has to specify (for this older version) that there's
no BL30 integration available (and these register bits should not be
touched).
Changes since v1 at [0]:
- switched to bool data-type for has_bl30_integration
- also added a "compatible" for Meson8 SoCs (the ADC driver from
Amlogic's GPL kernel sources handles Meson8 and Meson8b identical)
- added patch #3 to constify some structs (there were supposed to be
const from the very beginning)
[0] http://lists.infradead.org/pipermail/linux-amlogic/2017-March/003081.html
Martin Blumenstingl (3):
Documentation: dt-bindings: iio: adc: add Meson8 and Meson8b support
iio: adc: meson-saradc: add Meson8b SoC compatibility
iio: adc: meson-saradc: mark all meson_sar_adc_data static and const
.../bindings/iio/adc/amlogic,meson-saradc.txt | 2 +
drivers/iio/adc/meson_saradc.c | 86 +++++++++++++++-------
2 files changed, 61 insertions(+), 27 deletions(-)
--
2.12.2
^ permalink raw reply
* [PATCH v2] efi: Config options to assign versions in the PE-COFF header
From: Roy Franz (HPE) @ 2017-04-17 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413074728.5zglfjw2rxgc6lpj@GaryWorkstation>
On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin <glin@suse.com> wrote:
> On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote:
>> On 13 April 2017 at 04:58, Gary Lin <glin@suse.com> wrote:
>> > This commit adds the new config options to allow the user to modify the
>> > following fields in the PE-COFF header.
>> >
>> > UINT16 MajorOperatingSystemVersion
>> > UINT16 MinorOperatingSystemVersion
>> > UINT16 MajorImageVersion
>> > UINT16 MinorImageVersion
>> >
>> > Those fields are mainly for the executables or libraries in Windows NT
>> > or higher to specify the minimum supported Windows version and the
>> > version of the image itself.
>> >
>> > Given the fact that those fields are ignored in UEFI, we can safely reuse
>> > those fields for other purposes, e.g. Security Version(*).
>> >
>> > (*) https://github.com/lcp/shim/wiki/Security-Version
>> >
>> > v2 changes:
>> > - Modify the header direct instead of using an external script as
>> > suggested by Ard Biesheuvel
>> > - Include arm and arm64
>> >
>>
>> Thanks for the update. Could we put the Kconfig changes in
>> drivers/firmware/efi/Kconfig, rather than duplicating them 3 times?
>
> Sure. Will send a v3 to update Kconfig.
>
> Thanks,
>
> Gary Lin
I think it would be nice to have a comment in the code (or maybe help
in the kconfig, or Documentation/efi-stub.txt) that indicates the
expected use of these variables, as the field names and PE/COFF spec
won't help here.
Thanks,
Roy
>
>>
>> > Cc: Russell King <linux@armlinux.org.uk>
>> > Cc: Matt Fleming <matt@codeblueprint.co.uk>
>> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> > Cc: Catalin Marinas <catalin.marinas@arm.com>
>> > Cc: Will Deacon <will.deacon@arm.com>
>> > Cc: Thomas Gleixner <tglx@linutronix.de>
>> > Cc: Ingo Molnar <mingo@redhat.com>
>> > Cc: "H. Peter Anvin" <hpa@zytor.com>
>> > Cc: Joey Lee <jlee@suse.com>
>> > Cc: Vojtech Pavlik <vojtech@suse.cz>
>> > Signed-off-by: Gary Lin <glin@suse.com>
>> > ---
>> > arch/arm/Kconfig | 24 ++++++++++++++++++++++++
>> > arch/arm/boot/compressed/efi-header.S | 8 ++++----
>> > arch/arm64/Kconfig | 24 ++++++++++++++++++++++++
>> > arch/arm64/kernel/head.S | 8 ++++----
>> > arch/x86/Kconfig | 24 ++++++++++++++++++++++++
>> > arch/x86/boot/header.S | 8 ++++----
>> > 6 files changed, 84 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> > index 0d4e71b42c77..4965ad2ccc23 100644
>> > --- a/arch/arm/Kconfig
>> > +++ b/arch/arm/Kconfig
>> > @@ -2090,6 +2090,30 @@ config EFI
>> > is only useful for kernels that may run on systems that have
>> > UEFI firmware.
>> >
>> > +config EFI_MAJOR_OS
>> > + hex "EFI Major OS Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_OS
>> > + hex "EFI Minor OS Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MAJOR_IMAGE
>> > + hex "EFI Major Image Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_IMAGE
>> > + hex "EFI Minor Image Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > endmenu
>> >
>> > menu "CPU Power Management"
>> > diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
>> > index 9d5dc4fda3c1..67715472a76f 100644
>> > --- a/arch/arm/boot/compressed/efi-header.S
>> > +++ b/arch/arm/boot/compressed/efi-header.S
>> > @@ -69,10 +69,10 @@ extra_header_fields:
>> > .long 0 @ ImageBase
>> > .long 0x200 @ SectionAlignment
>> > .long 0x200 @ FileAlignment
>> > - .short 0 @ MajorOperatingSystemVersion
>> > - .short 0 @ MinorOperatingSystemVersion
>> > - .short 0 @ MajorImageVersion
>> > - .short 0 @ MinorImageVersion
>> > + .short CONFIG_EFI_MAJOR_OS @ MajorOperatingSystemVersion
>> > + .short CONFIG_EFI_MINOR_OS @ MinorOperatingSystemVersion
>> > + .short CONFIG_EFI_MAJOR_IMAGE @ MajorImageVersion
>> > + .short CONFIG_EFI_MINOR_IMAGE @ MinorImageVersion
>> > .short 0 @ MajorSubsystemVersion
>> > .short 0 @ MinorSubsystemVersion
>> > .long 0 @ Win32VersionValue
>> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> > index 3741859765cf..c782c422e58c 100644
>> > --- a/arch/arm64/Kconfig
>> > +++ b/arch/arm64/Kconfig
>> > @@ -1033,6 +1033,30 @@ config EFI
>> > allow the kernel to be booted as an EFI application. This
>> > is only useful on systems that have UEFI firmware.
>> >
>> > +config EFI_MAJOR_OS
>> > + hex "EFI Major OS Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_OS
>> > + hex "EFI Minor OS Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MAJOR_IMAGE
>> > + hex "EFI Major Image Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_IMAGE
>> > + hex "EFI Minor Image Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > config DMI
>> > bool "Enable support for SMBIOS (DMI) tables"
>> > depends on EFI
>> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>> > index 4fb6ccd886d1..9faa4b04d0ef 100644
>> > --- a/arch/arm64/kernel/head.S
>> > +++ b/arch/arm64/kernel/head.S
>> > @@ -129,10 +129,10 @@ extra_header_fields:
>> > .quad 0 // ImageBase
>> > .long 0x1000 // SectionAlignment
>> > .long PECOFF_FILE_ALIGNMENT // FileAlignment
>> > - .short 0 // MajorOperatingSystemVersion
>> > - .short 0 // MinorOperatingSystemVersion
>> > - .short 0 // MajorImageVersion
>> > - .short 0 // MinorImageVersion
>> > + .short CONFIG_EFI_MAJOR_OS // MajorOperatingSystemVersion
>> > + .short CONFIG_EFI_MINOR_OS // MinorOperatingSystemVersion
>> > + .short CONFIG_EFI_MAJOR_IMAGE // MajorImageVersion
>> > + .short CONFIG_EFI_MINOR_IMAGE // MinorImageVersion
>> > .short 0 // MajorSubsystemVersion
>> > .short 0 // MinorSubsystemVersion
>> > .long 0 // Win32VersionValue
>> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > index 5bbdef151805..233933fde7dd 100644
>> > --- a/arch/x86/Kconfig
>> > +++ b/arch/x86/Kconfig
>> > @@ -1803,6 +1803,30 @@ config EFI_STUB
>> >
>> > See Documentation/efi-stub.txt for more information.
>> >
>> > +config EFI_MAJOR_OS
>> > + hex "EFI Major OS Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_OS
>> > + hex "EFI Minor OS Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MAJOR_IMAGE
>> > + hex "EFI Major Image Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > +config EFI_MINOR_IMAGE
>> > + hex "EFI Minor Image Version"
>> > + range 0x0 0xFFFF
>> > + default "0x0"
>> > + depends on EFI_STUB
>> > +
>> > config EFI_MIXED
>> > bool "EFI mixed-mode support"
>> > depends on EFI_STUB && X86_64
>> > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
>> > index 3dd5be33aaa7..863813007207 100644
>> > --- a/arch/x86/boot/header.S
>> > +++ b/arch/x86/boot/header.S
>> > @@ -156,10 +156,10 @@ extra_header_fields:
>> > #endif
>> > .long 0x20 # SectionAlignment
>> > .long 0x20 # FileAlignment
>> > - .word 0 # MajorOperatingSystemVersion
>> > - .word 0 # MinorOperatingSystemVersion
>> > - .word 0 # MajorImageVersion
>> > - .word 0 # MinorImageVersion
>> > + .word CONFIG_EFI_MAJOR_OS # MajorOperatingSystemVersion
>> > + .word CONFIG_EFI_MINOR_OS # MinorOperatingSystemVersion
>> > + .word CONFIG_EFI_MAJOR_IMAGE # MajorImageVersion
>> > + .word CONFIG_EFI_MINOR_IMAGE # MinorImageVersion
>> > .word 0 # MajorSubsystemVersion
>> > .word 0 # MinorSubsystemVersion
>> > .long 0 # Win32VersionValue
>> > --
>> > 2.12.0
>> >
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" 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 V8 4/5] PCI/ASPM: save power on values during bridge init
From: Sinan Kaya @ 2017-04-17 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo7p_2dTDTC7J4HdQUw_5GH8081dUZ=XVqd=sRLrA_FJnA@mail.gmail.com>
On 4/17/2017 12:38 PM, Bjorn Helgaas wrote:
>> Like you said, what do we do by default is the question. Should we opt
>> for safe like we are doing, or try to save some power.
> I think safety is paramount. Every user should be able to boot safely
> without any kernel parameters. We don't want users to have a problem
> booting and then have to search for a workaround like booting with
> "pcie_aspm=off". Most users will never do that.
>
OK, no problem with leaving the behavior as it is.
My initial approach was #2. We knew this way that user had full control
over the ASPM policy by changing the BIOS option. Then, Mayurkumar
complained that ASPM is not enabled following a hotplug insertion to an
empty slot. That's when I switched to #3 as it sounded like a good thing
to have for us.
> Here's a long-term strawman proposal, see what you think:
>
> - Deprecate CONFIG_PCIEASPM_DEFAULT, CONFIG_PCIEASPM_POWERSAVE, etc.
> - Default aspm_policy is POLICY_DEFAULT always.
> - POLICY_DEFAULT means Linux doesn't touch anything: if BIOS enabled
> ASPM, we leave it that way; we leave ASPM disabled on hot-added
> devices.
I can easily see people complaining the other way around. There
could be some boot FW that doesn't know what ASPM is and this particular
system could rely on the compile time option for enabling power options.
Maybe, a command line option will be required for them to keep the existing
behavior.
> - Deprecate kernel boot parameters (possibly keep pcie_aspm=off for
> debugging use).
> - Use /sys/module/pcie_aspm/parameters/policy for run-time
> system-wide control, including for future hot-added devices.
> - Remove CONFIG_PCIEASPM_DEBUG and enable that code always, so we
> have fine-grained run-time control.
>
Runtime control sounds like a better plan. We need hooks into the system
power management policy.
>> Maybe, we are missing a HPP option from the PCI spec.
> That's an interesting idea. _HPX does have provision for manipulating
> Link Control bits (see ACPI r5.0, sec 6.2.8.3), but I don't think very
> many systems implement it. And there's currently no connection
> between program_hpp_type2() and aspm.c, so I'm a little worried that
> we might have issues if a system did implement an _HPX that sets any
> of the ASPM bits.
I looked at the spec some more. These are there to restore the register
settings following hotplug insertion. I agree it won't play nice with ASPM
as the control bits need to be enabled in coordination with the upstream
device.
I think the right approach is to let the userspace feed the required
policy to the kernel like you suggested. Then, it needs to be per port
via link_state to have the most flexibility.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH net-next] net: mvneta: fix failed to suspend if WOL is enabled
From: David Miller @ 2017-04-17 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414110732.3100-1-jszhang@marvell.com>
From: Jisheng Zhang <jszhang@marvell.com>
Date: Fri, 14 Apr 2017 19:07:32 +0800
> Recently, suspend/resume and WOL support are added into mvneta driver.
> If we enable WOL, then we get some error as below on Marvell BG4CT
> platforms during suspend:
>
> [ 184.149723] dpm_run_callback(): mdio_bus_suspend+0x0/0x50 returns -16
> [ 184.149727] PM: Device f7b62004.mdio-mi:00 failed to suspend: error -16
>
> -16 means -EBUSY, phy_suspend() will return -EBUSY if it finds the
> device has WOL enabled.
>
> We fix this issue by properly setting the netdev's power.can_wakeup
> and power.wakeup, i.e
>
> 1. in mvneta_mdio_probe(), call device_set_wakeup_capable() to set
> power.can_wakeup if the phy support WOL.
>
> 2. in mvneta_ethtool_set_wol(), call device_set_wakeup_enable() to
> set power.wakeup if WOL has been successfully enabled in phy.
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Applied.
^ permalink raw reply
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Jayachandran C @ 2017-04-17 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo731xSzrnKF+G+8SA_UUHy7ROA1V9oFkpwKi85GQf9VAg@mail.gmail.com>
On Fri, Apr 14, 2017 at 09:00:06PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 14, 2017 at 4:06 PM, Jayachandran C
> <jnair@caviumnetworks.com> wrote:
> > On Thu, Apr 13, 2017 at 07:19:11PM -0500, Bjorn Helgaas wrote:
> >> I tentatively applied both patches to pci/host-thunder for v4.12.
> >>
> >> However, I am concerned about the topology here:
> >>
> >> On Thu, Apr 13, 2017 at 08:30:45PM +0000, Jayachandran C wrote:
> >> > On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the
> >> > PCI topology is slightly unusual. For a multi-node system, it looks
> >> > like:
> >> >
> >> > 00:00.0 [PCI] bridge to [bus 01-1e]
> >> > 01:0a.0 [PCI-PCIe bridge, type 8] bridge to [bus 02-04]
> >> > 02:00.0 [PCIe root port, type 4] bridge to [bus 03-04] (XLATE_ROOT)
> >> > 03:00.0 PCIe Endpoint
> >>
> >> A root port normally has a single PCIe link leading downstream.
> >> According to this, 02:00.0 is a root port that has the usual
> >> downstream link leading to 03:00.0, but it also has an upstream link
> >> to 01:0a.0.
> >
> > The PCI topology is a bit broken due to the way that the PCIe IP block
> > was integrated into SoC PCI bridges and devices. The current mechanism
> > of adding a PCI-PCIe bridge to glue these together is not ideal.
>
> Yeah, that's definitely broken.
>
> >> Maybe this example is omitting details that are not relevant to DMA
> >> aliases? The PCIe capability only contains one set of link-related
> >> registers, so I don't know how we could manage a single device that
> >> has two links.
> >
> > The root port is standard and has just one link to the EP (or whatever
> > is on the external PCIe slot). The fallout of the current hw design is
> > that the PCI-PCIe bridge has a link that does not follow standard and
> > does not have a counterpart (as you noted).
> >
> >> A device with two links would break things like ASPM. In
> >> set_pcie_port_type(), for example, we have this comment:
> >>
> >> * A Root Port or a PCI-to-PCIe bridge is always the upstream end
> >> * of a Link. No PCIe component has two Links. Two Links are
> >> * connected by a Switch that has a Port on each Link and internal
> >> * logic to connect the two Ports.
> >>
> >> The topology above breaks these assumptions, which will make
> >> pdev->has_secondary_link incorrect, which means ASPM won't work
> >> correctly.
> >
> > Given the current hardware, the pcieport driver seems to work reasonably
> > for the root port at 02:00.0, with AER support. I will take a look at the
> > ASPM part.
>
> I don't think pcieport itself cares much about links. ASPM does, but
> it looks like set_pcie_port_type() actually is smart enough to know
> that PCI-to-PCIe bridges and Root Ports always have links on their
> secondary sides. So has_secondary_link probably does get set
> correctly.
>
> But I think you'll hit the VIA "strange chipset" thing in
> pcie_aspm_init_link_state(), which will probably prevent us from doing
> ASPM on the link from 02:00.0 to 03:00.0.
>
> Could you collect "lspci -vv" output from this system? I'd like to
> archive that as background for this IOMMU issue and the ASPM tweaks I
> suspect we'll have to do. I *wish* we had more information about that
> VIA thing, because I suspect we could get rid of it if we had more
> details.
The full logs are slightly large, so I have kept them at:
https://github.com/jchandra-cavm/thunderx2/blob/master/logs/
The lspci -vv output is lspci-vv.txt and lspci -tvn output is lspci-tvn.txt
The output is from 2 socket system, the cards are not on the first slot
like the example above, so the bus and device numbers are different.
Looks like I have to spend some time on ASPM next.
Thanks,
JC.
^ 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