* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Uwe Kleine-König @ 2017-01-11 19:49 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
is enabled:
# dmesg | grep ath
[ 7.207770] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
[ 7.237955] ath10k_pci 0000:02:00.0: failed to wake up device : -110
[ 7.238146] ath10k_pci: probe of 0000:02:00.0 failed with error -110
if however PCIEASPM is off, the driver probes correctly and the ath10k
adapter works fine.
I wonder if someone has an idea what needs to be done to fix this
problem. (OK, I could disable PCIEASPM, but I'd like to have a solution
for a distribution kernel where I think PCIEASPM=y is sensible in
general.)
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170111/91e57d62/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Icenowy Zheng @ 2017-01-11 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110202443.GC2479@uda0271908>
11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
>> ?Lichee Pi Zero features a USB OTG port.
>>
>> ?Add support for it.
>>
>> ?Note: in order to use the Host mode, the board must be powered via the
>> ?+5V and GND pins.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?---
>> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
>> ??1 file changed, 10 insertions(+)
>>
>> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?index 0099affc6ce3..3d9168cbaeca 100644
>> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?@@ -71,3 +71,13 @@
>> ??????????pinctrl-names = "default";
>> ??????????status = "okay";
>> ??};
>> ?+
>> ?+&usb_otg {
>> ?+ dr_mode = "otg";
>
> Why not set this default mode in dtsi instead?
>
> Regards,
> -Bin.
There's possibly boards which do not have OTG functions.
Even the official CDR design of V3s uses the USB controller to
connect a UVC webcam to make the design a dual-cam design
(V3s itself has a CSI).
>
>> ?+ status = "okay";
>> ?+};
>> ?+
>> ?+&usbphy {
>> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> ?+ status = "okay";
>> ?+};
>> ?--
>> ?2.11.0
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA defconfig updates for v4.11
From: Dinh Nguyen @ 2017-01-11 20:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof:
Please pull in this defconfig update for v4.11.
Thanks,
Dinh
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_defconfig_updates_for_v4.11
for you to fetch changes up to 4fdf18242408cc0b32b3a1a06510376bf609fa60:
ARM: socfpga_defconfig: update defconfig for SoCFPGA (2017-01-03 20:29:08 -0600)
----------------------------------------------------------------
SoCFPGA defconfig updates for v4.11
- enables Marvell PHY support
- enable MTD(I2C EEPROM), and NAND support
- enable SPI, RTC and LED support
- enables OF CONFIGFS to support DTS overlays
- enables more FS options
- enables A10 hwmon support
----------------------------------------------------------------
Dinh Nguyen (1):
ARM: socfpga_defconfig: update defconfig for SoCFPGA
arch/arm/configs/socfpga_defconfig | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA DTS updates for v4.11, part 1
From: Dinh Nguyen @ 2017-01-11 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484165237-26640-1-git-send-email-dinguyen@kernel.org>
Hi Arnd, Kevin, and Olof:
Please pull in these DTS updates for v4.11.
Thanks,
Dinh
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_for_v4.11_part_1
for you to fetch changes up to 7f0f5460d46867a8f980683136a054cff1357780:
ARM: dts: socfpga: add missing compatible string for SDRAM controller (2017-01-06 01:42:06 -0600)
----------------------------------------------------------------
SoCFPGA DTS updates for v4.11, part 1
- Adds FPGA manager bits
- Enable I2C on Cyclone5 and Arria5 devkits
- Adds LED support on C5/A5 devkits
- Enables CAN on C5 devkit
- Enables watchdog
- Add NAND on Arria10
- Add the LTC2977 Power Monitor on Arria10 devkit
----------------------------------------------------------------
Alan Tull (1):
ARM: dts: socfpga: add base fpga region and fpga bridges
Dinh Nguyen (10):
ARM: dts: socfpga: enable GPIO and LEDs for Cyclone5 and Arria5 devkits
ARM: dts: socfpga: set desired i2c clock on Cyclone5 and Arria5 devkits
ARM: dts: socfpga: Add Rohm DH2228FV DAC
ARM: dts: socfpga: enable CAN on Cyclone5 devkit
ARM: dts: socfpga: enable watchdog timer on Arria5 and Arria10
ARM: dts: socfpga: add the LTC2977 power monitor on Arria10 devkit
ARM: dts: socfpga: add fpga-manager node for Arria10
ARM: dts: socfpga: fpga manager data is 32 bits
ARM: dts: socfpga: add fpga region support on Arria10
ARM: dts: socfpga: add missing compatible string for SDRAM controller
Graham Moore (1):
ARM: dts: socfpga: Add NAND device tree for Arria10
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++-
arch/arm/boot/dts/socfpga_arria10.dtsi | 32 +++++++++++++-
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 9 ++++
arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts | 31 ++++++++++++++
arch/arm/boot/dts/socfpga_arria5.dtsi | 4 ++
arch/arm/boot/dts/socfpga_arria5_socdk.dts | 43 +++++++++++++++++++
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 53 ++++++++++++++++++++++++
8 files changed, 201 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-11 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2733831484164533@web1g.yandex.ru>
On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
>
>
> 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> ?Lichee Pi Zero features a USB OTG port.
> >>
> >> ?Add support for it.
> >>
> >> ?Note: in order to use the Host mode, the board must be powered via the
> >> ?+5V and GND pins.
> >>
> >> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ?---
> >> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> >> ??1 file changed, 10 insertions(+)
> >>
> >> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?index 0099affc6ce3..3d9168cbaeca 100644
> >> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?@@ -71,3 +71,13 @@
> >> ??????????pinctrl-names = "default";
> >> ??????????status = "okay";
> >> ??};
> >> ?+
> >> ?+&usb_otg {
> >> ?+ dr_mode = "otg";
> >
> > Why not set this default mode in dtsi instead?
> >
> > Regards,
> > -Bin.
>
> There's possibly boards which do not have OTG functions.
That is board specific.
You'd better to define the default dr_mode which the musb _controller_
supports in the dtsi, and then override it in a specific board dts if
necessary.
Regards,
-Bin.
>
> Even the official CDR design of V3s uses the USB controller to
> connect a UVC webcam to make the design a dual-cam design
> (V3s itself has a CSI).
>
> >
> >> ?+ status = "okay";
> >> ?+};
> >> ?+
> >> ?+&usbphy {
> >> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> ?+ status = "okay";
> >> ?+};
> >> ?--
> >> ?2.11.0
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Icenowy Zheng @ 2017-01-11 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111200811.GA16865@uda0271908>
12.01.2017, 04:08, "Bin Liu" <b-liu@ti.com>:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
>> ?11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
>> ?> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
>> ?>> ?Lichee Pi Zero features a USB OTG port.
>> ?>>
>> ?>> ?Add support for it.
>> ?>>
>> ?>> ?Note: in order to use the Host mode, the board must be powered via the
>> ?>> ?+5V and GND pins.
>> ?>>
>> ?>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?>> ?---
>> ?>> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
>> ?>> ??1 file changed, 10 insertions(+)
>> ?>>
>> ?>> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?>> ?index 0099affc6ce3..3d9168cbaeca 100644
>> ?>> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?>> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> ?>> ?@@ -71,3 +71,13 @@
>> ?>> ??????????pinctrl-names = "default";
>> ?>> ??????????status = "okay";
>> ?>> ??};
>> ?>> ?+
>> ?>> ?+&usb_otg {
>> ?>> ?+ dr_mode = "otg";
>> ?>
>> ?> Why not set this default mode in dtsi instead?
>> ?>
>> ?> Regards,
>> ?> -Bin.
>>
>> ?There's possibly boards which do not have OTG functions.
>
> That is board specific.
>
> You'd better to define the default dr_mode which the musb _controller_
> supports in the dtsi, and then override it in a specific board dts if
> necessary.
Is there MUSB controllers which do not support a certain mode?
(I remembered my omap3-n900 which do not work under OTG mode...)
>
> Regards,
> -Bin.
>
>> ?Even the official CDR design of V3s uses the USB controller to
>> ?connect a UVC webcam to make the design a dual-cam design
>> ?(V3s itself has a CSI).
>>
>> ?>
>> ?>> ?+ status = "okay";
>> ?>> ?+};
>> ?>> ?+
>> ?>> ?+&usbphy {
>> ?>> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> ?>> ?+ status = "okay";
>> ?>> ?+};
>> ?>> ?--
>> ?>> ?2.11.0
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-11 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <418251484165614@web21h.yandex.ru>
On Thu, Jan 12, 2017 at 04:13:34AM +0800, Icenowy Zheng wrote:
>
>
> 12.01.2017, 04:08, "Bin Liu" <b-liu@ti.com>:
> > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >> ?11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> >> ?> On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> ?>> ?Lichee Pi Zero features a USB OTG port.
> >> ?>>
> >> ?>> ?Add support for it.
> >> ?>>
> >> ?>> ?Note: in order to use the Host mode, the board must be powered via the
> >> ?>> ?+5V and GND pins.
> >> ?>>
> >> ?>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ?>> ?---
> >> ?>> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> >> ?>> ??1 file changed, 10 insertions(+)
> >> ?>>
> >> ?>> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?index 0099affc6ce3..3d9168cbaeca 100644
> >> ?>> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> ?>> ?@@ -71,3 +71,13 @@
> >> ?>> ??????????pinctrl-names = "default";
> >> ?>> ??????????status = "okay";
> >> ?>> ??};
> >> ?>> ?+
> >> ?>> ?+&usb_otg {
> >> ?>> ?+ dr_mode = "otg";
> >> ?>
> >> ?> Why not set this default mode in dtsi instead?
> >> ?>
> >> ?> Regards,
> >> ?> -Bin.
> >>
> >> ?There's possibly boards which do not have OTG functions.
> >
> > That is board specific.
> >
> > You'd better to define the default dr_mode which the musb _controller_
> > supports in the dtsi, and then override it in a specific board dts if
> > necessary.
>
> Is there MUSB controllers which do not support a certain mode?
I am not aware of any. That is why I recommended to set "otg" in dtsi,
then override it in board dts if a port is specically designed to
host-only or device-only mode.
>
> (I remembered my omap3-n900 which do not work under OTG mode...)
I belive it is n900 board specific. omap3 itself doesn't have such
limitation, AFAIK.
Regards,
-Bin.
>
> >
> > Regards,
> > -Bin.
> >
> >> ?Even the official CDR design of V3s uses the USB controller to
> >> ?connect a UVC webcam to make the design a dual-cam design
> >> ?(V3s itself has a CSI).
> >>
> >> ?>
> >> ?>> ?+ status = "okay";
> >> ?>> ?+};
> >> ?>> ?+
> >> ?>> ?+&usbphy {
> >> ?>> ?+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> ?>> ?+ status = "okay";
> >> ?>> ?+};
> >> ?>> ?--
> >> ?>> ?2.11.0
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: juno: Updates for juno r1/r2 boards
From: Mike Leach @ 2017-01-11 20:44 UTC (permalink / raw)
To: linux-arm-kernel
Juno r1/r2 boards have different CoreSight infrastructure outside the
clusters. This patchset moves the none cluster CoreSight to separate
.dtsi files to allow for these differences.
v2 moves the Addition of the STM component into a separate patch.
Mike Leach (2):
arm64: dts: juno: Fix CoreSight support for Juno r1/r2 variants
arm64: dts: juno: Adds missing CoreSight STM component.
arch/arm64/boot/dts/arm/juno-base.dtsi | 135 ---------------
arch/arm64/boot/dts/arm/juno-cs-r0.dtsi | 166 +++++++++++++++++++
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 266 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 1 +
arch/arm64/boot/dts/arm/juno-r2.dts | 1 +
arch/arm64/boot/dts/arm/juno.dts | 1 +
6 files changed, 435 insertions(+), 135 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: juno: Fix CoreSight support for Juno r1/r2 variants
From: Mike Leach @ 2017-01-11 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484167449-14432-1-git-send-email-mike.leach@linaro.org>
The CoreSight support added for Juno is valid for only Juno r0.
The Juno r1 and r2 variants have additional components and alternative
connection routes between trace source and sinks.
The CoreSight infrastructure external to the Cortex-Axx clusters, has
been split into separate .dtsi include files for r0 and r1/r2 to correctly
represent these variations.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 135 ----------------
arch/arm64/boot/dts/arm/juno-cs-r0.dtsi | 150 ++++++++++++++++++
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 250 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 1 +
arch/arm64/boot/dts/arm/juno-r2.dts | 1 +
arch/arm64/boot/dts/arm/juno.dts | 1 +
6 files changed, 403 insertions(+), 135 deletions(-)
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 7d83224..7c89000 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -83,104 +83,6 @@
* The actual size is just 4K though 64K is reserved. Access to the
* unmapped reserved region results in a DECERR response.
*/
- etf at 20010000 {
- compatible = "arm,coresight-tmc", "arm,primecell";
- reg = <0 0x20010000 0 0x1000>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* input port */
- port at 0 {
- reg = <0>;
- etf_in_port: endpoint {
- slave-mode;
- remote-endpoint = <&main_funnel_out_port>;
- };
- };
-
- /* output port */
- port at 1 {
- reg = <0>;
- etf_out_port: endpoint {
- remote-endpoint = <&replicator_in_port0>;
- };
- };
- };
- };
-
- tpiu at 20030000 {
- compatible = "arm,coresight-tpiu", "arm,primecell";
- reg = <0 0x20030000 0 0x1000>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- port {
- tpiu_in_port: endpoint {
- slave-mode;
- remote-endpoint = <&replicator_out_port0>;
- };
- };
- };
-
- main-funnel at 20040000 {
- compatible = "arm,coresight-funnel", "arm,primecell";
- reg = <0 0x20040000 0 0x1000>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
- main_funnel_out_port: endpoint {
- remote-endpoint = <&etf_in_port>;
- };
- };
-
- port at 1 {
- reg = <0>;
- main_funnel_in_port0: endpoint {
- slave-mode;
- remote-endpoint = <&cluster0_funnel_out_port>;
- };
- };
-
- port at 2 {
- reg = <1>;
- main_funnel_in_port1: endpoint {
- slave-mode;
- remote-endpoint = <&cluster1_funnel_out_port>;
- };
- };
-
- };
- };
-
- etr at 20070000 {
- compatible = "arm,coresight-tmc", "arm,primecell";
- reg = <0 0x20070000 0 0x1000>;
- iommus = <&smmu_etr 0>;
-
- clocks = <&soc_smc50mhz>;
- clock-names = "apb_pclk";
- power-domains = <&scpi_devpd 0>;
- port {
- etr_in_port: endpoint {
- slave-mode;
- remote-endpoint = <&replicator_out_port1>;
- };
- };
- };
-
etm0: etm at 22040000 {
compatible = "arm,coresight-etm4x", "arm,primecell";
reg = <0 0x22040000 0 0x1000>;
@@ -351,43 +253,6 @@
};
};
- coresight-replicator {
- /*
- * Non-configurable replicators don't show up on the
- * AMBA bus. As such no need to add "arm,primecell".
- */
- compatible = "arm,coresight-replicator";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* replicator output ports */
- port at 0 {
- reg = <0>;
- replicator_out_port0: endpoint {
- remote-endpoint = <&tpiu_in_port>;
- };
- };
-
- port at 1 {
- reg = <1>;
- replicator_out_port1: endpoint {
- remote-endpoint = <&etr_in_port>;
- };
- };
-
- /* replicator input port */
- port at 2 {
- reg = <0>;
- replicator_in_port0: endpoint {
- slave-mode;
- remote-endpoint = <&etf_out_port>;
- };
- };
- };
- };
-
sram: sram at 2e000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x2e000000 0x0 0x8000>;
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
new file mode 100644
index 0000000..24419ed
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
@@ -0,0 +1,150 @@
+ /*
+ * Juno trace infrastructure.
+ * Trace links and sinks and interconnections
+ * from clusters.
+ * Connections for Juno r0.
+ */
+ etf at 20010000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20010000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ etf_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&main_funnel_out_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ etf_out_port: endpoint {
+ remote-endpoint = <&replicator_in_port0>;
+ };
+ };
+ };
+ };
+
+ tpiu at 20030000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0 0x20030000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ tpiu_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+
+ main-funnel at 20040000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20040000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port at 0 {
+ reg = <0>;
+ main_funnel_out_port: endpoint {
+ remote-endpoint = <&etf_in_port>;
+ };
+ };
+
+ /* input ports */
+ port at 1 {
+ reg = <0>;
+ main_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster0_funnel_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ main_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster1_funnel_out_port>;
+ };
+ };
+
+ port at 3 {
+ reg = <2>;
+ main_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&stm_out_port>;
+ };
+ };
+
+
+ };
+ };
+
+ etr at 20070000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20070000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ etr_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port1>;
+ };
+ };
+ };
+
+ coresight-replicator {
+ /*
+ * Non-configurable replicators don't show up on the
+ * AMBA bus. As such no need to add "arm,primecell".
+ */
+ compatible = "arm,coresight-replicator";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* replicator output ports */
+ port at 0 {
+ reg = <0>;
+ replicator_out_port0: endpoint {
+ remote-endpoint = <&tpiu_in_port>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ replicator_out_port1: endpoint {
+ remote-endpoint = <&etr_in_port>;
+ };
+ };
+
+ /* replicator input port */
+ port at 2 {
+ reg = <0>;
+ replicator_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf_out_port>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
new file mode 100644
index 0000000..caaf58e
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -0,0 +1,250 @@
+ /*
+ * Juno trace infrastructure.
+ * Trace links and sinks and interconnections
+ * from clusters.
+ * Connections for Juno r1 and r2.
+ */
+ etf0 at 20010000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20010000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ etf0_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&main_funnel_out_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ etf0_out_port: endpoint {
+ remote-endpoint = <&csys2_funnel_in_port0>;
+ };
+ };
+ };
+ };
+
+ etf1 at 20140000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20140000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ etf1_in_port: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&csys1_funnel_out_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ etf1_out_port: endpoint {
+ remote-endpoint =
+ <&csys2_funnel_in_port1>;
+ };
+ };
+ };
+ };
+
+ csys1_funnel at 20130000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20130000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* input port */
+ port at 0 {
+ reg = <0>;
+ csys1_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&etf1_in_port>;
+ };
+ };
+
+ /* output port */
+ port at 1 {
+ reg = <0>;
+ csys1_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&stm_out_port>;
+ };
+ };
+
+ };
+ };
+
+ csys2_funnel at 20150000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20150000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port at 0 {
+ reg = <0>;
+ csys2_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&replicator_in_port0>;
+ };
+ };
+
+ /* input ports */
+ port at 1 {
+ reg = <0>;
+ csys2_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf0_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ csys2_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf1_out_port>;
+ };
+ };
+
+ };
+ };
+
+ tpiu at 20030000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0 0x20030000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ tpiu_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port0>;
+ };
+ };
+ };
+
+ /*
+ * This is labelled cssys0 funnel in the Juno r1/r2 TRM
+ * Retain the name from r0 to maintain compatibility with common
+ * juno-base.dtsi
+ */
+ main-funnel at 20040000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x20040000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* output port */
+ port at 0 {
+ reg = <0>;
+ main_funnel_out_port: endpoint {
+ remote-endpoint = <&etf0_in_port>;
+ };
+ };
+
+ /* input ports */
+ port at 1 {
+ reg = <0>;
+ main_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster0_funnel_out_port>;
+ };
+ };
+
+ port at 2 {
+ reg = <1>;
+ main_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&cluster1_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ etr at 20070000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x20070000 0 0x1000>;
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ etr_in_port: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out_port1>;
+ };
+ };
+ };
+
+ coresight-replicator {
+ /*
+ * Non-configurable replicators don't show up on the
+ * AMBA bus. As such no need to add "arm,primecell".
+ */
+ compatible = "arm,coresight-replicator";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* replicator output ports */
+ port at 0 {
+ reg = <0>;
+ replicator_out_port0: endpoint {
+ remote-endpoint = <&tpiu_in_port>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ replicator_out_port1: endpoint {
+ remote-endpoint = <&etr_in_port>;
+ };
+ };
+
+ /* replicator input port */
+ port at 2 {
+ reg = <0>;
+ replicator_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&csys2_funnel_out_port>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index eec37fe..8813395 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -178,6 +178,7 @@
};
#include "juno-base.dtsi"
+ #include "juno-cs-r1r2.dtsi"
};
&memtimer {
diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
index 28f40ec..fca3a17 100644
--- a/arch/arm64/boot/dts/arm/juno-r2.dts
+++ b/arch/arm64/boot/dts/arm/juno-r2.dts
@@ -178,6 +178,7 @@
};
#include "juno-base.dtsi"
+ #include "juno-cs-r1r2.dtsi"
};
&memtimer {
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index ac5ceb7..c90c37b 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -178,6 +178,7 @@
};
#include "juno-base.dtsi"
+ #include "juno-cs-r0.dtsi"
};
&etm0 {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: juno: Adds missing CoreSight STM component.
From: Mike Leach @ 2017-01-11 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484167449-14432-1-git-send-email-mike.leach@linaro.org>
Add missing CoreSight STM component definition to Juno CoreSight
infrastructure juno-cs-rX.dtsi files.
Component connected to different funnels depending on Juno platform variant.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
arch/arm64/boot/dts/arm/juno-cs-r0.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 16 ++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
index 24419ed..4e01b0e 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r0.dtsi
@@ -148,3 +148,19 @@
};
};
};
+
+ stm at 20100000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x20100000 0 0x1000>,
+ <0 0x28000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint = <&main_funnel_in_port2>;
+ };
+ };
+ };
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
index caaf58e..6fe8b62 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -248,3 +248,19 @@
};
};
};
+
+ stm at 20100000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x20100000 0 0x1000>,
+ <0 0x28000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+
+ clocks = <&soc_smc50mhz>;
+ clock-names = "apb_pclk";
+ power-domains = <&scpi_devpd 0>;
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint = <&csys1_funnel_in_port0>;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Sebastian Hesselbarth @ 2017-01-11 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaC+USN7YhZo49LAL9sorMxbTfhQbT5NrAu5D=Q1DHnnA@mail.gmail.com>
On 01/11/2017 03:44 PM, Linus Walleij wrote:
> On Fri, Jan 6, 2017 at 5:15 AM, Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>
>> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>>
>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>> from Marvell.
>>
>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>
> I am waiting for an ACK or comment from the maintainers on
> this patch. Sebastian?
Sorry for the ignorance.
I don't have the patch to reply to inline, but:
- In the driver MPP_MODE2, spi0 there is a typo "csk" instead of "sck".
- MPP_MODE5 binding "dev","bootcs" and driver "dev","bootcs0" differ.
- MPP_MODE6 binding "gpio" and driver "gpo" differ.
- MPP_MODE17 binding "dev","clk" and driver "dev","clkout" differ.
- MPP_MODE19 binding mentiones "dev","rb" but driver does not.
- MPP_MODE20 binding "gpio" and driver "gpo" differ.
- MPP_MODE20 binding "dev","we" and driver "dev","we0" differ.
- MPP_MODE21 through MPP_MODE30 binding "gpio" and driver "gpo" differ.
- remove spaces before "0, 0" in mv98dx3236_mpp_gpio_ranges.
Most of it is cosmetic stuff, so if you fix it feel free to add my
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Sebastian
^ permalink raw reply
* [RFC PATCH 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Kim Phillips @ 2017-01-11 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111123714.GK12388@arm.com>
On Wed, 11 Jan 2017 12:37:15 +0000
Will Deacon <will.deacon@arm.com> wrote:
> Hi Kim,
>
> On Tue, Jan 10, 2017 at 04:04:19PM -0600, Kim Phillips wrote:
> > On Tue, 3 Jan 2017 18:10:26 +0000
> > Will Deacon <will.deacon@arm.com> wrote:
> >
> > > +#define DRVNAME "arm_spe_pmu"
> >
> > Based on Intel naming "intel_pt" and "intel_bts', I had expected
> > "arm-spe" as the universal basename for SPE. I don't really care about
> > whether '_pmu' is included, but it's yet another naming inconsistency we
> > have with coresight's "cs_etm" (the other being prefixed with "arm_").
>
> It's consistent with the other PMUs under drivers/perf.
>
> > Also, nit, since I don't know why perf userspace tools can't handle
> > dashes in PMU names (commit 3d1ff755e367 "arm: perf: clean up PMU
> > names" doesn't say), can we at least start to use dashes in our
> > filenames? arm-spe-pmu.c is easier to type than arm_spe_pmu.c.
>
> I'd rather go for consistency both with the other PMU drivers under
> drivers/perf, but also with the PMU name itself.
Selecting a PMU naming consistency domain based on its driver's source
path doesn't accurately represent the naming consistency the user
expects. Not to mention there are only 2 out of 44 PMU device
registration callsites under drivers/perf...
> > > +static int arm_spe_pmu_event_init(struct perf_event *event)
> > > +{
> > > + u64 reg;
> > > + struct perf_event_attr *attr = &event->attr;
> > > + struct arm_spe_pmu *spe_pmu = to_spe_pmu(event->pmu);
> > > +
> > > + /* This is, of course, deeply driver-specific */
> > > + if (attr->type != event->pmu->type)
> > > + return -ENOENT;
> > > +
> > > + if (event->cpu >= 0 &&
> > > + !cpumask_test_cpu(event->cpu, &spe_pmu->supported_cpus))
> > > + return -ENOENT;
> > > +
> > > + if (arm_spe_event_to_pmsevfr(event) & PMSEVFR_EL1_RES0)
> > > + return -EOPNOTSUPP;
> > > +
> > > + if (event->hw.sample_period < spe_pmu->min_period ||
> > > + event->hw.sample_period & PMSIRR_EL1_IVAL_MASK)
> > > + return -EOPNOTSUPP;
> > > +
> > > + if (attr->exclude_idle)
> > > + return -EOPNOTSUPP;
> > > +
> > > + /*
> > > + * Feedback-directed frequency throttling doesn't work when we
> > > + * have a buffer of samples. We'd need to manually count the
> > > + * samples in the buffer when it fills up and adjust the event
> > > + * count to reflect that. Instead, force the user to specify a
> > > + * sample period instead.
> > > + */
> > > + if (attr->freq)
> > > + return -EINVAL;
> > > +
> > > + if (is_kernel_in_hyp_mode()) {
> > > + if (attr->exclude_kernel != attr->exclude_hv)
> > > + return -EOPNOTSUPP;
> > > + } else if (!attr->exclude_hv) {
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > + reg = arm_spe_event_to_pmsfcr(event);
> > > + if ((reg & BIT(PMSFCR_EL1_FE_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_EVT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FT_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_TYP))
> > > + return -EOPNOTSUPP;
> > > +
> > > + if ((reg & BIT(PMSFCR_EL1_FL_SHIFT)) &&
> > > + !(spe_pmu->features & SPE_PMU_FEAT_FILT_LAT))
> > > + return -EOPNOTSUPP;
> > > +
> > > + return 0;
> > > +}
> >
> > Without being provided instructions on how to use, I had to add
> > debug printks here to find out e.g., an event period *must* be specified
> > with record -c, and then again to find out that only a certain set of
> > numbers is allowed by the h/w (256, 512, etc.). Is it possible to
> > report why the driver is returning an error before it does? Otherwise,
> > all the user sees is, e.g.:
> >
> > Error:
> > The sys_perf_event_open() syscall returned with 19 (No such device) for event (arm_spe_pmu_0).
> > /bin/dmesg may provide additional information.
> > No CONFIG_PERF_EVENTS=y kernel support configured?
> >
> > ...and, in this case, with nothing in dmesg. And, IIRC, the above text
> > is emitted only if perf is run with -v and/or built with DEBUG set.
> > Granted, *that* problem is not explicitly relevant to this patch, but
> > new drivers should nevertheless express their usage details better.
>
> I don't disagree that the error reporting from the driver up to userspace
> leaves much to be desired, but there currently isn't a sensible way to
> communicate the exact reason for failure back from event_init and I
> don't think we're different to other PMU drivers in this respect. Yes,
> you can paper around the problem using pr_debug, but that really only
> helps the developer writing the perf tool support, and much of the
> constraints can also be inferred from the architecture spec.
This applies to all users of the driver, not just the developer writing
the perf tool support. And users definitely shouldn't need to read the
architecture spec in order to use the feature.
> There were patches to allow providing strings back via perf_err:
>
> https://lkml.org/lkml/2015/8/24/506
>
> but I don't think it ended up getting merged. Other subsystems wanted to
> use the same approach, and there are ABI considerations with all of this
> (the thread is worth a read).
OK I didn't read everything, but meanwhile, we need to be making perf -
esp. as it's so clearly pointed out already - to be easier to use in
the time being. Like one of the threads' responses, *anything* is
better than blindly returning -EINVAL/-ENOTSUPP, etc. Please insert
pr_* statements before returning errors.
We can easily migrate from pr_* to perf_err (or equivalent) when
perf_err becomes available. Maintenance-wise, it is much more
efficient to do this at driver submission time, rather than waiting for
perf_err to be merged, since it's likely the code will be in the same
place.
> > Also, curiously, arm_spe_pmu doesn't appear in 'perf list' (even when
> > SPE h/w is present).
>
> Weird, it would be nice to understand why that is. The sysfs plumbing should
> all be there, so I'd expect to see something. On my laptop, for example,
> intel_pt appears as:
>
> intel_pt// [Kernel PMU event]
>
> and strace show perf doing the following:
>
> stat("/sys/bus/event_source/devices/intel_pt/format", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/format", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 82
> open("/sys/bus/event_source/devices/intel_pt/format/psb_period", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/noretcomp", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/tsc", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/cyc_thresh", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/mtc_period", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/cyc", O_RDONLY) = 83
> open("/sys/bus/event_source/devices/intel_pt/format/mtc", O_RDONLY) = 83
> stat("/sys/bus/event_source/devices/intel_pt/events", 0x7ffe54eebb40) = -1 ENOENT (No such file or directory)
> stat("/sys/bus/event_source/devices/intel_pt/type", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/type", O_RDONLY) = 82
> stat("/sys/bus/event_source/devices/intel_pt/cpumask", 0x7ffe54eedd60) = -1 ENOENT (No such file or directory)
> stat("/sys/bus/event_source/devices/intel_pt/cpus", 0x7ffe54eedd60) = -1 ENOENT (No such file or directory)
> stat("/sys/bus/event_source/devices/intel_pt/caps/mtc", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/caps/mtc", O_RDONLY) = 82
> stat("/sys/bus/event_source/devices/intel_pt/caps/psb_cyc", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> open("/sys/bus/event_source/devices/intel_pt/caps/psb_cyc", O_RDONLY) = 82
>
> What do you see for SPE?
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format", {st_mode=S_IFDIR|0755, st_size=0, ...}, 0) = 0
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 58
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/branch_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/ts_enable", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/pa_enable", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/event_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/load_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/jitter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/store_filter", O_RDONLY) = 59
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/min_latency", O_RDONLY) = 59
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/events", 0xffffcd6bb078, 0) = -1 ENOENT (No such file or directory)
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/type", {st_mode=S_IFREG|0444, st_size=4096, ...}, 0) = 0
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/type", O_RDONLY) = 58
2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/cpumask", {st_mode=S_IFREG|0444, st_size=4096, ...}, 0) = 0
2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/cpumask", O_RDONLY) = 58
they're identical up until /.../cpumask's stat, which exists on the
ARM SPE run (as opposed to the Intel run).
Kim
^ permalink raw reply
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Maxime Ripard @ 2017-01-11 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111200811.GA16865@uda0271908>
On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >
> >
> > 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> > >> ?Lichee Pi Zero features a USB OTG port.
> > >>
> > >> ?Add support for it.
> > >>
> > >> ?Note: in order to use the Host mode, the board must be powered via the
> > >> ?+5V and GND pins.
> > >>
> > >> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > >> ?---
> > >> ??arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> > >> ??1 file changed, 10 insertions(+)
> > >>
> > >> ?diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> ?index 0099affc6ce3..3d9168cbaeca 100644
> > >> ?--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> ?+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> ?@@ -71,3 +71,13 @@
> > >> ??????????pinctrl-names = "default";
> > >> ??????????status = "okay";
> > >> ??};
> > >> ?+
> > >> ?+&usb_otg {
> > >> ?+ dr_mode = "otg";
> > >
> > > Why not set this default mode in dtsi instead?
> > >
> > > Regards,
> > > -Bin.
> >
> > There's possibly boards which do not have OTG functions.
>
> That is board specific.
Exactly, and this is why it should be done in the board DT.
The controller in the Allwinner SoCs do not handle directly the ID pin
and VBUS, but rather rely on a GPIO to do so.
So boards with OTG will need setup anyway, at least to tell which
GPIOs are used. There's no point in enforcing a default if it doesn't
work by default.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170111/2d54e75b/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops()
From: Arnd Bergmann @ 2017-01-11 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-2-git-send-email-nikita.yoush@cogentembedded.com>
On Wednesday, January 11, 2017 9:31:51 PM CET Nikita Yushchenko wrote:
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 9afcbf7..0995ab3 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1096,7 +1096,7 @@ static int rk_iommu_domain_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> /* Set dma_ops for dev, otherwise it would be dummy_dma_ops */
> - arch_setup_dma_ops(dev, 0, DMA_BIT_MASK(32), NULL, false);
> + arch_setup_dma_ops(dev, 0, DMA_BIT_MASK(32), false, NULL, false);
>
> dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index c9b7ad6..19f70d8 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2533,7 +2533,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
> priv->buf_layout[TX].priv_data_size = DPAA_TX_PRIV_DATA_SIZE; /* Tx */
>
> /* device used for DMA mapping */
> - arch_setup_dma_ops(dev, 0, 0, NULL, false);
> + arch_setup_dma_ops(dev, 0, 0, false, NULL, false);
> err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
> if (err) {
> dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
> diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> index 5ac373c..480b644 100644
> --- a/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> +++ b/drivers/staging/fsl-mc/bus/fsl-mc-bus.c
> @@ -540,7 +540,7 @@ int fsl_mc_device_add(struct dprc_obj_desc *obj_desc,
>
> /* Objects are coherent, unless 'no shareability' flag set. */
> if (!(obj_desc->flags & DPRC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> + arch_setup_dma_ops(&mc_dev->dev, 0, 0, false, NULL, true);
>
> /*
> * The device-specific probe callback will get invoked by device_add()
Why are these actually calling arch_setup_dma_ops() here in the first
place? Are these all devices that are DMA masters without an OF node?
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index fd5cfad..1cc2115 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -89,6 +89,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> bool coherent;
> unsigned long offset;
> const struct iommu_ops *iommu;
> + bool enforce_range = false;
>
> /*
> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> @@ -126,6 +127,8 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> return;
> }
> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> +
> + enforce_range = true;
> }
>
> dev->dma_pfn_offset = offset;
Hmm, I think when the dma-ranges are missing, we should either enforce
a 32-bit mask, or disallow DMA completely. It's probably too late for
the latter, I wish we had done this earlier in order to force everyone
on ARM64 to have a valid dma-ranges property for any DMA master.
Arnd
^ permalink raw reply
* [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports
From: Arnd Bergmann @ 2017-01-11 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484159512-28515-3-git-send-email-nikita.yoush@cogentembedded.com>
On Wednesday, January 11, 2017 9:31:52 PM CET Nikita Yushchenko wrote:
> @@ -959,6 +990,15 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> if (!dev->archdata.dma_ops)
> dev->archdata.dma_ops = &swiotlb_dma_ops;
>
> + /*
> + * Whatever the parent bus can set. A device must not set
> + * a DMA mask larger than this.
> + */
> + if (enforce_range)
> + dev->archdata.parent_dma_mask = size - 1;
> + else
> + dev->archdata.parent_dma_mask = DMA_BIT_MASK(64);
> +
> dev->archdata.dma_coherent = coherent;
> __iommu_setup_dma_ops(dev, dma_base, size, iommu);
>
Could we just pass the mask instead of the size here?
Arnd
^ permalink raw reply
* [PATCH net-next] net: thunderx: Fix error return code in nicvf_open()
From: David Miller @ 2017-01-11 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111163251.19367-1-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 11 Jan 2017 16:32:51 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 712c31853440 ("net: thunderx: Program LMAC credits based on MTU")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484096148-17120-1-git-send-email-cw00.choi@samsung.com>
On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
> This patch replaces the small letter of base address, offset and hex value
> with the capital letter to keep the consistency on Exynos5433.
You mean the other way around, right?
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index abaf6b4d599d..d7ed1a68b6fd 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -231,7 +231,7 @@
> compatible = "arm,psci";
> method = "smc";
> cpu_off = <0x84000002>;
> - cpu_on = <0xC4000003>;
> + cpu_on = <0xc4000003>;
> };
>
> reboot: syscon-reboot {
> @@ -753,7 +753,7 @@
>
> dsi: dsi at 13900000 {
> compatible = "samsung,exynos5433-mipi-dsi";
> - reg = <0x13900000 0xC0>;
> + reg = <0x13900000 0xc0>;
> interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
> phys = <&mipi_phy 1>;
> phy-names = "dsim";
> @@ -880,9 +880,9 @@
> iommus = <&sysmmu_jpeg>;
> };
>
> - mfc: codec at 152E0000 {
> + mfc: codec at 152e0000 {
> compatible = "samsung,exynos5433-mfc";
> - reg = <0x152E0000 0x10000>;
> + reg = <0x152e0000 0x10000>;
> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "pclk", "aclk", "aclk_xiu";
> clocks = <&cmu_mfc CLK_PCLK_MFC>,
> @@ -914,7 +914,7 @@
>
> sysmmu_gscl0: sysmmu at 13c80000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13C80000 0x1000>;
> + reg = <0x13c80000 0x1000>;
> interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL0>,
> @@ -924,7 +924,7 @@
>
> sysmmu_gscl1: sysmmu at 13c90000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13C90000 0x1000>;
> + reg = <0x13c90000 0x1000>;
> interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL1>,
> @@ -934,7 +934,7 @@
>
> sysmmu_gscl2: sysmmu at 13ca0000 {
> compatible = "samsung,exynos-sysmmu";
> - reg = <0x13CA0000 0x1000>;
> + reg = <0x13ca0000 0x1000>;
> interrupts = <GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>;
> clock-names = "aclk", "pclk";
> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL2>,
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Rob Herring @ 2017-01-11 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109192814.26811-1-s-anna@ti.com>
On Mon, Jan 09, 2017 at 01:28:14PM -0600, Suman Anna wrote:
> Fix couple of typos in the example given in the TI syscon reset
> binding. The ti,reset-bits used for DSP0 are corrected to match
> the values that will be used in the actual DT node.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> Hi Philipp,
>
> This is the Documentation part fix that goes along with
> the ti-syscon-reset fix that you have on your next branch.
> I will be submitting the DT nodes very soon
>
> regards
> Suman
>
> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> index 164c7f34c451..21ba739b162e 100644
> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> @@ -63,7 +63,7 @@ Example:
> --------
> The following example demonstrates a syscon node, the reset controller node
> using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
> -Edison SoC.
> +66AK2E SoC.
>
> / {
> soc {
> @@ -71,13 +71,13 @@ Edison SoC.
> compatible = "syscon", "simple-mfd";
> reg = <0x02350000 0x1000>;
>
> - pscrst: psc-reset {
> + pscrst: psc-reset-controller {
Really, this should be just 'reset-controller'.
Rob
^ permalink raw reply
* [PATCH v2 1/6] mmc: sunxi: Always set signal delay to 0 for A64
From: Maxime Ripard @ 2017-01-11 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96ba5fd8-d551-5993-f347-202c47efec8c@arm.com>
On Tue, Jan 10, 2017 at 12:30:41AM +0000, Andr? Przywara wrote:
> On 09/01/17 16:46, Maxime Ripard wrote:
> > Experience have shown that the using the autocalibration could severely
> > degrade the performances of the MMC bus.
> >
> > Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
> > Remove the calibration code for now, and add comments to document our
> > findings.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
> > 1 file changed, 17 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> > index b1d1303389a7..ea9552a0d820 100644
> > --- a/drivers/mmc/host/sunxi-mmc.c
> > +++ b/drivers/mmc/host/sunxi-mmc.c
> > @@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
> >
> > static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
> > {
> > - u32 reg = readl(host->reg_base + reg_off);
> > - u32 delay;
> > - unsigned long timeout;
> > -
> > if (!host->cfg->can_calibrate)
> > return 0;
> >
> > - reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
> > - reg &= ~SDXC_CAL_DL_SW_EN;
> > -
> > - writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
> > -
> > - dev_dbg(mmc_dev(host->mmc), "calibration started\n");
> > -
> > - timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
> > -
> > - while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
> > - if (time_before(jiffies, timeout))
> > - cpu_relax();
> > - else {
> > - reg &= ~SDXC_CAL_START;
> > - writel(reg, host->reg_base + reg_off);
> > -
> > - return -ETIMEDOUT;
> > - }
> > - }
> > -
> > - delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
> > -
> > - reg &= ~SDXC_CAL_START;
> > - reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
> > -
> > - writel(reg, host->reg_base + reg_off);
> > -
> > - dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
> > + /*
> > + * FIXME:
> > + * This is not clear how the calibration is supposed to work
> > + * yet. The best rate have been obtained by simply setting the
> > + * delay to 0, as Allwinner does in its BSP.
> > + *
> > + * The only mode that doesn't have such a delay is HS400, that
> > + * is in itself a TODO.
> > + */
> > + writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
> >
> > return 0;
> > }
> > @@ -806,7 +784,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
> > if (ret)
> > return ret;
> >
> > - /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
> > + /*
> > + * FIXME:
> > + *
> > + * In HS400 we'll also need to calibrate the data strobe
> > + * signal. This should only happen on the MMC2 controller (at
> > + * least on the A64 and older SoCs).
>
> Which older SoCs have this calibration register and a DS signal?
> Is that supposed to mean "other" SoCs?
That was supposed to mean that newer (than A64) SoCs might have that
calibration on other controllers than MMC2. But you're right that it
actually applies only to A64 anyway, I'll remove the and older part.
> Other than that:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170111/1c8767ce/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Chanwoo Choi @ 2017-01-11 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111162613.lxkc7k75f6q3fsz2@kozik-lap>
2017-01-12 1:26 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>> This patch replaces the small letter of base address, offset and hex value
>> with the capital letter to keep the consistency on Exynos5433.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index abaf6b4d599d..d7ed1a68b6fd 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -231,7 +231,7 @@
>> compatible = "arm,psci";
>> method = "smc";
>> cpu_off = <0x84000002>;
>> - cpu_on = <0xC4000003>;
>> + cpu_on = <0xc4000003>;
>
> There is no point of such "improvements". This is just unnecessary
> churn.
>
> Sometimes such things are accepted as part of some bigger work (vide
> recent Andrzej's sysmmu for HDMI/TV). But on its own? No sense at all.
Do you mean that this patch is not reasonable? or
The modification of cpu_on property is only not reasonable?
It is simple for the consistency to use the hex value in dts file.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-11 21:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484015754.4057.4.camel@mtkswgap22>
On Mon, Jan 9, 2017 at 8:35 PM, Sean Wang <sean.wang@mediatek.com> wrote:
> Hi Rob,
>
> thanks for your effort for reviewing. I added comments inline.
>
> On Mon, 2017-01-09 at 12:32 -0600, Rob Herring wrote:
>> On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.wang at mediatek.com wrote:
>> > From: Sean Wang <sean.wang@mediatek.com>
>> >
>> > This patch adds documentation for devicetree bindings for
>> > Mediatek IR controller.
>> >
>> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> > ---
>> > .../devicetree/bindings/media/mtk-cir.txt | 23 ++++++++++++++++++++++
>> > 1 file changed, 23 insertions(+)
>> > create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
>> > new file mode 100644
>> > index 0000000..bbedd71
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
>> > @@ -0,0 +1,23 @@
>> > +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
>> > +
>> > +Required properties:
>> > +- compatible : "mediatek,mt7623-ir"
>> > +- clocks : list of clock specifiers, corresponding to
>> > + entries in clock-names property;
>> > +- clock-names : should contain "clk" entries;
>> > +- interrupts : should contain IR IRQ number;
>> > +- reg : should contain IO map address for IR.
>> > +
>> > +Optional properties:
>> > +- linux,rc-map-name : Remote control map name.
>>
>> Would 'label' be appropriate here instead? If not, this needs to be
>> documented in a common location and explained better.
>>
> I checked with how the way applied in other IR drivers is and found that
> most IR driver also use the same label to identify the scan/key table
> they prefer to use such as gpio-ir-recv, ir-hix5hd2, meson-ir and
> sunxi-cir or use hard coding inside the driver. So I thought it should
> be appropriate here currently.
Maybe so, but anything with linux prefix gets extra scrutiny and I'm
not sure that happened on the previous cases. If label has the same
meaning, then we should start using that and deprecate this property.
In any case, a property used by multiple bindings needs to be
documented in a common place. The explanation of the property is bad
too. It just spells out RC with no explanation. I'm sure you just
copy-n-pasted it from the others, but that doesn't make it okay.
Rob
^ permalink raw reply
* [PATCH] arm64: dts: exynos: Replace small letter of base address/offset on Exynos5433
From: Chanwoo Choi @ 2017-01-11 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111211503.6kwqaunb5mpe6eb2@rob-hp-laptop>
2017-01-12 6:15 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Wed, Jan 11, 2017 at 09:55:48AM +0900, Chanwoo Choi wrote:
>> This patch replaces the small letter of base address, offset and hex value
>> with the capital letter to keep the consistency on Exynos5433.
>
> You mean the other way around, right?
When I posted the dts patches, I got the comment that small letter is better
for base address/offset. (It doesn?t mean that all dts file in Linux Kernel
have to use the small letter of base address and offset.)
This dts uses the both capital and small letter for each base address/offset.
Almost hex value already uses the small letter. If possible, I hope to use
the one style (small letter).
>
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index abaf6b4d599d..d7ed1a68b6fd 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -231,7 +231,7 @@
>> compatible = "arm,psci";
>> method = "smc";
>> cpu_off = <0x84000002>;
>> - cpu_on = <0xC4000003>;
>> + cpu_on = <0xc4000003>;
>> };
>>
>> reboot: syscon-reboot {
>> @@ -753,7 +753,7 @@
>>
>> dsi: dsi at 13900000 {
>> compatible = "samsung,exynos5433-mipi-dsi";
>> - reg = <0x13900000 0xC0>;
>> + reg = <0x13900000 0xc0>;
>> interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
>> phys = <&mipi_phy 1>;
>> phy-names = "dsim";
>> @@ -880,9 +880,9 @@
>> iommus = <&sysmmu_jpeg>;
>> };
>>
>> - mfc: codec at 152E0000 {
>> + mfc: codec at 152e0000 {
>> compatible = "samsung,exynos5433-mfc";
>> - reg = <0x152E0000 0x10000>;
>> + reg = <0x152e0000 0x10000>;
>> interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "pclk", "aclk", "aclk_xiu";
>> clocks = <&cmu_mfc CLK_PCLK_MFC>,
>> @@ -914,7 +914,7 @@
>>
>> sysmmu_gscl0: sysmmu at 13c80000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13C80000 0x1000>;
>> + reg = <0x13c80000 0x1000>;
>> interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL0>,
>> @@ -924,7 +924,7 @@
>>
>> sysmmu_gscl1: sysmmu at 13c90000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13C90000 0x1000>;
>> + reg = <0x13c90000 0x1000>;
>> interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL1>,
>> @@ -934,7 +934,7 @@
>>
>> sysmmu_gscl2: sysmmu at 13ca0000 {
>> compatible = "samsung,exynos-sysmmu";
>> - reg = <0x13CA0000 0x1000>;
>> + reg = <0x13ca0000 0x1000>;
>> interrupts = <GIC_SPI 292 IRQ_TYPE_LEVEL_HIGH>;
>> clock-names = "aclk", "pclk";
>> clocks = <&cmu_gscl CLK_ACLK_SMMU_GSCL2>,
>> --
>> 1.9.1
>>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2017-01-11 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7bd282d9-df6f-f4c6-1f7f-c8ed81c78af3@ti.com>
On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Rob,
>
> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>
>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>
>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>> will hook into the genpd framework and allow the TI SCI protocol to
>>> control device power states.
>>>
>>> Also, provide macros representing each device index as understood
>>> by TI SCI to be used in the device node power-domain references.
>>> These are identifiers for the K2G devices managed by the PMMC.
>>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>> ---
>>> v2->v3:
>>> Update k2g_pds node docs to show it should be a child of pmmc
>>> node.
>>> In early versions a phandle was used to point to pmmc and docs
>>> still
>>> incorrectly showed this.
>>>
>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
>>> MAINTAINERS | 2 +
>>> include/dt-bindings/genpd/k2g.h | 90
>>> ++++++++++++++++++++++
>>> 3 files changed, 151 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> new file mode 100644
>>> index 000000000000..4c9064e512cb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> @@ -0,0 +1,59 @@
>>> +Texas Instruments TI-SCI Generic Power Domain
>>> +---------------------------------------------
>>> +
>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>> +responsible for controlling the state of the IPs that are present.
>>> +Communication between the host processor running an OS and the system
>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>> domain
>>> +implementation plugs into the generic pm domain framework and makes use
>>> of
>>> +the TI SCI protocol power on and off each device when needed.
>>> +
>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>> +
>>> +PM Domain Node
>>> +==============
>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>> +which in this case is the single implementation as documented by the
>>> generic
>>> +PM domain bindings in
>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>> +Because this relies on the TI SCI protocol to communicate with the PMMC
>>> it
>>> +must be a child of the pmmc node.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- compatible: should be "ti,sci-pm-domain"
>>> +- #power-domain-cells: Must be 0.
>>> +
>>> +Example (K2G):
>>> +-------------
>>> + pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> + ...
>>> +
>>> + k2g_pds: k2g_pds {
>>> + compatible = "ti,sci-pm-domain";
>>> + #power-domain-cells = <0>;
>>> + };
>>> + };
>>> +
>>> +PM Domain Consumers
>>> +===================
>>> +Hardware blocks that require SCI control over their state must provide
>>> +a reference to the sci-pm-domain they are part of and a unique device
>>> +specific ID that identifies the device.
>>> +
>>> +Required Properties:
>>> +--------------------
>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>> + be used for device control.
>>
>>
>> As I've already stated before, this goes in power-domain cells. When you
>> have a single thing (i.e. node) that controls multiple things, then you
>> you need to specify the ID for each of them in phandle args. This is how
>> irqs, gpio, clocks, *everything* in DT works.
>
>
> You think the reasoning for doing it this way provided by both Ulf and
> myself on v2 [1] is not valid then?
>
> From Ulf:
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Sorry, but that sounds like a kernel problem to me and has nothing to
do with DT bindings.
> From me:
>
> Yes, you've pretty much hit it on the head. It is not an index into a list
> of genpds but rather identifies the device *within* a single genpd. It is a
> property specific to each device that resides in a ti-sci-genpd, not a
> mapping describing which genpd the device belongs to. The generic power
> domain binding is concerned with mapping the device to a specific genpd,
> which is does fine for us, but we have a sub mapping for devices that exist
> inside a genpd which, we must describe as well, hence the ti,sci-id.
>
>
> So to summarize, the genpd framework does interpret the phandle arg as an
> index into multiple genpds, just as you've said other frameworks do, but
> this is not what I am trying to do, we have multiple devices within this
> *single* genpd, hence the need for the ti,sci-id property.
Fix the genpd framework rather than work around it in DT.
Rob
^ permalink raw reply
* [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Suman Anna @ 2017-01-11 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111211520.w3sy5pkvjydiwvcs@rob-hp-laptop>
On 01/11/2017 03:15 PM, Rob Herring wrote:
> On Mon, Jan 09, 2017 at 01:28:14PM -0600, Suman Anna wrote:
>> Fix couple of typos in the example given in the TI syscon reset
>> binding. The ti,reset-bits used for DSP0 are corrected to match
>> the values that will be used in the actual DT node.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> Hi Philipp,
>>
>> This is the Documentation part fix that goes along with
>> the ti-syscon-reset fix that you have on your next branch.
>> I will be submitting the DT nodes very soon
>>
>> regards
>> Suman
>>
>> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> index 164c7f34c451..21ba739b162e 100644
>> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> @@ -63,7 +63,7 @@ Example:
>> --------
>> The following example demonstrates a syscon node, the reset controller node
>> using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
>> -Edison SoC.
>> +66AK2E SoC.
>>
>> / {
>> soc {
>> @@ -71,13 +71,13 @@ Edison SoC.
>> compatible = "syscon", "simple-mfd";
>> reg = <0x02350000 0x1000>;
>>
>> - pscrst: psc-reset {
>> + pscrst: psc-reset-controller {
>
> Really, this should be just 'reset-controller'.
Thanks Rob, I will fix this patch and the DTS patches as well.
regards
Suman
^ permalink raw reply
* CONFIG_PCIEASPM breaks PCIe on Marvell Armada 385 machine
From: Bjorn Helgaas @ 2017-01-11 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111194942.q5rdma2es6hkmxfe@perseus.defre.kleine-koenig.org>
Hi Uwe,
On Wed, Jan 11, 2017 at 08:49:46PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> on an Marvell Armada 385 based machine (Turris Omnia) with 4.9 the
> ath10k driver fails to bind to the matching hardware if CONFIG_PCIEASPM
> is enabled:
>
> # dmesg | grep ath
> [ 7.207770] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
> [ 7.237955] ath10k_pci 0000:02:00.0: failed to wake up device : -110
> [ 7.238146] ath10k_pci: probe of 0000:02:00.0 failed with error -110
>
> if however PCIEASPM is off, the driver probes correctly and the ath10k
> adapter works fine.
>
> I wonder if someone has an idea what needs to be done to fix this
> problem. (OK, I could disable PCIEASPM, but I'd like to have a solution
> for a distribution kernel where I think PCIEASPM=y is sensible in
> general.)
PCIEASPM=y is definitely sensible and disabling ASPM is OK for a
workaround but is not a fix.
We have several open issues related to ASPM:
https://bugzilla.kernel.org/show_bug.cgi?id=102311 ASPM: ASMEDA asm1062 not working
https://bugzilla.kernel.org/show_bug.cgi?id=187731 Null pointer dereference in ASPM
https://bugzilla.kernel.org/show_bug.cgi?id=189951 Enabling ASPM causes NIC performance issue
https://bugzilla.kernel.org/show_bug.cgi?id=60111 NULL pointer deref in ASPM alloc_pcie_link_state()
I don't recognize yours as being one of these. Can you open a new
issue and attach the complete dmesg log and "lspci -vv" output?
Is this a regression?
Bjorn
^ 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