* [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Alexandre Belloni @ 2016-11-14 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-2-git-send-email-sudeep.holla@arm.com>
On 14/11/2016 at 15:44:08 +0000, Sudeep Holla wrote :
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: add missing options for systemd
From: Sekhar Nori @ 2016-11-14 16:01 UTC (permalink / raw)
To: linux-arm-kernel
Some kernel configuration options required for systemd
support are missing in davinci_all_defconfig. Add them.
This is based on recommendations in:
http://cgit.freedesktop.org/systemd/systemd/tree/README
Options which kernel enables by default (and will thus be removed
upon next savedefconfig update) are not included.
Tested on OMAP-L138 LCDK board with fully up to date armv5
archlinux filesystem.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/configs/davinci_all_defconfig | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978ff177f..bdc62e69807a 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -7,13 +7,13 @@ CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CGROUPS=y
+CONFIG_CHECKPOINT_RESTORE=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
@@ -34,6 +34,7 @@ CONFIG_DAVINCI_MUX_WARNINGS=y
CONFIG_DAVINCI_RESET_CLOCKS=y
CONFIG_PREEMPT=y
CONFIG_AEABI=y
+CONFIG_SECCOMP=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
@@ -52,7 +53,6 @@ CONFIG_INET=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_NETFILTER=y
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_FW_LOADER is not set
@@ -189,11 +189,13 @@ CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
+CONFIG_TMPFS_XATTR=y
CONFIG_JFFS2_FS=m
CONFIG_UBIFS_FS=m
CONFIG_CRAMFS=y
--
2.9.0
^ permalink raw reply related
* [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Joerg Roedel @ 2016-11-14 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy@arm.com>
On Mon, Nov 14, 2016 at 12:16:26PM +0000, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, these can both be standalone callback implementations without
> the need for arch code wrappers.
>
> CC: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> v4: Add the missed static qualifier (thanks Catalin)
>
> drivers/iommu/dma-iommu.c | 24 +++++++++++++++++++++---
> include/linux/dma-iommu.h | 4 ++++
> 2 files changed, 25 insertions(+), 3 deletions(-)
Applied both, thanks Robin.
^ permalink raw reply
* [PATCH V7 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Steven Rostedt @ 2016-11-14 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG2=9p_SKF4TAbbqF6L4u=y9-_m73vZJ3tOAbRKHCT0MOsLwGQ@mail.gmail.com>
On Fri, 21 Oct 2016 20:13:13 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 18 October 2016 at 23:44, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Tue, 18 Oct 2016 16:08:58 +0800
> > Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> >
> >> Currently Function traces can be only exported to ring buffer, this
> >> patch added trace_export concept which can process traces and export
> >> them to a registered destination as an addition to the current only
> >> one output of Ftrace - i.e. ring buffer.
> >>
> >> In this way, if we want Function traces to be sent to other destination
> >> rather than ring buffer only, we just need to register a new trace_export
> >> and implement its own .write() function for writing traces to storage.
> >>
> >> With this patch, only Function trace (trace type is TRACE_FN)
> >> is supported.
> >
> > This is getting better, but I still have some nits.
> >
>
> Thanks.
>
> >>
> >> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
> >> ---
> >> include/linux/trace.h | 28 +++++++++++
> >> kernel/trace/trace.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++-
> >> 2 files changed, 159 insertions(+), 1 deletion(-)
> >> create mode 100644 include/linux/trace.h
> >>
> >> diff --git a/include/linux/trace.h b/include/linux/trace.h
> >> new file mode 100644
> >> index 0000000..eb1c5b8
> >> --- /dev/null
> >> +++ b/include/linux/trace.h
> >> @@ -0,0 +1,28 @@
> >> +#ifndef _LINUX_TRACE_H
> >> +#define _LINUX_TRACE_H
> >> +
> >> +#ifdef CONFIG_TRACING
> >> +/*
> >> + * The trace export - an export of Ftrace output. The trace_export
> >> + * can process traces and export them to a registered destination as
> >> + * an addition to the current only output of Ftrace - i.e. ring buffer.
> >> + *
> >> + * If you want traces to be sent to some other place rather than ring
> >> + * buffer only, just need to register a new trace_export and implement
> >> + * its own .write() function for writing traces to the storage.
> >> + *
> >> + * next - pointer to the next trace_export
> >> + * write - copy traces which have been delt with ->commit() to
> >> + * the destination
> >> + */
> >> +struct trace_export {
> >> + struct trace_export __rcu *next;
> >> + void (*write)(const char *, unsigned int);
> >
> > Why const char*? Why not const void *? This will never be a string.
> >
>
> Will revise this.
>
> >
> >> +};
> >> +
> >> +int register_ftrace_export(struct trace_export *export);
> >> +int unregister_ftrace_export(struct trace_export *export);
> >> +
> >> +#endif /* CONFIG_TRACING */
> >> +
> >> +#endif /* _LINUX_TRACE_H */
> >> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> >> index 8696ce6..db94ec1 100644
> >> --- a/kernel/trace/trace.c
> >> +++ b/kernel/trace/trace.c
> >> @@ -40,6 +40,7 @@
> >> #include <linux/poll.h>
> >> #include <linux/nmi.h>
> >> #include <linux/fs.h>
> >> +#include <linux/trace.h>
> >> #include <linux/sched/rt.h>
> >>
> >> #include "trace.h"
> >> @@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
> >> ftrace_trace_userstack(buffer, flags, pc);
> >> }
> >>
> >> +static void
> >> +trace_process_export(struct trace_export *export,
> >> + struct ring_buffer_event *event)
> >> +{
> >> + struct trace_entry *entry;
> >> + unsigned int size = 0;
> >> +
> >> + entry = ring_buffer_event_data(event);
> >> +
> >> + size = ring_buffer_event_length(event);
> >> +
> >> + if (export->write)
> >> + export->write((char *)entry, size);
> >
> > Is there ever going to be a time where export->write wont be set?
>
> There hasn't been since only one trace_export (i.e. stm_ftrace) was
> added in this patch-set , I just wanted to make sure the write() has
> been set before registering trace_export like what I added in 2/3 of
> this series.
>
> >
> > And if there is, this can be racy. As in
> >
> >
> > CPU 0: CPU 1:
> > ------ ------
> > if (export->write)
> >
> > export->write = NULL;
>
> Is there going to be this kind of use case? Why some one needs to
> change export->write() rather than register a new trace_export?
Then why have a
if (export->write)
Is there every going to be a case where export will not have a write
function?
-- Steve
>
> I probably haven't understood your point thoroughly, please correct me
> if my guess was wrong.
>
>
> Thanks for the review,
> Chunyan
>
> >
> > export->write(entry, size);
> >
> > BOOM!
> >
> >
> > -- Steve
^ permalink raw reply
* [PATCH v2 03/11] ARM: shmobile: r8a7745: basic SoC support
From: Rob Herring @ 2016-11-14 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1611958.qRQu5pdJd3@wasted.cogentembedded.com>
On Sat, Nov 05, 2016 at 12:49:55AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the RZ/G1E (R8A7745) SoC.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> Changes in version 2:
> - added Geert's tag;
> - refreshed the patch.
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> arch/arm/mach-shmobile/Kconfig | 4 ++++
> arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
> 3 files changed, 7 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Joerg Roedel @ 2016-11-14 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41e3eff1-9ce6-bcfb-5716-c65ef38add63@arm.com>
On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> If we've already made the decision to move away from bus ops, I don't
> see that it makes sense to deliberately introduce new dependencies on
> them. Besides, as it stands, this patch literally implements "tell the
> iommu-core which hardware-iommus exist in the system and a seperate
> iommu_ops ptr for each of them" straight off.
Not sure which code you are looking at, but as I see it we have only
per-device iommu-ops now (with this patch). That is different from
having core-visible hardware-iommu instances where devices could link
to.
Also the rest of iommu-core code still makes use of the per-bus ops. The
per-device ops are only used for the of_xlate fn-ptr.
Joerg
^ permalink raw reply
* [PATCH v3 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-14 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104174240.9688-2-afd@ti.com>
On Fri, Nov 04, 2016 at 12:42:39PM -0500, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> [s-anna at ti.com: revise the binding format]
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 65 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> new file mode 100644
> index 0000000..cb00679
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> @@ -0,0 +1,65 @@
> +Texas Instruments System Control Interface (TI-SCI) Reset Controller
> +=====================================================================
> +
> +Some TI SoCs contain a system controller (like the Power Management Micro
> +Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
> +the state of the various hardware modules present on the SoC. Communication
> +between the host processor running an OS and the system controller happens
> +through a protocol called TI System Control Interface (TI-SCI protocol).
> +For TI SCI details, please refer to the document,
> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +TI-SCI Reset Controller Node
> +============================
> +This reset controller node uses the TI SCI protocol to perform the reset
> +management of various hardware modules present on the SoC.
Needs to say must be a child of the SCI node somewhere in here.
> +
> +Required properties:
> +--------------------
> + - compatible : Should be "ti,sci-reset"
> + - #reset-cells : Should be 2. Please see the reset consumer node below for
> + usage details.
> +
> +TI-SCI Reset Consumer Nodes
> +===========================
> +Each of the reset consumer nodes should have the following properties,
> +in addition to their own properties.
> +
> +Required properties:
> +--------------------
> + - resets : A phandle and reset specifier pair, one pair for each reset
> + signal that affects the device, or that the device manages.
> + The phandle should point to the TI-SCI reset controller node,
> + and the reset specifier should have 2 cell-values. The first
> + cell should contain the device ID, the values of which are
> + specified in the <dt-bindings/genpd/<soc>.h> include file.
> + The second cell should contain the reset mask value used by
> + system controller, the values of which are specified in the
> + include file <dt-bindings/reset/<soc>.h>, where <soc> is the
> + name of the SoC involved, for example 'k2g'.
> +
> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
> +common reset controller usage by consumers.
> +
> +Example:
> +--------
> +The following example demonstrates both a TI-SCI reset controller node and a
> +consumer (a DSP device) on the K2G SoC.
> +
> +#include <dt-bindings/genpd/k2g.h>
> +#include <dt-bindings/reset/k2g.h>
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_reset: k2g_reset {
...: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> +};
> +
> +dsp0: dsp0 {
> + ...
> + resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
> + ...
> +};
^ permalink raw reply
* [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Sudeep Holla @ 2016-11-14 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55e95acc-d30f-432e-90d6-f96bad69ac3d@atmel.com>
On 14/11/16 15:45, Nicolas Ferre wrote:
> Le 14/11/2016 ? 16:44, Sudeep Holla a ?crit :
>> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
>> check for/support the legacy "gpio-key,wakeup" boolean property to
>> enable gpio buttons as wakeup source, "wakeup-source" is the new
>> standard binding.
>>
>> This patch replaces the legacy "gpio-key,wakeup" with the unified
>> "wakeup-source" property in order to avoid any further copy-paste
>> duplication.
>>
>> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
>> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Hi,
>>
>> Inspite of getting rid of most of the legacy property almost a year ago,
>> addition of new platforms have brought this back and over time it's
>> now found again in few places. Just get rid of them *again*
>>
>> Regards,
>> Sudeep
>
> Sorry for this Sudeep and thanks for the patch.
>
No problem, in fact you reminded me to post them :)
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: dts: imx6q: replace gpio-key,wakeup with wakeup-source for Utilite Pro
From: Fabio Estevam @ 2016-11-14 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-3-git-send-email-sudeep.holla@arm.com>
On Mon, Nov 14, 2016 at 1:44 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Nicolas Ferre @ 2016-11-14 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-2-git-send-email-sudeep.holla@arm.com>
Le 14/11/2016 ? 16:44, Sudeep Holla a ?crit :
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Hi,
>
> Inspite of getting rid of most of the legacy property almost a year ago,
> addition of new platforms have brought this back and over time it's
> now found again in few places. Just get rid of them *again*
>
> Regards,
> Sudeep
Sorry for this Sudeep and thanks for the patch.
Best regards,
> diff --git a/arch/arm/boot/dts/at91sam9260ek.dts b/arch/arm/boot/dts/at91sam9260ek.dts
> index 2c87f58448e7..b2578feceb08 100644
> --- a/arch/arm/boot/dts/at91sam9260ek.dts
> +++ b/arch/arm/boot/dts/at91sam9260ek.dts
> @@ -174,14 +174,14 @@
> label = "Button 3";
> gpios = <&pioA 30 GPIO_ACTIVE_LOW>;
> linux,code = <0x103>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
>
> btn4 {
> label = "Button 4";
> gpios = <&pioA 31 GPIO_ACTIVE_LOW>;
> linux,code = <0x104>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
> };
>
> --
> 2.7.4
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: ftrace: fix syscall name matching
From: Steven Rostedt @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114104008.36e9c40d@gandalf.local.home>
On Mon, 14 Nov 2016 10:40:08 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> > Is this really safe? What guarantees that we can wind forward four
> > bytes here? If it's always safe, it needs a better comment than just
> > two words.
>
> I believe it is, but a comment would do well.
Also, the generic function that is called if the arch does not define
ARCH_HAS_SYSCALL_MATCH_SYM_NAME does this too.
return !strcmp(sym + 3, name + 3);
And looking at this, it really should be + 4 and not + 3, because it
doesn't match the comment above, where it says it can handle both
".SyS" and "SyS", but it doesn't handle ".SyS" compared to ".sys".
-- Steve
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel
Though the mmc core driver will continue to support the legacy
"enable-sdio-wakeup" property to enable SDIO as the wakeup source,
"wakeup-source" is the new standard binding.
This patch replaces the legacy "enable-sdio-wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index ba5bca0fe997..1df47aa0a07b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -167,7 +167,7 @@
mmc-pwrseq = <&mmc3_pwrseq>;
bus-width = <4>;
non-removable;
- enable-sdio-wakeup;
+ wakeup-source;
status = "okay";
brcmf: bcrmf at 1 {
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: imx6q: replace gpio-key, wakeup with wakeup-source for Utilite Pro
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel
Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.
This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/boot/dts/imx6q-utilite-pro.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
index 61990630a748..104bbe710927 100644
--- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
@@ -68,7 +68,7 @@
label = "Power Button";
gpios = <&gpio1 29 GPIO_ACTIVE_LOW>;
linux,code = <KEY_POWER>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: at91: replace gpio-key, wakeup with wakeup-source for sam9260ek
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel
Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.
This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/at91sam9260ek.dts b/arch/arm/boot/dts/at91sam9260ek.dts
index 2c87f58448e7..b2578feceb08 100644
--- a/arch/arm/boot/dts/at91sam9260ek.dts
+++ b/arch/arm/boot/dts/at91sam9260ek.dts
@@ -174,14 +174,14 @@
label = "Button 3";
gpios = <&pioA 30 GPIO_ACTIVE_LOW>;
linux,code = <0x103>;
- gpio-key,wakeup;
+ wakeup-source;
};
btn4 {
label = "Button 4";
gpios = <&pioA 31 GPIO_ACTIVE_LOW>;
linux,code = <0x104>;
- gpio-key,wakeup;
+ wakeup-source;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH -next] ARM: dts: omap5: replace gpio-key, wakeup with wakeup-source property
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel
Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.
This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: "Beno?t Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm/boot/dts/omap5-uevm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 2fcdc516da45..a8c72611fbe3 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -41,7 +41,7 @@
label = "BTN1";
linux,code = <169>;
gpios = <&gpio3 19 GPIO_ACTIVE_LOW>; /* gpio3_83 */
- gpio-key,wakeup;
+ wakeup-source;
autorepeat;
debounce_interval = <50>;
};
--
2.7.4
^ permalink raw reply related
* [RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions
From: Hans Verkuil @ 2016-11-14 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114153926.GO1041@n2100.armlinux.org.uk>
You're CC-ed for all, so if you don't receive it in the next 15 minutes
let me know and I'll forward it to you. But my guess is that the mails were
delayed for some reason and that they simply haven't arrived yet.
Hans
On 11/14/2016 04:39 PM, Russell King - ARM Linux wrote:
> I can't comment on these, you've not included me in patch 1 nor the
> covering message.
>
> On Mon, Nov 14, 2016 at 04:22:45PM +0100, Hans Verkuil wrote:
>> From: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> We don't need the CEC engine register definitions, so let's remove them.
>>
>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> ---
>> drivers/gpu/drm/bridge/dw-hdmi.h | 45 ----------------------------------------
>> 1 file changed, 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
>> index fc9a560..26d6845 100644
>> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
>> @@ -478,51 +478,6 @@
>> #define HDMI_A_PRESETUP 0x501A
>> #define HDMI_A_SRM_BASE 0x5020
>>
>> -/* CEC Engine Registers */
>> -#define HDMI_CEC_CTRL 0x7D00
>> -#define HDMI_CEC_STAT 0x7D01
>> -#define HDMI_CEC_MASK 0x7D02
>> -#define HDMI_CEC_POLARITY 0x7D03
>> -#define HDMI_CEC_INT 0x7D04
>> -#define HDMI_CEC_ADDR_L 0x7D05
>> -#define HDMI_CEC_ADDR_H 0x7D06
>> -#define HDMI_CEC_TX_CNT 0x7D07
>> -#define HDMI_CEC_RX_CNT 0x7D08
>> -#define HDMI_CEC_TX_DATA0 0x7D10
>> -#define HDMI_CEC_TX_DATA1 0x7D11
>> -#define HDMI_CEC_TX_DATA2 0x7D12
>> -#define HDMI_CEC_TX_DATA3 0x7D13
>> -#define HDMI_CEC_TX_DATA4 0x7D14
>> -#define HDMI_CEC_TX_DATA5 0x7D15
>> -#define HDMI_CEC_TX_DATA6 0x7D16
>> -#define HDMI_CEC_TX_DATA7 0x7D17
>> -#define HDMI_CEC_TX_DATA8 0x7D18
>> -#define HDMI_CEC_TX_DATA9 0x7D19
>> -#define HDMI_CEC_TX_DATA10 0x7D1a
>> -#define HDMI_CEC_TX_DATA11 0x7D1b
>> -#define HDMI_CEC_TX_DATA12 0x7D1c
>> -#define HDMI_CEC_TX_DATA13 0x7D1d
>> -#define HDMI_CEC_TX_DATA14 0x7D1e
>> -#define HDMI_CEC_TX_DATA15 0x7D1f
>> -#define HDMI_CEC_RX_DATA0 0x7D20
>> -#define HDMI_CEC_RX_DATA1 0x7D21
>> -#define HDMI_CEC_RX_DATA2 0x7D22
>> -#define HDMI_CEC_RX_DATA3 0x7D23
>> -#define HDMI_CEC_RX_DATA4 0x7D24
>> -#define HDMI_CEC_RX_DATA5 0x7D25
>> -#define HDMI_CEC_RX_DATA6 0x7D26
>> -#define HDMI_CEC_RX_DATA7 0x7D27
>> -#define HDMI_CEC_RX_DATA8 0x7D28
>> -#define HDMI_CEC_RX_DATA9 0x7D29
>> -#define HDMI_CEC_RX_DATA10 0x7D2a
>> -#define HDMI_CEC_RX_DATA11 0x7D2b
>> -#define HDMI_CEC_RX_DATA12 0x7D2c
>> -#define HDMI_CEC_RX_DATA13 0x7D2d
>> -#define HDMI_CEC_RX_DATA14 0x7D2e
>> -#define HDMI_CEC_RX_DATA15 0x7D2f
>> -#define HDMI_CEC_LOCK 0x7D30
>> -#define HDMI_CEC_WKUPCTRL 0x7D31
>> -
>> /* I2C Master Registers (E-DDC) */
>> #define HDMI_I2CM_SLAVE 0x7E00
>> #define HDMI_I2CM_ADDRESS 0x7E01
>> --
>> 2.8.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Sudeep Holla @ 2016-11-14 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang@atmel.com>
On 02/11/16 03:05, Wenyou Yang wrote:
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts
> is listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
> 3 files changed, 482 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
[...]
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + gpio-key,wakeup;
Please replace this with "wakeup-source", I will post patches to fix the
new comers in the mainline. It was cleaned last year.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: ftrace: fix syscall name matching
From: Steven Rostedt @ 2016-11-14 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114134017.GJ1041@n2100.armlinux.org.uk>
On Mon, 14 Nov 2016 13:40:17 +0000
Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> On Mon, Nov 14, 2016 at 02:03:45PM +0100, Rabin Vincent wrote:
> > From: Rabin Vincent <rabinv@axis.com>
> >
> > ARM has a few system calls (most notably mmap) for which the names of
> > the functions which are referenced in the syscall table do not match the
> > names of the syscall tracepoints. As a consequence of this, these
> > tracepoints are not made available. Implement
> > arch_syscall_match_sym_name to fix this and allow tracing even these
> > system calls.
> >
> > Signed-off-by: Rabin Vincent <rabinv@axis.com>
> > ---
> > arch/arm/include/asm/ftrace.h | 21 +++++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> > index bfe2a2f..8467909 100644
> > --- a/arch/arm/include/asm/ftrace.h
> > +++ b/arch/arm/include/asm/ftrace.h
> > @@ -54,6 +54,27 @@ static inline void *return_address(unsigned int level)
> >
> > #define ftrace_return_address(n) return_address(n)
> >
> > +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> > +
> > +static inline bool arch_syscall_match_sym_name(const char *sym,
> > + const char *name)
> > +{
> > + /* Skip sys_ */
> > + sym += 4;
> > + name += 4;
>
> Is this really safe? What guarantees that we can wind forward four
> bytes here? If it's always safe, it needs a better comment than just
> two words.
I believe it is, but a comment would do well.
The "sym" comes from kallsyms_lookup(syscall-address...)
Which it becomes the syscall function. Mostly defined by:
include/linux/syscalls.h:
#define SYSCALL_DEFINEx(x, name)
asmlinkage long sys_##name(...)
But there are cases that archs can define their own system calls
outside of this method. But then again, those system calls wont have
tracepoints attached to them, and they wont be called with this
function.
The "name" part comes from the system call tracepoint.
#define SYSCALL_METADATA(sname, ...)
static struct syscall_metadata
__syscall_meta_##sname = {
.name = "sys"#sname,
It too appends the "sys" to the name. Note, sname here is called with
appending "_" to name, so the .name will start with "sys_" as well.
I'm guessing that there's an issue if more than one function name is
used for the same function, that is, the symbol maps to the same IP.
Then kallsyms_lookup() can return different function names for the same
function being called, and I'm guessing that's what this is trying to
fix.
-- Steve
>
> > +
> > + if (!strcmp(sym, "mmap2"))
> > + sym = "mmap_pgoff";
> > + else if (!strcmp(sym, "statfs64_wrapper"))
> > + sym = "statfs64";
> > + else if (!strcmp(sym, "fstatfs64_wrapper"))
> > + sym = "fstatfs64";
> > + else if (!strcmp(sym, "arm_fadvise64_64"))
> > + sym = "fadvise64_64";
> > +
> > + return !strcmp(sym, name);
> > +}
> > +
> > #endif /* ifndef __ASSEMBLY__ */
> >
> > #endif /* _ASM_ARM_FTRACE */
> > --
> > 2.1.4
> >
>
^ permalink raw reply
* [RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions
From: Russell King - ARM Linux @ 2016-11-14 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479136968-24477-3-git-send-email-hverkuil@xs4all.nl>
I can't comment on these, you've not included me in patch 1 nor the
covering message.
On Mon, Nov 14, 2016 at 04:22:45PM +0100, Hans Verkuil wrote:
> From: Russell King <rmk+kernel@arm.linux.org.uk>
>
> We don't need the CEC engine register definitions, so let's remove them.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/gpu/drm/bridge/dw-hdmi.h | 45 ----------------------------------------
> 1 file changed, 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
> index fc9a560..26d6845 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> @@ -478,51 +478,6 @@
> #define HDMI_A_PRESETUP 0x501A
> #define HDMI_A_SRM_BASE 0x5020
>
> -/* CEC Engine Registers */
> -#define HDMI_CEC_CTRL 0x7D00
> -#define HDMI_CEC_STAT 0x7D01
> -#define HDMI_CEC_MASK 0x7D02
> -#define HDMI_CEC_POLARITY 0x7D03
> -#define HDMI_CEC_INT 0x7D04
> -#define HDMI_CEC_ADDR_L 0x7D05
> -#define HDMI_CEC_ADDR_H 0x7D06
> -#define HDMI_CEC_TX_CNT 0x7D07
> -#define HDMI_CEC_RX_CNT 0x7D08
> -#define HDMI_CEC_TX_DATA0 0x7D10
> -#define HDMI_CEC_TX_DATA1 0x7D11
> -#define HDMI_CEC_TX_DATA2 0x7D12
> -#define HDMI_CEC_TX_DATA3 0x7D13
> -#define HDMI_CEC_TX_DATA4 0x7D14
> -#define HDMI_CEC_TX_DATA5 0x7D15
> -#define HDMI_CEC_TX_DATA6 0x7D16
> -#define HDMI_CEC_TX_DATA7 0x7D17
> -#define HDMI_CEC_TX_DATA8 0x7D18
> -#define HDMI_CEC_TX_DATA9 0x7D19
> -#define HDMI_CEC_TX_DATA10 0x7D1a
> -#define HDMI_CEC_TX_DATA11 0x7D1b
> -#define HDMI_CEC_TX_DATA12 0x7D1c
> -#define HDMI_CEC_TX_DATA13 0x7D1d
> -#define HDMI_CEC_TX_DATA14 0x7D1e
> -#define HDMI_CEC_TX_DATA15 0x7D1f
> -#define HDMI_CEC_RX_DATA0 0x7D20
> -#define HDMI_CEC_RX_DATA1 0x7D21
> -#define HDMI_CEC_RX_DATA2 0x7D22
> -#define HDMI_CEC_RX_DATA3 0x7D23
> -#define HDMI_CEC_RX_DATA4 0x7D24
> -#define HDMI_CEC_RX_DATA5 0x7D25
> -#define HDMI_CEC_RX_DATA6 0x7D26
> -#define HDMI_CEC_RX_DATA7 0x7D27
> -#define HDMI_CEC_RX_DATA8 0x7D28
> -#define HDMI_CEC_RX_DATA9 0x7D29
> -#define HDMI_CEC_RX_DATA10 0x7D2a
> -#define HDMI_CEC_RX_DATA11 0x7D2b
> -#define HDMI_CEC_RX_DATA12 0x7D2c
> -#define HDMI_CEC_RX_DATA13 0x7D2d
> -#define HDMI_CEC_RX_DATA14 0x7D2e
> -#define HDMI_CEC_RX_DATA15 0x7D2f
> -#define HDMI_CEC_LOCK 0x7D30
> -#define HDMI_CEC_WKUPCTRL 0x7D31
> -
> /* I2C Master Registers (E-DDC) */
> #define HDMI_I2CM_SLAVE 0x7E00
> #define HDMI_I2CM_ADDRESS 0x7E01
> --
> 2.8.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 RFC 3/2] ARM: improve arch_irq_work_has_interrupt()
From: Russell King - ARM Linux @ 2016-11-14 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1c6GpW-0008DO-BD@rmk-PC.armlinux.org.uk>
Following on from the previous patch, I think this makes more sense to
determine whether we can support IRQ work interrupts.
Whether we can support them or not depends on two things:
(a) whether the kernel has support for receiving IPIs
(b) whether it's possible to send an IPI to CPUs including the raising CPU.
(a) is a function of how the kernel is built - and in the case of ARM, it
depends whether the kernel is built with SMP enabled or not.
(b) is a property of the interrupt controller.
It hasn't ever been a function of the CPU or architecture.
Commit 059e232089e4 ("irqchip/gic: Allow self-SGIs for SMP on UP
configurations") changes the GIC IPI code such that we can raise
SGIs on uniprocessor systems running on a SMP kernel, which means
we can support IRQ work interrupts here as well.
So, we shouldn't be using cpu_smp() (or its previous is_smp() here
at all. Use a flag to indicate whether we can IPI and use that to
indicate whether we support irq work interrupts.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/include/asm/irq_work.h | 11 +++++++++--
arch/arm/kernel/irq.c | 0
arch/arm/kernel/smp.c | 3 +++
drivers/irqchip/irq-gic.c | 17 +++++++++++++----
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
index 2dc8d7995b48..d7262a3c2f2e 100644
--- a/arch/arm/include/asm/irq_work.h
+++ b/arch/arm/include/asm/irq_work.h
@@ -1,11 +1,18 @@
#ifndef __ASM_ARM_IRQ_WORK_H
#define __ASM_ARM_IRQ_WORK_H
-#include <asm/smp_plat.h>
+extern bool irq_controller_can_ipi;
+#define irq_controller_can_ipi irq_controller_can_ipi
static inline bool arch_irq_work_has_interrupt(void)
{
- return cpu_smp();
+#ifdef CONFIG_SMP
+ /* This depends on the IRQ controller */
+ return irq_controller_can_ipi;
+#else
+ /* The kernel is not built to support IPIs */
+ return false;
+#endif
}
#endif /* _ASM_ARM_IRQ_WORK_H */
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7dd14e8395e6..1fa9412cc4aa 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -473,6 +473,9 @@ void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
__smp_cross_call = fn;
}
+/* This indicates whether the IRQ controller can IPI (including self-IPI) */
+bool irq_controller_can_ipi;
+
static const char *ipi_types[NR_IPI] __tracepoint_string = {
#define S(x,s) [x] = s
S(IPI_WAKEUP, "CPU wakeup interrupts"),
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d6c404b3584d..abe8d5807c0f 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1187,9 +1187,6 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
*/
for (i = 0; i < NR_GIC_CPU_IF; i++)
gic_cpu_map[i] = 0xff;
-#ifdef CONFIG_SMP
- set_smp_cross_call(gic_raise_softirq);
-#endif
cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
"AP_IRQ_GIC_STARTING",
gic_starting_cpu, NULL);
@@ -1207,8 +1204,20 @@ static int __init __gic_init_bases(struct gic_chip_data *gic,
}
ret = gic_init_bases(gic, irq_start, handle);
- if (ret)
+ if (ret) {
kfree(name);
+ return ret;
+ }
+
+ if (gic == &gic_data[0]) {
+#ifdef CONFIG_SMP
+ set_smp_cross_call(gic_raise_softirq);
+#ifdef irq_controller_can_ipi
+ if (nr_cpu_ids == 1 || hweight8(gic_cpu_map[0]) == 1)
+ irq_controller_can_ipi = true;
+#endif
+#endif
+ }
return ret;
}
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [PATCH v2] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Nicolas Ferre @ 2016-11-14 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478055958-8463-1-git-send-email-wenyou.yang@atmel.com>
Le 02/11/2016 ? 04:05, Wenyou Yang a ?crit :
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts
> is listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 +++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 +++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 265 ++++++++++++++++++++++++++++++++++
> 3 files changed, 482 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
> diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> new file mode 100644
> index 0000000..fd6bcd6
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
> @@ -0,0 +1,51 @@
> +/*
> + * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
No, in fact we now use a dual license scheme for DT files. Please have a
look at the recent board that we posted to take the header from them.
> + */
> +/dts-v1/;
> +#include "sama5d36.dtsi"
> +#include "sama5d3xmb_cmp.dtsi"
> +
> +/ {
> + model = "Atmel SAMA5D36-EK";
> + compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
I don't think the model name nor the compatible string reflect the
nature of this new "CMP" board.
> +
> + ahb {
> + apb {
> + spi0: spi at f0004000 {
> + status = "okay";
> + };
> +
> + ssc0: ssc at f0008000 {
> + status = "okay";
> + };
> +
> + can0: can at f000c000 {
> + status = "okay";
> + };
> +
> + i2c0: i2c at f0014000 {
> + status = "okay";
> + };
> +
> + i2c1: i2c at f0018000 {
> + status = "okay";
> + };
> +
> + macb0: ethernet at f0028000 {
> + status = "okay";
> + };
> +
> + macb1: ethernet at f802c000 {
> + status = "okay";
> + };
> + };
> + };
> +
> + sound {
> + status = "okay";
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> new file mode 100644
> index 0000000..77638c3
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> @@ -0,0 +1,166 @@
> +/*
> + * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +
> +/ {
> + compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + chosen {
> + bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
Remove bootargs.
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + reg = <0x20000000 0x20000000>;
> + };
> +
> + clocks {
> + slow_xtal {
> + clock-frequency = <32768>;
> + };
> +
> + main_xtal {
> + clock-frequency = <12000000>;
> + };
> + };
> +
> + ahb {
> + apb {
> + spi0: spi at f0004000 {
> + cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
> + };
> +
> + macb0: ethernet at f0028000 {
> + phy-mode = "rgmii";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet-phy at 1 {
> + reg = <0x1>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> +
> + ethernet-phy at 7 {
> + reg = <0x7>;
> + interrupt-parent = <&pioB>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + txen-skew-ps = <800>;
> + txc-skew-ps = <3000>;
> + rxdv-skew-ps = <400>;
> + rxc-skew-ps = <3000>;
> + rxd0-skew-ps = <400>;
> + rxd1-skew-ps = <400>;
> + rxd2-skew-ps = <400>;
> + rxd3-skew-ps = <400>;
> + };
> + };
> +
> + i2c1: i2c at f0018000 {
> + pmic: act8865 at 5b {
> + compatible = "active-semi,act8865";
> + reg = <0x5b>;
> + status = "disabled";
> +
> + regulators {
> + vcc_1v8_reg: DCDC_REG1 {
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + vcc_1v2_reg: DCDC_REG2 {
> + regulator-name = "VCC_1V2";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1300000>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3_reg: DCDC_REG3 {
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddana_reg: LDO_REG1 {
> + regulator-name = "VDDANA";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vddfuse_reg: LDO_REG2 {
> + regulator-name = "FUSE_2V5";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + };
> + };
> + };
> + };
> + };
> +
> + nand0: nand at 60000000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc;
> + atmel,pmecc-cap = <4>;
> + atmel,pmecc-sector-size = <512>;
> + nand-on-flash-bbt;
> + status = "okay";
> +
> + at91bootstrap at 0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x40000>;
> + };
> +
> + bootloader at 40000 {
> + label = "bootloader";
> + reg = <0x40000 0x80000>;
> + };
> +
> + bootloaderenv at c0000 {
> + label = "bootloader env";
> + reg = <0xc0000 0xc0000>;
> + };
> +
> + dtb at 180000 {
> + label = "device tree";
> + reg = <0x180000 0x80000>;
> + };
> +
> + kernel at 200000 {
> + label = "kernel";
> + reg = <0x200000 0x600000>;
> + };
> +
> + rootfs at 800000 {
> + label = "rootfs";
> + reg = <0x800000 0x0f800000>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + d2 {
> + label = "d2";
> + gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> new file mode 100644
> index 0000000..62c6230
> --- /dev/null
> +++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
> @@ -0,0 +1,265 @@
> +/*
> + * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
> + *
> + * Copyright (C) 2016 Atmel,
> + *
> + * Licensed under GPLv2 or later.
Ditto.
> + */
> +#include "sama5d3xcm_cmp.dtsi"
> +
> +/ {
> + compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
Ditto.
> +
> + ahb {
> + apb {
> + mmc0: mmc at f0000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
> + status = "okay";
> + slot at 0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + spi0: spi at f0004000 {
> + dmas = <0>, <0>; /* Do not use DMA for spi0 */
> +
> + m25p80 at 0 {
> + compatible = "atmel,at25df321a";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> + };
> +
> + ssc0: ssc at f0008000 {
> + atmel,clk-from-rk-pin;
> + };
> +
> + /*
> + * i2c0 conflicts with ISI:
> + * disable it to allow the use of ISI
> + * can not enable audio when i2c0 disabled
> + */
> + i2c0: i2c at f0014000 {
> + wm8904: wm8904 at 1a {
> + compatible = "wlf,wm8904";
> + reg = <0x1a>;
> + clocks = <&pck0>;
> + clock-names = "mclk";
> + };
> + };
> +
> + i2c1: i2c at f0018000 {
> + ov2640: camera at 0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
> + resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
> + /* use pck1 for the master clock of ov2640 */
> + clocks = <&pck1>;
> + clock-names = "xvclk";
> + assigned-clocks = <&pck1>;
> + assigned-clock-rates = <25000000>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> + usart1: serial at f0020000 {
> + dmas = <0>, <0>; /* Do not use DMA for usart1 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
> + status = "okay";
> + };
> +
> + isi: isi at f0034000 {
> + port {
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + bus-width = <8>;
> + vsync-active = <1>;
> + hsync-active = <1>;
> + };
> + };
> + };
> +
> + mmc1: mmc at f8000000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
> + status = "okay";
> + slot at 0 {
> + reg = <0>;
> + bus-width = <4>;
> + cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + adc0: adc at f8018000 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <
> + &pinctrl_adc0_adtrg
> + &pinctrl_adc0_ad0
> + &pinctrl_adc0_ad1
> + &pinctrl_adc0_ad2
> + &pinctrl_adc0_ad3
> + &pinctrl_adc0_ad4
> + >;
> + pinctrl-1 = <
> + &pinctrl_adc0_adtrg_sleep
> + &pinctrl_adc0_ad0_sleep
> + &pinctrl_adc0_ad1_sleep
> + &pinctrl_adc0_ad2_sleep
> + &pinctrl_adc0_ad3_sleep
> + &pinctrl_adc0_ad4_sleep
> + >;
> + status = "okay";
> + };
> +
> + macb1: ethernet at f802c000 {
> + phy-mode = "rmii";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy at 1 {
> + /*interrupt-parent = <&pioE>;*/
> + /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
> + reg = <1>;
> + };
> + };
> +
> + pinctrl at fffff200 {
> + adc0 {
> + pinctrl_adc0_adtrg_sleep: adc0_adtrg_1 {
> + atmel,pins =
> + <AT91_PIOD 19 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD19 GPIO output 0 */
> + };
> + pinctrl_adc0_ad0_sleep: adc0_ad0_1 {
> + atmel,pins =
> + <AT91_PIOD 20 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD20 GPIO output 0 */
> + };
> + pinctrl_adc0_ad1_sleep: adc0_ad1_1 {
> + atmel,pins =
> + <AT91_PIOD 21 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD21 GPIO output 0 */
> + };
> + pinctrl_adc0_ad2_sleep: adc0_ad2_1 {
> + atmel,pins =
> + <AT91_PIOD 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD22 GPIO output 0 */
> + };
> + pinctrl_adc0_ad3_sleep: adc0_ad3_1 {
> + atmel,pins =
> + <AT91_PIOD 23 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD23 GPIO output 0 */
> + };
> + pinctrl_adc0_ad4_sleep: adc0_ad4_1 {
> + atmel,pins =
> + <AT91_PIOD 24 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>; /* PD24 GPIO output 0 */
Please remove all these comments. The binding is good enough to
understand easily.
> + };
> + };
> +
> + board {
> + pinctrl_gpio_keys: gpio_keys {
> + atmel,pins =
> + <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> + };
> +
> + pinctrl_mmc0_cd: mmc0_cd {
> + atmel,pins =
> + <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_mmc1_cd: mmc1_cd {
> + atmel,pins =
> + <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
> + };
> +
> + pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
> + atmel,pins =
> + <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
> + };
> +
> + pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
> + atmel,pins =
> + <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
> + };
> +
> + pinctrl_sensor_reset: sensor_reset-0 {
> + atmel,pins =
> + <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
> + };
> +
> + pinctrl_sensor_power: sensor_power-0 {
> + atmel,pins =
> + <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
> + };
> +
> + pinctrl_usba_vbus: usba_vbus {
> + atmel,pins =
> + <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
Here again, all comments are not or great use: remove them.
> + };
> + };
> + };
> +
> + dbgu: serial at ffffee00 {
> + dmas = <0>, <0>; /* Do not use DMA for dbgu */
> + status = "okay";
> + };
> +
> + watchdog at fffffe40 {
> + status = "okay";
> + };
> + };
> +
> + usb0: gadget at 00500000 {
> + atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usba_vbus>;
> + status = "okay";
> + };
> + };
> +
> + sound {
> + compatible = "atmel,asoc-wm8904";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
> +
> + atmel,model = "wm8904 @ SAMA5D3EK";
> + atmel,audio-routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "IN2L", "Line In Jack",
> + "IN2R", "Line In Jack",
> + "Mic", "MICBIAS",
> + "IN1L", "Mic";
> +
> + atmel,ssc-controller = <&ssc0>;
> + atmel,audio-codec = <&wm8904>;
> +
> + status = "disabled";
> + };
> +
> + /* Conflict with LCD pins */
> + gpio_keys {
> + compatible = "gpio-keys";
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + pb_user1 {
> + label = "pb_user1";
> + gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
> + linux,code = <0x100>;
> + gpio-key,wakeup;
> + };
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Stefan Wahren @ 2016-11-14 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126206-20482-1-git-send-email-linus.walleij@linaro.org>
Hi Linus,
Am 14.11.2016 um 13:23 schrieb Linus Walleij:
> From: Phil Elwell <phil@raspberrypi.org>
>
> Contrary to the documentation, the BCM2835 GPIO controller actually
> has four interrupt lines - one each for the three IRQ groups and one
> common. Confusingly, the GPIO interrupt groups don't correspond
> directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
> GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
>
> Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
> so split out a function to process the interrupts for a single GPIO
> bank.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I want to apply this to cater for my GPIOLIB_IRQCHIP
> refactorings.
> ---
> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
> 1 file changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index b2dd278f18b1..1d8fc104e26b 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>
...
> @@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
> .remove = bcm2835_pinctrl_remove,
> .driver = {
> .name = MODULE_NAME,
> + .owner = THIS_MODULE,
this is unnecessary. Please remove it.
Thanks for submitting these patches
Stefan
> .of_match_table = bcm2835_pinctrl_match,
> },
> };
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Joerg Roedel @ 2016-11-14 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <634ac375-3507-6926-164f-e67f7c798c98@redhat.com>
Hi Eric,
On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
> On 11/11/2016 17:22, Joerg Roedel wrote:
> > So I think we need a way to tell userspace about the reserved regions
> > (per iommu-group) so that userspace knows where it can not map anything,
> Current plan is to expose that info through an iommu-group sysfs
> attribute, as you and Robin advised.
Great.
> > and VFIO can enforce that. But the right struct here is not an
> > iova-allocator rb-tree, a ordered linked list should be sufficient.
> I plan a linked list to store the reserved regions (P2P regions, MSI
> region, ...). get_dma_regions is called with a list local to a function
> for that. Might be needed to move that list head in the iommu_group to
> avoid calling the get_dm_regions again in the attribute show function?
You can re-use the get_dm_regions() call-back available in the iommu-ops
already. Just rename it and add a flag to it which tells the iommu-core
whether that region needs to be mapped or not.
> But to allocate the IOVAs within the MSI reserved region, I understand
> you don't want us to use the iova.c allocator, is that correct? We need
> an allocator though, even a very basic one based on bitmap or whatever.
> There potentially have several different physical MSI frame pages to map.
I don't get this, what do you need and address-allocator for?
Joerg
^ permalink raw reply
* [PATCH RESEND] spi: atmel: Fix scheduling while atomic
From: Alexandre Belloni @ 2016-11-14 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479136400-10285-1-git-send-email-ben.whitten@lairdtech.com>
On 14/11/2016 at 15:13:20 +0000, Ben Whitten wrote :
> A call to clk_get_rate appears to be called in the context of an interrupt,
> cache the bus clock for the frequency calculations in transmission.
>
> This fixes a 'BUG: scheduling while atomic' and
> 'WARNING: CPU: 0 PID: 777 at kernel/sched/core.c:2960 atmel_spi_unlock'
>
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> Signed-off-by: Steve deRosier <steve.derosier@lairdtech.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>
> Resending due to missing off the subsystem maintainer in initial submission,
> pointed out by Alexandre Belloni, thanks.
>
> ---
> drivers/spi/spi-atmel.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 8feac59..c281d1a 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -295,6 +295,7 @@ struct atmel_spi {
> int irq;
> struct clk *clk;
> struct platform_device *pdev;
> + unsigned long spi_clk;
>
> struct spi_transfer *current_transfer;
> int current_remaining_bytes;
> @@ -864,7 +865,7 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
> unsigned long bus_hz;
>
> /* v1 chips start out at half the peripheral bus speed. */
> - bus_hz = clk_get_rate(as->clk);
> + bus_hz = as->spi_clk;
> if (!atmel_spi_is_v2(as))
> bus_hz /= 2;
>
> @@ -1606,6 +1607,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
> ret = clk_prepare_enable(clk);
> if (ret)
> goto out_free_irq;
> +
> + as->spi_clk = clk_get_rate(clk);
> +
> spi_writel(as, CR, SPI_BIT(SWRST));
> spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
> if (as->caps.has_wdrbt) {
> --
> 2.7.4
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 2/9] arm64: dts: rockchip: add pd_sd power node for rk3399
From: Heiko Stuebner @ 2016-11-14 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-3-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:54 CET schrieb Caesar Wang:
> From: zhangqing <zhangqing@rock-chips.com>
>
> 1.add pd node for RK3399 Soc
> 2.create power domain tree
> 3.add qos node for domain
> 4.add the pd_sd consumers node
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Applied to my dts64 branch after some tweaks to patch subject and commit
message.
Thanks
Heiko
^ 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