* [PATCH v5 1/9] Documentation: dt-bindings: Document STM32 EXTI controller bindings
From: Rob Herring @ 2016-09-19 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473432124-6784-2-git-send-email-alexandre.torgue@st.com>
On Fri, Sep 09, 2016 at 04:41:56PM +0200, Alexandre TORGUE wrote:
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v15 5/5] ASoC: rockchip: Add DP dai-links to the rk3399-gru machine driver
From: Rob Herring @ 2016-09-19 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473473748-22331-6-git-send-email-zyw@rock-chips.com>
On Fri, Sep 09, 2016 at 07:15:48PM -0700, Chris Zhong wrote:
> This patch adds DP audio output support to the rk3399-gru machine
> driver.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> ---
>
> Changes in v15: None
> Changes in v14: None
> Changes in v13: None
> Changes in v12: None
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - change spdif to i2s2
>
> Changes in v2:
> - correct the commit message
>
> Changes in v1: None
>
> .../bindings/sound/rockchip,rk3399-gru-sound.txt | 11 +--
> sound/soc/rockchip/rk3399_gru_sound.c | 93 ++++++++++++++++++++++
> 2 files changed, 99 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> index f19b6c8..83af540 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
> @@ -1,15 +1,16 @@
> -ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
> +ROCKCHIP with MAX98357A/RT5514/DA7219 codecs and DP via spdif on GRU boards
>
> Required properties:
> - compatible: "rockchip,rk3399-gru-sound"
> -- rockchip,cpu: The phandle of the Rockchip I2S controller that's
> +- rockchip,cpu: The phandle of the Rockchip I2S controller controller that's
Huh?
^ permalink raw reply
* [PATCH] of: Add vendor prefix for Aries Embedded GmbH
From: Marek Vasut @ 2016-09-19 21:38 UTC (permalink / raw)
To: linux-arm-kernel
Add vendor prefix for Aries Embedded GmbH
http://www.aries-embedded.de/
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 69caf14..522dd65 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -27,6 +27,7 @@ analogix Analogix Semiconductor, Inc.
apm Applied Micro Circuits Corporation (APM)
aptina Aptina Imaging
arasan Arasan Chip Systems
+aries Aries Embedded GmbH
arm ARM Ltd.
armadeus ARMadeus Systems SARL
arrow Arrow Electronics
--
2.9.3
^ permalink raw reply related
* [PATCH] arm: migrate exception table users off module.h and onto extable.h
From: Paul Gortmaker @ 2016-09-19 21:38 UTC (permalink / raw)
To: linux-arm-kernel
These files were only including module.h for exception table
related functions. We've now separated that content out into its
own file "extable.h" so now move over to that and avoid all the
extra header content in module.h that we don't really need to compile
these files.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[see: https://lkml.org/lkml/2016/7/24/224 for additional context if needed]
arch/arm/mm/extable.c | 2 +-
arch/arm/mm/fault.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/extable.c b/arch/arm/mm/extable.c
index 312e15e6d00b..f436f7439e46 100644
--- a/arch/arm/mm/extable.c
+++ b/arch/arm/mm/extable.c
@@ -1,7 +1,7 @@
/*
* linux/arch/arm/mm/extable.c
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/uaccess.h>
int fixup_exception(struct pt_regs *regs)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 3a2e678b8d30..94de590db99e 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -8,7 +8,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/signal.h>
#include <linux/mm.h>
#include <linux/hardirq.h>
--
2.8.4
^ permalink raw reply related
* [PATCH] arm64: migrate exception table users off module.h and onto extable.h
From: Paul Gortmaker @ 2016-09-19 21:38 UTC (permalink / raw)
To: linux-arm-kernel
These files were only including module.h for exception table
related functions. We've now separated that content out into its
own file "extable.h" so now move over to that and avoid all the
extra header content in module.h that we don't really need to compile
these files.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[see: https://lkml.org/lkml/2016/7/24/224 for additional context if needed]
arch/arm64/kernel/probes/kprobes.c | 2 +-
arch/arm64/mm/extable.c | 2 +-
arch/arm64/mm/fault.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index bf9768588288..9c1866ef3271 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -19,7 +19,7 @@
#include <linux/kasan.h>
#include <linux/kernel.h>
#include <linux/kprobes.h>
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/slab.h>
#include <linux/stop_machine.h>
#include <linux/stringify.h>
diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c
index 81acd4706878..c9f118cd812b 100644
--- a/arch/arm64/mm/extable.c
+++ b/arch/arm64/mm/extable.c
@@ -2,7 +2,7 @@
* Based on arch/arm/mm/extable.c
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/uaccess.h>
int fixup_exception(struct pt_regs *regs)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index c8beaa0da7df..427f2fd49463 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -18,7 +18,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#include <linux/module.h>
+#include <linux/extable.h>
#include <linux/signal.h>
#include <linux/mm.h>
#include <linux/hardirq.h>
--
2.8.4
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: mxs: Add new M28EVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx28-m28.dtsi | 4 ++--
arch/arm/boot/dts/imx28-m28evk.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
index 214bb15..a69856e 100644
--- a/arch/arm/boot/dts/imx28-m28.dtsi
+++ b/arch/arm/boot/dts/imx28-m28.dtsi
@@ -12,8 +12,8 @@
#include "imx28.dtsi"
/ {
- model = "DENX M28";
- compatible = "denx,m28", "fsl,imx28";
+ model = "Aries/DENX M28";
+ compatible = "aries,m28", "denx,m28", "fsl,imx28";
memory {
reg = <0x40000000 0x08000000>;
diff --git a/arch/arm/boot/dts/imx28-m28evk.dts b/arch/arm/boot/dts/imx28-m28evk.dts
index 8d04e57..dbfb8aa 100644
--- a/arch/arm/boot/dts/imx28-m28evk.dts
+++ b/arch/arm/boot/dts/imx28-m28evk.dts
@@ -13,8 +13,8 @@
#include "imx28-m28.dtsi"
/ {
- model = "DENX M28EVK";
- compatible = "denx,m28evk", "fsl,imx28";
+ model = "Aries/DENX M28EVK";
+ compatible = "aries,m28evk", "denx,m28evk", "fsl,imx28";
apb at 80000000 {
apbh at 80000000 {
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: mx5: Add new M53EVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx53-m53.dtsi | 4 ++--
arch/arm/boot/dts/imx53-m53evk.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-m53.dtsi b/arch/arm/boot/dts/imx53-m53.dtsi
index d259f57..ec390aa5 100644
--- a/arch/arm/boot/dts/imx53-m53.dtsi
+++ b/arch/arm/boot/dts/imx53-m53.dtsi
@@ -12,8 +12,8 @@
#include "imx53.dtsi"
/ {
- model = "DENX M53";
- compatible = "denx,imx53-m53", "fsl,imx53";
+ model = "Aries/DENX M53";
+ compatible = "aries,imx53-m53", "denx,imx53-m53", "fsl,imx53";
memory {
reg = <0x70000000 0x20000000>,
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts
index dcee1e0f..4347a32 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -13,8 +13,8 @@
#include "imx53-m53.dtsi"
/ {
- model = "DENX M53EVK";
- compatible = "denx,imx53-m53evk", "fsl,imx53";
+ model = "Aries/DENX M53EVK";
+ compatible = "aries,imx53-m53evk", "denx,imx53-m53evk", "fsl,imx53";
display1: display at di1 {
compatible = "fsl,imx-parallel-display";
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: socfpga: Add new MCVEVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
---
arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi b/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi
index f86f9c0..6ad3b1e 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5_mcv.dtsi
@@ -18,7 +18,7 @@
#include "socfpga_cyclone5.dtsi"
/ {
- model = "DENX MCV";
+ model = "Aries/DENX MCV";
compatible = "altr,socfpga-cyclone5", "altr,socfpga";
memory {
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
index caa40cf..8882314 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
@@ -18,7 +18,7 @@
#include "socfpga_cyclone5_mcv.dtsi"
/ {
- model = "DENX MCV EVK";
+ model = "Aries/DENX MCV EVK";
compatible = "altr,socfpga-cyclone5", "altr,socfpga";
aliases {
--
2.9.3
^ permalink raw reply related
* [PATCH 4/4] ARM: at91/dt: sama5d4: Add new MA5D4EVK manufacturer compat
From: Marek Vasut @ 2016-09-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919214044.9615-1-marex@denx.de>
The board is now manufactured by Aries Embedded GmbH, update compat string.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 ++--
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi b/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi
index 7c75872..b40dd9f 100644
--- a/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi
+++ b/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi
@@ -12,8 +12,8 @@
#include "sama5d4.dtsi"
/ {
- model = "DENX MA5D4";
- compatible = "denx,ma5d4", "atmel,sama5d4", "atmel,sama5";
+ model = "Aries/DENX MA5D4";
+ compatible = "aries,ma5d4", "denx,ma5d4", "atmel,sama5d4", "atmel,sama5";
memory {
reg = <0x20000000 0x10000000>;
diff --git a/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts b/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
index a52f520..d4ebd90 100644
--- a/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
@@ -13,8 +13,8 @@
#include "at91-sama5d4_ma5d4.dtsi"
/ {
- model = "DENX MA5D4EVK";
- compatible = "denx,ma5d4evk", "atmel,sama5d4", "atmel,sama5";
+ model = "Aries/DENX MA5D4EVK";
+ compatible = "aries,ma5d4evk", "denx,ma5d4evk", "atmel,sama5d4", "atmel,sama5";
chosen {
stdout-path = "serial3:115200n8";
--
2.9.3
^ permalink raw reply related
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmzqbilu.fsf@free-electrons.com>
On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
> mvebu soc for 4.9 (part 1)
>
> - irq cleanup for old mvebu SoC
> - Convert orion5x based SoC Netgear WNR854T to devicetree
>
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21718559.viYP8Vn8qc@wuerfel>
On Monday, September 19, 2016 11:46:22 PM CEST Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
> > mvebu soc for 4.9 (part 1)
> >
> > - irq cleanup for old mvebu SoC
> > - Convert orion5x based SoC Netgear WNR854T to devicetree
> >
>
> Pulled into next/soc, thanks!
Sorry, backed out again after seeing the PCI stuff on the WNR854T in
there. I thought the plan was to leave out PCI support from the DT
based machine file, and leave the old board in place, or am I
missing something?
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm EBI2 bindings and bus driver
From: Arnd Bergmann @ 2016-09-19 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYvowN2htUuN46JNVdfaKNw3AEbBfzAeScHQcLU5o3ZUg@mail.gmail.com>
On Thursday, September 8, 2016 3:34:42 PM CEST Linus Walleij wrote:
> please pull this new EBI2 bus driver and its bindings into an
> apropriate branch in the ARM SoC tree. The binding now has
> Rob Herrings ACK and we have hopefully finally figured out how
> this should be done.
>
I just noticed that you sent the pull request directly to arm at kernel.org
rather than the Qualcomm maintainers (which are only on Cc).
Usually, I'd expect to see this forwarded from Andy, is there a
reason to do it differently here? If so, can I have an Ack
from him?
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: drivers for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8fabikx.fsf@free-electrons.com>
On Wednesday, September 14, 2016 5:35:10 PM CEST Gregory CLEMENT wrote:
> mvebu drivers for 4.9 (part 1)
>
> - Add pinctrl and clk support for the Orion5x SoC mv88f5181 variant
>
> ----------------------------------------------------------------
> Jamie Lentin (2):
> clk: mvebu: Add clk support for the orion5x SoC mv88f5181
> pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
>
> .../devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
> .../bindings/pinctrl/marvell,orion-pinctrl.txt | 4 +-
> drivers/clk/mvebu/orion.c | 70 ++++++++++++++++++++++
> drivers/pinctrl/mvebu/pinctrl-orion.c | 23 +++----
> 4 files changed, 86 insertions(+), 12 deletions(-)
I see this touches pinctrl and clk drivers, but none of the maintainers are
on Cc for this pull request, nor have they provided an Ack for the patches
according to your git log.
Why did you not send the driver changes to them?
Not pulled for now, until this is resolved, sorry.
Arnd
^ permalink raw reply
* [PATCH] MAINTAINERS: update list of Oxnas maintainers
From: Arnd Bergmann @ 2016-09-19 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916080917.19162-1-narmstrong@baylibre.com>
On Friday, September 16, 2016 10:09:17 AM CEST Neil Armstrong wrote:
> Add a new list address in the MAINTAINERS file for the Oxnas platform.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Applied to next/soc, thanks!
When you send a single patch to be applied, please try to be specific
about who you send it to, and put only the recipient (arm at kernel.org here)
on "To:", while the mailing lists and any other people should all be on
Cc.
Arnd
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Jason Wessel @ 2016-09-19 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916074513.GI3380@arm.com>
On 09/16/2016 02:45 AM, Will Deacon wrote:
> On Fri, Sep 16, 2016 at 01:32:19PM +0900, AKASHI Takahiro wrote:
>> On Thu, Sep 15, 2016 at 08:04:57AM -0500, Jason Wessel wrote:
>>> I added the patch to kgdb-next after fixing up the context since it no
>>> longer applied to the mainline (
>>> https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/log/?h=kgdb-next).
>>> If there is further discussion on the point above, another patch can be
>>> added, but it I am assuming this is the way you desire it to work as
>>> there are some other architectures that use the same behaviour. I do
>>> not presently have any ARM64 hardware to validate this particular
>>> change.
>>>
>>> I also added to the patch a "Cc: linux-stable <stable@vger.kernel.org>"
>>> so we can have this appear on some of the older kernels.
>> Since Will asked me to split this patch into a few, I need some reworks
>> to clarify which hunks in the patch are necessary for which version of kernel.
> Yes, splitting the patch would be much better for sorting out the stable
> backports too. Jason, please can you drop the patch for now? I don't mind
> whether the end result goes via arm64 or kgdb, but we should at least both
> agree on it first :)
Splitting it is a very wise idea so that we can have all the -stable kernels patched up with a working single step function.
The separated patches can easily be tagged with the CC line examples as shown below:
Cc: <stable@vger.kernel.org> # 3.15.x-
Cc: <stable@vger.kernel.org> # 4.4
Cc: <stable@vger.kernel.org> # 4.4-4.5
I had dropped the original patch.
Cheers,
Jason.
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Jason Wessel @ 2016-09-19 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916043218.GA30248@linaro.org>
On 09/15/2016 11:32 PM, AKASHI Takahiro wrote:
> @@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
>>> * over and over again.
>>> */
>>> kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
>>> - atomic_set(&kgdb_cpu_doing_single_step, -1);
>>> - kgdb_single_step = 0;
>>
>> This is a subtle change, but I assume it is what you intended? All the CPUs will get released into the run state when exiting the kgdb exception handler.
> You are talking about "- kgdb_single_step = 0." Right?
Correct.
> Do you think that there is any (negative) side effect of this change?
Not at all. The kernel debugger always skids to a stop, and it is more reliable from a locking perspective if the other CPU threads are released while a single CPU is asked to single step until the next "skid" for all the other CPUs.
When you do not release the other CPUs you can end up single stepping a CPU which dead locks or never exits a lock elsewhere due to what ever it was blocking on never getting freed from another CPU.
Cheers,
Jason.
^ permalink raw reply
* [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for 4.9
From: Duc Dang @ 2016-09-19 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369836.4ELrYOmq06@wuerfel>
On Mon, Sep 19, 2016 at 1:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Friday, September 16, 2016 12:01:28 AM CEST Duc Dang wrote:
> > This is the DTS changes for X-Gene platforms targeted for 4.9.
> >
> > The changes include:
> > + X-Gene Soc PMU DTS entry from X-Gene PMU patch set of Tai Nguyen [1]
> > + Follow up patch to enable DTS entry for SoC PMU on X-Gene v2
> > + Correct PCIe legacy interrupt mode to level-active high
> > + DTS entry for X-Gene hwmon (v4 acked by Guenter, DT binding document
> > and driver is in linux-next now [2])
> > + DTS entries for X-Gene v2 CPU clock from X-Gene PMD clock patch set
> > (v3 already accepted by Stephen into clk-next [3])
> >
> >
>
> Pulled into next/dt64, thanks!
Thanks, Arnd.
>
> Arnd
>
Regards,
Duc Dang.
^ permalink raw reply
* [GIT PULL] Qualcomm EBI2 bindings and bus driver
From: Andy Gross @ 2016-09-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4360974.U0qvolVKdi@wuerfel>
On Tue, Sep 20, 2016 at 12:12:33AM +0200, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 3:34:42 PM CEST Linus Walleij wrote:
> > please pull this new EBI2 bus driver and its bindings into an
> > apropriate branch in the ARM SoC tree. The binding now has
> > Rob Herrings ACK and we have hopefully finally figured out how
> > this should be done.
> >
>
> I just noticed that you sent the pull request directly to arm at kernel.org
> rather than the Qualcomm maintainers (which are only on Cc).
>
> Usually, I'd expect to see this forwarded from Andy, is there a
> reason to do it differently here? If so, can I have an Ack
> from him?
When I looked at this last, I thought there were comments. Sorry I missed it.
If you want to pick it up Arnd, please do, otherwise I can send it along in the
next pull request.
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Russell King - ARM Linux @ 2016-09-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919200816.GC29242@roeck-us.net>
On Mon, Sep 19, 2016 at 01:08:16PM -0700, Guenter Roeck wrote:
> On Mon, Sep 19, 2016 at 09:12:14PM +0200, Robert Jarzmik wrote:
> > The OS timer rate used for the watchdog can now be fetched from the
> > standard clock API. This will remove the last user of
> > get_clock_tick_rate() in both pxa and sa11x0 architectures.
> >
> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>
> Did you test this ? Potential problem, if built into the kernel, could be that
> the clocks might not be ready by the time the driver is instantiated. Unless
> this is converted to a platform driver, it won't be able to handle a
> -EPROBE_DEFER from the clock subsystem.
Really not a problem at all. The OSTIMER0 is required for the system
tick, and if that's not present, the kernel will be without any kind
of time keeping, so a missing watchdog driver is the least of the
problems.
Therefore, both PXA and SA11x0 register their clocks really early to
ensure that OSTIMER0 is available by the time_init() stage, which is
way before driver probe time.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH V5] perf tools: adding support for address filters
From: Masami Hiramatsu @ 2016-09-19 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <008718a0-13bf-8245-e2ee-562cffeba3c5@intel.com>
On Mon, 19 Sep 2016 09:15:40 +0300
Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 17/09/16 16:33, Masami Hiramatsu wrote:
> > On Fri, 16 Sep 2016 09:32:43 -0600
> > Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> >> On 13 September 2016 at 17:25, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >>> On Tue, 13 Sep 2016 08:18:10 -0600
> >>> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >>>
> >>>> On 13 September 2016 at 04:01, Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>>>> On 12/09/16 20:53, Mathieu Poirier wrote:
> >>>>>> This patch makes it possible to use the current filter
> >>>>>> framework with address filters. That way address filters for
> >>>>>> HW tracers such as CoreSight and IntelPT can be communicated
> >>>>>> to the kernel drivers.
> >>>>>>
> >>>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> >>>>>>
> >>>>>> ---
> >>>>>> Changes for V5:
> >>>>>> - Modified perf_evsel__append_filter() to take a string format
> >>>>>> rather than an operation.
> >>>>>
> >>>>> Hope I'm not being a pain, but aren't there other places calling
> >>>>> perf_evsel__append_filter() that need to be changed. Might make
> >>>>> sense as a separate patch.
> >>>>
> >>>> No no, you're right - I completely overlooked that.
> >>>>
> >>>> But shouldn't it be in the same patch? That way a git bisect would
> >>>> stay consistent...
> >>>
> >>> You're right. Caller and callee should be changed in atomic.
> >>>
> >>> BTW, could you add document updates how the perf command line
> >>> will be changed, and also show the result in the patch description?
> >>
> >> This patch does not change anything on the perf command line. It
> >> simply allows current options to succeed (as they should) rather than
> >> fail.
> >
> > Yes, and it will make perf acceptable to pass --filter to CoreSight or
> > Intel PT events, or am I misunderstand?
> > If it is correct, could you give us an example how to pass it, since
> > tools/perf/Documentation/perf-record.txt says it is only for tracepoints?
>
> I am adding support for symbols in the address filter. I will send the
> patches soon, but the documentation will be:
>
> --filter=<filter>::
> Event filter. This option should follow a event selector (-e) which
> selects either tracepoint event(s) or a hardware trace PMU
> (e.g. Intel PT or CoreSight).
>
> - tracepoint filters
>
> In the case of tracepoints, multiple '--filter' options are combined
> using '&&'.
>
> - address filters
>
> A hardware trace PMU advertises its ability to accept a number of
> address filters by specifying a non-zero value in
> /sys/bus/event_source/devices/<pmu>/nr_addr_filters.
>
> Address filters have the format:
>
> filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
>
> Where:
> - 'filter': defines a region that will be traced.
> - 'start': defines an address at which tracing will begin.
> - 'stop': defines an address at which tracing will stop.
> - 'tracestop': defines a region in which tracing will stop.
>
> <file name> is the name of the object file, <start> is the offset to the
> code to trace in that file, and <size> is the size of the region to
> trace. 'start' and 'stop' filters need not specify a <size>.
>
> If no object file is specified then the kernel is assumed, in which case
> the start address must be a current kernel memory address.
>
> <start> can also be specified by providing the name of a symbol. If the
> symbol name is not unique, it can be disambiguated by inserting #n where
> 'n' selects the n'th symbol in address order. Alternately #0, #g or #G
> select only a global symbol. <size> can also be specified by providing
> the name of a symbol, in which case the size is calculated to the end
> of that symbol. For 'filter' and 'tracestop' filters, if <size> is
> omitted and <start> is a symbol, then the size is calculated to the end
> of that symbol.
>
> If <size> is omitted and <start> is '*', then the start and size will
> be calculated from the first and last symbols, i.e. to trace the whole
> file.
>
> If symbol names (or "*") are provided, they must be surrounded by white
> space.
>
> The filter passed to the kernel is not necessarily the same as entered.
> To see the filter that is passed, use the -v option.
>
> The kernel may not be able to configure a trace region if it is not
> within a single mapping. MMAP events (or /proc/<pid>/maps) can be
> examined to determine if that is a possibility.
>
> Multiple filters can be separated with space or comma.
Perfect! :)
OK, I'll wait your patch.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: Add power button support for igepv5
From: Tony Lindgren @ 2016-09-19 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMVEqEkKrw2eH3L6+te5MZLqxBT2jUiRO-KNuS+9nuNYvihCRA@mail.gmail.com>
* Pau Pajuel <ppajuel@gmail.com> [160919 01:13]:
> Hello Tony,
>
> 2016-09-14 3:26 GMT+02:00 Javier Martinez Canillas <javier@osg.samsung.com>:
> > Hello Tony,
> >
> > On 09/09/2016 05:07 PM, Tony Lindgren wrote:
> >> Add power button support for igepv5.
> >>
> >> Cc: Agust? Fontquerni i Gorchs <afontquerni@iseebcn.com>
> >> Cc: Enric Balletbo Serra <eballetbo@gmail.com>
> >> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >> Cc: Pau Pajuel <ppajuel@gmail.com>
> >> Signed-off-by: Tony Lindgren <tony@atomide.com>
> >> ---
> >
> > I don't have a schematics for this board, but the patch looks good to me.
> Patch has an errata. Power button is GPIO_ACTIVE_LOW instead GPIO_ACTIVE_HIGH.
Oops sorry about that, here's an incremental fix.
Regards,
Tony
8< -----------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 19 Sep 2016 16:02:12 -0700
Subject: [PATCH] ARM: dts: Fix igepv5 power button GPIO direction
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It should be GPIO_ACTIVE_LOW instead of GPIO_ACTIVE_HIGH as
pointed out by Pau Pajuel <ppajuel@gmail.com>.
Cc: Agust? Fontquerni i Gorchs <afontquerni@iseebcn.com>
Cc: Enric Balletbo Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Pau Pajuel <ppajuel@gmail.com>
Fixes: b118c6a6ffa1 ("ARM: dts: Add power button support for igepv5")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap5-igep0050.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-igep0050.dts b/arch/arm/boot/dts/omap5-igep0050.dts
--- a/arch/arm/boot/dts/omap5-igep0050.dts
+++ b/arch/arm/boot/dts/omap5-igep0050.dts
@@ -27,7 +27,7 @@
power-button {
label = "Power Button";
linux,code = <KEY_POWER>;
- gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+ gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
};
};
--
2.9.3
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Brian Norris @ 2016-09-19 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBA81F.2060404@arm.com>
On Fri, Sep 16, 2016 at 09:06:55AM +0100, Marc Zyngier wrote:
> Hi Brian,
Hi Marc,
Thanks for the quick response.
> On 16/09/16 06:49, Brian Norris wrote:
> > Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
> > for suspend timekeeping"), this driver assumes that the ARM architected
> > timer keeps running in suspend. This is not the case for some ARM SoCs,
> > depending on the HW state used for system suspend. Let's not assume that
> > all SoCs support this, and instead only support this if the device tree
> > explicitly tells us it's "always on". In all other cases, just fall back
> > to the RTC. This should be relatively harmless.
>
> I'm afraid you're confusing two things:
> - the counter, which *must* carry on counting no matter what, as
> (quoting the ARM ARM) "The system counter must be implemented in an
> always-on power domain"
> - the timer, which is allowed to be powered off, and can be tagged with
> the "always-on" property to indicate that it is guaranteed to stay up
> (which in practice only exists in virtual machines and never on real HW).
Indeed, sorry for that confusion, and thanks for the explanations.
> If your counter does stop counting when suspended, then this is starting
> to either feel like a HW bug, or someone is killing the clock that feeds
> this counter when entering suspend.
>
> If this is the former, then we need a separate quirk to indicate the
> non-standard behaviour. If it is the latter, don't do it! ;-)
It's beginning to seem more like a HW quirk which yields nonstandard
behavior. AIUI, this SoC normally runs the counter off its 24 MHz clock,
but for low power modes, this "always-on" domain switches over to a 32
KHz alternative clock. Unfortunately, the counter doesn't actually tick
when run this way. I'm trying to confirm with the chip designers
(Rockchip, RK3399) about the nature of the quirk, but I think we'll need
a separate DT flag for this behavior.
Brian
^ permalink raw reply
* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473081421-16555-18-git-send-email-peter.griffin@linaro.org>
On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.
Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.
Is there something that requires such a different/unusual behaviour in
remoteproc ?
Regards,
Emil
^ permalink raw reply
* linux-next: manual merge of the amlogic tree with the arm-soc tree
From: Stephen Rothwell @ 2016-09-20 0:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the amlogic tree got a conflict in:
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
between commit:
8735053d7968 ("ARM64: dts: meson-gxbb-p20x: Enable USB Nodes")
from the arm-soc tree and commit:
d82801a385a1 ("ARM64: dts: meson-gxbb-p20x: Enable USB Nodes")
from the amlogic tree.
This patch was modified before being merged into the arm-soc tree.
Please clean up the amlogic tree.
I fixed it up (I used the arm-soc tree version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH v2 3/7] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
From: Tomasz Figa @ 2016-09-20 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57CD27FC.2020201@samsung.com>
Hi Chanwoo,
Sorry for late reply. Yours was quick compared to mine. ;(
2016-09-05 17:08 GMT+09:00 Chanwoo Choi <cw00.choi@samsung.com>:
> Hi Tomasz,
>
> I'm sorry for late reply.
>
> On 2016? 08? 25? 23:41, Tomasz Figa wrote:
>> 2016-08-25 23:30 GMT+09:00 Tomasz Figa <tomasz.figa@gmail.com>:
>>>> + }
>>>> +
>>>> +#define EXYNOS_PIN_BANK_EINTN_EXT(pins, reg, id, pctl_idx, eint_idx) \
>>>> + { \
>>>> + .type = &bank_type_off, \
>>>> + .pctl_offset = reg, \
>>>> + .nr_pins = pins, \
>>>> + .eint_type = EINT_TYPE_NONE, \
>>>> + .name = id, \
>>>> + .pctl_res_idx = pctl_idx, \
>>>> + .eint_res_idx = eint_dix \
>>>> + }
>>>
>>> Your patch 4/7 doesn't seem to use this one, so this is dead code for
>>> the time being. Please add when there is real need for it.
>>>
>>> Also it doesn't really make much sense to have index for both pctl and
>>> eint. Please define first entry of regs property as always pointing to
>>> pctl registers and by also eint registers for usual controllers. Then
>>> second regs entry would be eint registers for controllers with
>>> separate register blocks. Then there is only a need to have
>>> eint_res_idx in the driver and no need for pctl_res_idx, because it
>>> would be always 0.
>>
>> Ah, sorry, I got confused again by which registers are where in these
>> GPF banks. Let's make it the other way around and make DT contain eint
>> registers in first regs entry and hardcode eint_res_idx to 0 for the
>> time being.
>
> I got with slight confusion.
> Do you mean that you want to remove the 'eint_res_idx' because
> it is always zero(0) as your comment. And do you agree to add 'pctl_res_idx'?
>
> Also, as you commented, the eint_res_idx for both GPA and GPFx is zero(0).
>
> Example:
> pinctrl_alive: pinctrl at 10580000 {
> compatible = "samsung,exynos5433-pinctrl";
> /* ALIVE domain , IMEM domain */
> reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
>
> wakeup-interrupt-controller {
> compatible = "samsung,exynos7-wakeup-eint";
> interrupts = <GIC_SPI 16 0>;
> };
> };
>
> GPA's eint_res_idx is 0
> GPA's pctl_res_idx is 0
>
> GPFx's eint_res_idx is 0
> GPFx's pctl_res_idx is 1
Yeah, that's right. I just want to avoid adding eint_res_idx until it
is found to be really needed.
>
>
> However it should be still beneficial to refactor the code
>> and calculate per-bank eint_base to avoid adding the offset every
>> time, similarly to pctl_base/offset, from my suggestion below.
>
> I agree. I'll modify it according to your comment.
Thanks. Looking forward to the patch.
Best regards,
Tomasz
^ 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