* [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
From: Pavel Machek @ 2017-04-14 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492091578.2383.39.camel@pengutronix.de>
Hi!
> > The MUX framework is already in linux-next. Could you use that instead of
> > adding new driver + bindings that are not compliant with the MUX framework?
> > I don't think it'd be much of a change in terms of code, using the MUX
> > framework appears quite simple.
>
> It is not quite clear to me how to design the DT bindings for this. Just
> splitting the video-multiplexer driver from the mux-mmio / mux-gpio
> would make it necessary to keep the video-multiplexer node to describe
> the of-graph bindings. But then we have two different nodes in the DT
> that describe the same hardware:
>
> mux: mux {
> compatible = "mux-gpio";
> mux-gpios = <&gpio 0>, <&gpio 1>;
> #mux-control-cells = <0>;
> }
>
> video-multiplexer {
> compatible = "video-multiplexer"
> mux-controls = <&mux>;
>
> ports {
> /* ... */
> }
> }
>
> It would feel more natural to have the ports in the mux node, but then
> how would the video-multiplexer driver be instanciated, and how would it
> get to the of-graph nodes?
Device tree representation and code used to implement the muxing
driver should be pretty independend, no? Yes, one piece of hardware
should have one entry in the device tree, so it should be something
like:
video-multiplexer {
compatible = "video-multiplexer-gpio"
mux-gpios = <&gpio 0>, <&gpio 1>;
#mux-control-cells = <0>;
mux-controls = <&mux>;
ports {
/* ... */
}
}
You should be able to use code in drivers/mux as a library...
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/20170414/381bc993/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/8] trace: ras: add ARM processor error information trace event
From: Baicar, Tyler @ 2017-04-14 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490869877-118713-11-git-send-email-xiexiuqi@huawei.com>
On 3/30/2017 4:31 AM, Xie XiuQi wrote:
> Add a new trace event for ARM processor error information, so that
> the user will know what error occurred. With this information the
> user may take appropriate action.
>
> These trace events are consistent with the ARM processor error
> information table which defined in UEFI 2.6 spec section N.2.4.4.1.
>
> ---
> v2: add trace enabled condition as Steven's suggestion.
> fix a typo.
> ---
>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
> ---
...
>
> +#define ARM_PROC_ERR_TYPE \
> + EM ( CPER_ARM_INFO_TYPE_CACHE, "cache error" ) \
> + EM ( CPER_ARM_INFO_TYPE_TLB, "TLB error" ) \
> + EM ( CPER_ARM_INFO_TYPE_BUS, "bus error" ) \
> + EMe ( CPER_ARM_INFO_TYPE_UARCH, "micro-architectural error" )
> +
> +#define ARM_PROC_ERR_FLAGS \
> + EM ( CPER_ARM_INFO_FLAGS_FIRST, "First error captured" ) \
> + EM ( CPER_ARM_INFO_FLAGS_LAST, "Last error captured" ) \
> + EM ( CPER_ARM_INFO_FLAGS_PROPAGATED, "Propagated" ) \
> + EMe ( CPER_ARM_INFO_FLAGS_OVERFLOW, "Overflow" )
> +
Hello Xie XiuQi,
This isn't compiling for me because of these definitions. Here you are
using ARM_*, but below in the TP_printk you are using ARCH_*. The
compiler complains the ARCH_* ones are undefined:
./include/trace/../../include/ras/ras_event.h:278:37: error:
'ARCH_PROC_ERR_TYPE' undeclared (first use in this function)
__print_symbolic(__entry->type, ARCH_PROC_ERR_TYPE),
./include/trace/../../include/ras/ras_event.h:280:38: error:
'ARCH_PROC_ERR_FLAGS' undeclared (first use in this function)
__print_symbolic(__entry->flags, ARCH_PROC_ERR_FLAGS),
> +/*
> + * First define the enums in MM_ACTION_RESULT to be exported to userspace
> + * via TRACE_DEFINE_ENUM().
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a, b) TRACE_DEFINE_ENUM(a);
> +#define EMe(a, b) TRACE_DEFINE_ENUM(a);
> +
> +ARM_PROC_ERR_TYPE
> +ARM_PROC_ERR_FLAGS
Are the above two lines supposed to be here?
> +
> +/*
> + * Now redefine the EM() and EMe() macros to map the enums to the strings
> + * that will be printed in the output.
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a, b) { a, b },
> +#define EMe(a, b) { a, b }
> +
> +TRACE_EVENT(arm_proc_err,
I think it would be better to keep this similar to the naming of the
current RAS trace events (right now we have mc_event, arm_event,
aer_event, etc.). I would suggest using "arm_err_info_event" since this
is handling the error information structures of the arm errors.
> +
> + TP_PROTO(const struct cper_arm_err_info *err),
> +
> + TP_ARGS(err),
> +
> + TP_STRUCT__entry(
> + __field(u8, type)
> + __field(u16, multiple_error)
> + __field(u8, flags)
> + __field(u64, error_info)
> + __field(u64, virt_fault_addr)
> + __field(u64, physical_fault_addr)
Validation bits should also be a part of this structure that way user
space tools will know which of these fields are valid.
> + ),
> +
> + TP_fast_assign(
> + __entry->type = err->type;
> +
> + if (err->validation_bits & CPER_ARM_INFO_VALID_MULTI_ERR)
> + __entry->multiple_error = err->multiple_error;
> + else
> + __entry->multiple_error = ~0;
> +
> + if (err->validation_bits & CPER_ARM_INFO_VALID_FLAGS)
> + __entry->flags = err->flags;
> + else
> + __entry->flags = ~0;
> +
> + if (err->validation_bits & CPER_ARM_INFO_VALID_ERR_INFO)
> + __entry->error_info = err->error_info;
> + else
> + __entry->error_info = 0ULL;
> +
> + if (err->validation_bits & CPER_ARM_INFO_VALID_VIRT_ADDR)
> + __entry->virt_fault_addr = err->virt_fault_addr;
> + else
> + __entry->virt_fault_addr = 0ULL;
> +
> + if (err->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR)
> + __entry->physical_fault_addr = err->physical_fault_addr;
> + else
> + __entry->physical_fault_addr = 0ULL;
> + ),
> +
> + TP_printk("ARM Processor Error: type %s; count: %u; flags: %s;"
I think the "ARM Processor Error:" part of this should just be removed.
Here's the output with this removed and the trace event renamed to
arm_err_info_event. I think this looks much cleaner and matches the
style used with the arm_event.
<idle>-0 [020] .ns. 366.592434: arm_event: affinity
level: 2; MPIDR: 0000000000000000; MIDR: 00000000510f8000; running
state: 1; PSCI state: 0
<idle>-0 [020] .ns. 366.592437: arm_err_info_event:
type cache error; count: 0; flags: 0x3; error info: 0000000000c20058;
virtual address: 0000000000000000; physical address: 0000000000000000
Thanks,
Tyler
--
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 v2 0/5] arm: spear6xx: DT cleanups and improvements
From: Thomas Petazzoni @ 2017-04-14 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170321105943.GT25659@vireshk-i7>
Hello,
On Tue, 21 Mar 2017 16:29:43 +0530, Viresh Kumar wrote:
> > Changes since v1:
> >
> > - Add a few more node labels, and convert the spear600-evb.dts to use
> > node labels, so that one platform upstream uses the node labels.
> >
> > - Add more patches making misc cleanups/improvements in
> > spear600-evb.dts.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Thanks! However, unless I'm missing something, I don't see these
changes in linux-next. Who is going to apply them and send a pull
request to arm-soc? You're listed as one the maintainers for SPEAr, so
I was assuming you would do it. Is this correct?
Let me know if there's anything to be done on my side to get those
patches merged.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/2] ADC support for SPEAr600
From: Thomas Petazzoni @ 2017-04-14 20:51 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This set of two patches add support for the ADC of the SPEAr600, using
the existing spear_adc driver. Only a Device Tree description and a
minor clock fix are needed to make the ADC work.
Thomas
Thomas Petazzoni (2):
arm: spear6xx: add DT description of the ADC on SPEAr600
clk: spear: fix ADC clock definition on SPEAr600
arch/arm/boot/dts/spear600.dtsi | 8 ++++++++
drivers/clk/spear/spear6xx_clock.c | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] arm: spear6xx: add DT description of the ADC on SPEAr600
From: Thomas Petazzoni @ 2017-04-14 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492203072-27771-1-git-send-email-thomas.petazzoni@free-electrons.com>
The SPEAr600 has a built-in ADC, which already has a Device Tree binding
described in
Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt. This
commit adds the description in the SPEAr600 Device Tree of this ADC
device.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/spear600.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi
index 8459286..6b32d20 100644
--- a/arch/arm/boot/dts/spear600.dtsi
+++ b/arch/arm/boot/dts/spear600.dtsi
@@ -204,6 +204,14 @@
interrupt-parent = <&vic0>;
interrupts = <16>;
};
+
+ adc: adc at d820b000 {
+ compatible = "st,spear600-adc";
+ reg = <0xd820b000 0x1000>;
+ interrupt-parent = <&vic1>;
+ interrupts = <6>;
+ status = "disabled";
+ };
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] clk: spear: fix ADC clock definition on SPEAr600
From: Thomas Petazzoni @ 2017-04-14 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492203072-27771-1-git-send-email-thomas.petazzoni@free-electrons.com>
There is no SPEAr600 device named "adc". Instead, the description of the
ADC was recently added to the Device Tree, and the device name is
"d820b000.adc", so we should associate the ADC gatable clock to this
device name.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/clk/spear/spear6xx_clock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/spear/spear6xx_clock.c b/drivers/clk/spear/spear6xx_clock.c
index 7c9383c..f911d9f 100644
--- a/drivers/clk/spear/spear6xx_clock.c
+++ b/drivers/clk/spear/spear6xx_clock.c
@@ -313,7 +313,7 @@ void __init spear6xx_clk_init(void __iomem *misc_base)
/* clock derived from apb clk */
clk = clk_register_gate(NULL, "adc_clk", "apb_clk", 0, PERIP1_CLK_ENB,
ADC_CLK_ENB, 0, &_lock);
- clk_register_clkdev(clk, NULL, "adc");
+ clk_register_clkdev(clk, NULL, "d820b000.adc");
clk = clk_register_fixed_factor(NULL, "gpio0_clk", "apb_clk", 0, 1, 1);
clk_register_clkdev(clk, NULL, "f0100000.gpio");
--
2.7.4
^ permalink raw reply related
* [PATCH] i2c: designware: do not show SDA hold time warning when not needed
From: Thomas Petazzoni @ 2017-04-14 20:53 UTC (permalink / raw)
To: linux-arm-kernel
When the I2C controller IP block has a revision too old to be able to
configure the SDA hold time, the driver currently displays a
warning. However, it does so unconditionally, even if no SDA hold time
has been configured through the Device Tree. This causes useless
warnings when running the system, so only show the warning if a SDA
hold time was specified.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/i2c/busses/i2c-designware-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 7a3faa5..7f9da6e 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -436,8 +436,9 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
dev->sda_hold_time |= 1 << DW_IC_SDA_HOLD_RX_SHIFT;
dw_writel(dev, dev->sda_hold_time, DW_IC_SDA_HOLD);
} else {
- dev_warn(dev->dev,
- "Hardware too old to adjust SDA hold time.\n");
+ if (dev->sda_hold_time)
+ dev_warn(dev->dev,
+ "Hardware too old to adjust SDA hold time.\n");
}
/* Configure Tx/Rx FIFO threshold levels */
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Jayachandran C @ 2017-04-14 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414001911.GA13163@bhelgaas-glaptop.roam.corp.google.com>
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.
> 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.
Thanks,
JC.
^ permalink raw reply
* [PATCH 0/3] Add R8A7743/SK-RZG1M PFC support
From: Sergei Shtylyov @ 2017-04-14 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20170410-v4.11-rc6' tag. We're adding the R8A7743 PFC node and
then describe the pins for SCIF0 and Ether devices described eralier. These
patches depend on the R8A7743 PFC suport in order to work properly.
[1/3] ARM: dts: r8a7743: add PFC support
[2/3] ARM: dts: sk-rzg1m: add SCIF0 pins
[3/3] ARM: dts: sk-rzg1m: add Ether pins
WBR, Sergei
^ permalink raw reply
* [PATCH 1/3] ARM: dts: r8a7743: add PFC support
From: Sergei Shtylyov @ 2017-04-14 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Define the generic R8A7743 part of the PFC device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -1,7 +1,7 @@
/*
* Device Tree Source for the r8a7743 SoC
*
- * Copyright (C) 2016 Cogent Embedded Inc.
+ * Copyright (C) 2016-2017 Cogent Embedded Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -123,6 +123,11 @@
#power-domain-cells = <1>;
};
+ pfc: pin-controller at e6060000 {
+ compatible = "renesas,pfc-r8a7743";
+ reg = <0 0xe6060000 0 0x250>;
+ };
+
dmac0: dma-controller at e6700000 {
compatible = "renesas,dmac-r8a7743",
"renesas,rcar-dmac";
^ permalink raw reply
* [PATCH 2/3] ARM: dts: sk-rzg1m: add SCIF0 pins
From: Sergei Shtylyov @ 2017-04-14 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Add the (previously omitted) SCIF0 pin data to the SK-RZG1M board's
device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -1,7 +1,7 @@
/*
* Device Tree Source for the SK-RZG1M board
*
- * Copyright (C) 2016 Cogent Embedded, Inc.
+ * Copyright (C) 2016-2017 Cogent Embedded, Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -39,7 +39,17 @@
clock-frequency = <20000000>;
};
+&pfc {
+ scif0_pins: scif0 {
+ groups = "scif0_data";
+ function = "scif0";
+ };
+};
+
&scif0 {
+ pinctrl-0 = <&scif0_pins>;
+ pinctrl-names = "default";
+
status = "okay";
};
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sk-rzg1m: add Ether pins
From: Sergei Shtylyov @ 2017-04-14 21:09 UTC (permalink / raw)
To: linux-arm-kernel
Add the (previously omitted) Ether/PHY pin data to the SK-RZG1M board's
device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -44,6 +44,16 @@
groups = "scif0_data";
function = "scif0";
};
+
+ ether_pins: ether {
+ groups = "eth_link", "eth_mdio", "eth_rmii";
+ function = "eth";
+ };
+
+ phy1_pins: phy1 {
+ groups = "intc_irq0";
+ function = "intc";
+ };
};
&scif0 {
@@ -54,6 +64,9 @@
};
ðer {
+ pinctrl-0 = <ðer_pins &phy1_pins>;
+ pinctrl-names = "default";
+
phy-handle = <&phy1>;
renesas,ether-link-active-low;
status = "okay";
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301X: Add CPU thermal sensor and zone
From: Rafał Miłecki @ 2017-04-14 21:42 UTC (permalink / raw)
To: linux-arm-kernel
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.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm5301x.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 6a2afe7880ae..bbf39deb89f3 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -356,6 +356,12 @@
"sata2";
};
+ thermal: thermal at 1800c2c0 {
+ compatible = "brcm,ns-thermal";
+ reg = <0x1800c2c0 0x10>;
+ #thermal-sensor-cells = <0>;
+ };
+
srab: srab at 18007000 {
compatible = "brcm,bcm5301x-srab";
reg = <0x18007000 0x1000>;
@@ -419,4 +425,24 @@
status = "disabled";
};
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ coefficients = <(-556) 418000>;
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <125000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ };
+ };
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init
From: Bjorn Helgaas @ 2017-04-14 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d3857812-7e03-4b62-f7cb-ac0d139b6123@codeaurora.org>
[+cc Myron, lkml]
On Fri, Apr 14, 2017 at 03:12:35PM -0400, Sinan Kaya wrote:
> Bjorn,
>
> On 4/12/2017 3:19 PM, Rajat Jain wrote:
> > On Fri, Apr 7, 2017 at 9:55 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> >> Now that we added a hook to be called from device_add, save the
> >> default values from the HW registers early in the boot for further
> >> reuse during hot device add/remove operations.
> >>
> >> If the link is down during boot, assume that we want to enable L0s
> >> and L1 following hotplug insertion as well as L1SS if supported.
> >
> > IIUC, so far POLICY_DEFAULT meant that we'd just use & follow what
> > BIOS has done, and play it safe (never try to be more opportunistic).
> > With this change however, we'd be slightly overstepping and giving
> > ourselves benefit of doubt if the BIOS could not enable ASPM states
> > because the link was not up. This may be good, but I think we should
> > call it out, and add some more elaborate comment on the POLICY_DEFAULT
> > description (what to, and what not to expect in different situations).
> >
> > It is important because existing systems today, that used to boot
> > without cards and later hotplugged them, didn't have ASPM states
> > enabled. They will now suddenly start seeing all ASPM states enabled
> > including L1 substates for the first time (if supported).
> >
>
> Rajat has a good point here. Would you like me to update the ASPM document
> with this new behavior for hotplug?
>
> Do you have another behavior preference when it comes this?
That *is* a very good point. ?I think the change in behavior could be
surprising.
I wonder if we should revise our understanding of what POLICY_DEFAULT
means. ?If we decided it means "the kernel never changes any ASPM
config", it would be clear that we keep the BIOS configuration for
everything present at boot, and we don't enable ASPM for any hot-added
devices.
I think the motivation for this series is to apply the BIOS's power
management policy to hot-added devices. ?There's no direct way to know
the BIOS's policy, so we're trying to infer it from the boot-time link
configurations.
Should we even *try* to apply the BIOS's policy? ?I don't know. ?If a
platform really wanted to maintain control over ASPM and apply its policy
consistently, I think it could do that by setting ACPI_FADT_NO_ASPM and
using acpiphp instead of pciehp. ?Then the OS would keep its mitts off
ASPM, and the BIOS would have a chance to configure ASPM for hot-added
devices before giving them to the OS.
Here are the possibilities I see for POLICY_DEFAULT:
1) Never touch ASPM config (what we have today)
Boot-present devices: ASPM config retained from BIOS
Hot-added devices: ASPM disabled (poweron state)
2) Linux maintains BIOS policy (conservative)
Boot-present devices: ASPM config retained from BIOS
Hot-added devices (slot occupied at boot): use boot-time ASPM config
Hot-added devices (slot empty at boot): ASPM disabled
3) Linux maintains BIOS policy (aggressive, your current patch)
Boot-present devices: ASPM config retained from BIOS
Hot-added devices (slot occupied at boot): use boot-time ASPM config
Hot-added devices (slot empty at boot): ASPM enabled
I'm becoming less convinced that options 2 or 3 make sense. For one
thing, they're both hard to describe concisely because there are too
many special cases, and that's always a red flag for me.
Even for a given BIOS power management policy, the ASPM configuration
may depend on the particular device; for example, a balanced policy
might enable ASPM for USB devices but not for NICs. So I'm not sure
it really makes sense to remember what BIOS did for the card that was
in the slot at boot-time and apply that to a possibly different card
hot-added later.
I think there's an argument to be made that if we care about ASPM
configuration, we should be using a non-POLICY_DEFAULT setting. And I
think there's value in having POLICY_DEFAULT be the absolute lowest-
risk setting, which I think means option 1.
What do you think?
Bjorn
^ permalink raw reply
* [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init
From: Sinan Kaya @ 2017-04-14 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414214452.GA21870@bhelgaas-glaptop.roam.corp.google.com>
On 4/14/2017 5:44 PM, Bjorn Helgaas wrote:
> I think there's an argument to be made that if we care about ASPM
> configuration, we should be using a non-POLICY_DEFAULT setting. And I
> think there's value in having POLICY_DEFAULT be the absolute lowest-
> risk setting, which I think means option 1.
>
> What do you think?
I see your point. The counter argument is that most of the users do not
know what an ASPM kernel command line is unless they understand PCI
language.
I have been using the powersave policy option until now. I recently realized
that nobody except me is using this option. Therefore, we are wasting
power by default following a hotplug insertion.
This is the case where I'm trying to avoid. With the introduction of NVMe
u.2 drives, hotplug is becoming more and more mainstream. I decided to
take the matters into my hand with this series for this very reason.
Like you said, BIOS is out of the picture with pciehp. There is nobody
to configure ASPM following a hotplug insertion.
I can also claim that If user wants performance, they should boot with
the performance policy or pcie_aspm=off parameters.
I saw this recommendation in multiple DPDK tuning documents.
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.
Maybe, we are missing a HPP option from the PCI spec.
--
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 V2] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-14 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <70e7c7ee13722ab9c73cb073f88502eaf1ada5f5.1491816050.git.viresh.kumar@linaro.org>
On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
OK, so any ACKs from the DT side? Rob?
Thanks,
Rafael
^ permalink raw reply
* [PATCH net-next] drivers: net: xgene-v2: Extend ethtool statistics
From: Iyappan Subramanian @ 2017-04-14 23:48 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds extended statistics reporting to ethtool.
In summary, this patch,
- adds ethtool.h with the statistics register definitions
- adds 'struct xge_gstrings_extd_stats' to gather extended stats
- modifies xge_get_strings(), get_sset_count() and
get_ethtool_stats() accordingly
- moves 'struct xge_gstrings_stats' to ethtool.h
Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
---
drivers/net/ethernet/apm/xgene-v2/ethtool.c | 82 ++++++++++++++++++++++++++---
drivers/net/ethernet/apm/xgene-v2/ethtool.h | 82 +++++++++++++++++++++++++++++
drivers/net/ethernet/apm/xgene-v2/mac.h | 3 --
drivers/net/ethernet/apm/xgene-v2/main.h | 2 +-
4 files changed, 159 insertions(+), 10 deletions(-)
create mode 100644 drivers/net/ethernet/apm/xgene-v2/ethtool.h
diff --git a/drivers/net/ethernet/apm/xgene-v2/ethtool.c b/drivers/net/ethernet/apm/xgene-v2/ethtool.c
index 0c426f5..421b1dd 100644
--- a/drivers/net/ethernet/apm/xgene-v2/ethtool.c
+++ b/drivers/net/ethernet/apm/xgene-v2/ethtool.c
@@ -21,12 +21,13 @@
#include "main.h"
-struct xge_gstrings_stats {
- char name[ETH_GSTRING_LEN];
- int offset;
-};
-
#define XGE_STAT(m) { #m, offsetof(struct xge_pdata, stats.m) }
+#define XGE_EXTD_STAT(m, n) \
+ { \
+ #m, \
+ n, \
+ 0 \
+ }
static const struct xge_gstrings_stats gstrings_stats[] = {
XGE_STAT(rx_packets),
@@ -36,7 +37,66 @@ struct xge_gstrings_stats {
XGE_STAT(rx_errors)
};
+static struct xge_gstrings_extd_stats gstrings_extd_stats[] = {
+ XGE_EXTD_STAT(tx_rx_64b_frame_cntr, TR64),
+ XGE_EXTD_STAT(tx_rx_127b_frame_cntr, TR127),
+ XGE_EXTD_STAT(tx_rx_255b_frame_cntr, TR255),
+ XGE_EXTD_STAT(tx_rx_511b_frame_cntr, TR511),
+ XGE_EXTD_STAT(tx_rx_1023b_frame_cntr, TR1K),
+ XGE_EXTD_STAT(tx_rx_1518b_frame_cntr, TRMAX),
+ XGE_EXTD_STAT(tx_rx_1522b_frame_cntr, TRMGV),
+ 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),
+ XGE_EXTD_STAT(rx_ctrl_frame_pkt_cntr, RXCF),
+ XGE_EXTD_STAT(rx_pause_frame_pkt_cntr, RXPF),
+ XGE_EXTD_STAT(rx_unk_opcode_cntr, RXUO),
+ XGE_EXTD_STAT(rx_align_err_cntr, RALN),
+ XGE_EXTD_STAT(rx_frame_len_err_cntr, RFLR),
+ XGE_EXTD_STAT(rx_code_err_cntr, RCDE),
+ XGE_EXTD_STAT(rx_carrier_sense_err_cntr, RCSE),
+ XGE_EXTD_STAT(rx_undersize_pkt_cntr, RUND),
+ XGE_EXTD_STAT(rx_oversize_pkt_cntr, ROVR),
+ XGE_EXTD_STAT(rx_fragments_cntr, RFRG),
+ XGE_EXTD_STAT(rx_jabber_cntr, RJBR),
+ XGE_EXTD_STAT(rx_dropped_pkt_cntr, RDRP),
+ XGE_EXTD_STAT(tx_byte_cntr, TBYT),
+ XGE_EXTD_STAT(tx_pkt_cntr, TPKT),
+ XGE_EXTD_STAT(tx_multicast_pkt_cntr, TMCA),
+ XGE_EXTD_STAT(tx_broadcast_pkt_cntr, TBCA),
+ XGE_EXTD_STAT(tx_pause_ctrl_frame_cntr, TXPF),
+ XGE_EXTD_STAT(tx_defer_pkt_cntr, TDFR),
+ XGE_EXTD_STAT(tx_excv_defer_pkt_cntr, TEDF),
+ XGE_EXTD_STAT(tx_single_col_pkt_cntr, TSCL),
+ XGE_EXTD_STAT(tx_multi_col_pkt_cntr, TMCL),
+ XGE_EXTD_STAT(tx_late_col_pkt_cntr, TLCL),
+ XGE_EXTD_STAT(tx_excv_col_pkt_cntr, TXCL),
+ XGE_EXTD_STAT(tx_total_col_cntr, TNCL),
+ XGE_EXTD_STAT(tx_pause_frames_hnrd_cntr, TPFH),
+ XGE_EXTD_STAT(tx_drop_frame_cntr, TDRP),
+ XGE_EXTD_STAT(tx_jabber_frame_cntr, TJBR),
+ XGE_EXTD_STAT(tx_fcs_error_cntr, TFCS),
+ XGE_EXTD_STAT(tx_ctrl_frame_cntr, TXCF),
+ XGE_EXTD_STAT(tx_oversize_frame_cntr, TOVR),
+ XGE_EXTD_STAT(tx_undersize_frame_cntr, TUND),
+ XGE_EXTD_STAT(tx_fragments_cntr, TFRG)
+};
+
#define XGE_STATS_LEN ARRAY_SIZE(gstrings_stats)
+#define XGE_EXTD_STATS_LEN ARRAY_SIZE(gstrings_extd_stats)
+
+static void xge_mac_get_extd_stats(struct xge_pdata *pdata)
+{
+ u32 data;
+ int i;
+
+ for (i = 0; i < XGE_EXTD_STATS_LEN; i++) {
+ data = xge_rd_csr(pdata, gstrings_extd_stats[i].addr);
+ gstrings_extd_stats[i].value += data;
+ }
+}
static void xge_get_drvinfo(struct net_device *ndev,
struct ethtool_drvinfo *info)
@@ -62,6 +122,11 @@ static void xge_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
memcpy(p, gstrings_stats[i].name, ETH_GSTRING_LEN);
p += ETH_GSTRING_LEN;
}
+
+ for (i = 0; i < XGE_EXTD_STATS_LEN; i++) {
+ memcpy(p, gstrings_extd_stats[i].name, ETH_GSTRING_LEN);
+ p += ETH_GSTRING_LEN;
+ }
}
static int xge_get_sset_count(struct net_device *ndev, int sset)
@@ -69,7 +134,7 @@ static int xge_get_sset_count(struct net_device *ndev, int sset)
if (sset != ETH_SS_STATS)
return -EINVAL;
- return XGE_STATS_LEN;
+ return XGE_STATS_LEN + XGE_EXTD_STATS_LEN;
}
static void xge_get_ethtool_stats(struct net_device *ndev,
@@ -81,6 +146,11 @@ static void xge_get_ethtool_stats(struct net_device *ndev,
for (i = 0; i < XGE_STATS_LEN; i++)
*data++ = *(u64 *)(pdata + gstrings_stats[i].offset);
+
+ xge_mac_get_extd_stats(pdata);
+
+ for (i = 0; i < XGE_EXTD_STATS_LEN; i++)
+ *data++ = gstrings_extd_stats[i].value;
}
static int xge_get_link_ksettings(struct net_device *ndev,
diff --git a/drivers/net/ethernet/apm/xgene-v2/ethtool.h b/drivers/net/ethernet/apm/xgene-v2/ethtool.h
new file mode 100644
index 0000000..5b9bfa8
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene-v2/ethtool.h
@@ -0,0 +1,82 @@
+/*
+ * Applied Micro X-Gene SoC Ethernet v2 Driver
+ *
+ * Copyright (c) 2017, Applied Micro Circuits Corporation
+ * Author(s): Iyappan Subramanian <isubramanian@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __XGENE_ENET_V2_ETHTOOL_H__
+#define __XGENE_ENET_V2_ETHTOOL_H__
+
+struct xge_gstrings_stats {
+ char name[ETH_GSTRING_LEN];
+ int offset;
+};
+
+struct xge_gstrings_extd_stats {
+ char name[ETH_GSTRING_LEN];
+ u32 addr;
+ u32 value;
+};
+
+#define TR64 0xa080
+#define TR127 0xa084
+#define TR255 0xa088
+#define TR511 0xa08c
+#define TR1K 0xa090
+#define TRMAX 0xa094
+#define TRMGV 0xa098
+#define RBYT 0xa09c
+#define RPKT 0xa0a0
+#define RFCS 0xa0a4
+#define RMCA 0xa0a8
+#define RBCA 0xa0ac
+#define RXCF 0xa0b0
+#define RXPF 0xa0b4
+#define RXUO 0xa0b8
+#define RALN 0xa0bc
+#define RFLR 0xa0c0
+#define RCDE 0xa0c4
+#define RCSE 0xa0c8
+#define RUND 0xa0cc
+#define ROVR 0xa0d0
+#define RFRG 0xa0d4
+#define RJBR 0xa0d8
+#define RDRP 0xa0dc
+#define TBYT 0xa0e0
+#define TPKT 0xa0e4
+#define TMCA 0xa0e8
+#define TBCA 0xa0ec
+#define TXPF 0xa0f0
+#define TDFR 0xa0f4
+#define TEDF 0xa0f8
+#define TSCL 0xa0fc
+#define TMCL 0xa100
+#define TLCL 0xa104
+#define TXCL 0xa108
+#define TNCL 0xa10c
+#define TPFH 0xa110
+#define TDRP 0xa114
+#define TJBR 0xa118
+#define TFCS 0xa11c
+#define TXCF 0xa120
+#define TOVR 0xa124
+#define TUND 0xa128
+#define TFRG 0xa12c
+
+void xge_set_ethtool_ops(struct net_device *ndev);
+
+#endif /* __XGENE_ENET_V2_ETHTOOL_H__ */
diff --git a/drivers/net/ethernet/apm/xgene-v2/mac.h b/drivers/net/ethernet/apm/xgene-v2/mac.h
index 18a9c9d..3c83fa6 100644
--- a/drivers/net/ethernet/apm/xgene-v2/mac.h
+++ b/drivers/net/ethernet/apm/xgene-v2/mac.h
@@ -34,9 +34,6 @@
#define INTERFACE_CONTROL 0xa038
#define STATION_ADDR0 0xa040
#define STATION_ADDR1 0xa044
-#define RBYT 0xa09c
-#define RPKT 0xa0a0
-#define RFCS 0xa0a4
#define RGMII_REG_0 0x27e0
#define ICM_CONFIG0_REG_0 0x2c00
diff --git a/drivers/net/ethernet/apm/xgene-v2/main.h b/drivers/net/ethernet/apm/xgene-v2/main.h
index db1178e..969b258 100644
--- a/drivers/net/ethernet/apm/xgene-v2/main.h
+++ b/drivers/net/ethernet/apm/xgene-v2/main.h
@@ -38,6 +38,7 @@
#include "mac.h"
#include "enet.h"
#include "ring.h"
+#include "ethtool.h"
#define XGENE_ENET_V2_VERSION "v1.0"
#define XGENE_ENET_STD_MTU 1536
@@ -75,6 +76,5 @@ struct xge_pdata {
int xge_mdio_config(struct net_device *ndev);
void xge_mdio_remove(struct net_device *ndev);
-void xge_set_ethtool_ops(struct net_device *ndev);
#endif /* __XGENE_ENET_V2_MAIN_H__ */
--
1.9.1
^ permalink raw reply related
* [PATCH v5 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Bjorn Helgaas @ 2017-04-15 2:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414210646.GA5346@localhost>
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.
Bjorn
^ permalink raw reply
* [PATCH] irqchip/irq-imx-gpcv2: fix spinlock initialization
From: Marc Zyngier @ 2017-04-15 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413222731.5917-1-tyler.baker@linaro.org>
On Thu, Apr 13 2017 at 11:27:31 pm BST, Tyler Baker <tyler.baker@linaro.org> wrote:
> Call raw_spin_lock_init() before the spinlocks are used to prevent a
> lockdep splat.
>
> Fixes the following trace:
>
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> Hardware name: Freescale i.MX7 Dual (Device Tree)
> Backtrace:
> [<c010c364>] (dump_backtrace) from [<c010c610>] (show_stack+0x18/0x1c)
> r7:00000000 r6:600000d3 r5:00000000 r4:c0e273dc
> [<c010c5f8>] (show_stack) from [<c04070a4>] (dump_stack+0xb4/0xe8)
> [<c0406ff0>] (dump_stack) from [<c0169e04>] (register_lock_class+0x208/0x5ec)
> r9:ef00d010 r8:ef00d010 r7:c1606448 r6:00000000 r5:00000000 r4:ffffe000
> [<c0169bfc>] (register_lock_class) from [<c016da48>]
> (__lock_acquire+0x7c/0x18d0)
> r10:c0e0af40 r9:ef00d010 r8:c0e274cc r7:00000001 r6:600000d3 r5:c1606448
> r4:ffffe000
> [<c016d9cc>] (__lock_acquire) from [<c016fa4c>] (lock_acquire+0x70/0x90)
> r10:00000000 r9:ef007e38 r8:00000001 r7:00000001 r6:600000d3 r5:00000000
> r4:ffffe000
> [<c016f9dc>] (lock_acquire) from [<c09accc8>] (_raw_spin_lock+0x30/0x40)
> r8:600000d3 r7:ef007e10 r6:00000001 r5:ef007e10 r4:ef00d000
> [<c09acc98>] (_raw_spin_lock) from [<c04403a4>] (imx_gpcv2_irq_unmask+0x1c/0x5c)
> r4:ef00d000
> [<c0440388>] (imx_gpcv2_irq_unmask) from [<c017e838>] (irq_enable+0x38/0x4c)
> r5:00000000 r4:ef007e00
> [<c017e800>] (irq_enable) from [<c017e8d0>] (irq_startup+0x84/0x88)
> r5:00000000 r4:ef007e00
> [<c017e84c>] (irq_startup) from [<c017cd7c>] (__setup_irq+0x538/0x5f4)
> r7:ef007e60 r6:00000015 r5:ef007e00 r4:ef007d00
> [<c017c844>] (__setup_irq) from [<c017ce98>] (setup_irq+0x60/0xd0)
> r10:c0d5fa48 r9:efffcbc0 r8:ef007d00 r7:00000015 r6:ef007e10 r5:00000000
> r4:ef007e00
> [<c017ce38>] (setup_irq) from [<c0d4dfdc>] (_mxc_timer_init+0x1f8/0x248)
> r9:efffcbc0 r8:00000003 r7:016e3600 r6:c0c69bbc r5:ef007c40 r4:ef007c00
> [<c0d4dde4>] (_mxc_timer_init) from [<c0d4e0dc>] (mxc_timer_init_dt+0xb0/0xf8)
> r7:00000000 r6:c1669e48 r5:ef7ebf7c r4:ef007c00
> [<c0d4e02c>] (mxc_timer_init_dt) from [<c0d4e168>]
> (imx6dl_timer_init_dt+0x14/0x18)
> r9:efffcbc0 r8:c0e7b000 r7:c0c695c0 r6:c0d6fe18 r5:00000001 r4:ef7ebf7c
> [<c0d4e154>] (imx6dl_timer_init_dt) from [<c0d4d158>]
> (clocksource_probe+0x54/0xb0)
> [<c0d4d104>] (clocksource_probe) from [<c0d04a2c>] (time_init+0x30/0x38)
> r7:c0e07900 r6:c0e7b000 r5:ffffffff r4:00000000
> [<c0d049fc>] (time_init) from [<c0d00bc8>] (start_kernel+0x220/0x3a0)
> [<c0d009a8>] (start_kernel) from [<8000807c>] (0x8000807c)
> r10:00000000 r9:410fc075 r8:8000406a r7:c0e0c958 r6:c0d5fa44 r5:c0e07918
> r4:c0e7b294
>
> Verified the fix on a imx7d-cl-som with CONFIG_IMX_GPCV2 set.
>
> Signed-off-by: Tyler Baker <tyler.baker@linaro.org>
> Reported-by: Tyler Baker <tyler.baker@linaro.org>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Issue reported in this thread: https://lkml.org/lkml/2017/4/13/646
>
> drivers/irqchip/irq-imx-gpcv2.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
> index e13236f..9463f35 100644
> --- a/drivers/irqchip/irq-imx-gpcv2.c
> +++ b/drivers/irqchip/irq-imx-gpcv2.c
> @@ -230,6 +230,8 @@ static int __init imx_gpcv2_irqchip_init(struct device_node *node,
> return -ENOMEM;
> }
>
> + raw_spin_lock_init(&cd->rlock);
> +
> cd->gpc_base = of_iomap(node, 0);
> if (!cd->gpc_base) {
> pr_err("fsl-gpcv2: unable to map gpc registers\n");
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Thomas, any chance you could take this as a fix through the tip tree?
Thanks,
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH] irqchip/irq-imx-gpcv2: fix spinlock initialization
From: Thomas Gleixner @ 2017-04-15 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmrxpz58.fsf@on-the-bus.cambridge.arm.com>
On Sat, 15 Apr 2017, Marc Zyngier wrote:
>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
> Thomas, any chance you could take this as a fix through the tip tree?
It's in Linus tree already :)
^ permalink raw reply
* [PATCH] irqchip/irq-imx-gpcv2: fix spinlock initialization
From: Marc Zyngier @ 2017-04-15 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1704151554220.2327@nanos>
On Sat, Apr 15 2017 at 2:54:54 pm BST, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Sat, 15 Apr 2017, Marc Zyngier wrote:
>>
>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>> Thomas, any chance you could take this as a fix through the tip tree?
>
> It's in Linus tree already :)
Ah, that's how you can tell I'm on holiday... ;-)
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [patch 08/20] hwtracing/coresight-etm3x: Use the locked version of cpuhp_setup_state_nocalls()
From: Thomas Gleixner @ 2017-04-15 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170415170107.643253702@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
etm_probe() holds get_online_cpus() while invoking
cpuhp_setup_state_nocalls().
cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is
correct, but prevents the conversion of the hotplug locking to a percpu
rwsem.
Use cpuhp_setup_state_nocalls_locked() to avoid the nested call.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
---
drivers/hwtracing/coresight/coresight-etm3x.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index a51b6b64ecdf..0887265f361d 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -803,12 +803,12 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
dev_err(dev, "ETM arch init failed\n");
if (!etm_count++) {
- cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING,
- "arm/coresight:starting",
- etm_starting_cpu, etm_dying_cpu);
- ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
- "arm/coresight:online",
- etm_online_cpu, NULL);
+ cpuhp_setup_state_nocalls_locked(CPUHP_AP_ARM_CORESIGHT_STARTING,
+ "arm/coresight:starting",
+ etm_starting_cpu, etm_dying_cpu);
+ ret = cpuhp_setup_state_nocalls_locked(CPUHP_AP_ONLINE_DYN,
+ "arm/coresight:online",
+ etm_online_cpu, NULL);
if (ret < 0)
goto err_arch_supported;
hp_online = ret;
--
2.11.0
^ permalink raw reply related
* [patch 09/20] hwtracing/coresight-etm4x: Use cpuhp_setup_state_nocalls_locked()
From: Thomas Gleixner @ 2017-04-15 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170415170107.643253702@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
etm_probe4() holds get_online_cpus() while invoking
cpuhp_setup_state_nocalls().
cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is
correct, but prevents the conversion of the hotplug locking to a percpu
rwsem.
Use cpuhp_setup_state_nocalls_locked() to avoid the nested call.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
---
drivers/hwtracing/coresight/coresight-etm4x.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -990,12 +990,12 @@ static int etm4_probe(struct amba_device
dev_err(dev, "ETM arch init failed\n");
if (!etm4_count++) {
- cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING,
- "arm/coresight4:starting",
- etm4_starting_cpu, etm4_dying_cpu);
- ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
- "arm/coresight4:online",
- etm4_online_cpu, NULL);
+ cpuhp_setup_state_nocalls_locked(CPUHP_AP_ARM_CORESIGHT_STARTING,
+ "arm/coresight4:starting",
+ etm4_starting_cpu, etm4_dying_cpu);
+ ret = cpuhp_setup_state_nocalls_locked(CPUHP_AP_ONLINE_DYN,
+ "arm/coresight4:online",
+ etm4_online_cpu, NULL);
if (ret < 0)
goto err_arch_supported;
hp_online = ret;
^ permalink raw reply
* [patch 11/20] ARM/hw_breakpoint: Use cpuhp_setup_state_locked()
From: Thomas Gleixner @ 2017-04-15 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170415170107.643253702@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
arch_hw_breakpoint_init() holds get_online_cpus() while registerring the
hotplug callbacks.
cpuhp_setup_state() invokes get_online_cpus() as well. This is correct, but
prevents the conversion of the hotplug locking to a percpu rwsem.
Use cpuhp_setup_state_locked() to avoid the nested call.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/kernel/hw_breakpoint.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -1098,8 +1098,9 @@ static int __init arch_hw_breakpoint_ini
* assume that a halting debugger will leave the world in a nice state
* for us.
*/
- ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm/hw_breakpoint:online",
- dbg_reset_online, NULL);
+ ret = cpuhp_setup_state_locked(CPUHP_AP_ONLINE_DYN,
+ "arm/hw_breakpoint:online",
+ dbg_reset_online, NULL);
unregister_undef_hook(&debug_reg_hook);
if (WARN_ON(ret < 0) || !cpumask_empty(&debug_err_mask)) {
core_num_brps = 0;
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Sebastian Reichel @ 2017-04-15 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413150353.7389-2-robh@kernel.org>
Hi,
On Thu, Apr 13, 2017 at 10:03:50AM -0500, Rob Herring wrote:
> Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
> devices.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: netdev at vger.kernel.org
> Cc: devicetree at vger.kernel.org
> ---
> v3:
> - rebase on bluetooth-next
>
> .../devicetree/bindings/net/ti,wilink-st.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> new file mode 100644
> index 000000000000..cbad73a84ac4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -0,0 +1,35 @@
> +TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
> +
> +TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
> +and GPS over what's called "shared transport". The shared transport is
> +standard BT HCI protocol with additional channels for the other functions.
> +
> +These devices also have a separate WiFi interface as described in
> +wireless/ti,wlcore.txt.
> +
> +This bindings follows the UART slave device binding in
> +../serial/slave-device.txt.
> +
> +Required properties:
> + - compatible: should be one of the following:
> + "ti,wl1271-st"
> + "ti,wl1273-st"
> + "ti,wl1831-st"
> + "ti,wl1835-st"
> + "ti,wl1837-st"
> +
> +Optional properties:
> + - enable-gpios : GPIO signal controlling enabling of BT. Active high.
> + - vio-supply : Vio input supply (1.8V)
> + - vbat-supply : Vbat input supply (2.9-4.8V)
> +
> +Example:
> +
> +&serial0 {
> + compatible = "ns16550a";
> + ...
> + bluetooth {
> + compatible = "ti,wl1835-st";
> + enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> + };
> +};
Reviewed-by: Sebastian Reichel <sre@kernel.org>
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170415/5a3a5a04/attachment.sig>
^ 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