* [PATCH 4/5] ARM: qcom_defconfig: Drop SoC specific configs
From: Stephen Boyd @ 2017-01-18 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232726.22876-1-sboyd@codeaurora.org>
Now that these configs are gone let's remove them from the
defconfig.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/configs/qcom_defconfig | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 8c3a0108a231..03fc52964902 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -20,10 +20,6 @@ CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MSM8X60=y
-CONFIG_ARCH_MSM8960=y
-CONFIG_ARCH_MSM8974=y
-CONFIG_ARCH_MDM9615=y
CONFIG_SMP=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_PREEMPT=y
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 3/5] ARM: qcom: Remove SoC specific configs
From: Stephen Boyd @ 2017-01-18 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232726.22876-1-sboyd@codeaurora.org>
We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
because they are proxy configs for selecting the right
clocksource driver and adjusting the text offset and there is no
difference between ARCH_MSM8X60 and ARCH_MSM8960 anymore.
Furthermore, there aren't configs for all the SoCs supported by
the mainline kernel, leading to confusion about which SoCs are
supported.
So just select the qcom clocksource driver all the time and rely
on users selecting HAVE_ARM_ARCH_TIMER in their defconfig for
SoCs that use the architected timer. This should simplify things.
Finally, since we're here alphabetize the select list under
ARCH_QCOM.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/mach-qcom/Kconfig | 23 ++---------------------
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig
index 46ed10a807f0..16fc13246926 100644
--- a/arch/arm/mach-qcom/Kconfig
+++ b/arch/arm/mach-qcom/Kconfig
@@ -2,29 +2,10 @@ menuconfig ARCH_QCOM
bool "Qualcomm Support"
depends on ARCH_MULTI_V7
select ARCH_SUPPORTS_BIG_ENDIAN
- select ARM_GIC
select ARM_AMBA
+ select ARM_GIC
+ select CLKSRC_QCOM
select PINCTRL
select QCOM_SCM if SMP
help
Support for Qualcomm's devicetree based systems.
-
-if ARCH_QCOM
-
-config ARCH_MSM8X60
- bool "Enable support for MSM8X60"
- select CLKSRC_QCOM
-
-config ARCH_MSM8960
- bool "Enable support for MSM8960"
- select CLKSRC_QCOM
-
-config ARCH_MSM8974
- bool "Enable support for MSM8974"
- select HAVE_ARM_ARCH_TIMER
-
-config ARCH_MDM9615
- bool "Enable support for MDM9615"
- select CLKSRC_QCOM
-
-endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 2/5] ARM: Makefile: Generalize qcom platform text offset
From: Stephen Boyd @ 2017-01-18 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232726.22876-1-sboyd@codeaurora.org>
Some qcom platforms need a specific text offset because the first
2MB of memory is reserved for shared memory. Let's just always
shift the text segment up by 2MB when ARCH_QCOM is selected so
that we don't have to specify the specific platforms that exhibit
this problem in Kconfig.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ab30cc634d02..8a6d344e6043 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -145,8 +145,7 @@ textofs-$(CONFIG_PM_H1940) := 0x00108000
ifeq ($(CONFIG_ARCH_SA1100),y)
textofs-$(CONFIG_SA1111) := 0x00208000
endif
-textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
-textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
+textofs-$(CONFIG_ARCH_QCOM) := 0x00208000
textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
# Machine directory name. This list is sorted alphanumerically
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 1/5] iommu: Generalize MSM_IOMMU config to ARCH_QCOM
From: Stephen Boyd @ 2017-01-18 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232726.22876-1-sboyd@codeaurora.org>
We want to get rid of the ARCH_MSM* configs in the future, but
this still depends on them. Generalize to the ARCH_QCOM config,
which isn't going away.
Cc: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 8ee54d71c7eb..a91fc7986428 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -88,7 +88,7 @@ config FSL_PAMU
config MSM_IOMMU
bool "MSM IOMMU Support"
depends on ARM
- depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
+ depends on ARCH_QCOM || COMPILE_TEST
select IOMMU_API
select IOMMU_IO_PGTABLE_ARMV7S
help
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 0/5] Remove qcom SoC configs
From: Stephen Boyd @ 2017-01-18 23:27 UTC (permalink / raw)
To: linux-arm-kernel
We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig
because they are proxy configs for selecting the right
clocksource driver and adjusting the text offset and there is no
difference between ARCH_MSM8X60 and ARCH_MSM8960 anymore.
Furthermore, there aren't configs for all the SoCs supported by
the mainline kernel, leading to confusion about which SoCs are
supported. This patch series removes them, leading to less confusion
with the minor downside of always forcing a text offset shift and
the selection of the qcom specific clocksource driver. The size
increase from the clocksource driver is already taken in
the qcom_defconfig, so most likely nobody will care.
Cc: Joerg Roedel <joro@8bytes.org>
Stephen Boyd (5):
iommu: Generalize MSM_IOMMU config to ARCH_QCOM
ARM: Makefile: Generalize qcom platform text offset
ARM: qcom: Remove SoC specific configs
ARM: qcom_defconfig: Drop SoC specific configs
ARM: multi_v7_defconfig: Remove qcom SoC configs
arch/arm/Makefile | 3 +--
arch/arm/configs/multi_v7_defconfig | 3 ---
arch/arm/configs/qcom_defconfig | 4 ----
arch/arm/mach-qcom/Kconfig | 23 ++---------------------
drivers/iommu/Kconfig | 2 +-
5 files changed, 4 insertions(+), 31 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: Baicar, Tyler @ 2017-01-18 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587DF279.1010402@arm.com>
Hello James,
On 1/17/2017 3:31 AM, James Morse wrote:
> Hi Tyler,
>
> On 12/01/17 18:15, Tyler Baicar wrote:
>> SEA exceptions are often caused by an uncorrected hardware
>> error, and are handled when data abort and instruction abort
>> exception classes have specific values for their Fault Status
>> Code.
>> When SEA occurs, before killing the process, go through
>> the handlers registered in the notification list.
>> Update fault_info[] with specific SEA faults so that the
>> new SEA handler is used.
>> @@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> return 1;
>> }
>>
>> +/*
>> + * This abort handler deals with Synchronous External Abort.
>> + * It calls notifiers, and then returns "fault".
>> + */
>> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> +{
>> + struct siginfo info;
>> +
>> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>> +
>> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>> + fault_name(esr), esr, addr);
>> +
>> + info.si_signo = SIGBUS;
>> + info.si_errno = 0;
>> + info.si_code = 0;
> Half of the other do_*() functions in this file read the signo and code from the
> fault_info table.
>
>
>> + info.si_addr = (void __user *)addr;
> addr here was read from FAR_EL1, but for some of the classes of exception you
> have listed below this register isn't updated with the faulting address.
>
> The ARM-ARM version 'k' in D1.10.5 "Summary of registers on faults taken to an
> Exception level that is using Aarch64" has:
>> The architecture permits that the FAR_ELx is UNKNOWN for Synchronous External
>> Aborts other than Synchronous External Aborts on Translation Table Walks. In
>> this case, the ISS.FnV bit returned in ESR_ELx indicates whether FAR_ELx is
>> valid.
> This is a problem if we get 'synchronous external abort' or 'synchronous parity
> error' while a user space process was running.
It looks like this would just cause an incorrect address to be printed
in the above pr_err.
Unless I'm missing something, I don't see arm64_notify_die or anything
that gets called from
there using the info.si_addr variable.
What do you suggest I do here? The firmware should be reporting the
physical and virtual
address information if it is available in the HEST entry that the kernel
will parse. So should I
just remove the use of the addr parameter in do_sea?
Thanks,
Tyler
>> + arm64_notify_die("", regs, &info, esr);
>> +
>> + return 0;
>> +}
>> +
>> static const struct fault_info {
>> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
>> int sig;
>
> Thanks,
>
> James
>
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: Reduce "CPU: shutdown" message to debug level
From: Russell King - ARM Linux @ 2017-01-18 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118225328.2597-1-f.fainelli@gmail.com>
On Wed, Jan 18, 2017 at 02:53:26PM -0800, Florian Fainelli wrote:
> Similar to c68b0274fb3c ("ARM: reduce "Booted secondary processor"
> message to debug level"), demote the "CPU: shutdown" pr_notice() into a
> pr_debug().
Much better, and thanks for dropping the "performance" argument as well.
CPU hotplug isn't about performance :)
Please put this in the patch system, thanks.
--
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 4/4] drm: exynos: Remove support for Exynos4415 (SoC not supported anymore)
From: Rob Herring @ 2017-01-18 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170114123642.15581-5-krzk@kernel.org>
On Sat, Jan 14, 2017 at 02:36:42PM +0200, Krzysztof Kozlowski wrote:
> Support for Exynos4415 is going away because there are no internal nor
> external users.
>
> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
> the platform cannot be instantiated so remove also the drivers.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../devicetree/bindings/display/exynos/exynos_dsim.txt | 1 -
> .../bindings/display/exynos/samsung-fimd.txt | 1 -
Acked-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 15 +--------------
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 ++----------------
> 4 files changed, 3 insertions(+), 32 deletions(-)
^ permalink raw reply
* [PATCH 06/10] soc/qbman: Add ARM equivalent for flush_dcache_range()
From: Russell King - ARM Linux @ 2017-01-18 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484779180-1344-7-git-send-email-roy.pledge@nxp.com>
On Wed, Jan 18, 2017 at 05:39:36PM -0500, Roy Pledge wrote:
> From: Claudiu Manoil <claudiu.manoil@nxp.com>
>
> Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
> ---
> drivers/soc/fsl/qbman/qman_ccsr.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c b/drivers/soc/fsl/qbman/qman_ccsr.c
> index 43feaa9..67ae073 100644
> --- a/drivers/soc/fsl/qbman/qman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
> @@ -446,8 +446,14 @@ static int zero_priv_mem(struct device *dev, struct device_node *node,
> return -ENOMEM;
>
> memset(tmpp, 0, sz);
> +#ifdef CONFIG_PPC
> flush_dcache_range((unsigned long)tmpp,
> (unsigned long)tmpp + sz);
> +#elif defined(CONFIG_ARM)
> + __cpuc_flush_dcache_area(tmpp, sz);
Please do not fiddle about under the covers, there be dragons there.
It looks to me like you're trying to use __cpuc_flush_dcache_area()
on an area that's been ioremap()'d, which is a waste of CPU cycles.
ioremap()'d areas are mapped as "device" memory type, which means
the region isn't even cached. So I don't think this is necessary.
--
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 v4 3/4] dt-bindings: add "microchip,24c128" compatible string
From: Rob Herring @ 2017-01-18 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484334222-14223-4-git-send-email-david@lechnology.com>
On Fri, Jan 13, 2017 at 01:03:41PM -0600, David Lechner wrote:
> This adds "microchip,24c128" to the list of compatible strings for i2c
> eeproms.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 2/4] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
From: Rob Herring @ 2017-01-18 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484334222-14223-3-git-send-email-david@lechnology.com>
On Fri, Jan 13, 2017 at 01:03:40PM -0600, David Lechner wrote:
> This adds the board level device tree specification for LEGO MINDSTORMS EV3
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++
> 1 file changed, 4 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: Add vendor prefix for LEGO
From: Rob Herring @ 2017-01-18 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484334222-14223-2-git-send-email-david@lechnology.com>
On Fri, Jan 13, 2017 at 01:03:39PM -0600, David Lechner wrote:
> Add a vendor prefix for LEGO Systems A/S
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Linus Walleij @ 2017-01-18 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116132424.7038-1-maxime.ripard@free-electrons.com>
On Mon, Jan 16, 2017 at 2:24 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
> Allwinner, Amlogic, Mediatek or Rockchip.
>
> Add a binding for the GPU of that family.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> new file mode 100644
> index 000000000000..df05ba0ec357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -0,0 +1,76 @@
> +ARM Mali Utgard GPU
> +===================
> +
> +Required properties:
> + - compatible:
> + * "arm,mali-utgard" and one of the following:
> + + "arm,mali-300"
> + + "arm,mali-400"
> + + "arm,mali-450"
> +
> + - reg: Physical base address and length of the GPU registers
> +
> + - interrupts: an entry for each entry in interrupt-names.
> + See ../interrupt-controller/interrupts.txt for details.
> +
> + - interrupt-names:
> + * ppX: Pixel Processor X interrupt (X from 0 to 7)
> + * ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7)
> + * pp: Pixel Processor broadcast interrupt (mali-450 only)
> + * gp: Geometry Processor interrupt
> + * gpmmu: Geometry Processor MMU interrupt
> +
> +
> +Optional properties:
> + - interrupt-names:
> + * pmu: Power Management Unit interrupt, if implemented in hardware
On the MALI-400 MP in the ST-Ericsson DB8500 we have an additional interrupt
called "Mali400 combined". This is simply the HW designer's
doing an OR over all the 4 IRQ lines. Is this useful to define in the
bindings? Then it should be an optional
* combined: all lines OR:ed together (if available)
Also you are defining "resets" below in the examples, should
this be listed as an optional property?
> +The Mali GPU is integrated very differently from one SoC to
> +another. In order to accommodate those differences, you have the option
> +to specify one more vendor-specific compatible, among:
> +
> + - allwinner,sun4i-a10-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
> +
> + - allwinner,sun7i-a20-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
Please add:
- stericsson,db8500-mali: also known as the "Smart Graphics
Accelerator" (SGA500)
Required properties:
* clocks: an entry for each entry in clock-names
* clock-names:
+ bus: bus clock for the GPU (ICNCLK a.k.a. PRCMU_ACLK)
+ core: clock driving the GPU itself (PRCMU_SGACLK)
(It has no explicit reset line.)
With these:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
From: Kevin Hilman @ 2017-01-18 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484758245-9354-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
> this patch adds these reserved zones.
Applying to v4.10/fixes for broader testing.
Will wait for ack from Andreas befores submitting to arm-soc fixes.
Kevin
> Without such reserved memory zones, running the following stress command :
> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
> multiple times:
>
> Could lead to the following kernel crashes :
> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
> Instead of the OOM killer.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> Changes since v4 at [5]:
> - Move start of ddr memory to reserved-memory node
> - Drop memory node move
> - Fix typo in sizes
>
> Changes since resent v2 at [4]:
> - Fix invalid comment of useable memory attributes
>
> Changes since original v2 at [3]:
> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>
> Changes since v2 at [2]:
> - Moved all memory node out of dtsi
> - Added comment about useable memory
> - Fixed comment about secmon reserved zone
>
> Changes since v1 at [1] :
> - Renamed reg into linux,usable-memory to ovveride u-boot memory
> - only kept secmon memory zone
>
> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong at baylibre.com
> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong at baylibre.com
> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong at baylibre.com
> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong at baylibre.com
> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong at baylibre.com
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index eada0b5..63d52b7 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -55,6 +55,24 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 16 MiB reserved for Hardware ROM Firmware */
> + hwrom: hwrom {
> + reg = <0x0 0x0 0x0 0x1000000>;
> + no-map;
> + };
> +
> + /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
> + secmon: secmon {
> + reg = <0x0 0x10000000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <0x2>;
> #size-cells = <0x0>;
^ permalink raw reply
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2017-01-18 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2ziip2puf.fsf@baylibre.com>
On Tue, Jan 17, 2017 at 6:07 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Tero Kristo <t-kristo@ti.com> writes:
>> On 17/01/17 00:12, Dave Gerlach wrote:
>>> On 01/13/2017 08:40 PM, Rob Herring wrote:
>>>> On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach <d-gerlach@ti.com> wrote:
[...]
>>>>> My ti,sci-id is not an index into a list of power domains, so it
>>>>> should not
>>>>> go in the power-domains cells and go against what the power-domains
>>>>> binding
>>>>> says that the cell expects. We have one single power domain, and the new
>>>>> ti,sci-id binding is not something the genpd framework itself is
>>>>> concerned
>>>>> with as it's our property to identify a device inside a power domain,
>>>>> not to
>>>>> identify which power domain it is associated with.
>>>>
>>>> What is the id used for? I can understand why you need to know what
>>>> power domain a device is in (as power-domains identifies), but not
>>>> what devices are in a power domain.
>>>
>>> We have a system control processor that provides power management
>>> services to the OS and it responsible for handling the power state of
>>> each device. This control happens over a communication interface we have
>>> called TI SCI (implemented at drivers/firmware/ti-sci.c). The
>>> communication protocol uses these ids to identify each device within the
>>> power domain so that the control processor can do what is necessary to
>>> enable that device.
>>
>> I think a minor detail here that Rob might be missing right now is,
>> that the ti,sci-id is only controlling the PM runtime handling, and
>> providing the ID per-device for this purpose only. AFAIK, it is not
>> really connected to the power domain anymore as such, as we don't have
>> power-domains / per device anymore as was the case in some earlier
>> revision of this work.
>
> I think this gets to the heart of things. IMO The confusion arises
> because we're throwing around the term "power domain" when there isn't
> an actual hardware power domain here.
I thought there was 1.
> Unfortunately, the genpd bindings have used the terminology power-domain
> when in fact genpd is more generic than that and can be used not just
> for hardware power domains, but for arbitrary grouping of devices that
> have common PM properties. That's why genpd actually stands for generic
> PM domain, not power domain. Unfortunately, the bindings have grown
> primarily out of the usage for hardware power domains.
Now it makes some sense.
So the question is does this PM domain grouping need to be described
in DT or not, and if so what does that look like?
We could continue to use the power domain binding (maybe we already
are and that ship has sailed). I'm not totally against the idea even
if there is no power domain, but I'm not sold on it either. If we do
go this route, then I still say the id should be a cell in the
power-domain phandle.
Another option is create something new either common or TI SCI
specific. It could be just a table of ids and phandles in the SCI
node. I'm much more comfortable with an isolated property in one node
than something scattered throughout the DT.
>> One could argue though that the whole usage of power-domains is now
>> moot, as we basically only have implemented one genpd in the whole
>> SoC, which doesn't really reflect the reality. I wonder if better
>> approach would be to have this replaced with proper power domains at
>> some point (if needed), and just have a runtime-pm implementation in
>> place for the devices that require it.
>>
>> So, as an example in DT, we would only have:
>>
>> uart0: serial at 02530c00 {
>> compatible = "xyz";
>> ...
>> ti,sci-id = <K2G_DEV_UART0>;
>> };
>>
>> This is somewhat analogous to what OMAP family of SoCs have in place
>> now, under "ti,hwmods" property. I also wonder if the "ti,sci-id"
>> should be replaced with something like "ti,sci-dev-id" to make its
>> purpose clearer.
>
> Unless I'm missing something, that still begs the question of who reads
> that property and takes care of the call into TI-SCI though.
>
> Kevin
^ permalink raw reply
* [PATCH 2/7] ARM: Add Broadcom Brahma-B15 readahead cache support
From: Russell King - ARM Linux @ 2017-01-18 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118202927.28740-3-f.fainelli@gmail.com>
On Wed, Jan 18, 2017 at 12:29:21PM -0800, Florian Fainelli wrote:
> The readahead cache only intercepts reads, not writes, as such, some
> data can remain stale in any of its buffers, such that we need to flush
> it, which is an operation that needs to happen in a particular order:
>
> - disable the readahead cache
> - flush it
> - call the appropriate cache-v7.S function
> - re-enable
I really do hope that the above explanation is wrong, because if that's
really how it's implemented, it's going to cause coherency problems.
It's got to at least monitor writes, otherwise how do you guarantee
that the CPU doesn't see stale data? IOW:
Consider this at the L2 memory-side interface (iow, downstream of the
point-of-coherency):
CPU1 CPU2 Read-ahead buffer
read cache line C
reads cache line C and C+1
writes cache line C+1
read cache line C+1
What ensures that CPU2 sees the written out cache line from CPU1?
--
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 2/3] ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
From: Kevin Hilman @ 2017-01-18 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484736642-5451-3-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Adds support for the WeTek Hub and Play2 boards.
> The Hub is an extremely small IPTv Set-Top-Box and the Play2 is a more
> traditionnal Satellite or Terrestrial and IPTv Set-Top-Box.
>
> Both are based on the p200 Reference Design and out-of-tree support is
> based on OpenELEC kernel at [1].
>
> [1] https://github.com/wetek-enigma/linux-amlogic
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Did you get the GPIO/button info from the LibreELEC tree or did you find
some schematics someplace? If you found any schematics, it would be
nice to have links in the DTS files.
Kevin
^ permalink raw reply
* [PATCH] ARM: Reduce "CPU: shutdown" message to debug level
From: Florian Fainelli @ 2017-01-18 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117230714.6799-1-f.fainelli@gmail.com>
Similar to c68b0274fb3c ("ARM: reduce "Booted secondary processor"
message to debug level"), demote the "CPU: shutdown" pr_notice() into a
pr_debug().
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7dd14e8395e6..46377c40d056 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -251,7 +251,7 @@ void __cpu_die(unsigned int cpu)
pr_err("CPU%u: cpu didn't die\n", cpu);
return;
}
- pr_notice("CPU%u: shutdown\n", cpu);
+ pr_debug("CPU%u: shutdown\n", cpu);
/*
* platform_cpu_kill() is generally expected to do the powering off
--
2.9.3
^ permalink raw reply related
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: Baicar, Tyler @ 2017-01-18 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117102753.GA27328@arm.com>
On 1/17/2017 3:27 AM, Will Deacon wrote:
> On Mon, Jan 16, 2017 at 01:09:22PM -0700, Baicar, Tyler wrote:
>> On 1/16/2017 4:53 AM, Will Deacon wrote:
>>> On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote:
>>>> SEA exceptions are often caused by an uncorrected hardware
>>>> error, and are handled when data abort and instruction abort
>>>> exception classes have specific values for their Fault Status
>>>> Code.
>>>> When SEA occurs, before killing the process, go through
>>>> the handlers registered in the notification list.
>>>> Update fault_info[] with specific SEA faults so that the
>>>> new SEA handler is used.
>>>>
>>>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>>>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>>>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>>>> ---
>>>> arch/arm64/include/asm/system_misc.h | 13 ++++++++
>>>> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
>>>> 2 files changed, 61 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
>>>> index 57f110b..e7f3440 100644
>>>> --- a/arch/arm64/include/asm/system_misc.h
>>>> +++ b/arch/arm64/include/asm/system_misc.h
>>>> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>>>> #endif /* __ASSEMBLY__ */
>>>> +/*
>>>> + * The functions below are used to register and unregister callbacks
>>>> + * that are to be invoked when a Synchronous External Abort (SEA)
>>>> + * occurs. An SEA is raised by certain fault status codes that have
>>>> + * either data or instruction abort as the exception class, and
>>>> + * callbacks may be registered to parse or handle such hardware errors.
>>>> + *
>>>> + * Registered callbacks are run in an interrupt/atomic context. They
>>>> + * are not allowed to block or sleep.
>>>> + */
>>>> +int register_sea_notifier(struct notifier_block *nb);
>>>> +void unregister_sea_notifier(struct notifier_block *nb);
>>> I still don't understand why you need notifiers for this. You register
>>> precisely one hook in the series.
>> I didn't see a response to my last comment on the previous series so I just
>> left it in for this series.
>> The notifier usage is consistent with the GHES code for SCI errors which are
>> also only used a single
>> time in the code. If you think making the call directly is a better option I
>> will remove the notifiers.
> Yes, please. It's easy to add the notifier infrastructure back if/when it's
> actually needed and I don't see why the low-level fault dispatching needs to
> be consistent with the GHES/SCI code.
>
> Will
Sounds good, I will remove the notifier in the next patchset.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort
From: Baicar, Tyler @ 2017-01-18 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587DF0B6.4060000@arm.com>
On 1/17/2017 3:23 AM, James Morse wrote:
> Hi Tyler,
>
> On 16/01/17 11:53, Will Deacon wrote:
>> On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote:
>>> SEA exceptions are often caused by an uncorrected hardware
>>> error, and are handled when data abort and instruction abort
>>> exception classes have specific values for their Fault Status
>>> Code.
>>> When SEA occurs, before killing the process, go through
>>> the handlers registered in the notification list.
>>> Update fault_info[] with specific SEA faults so that the
>>> new SEA handler is used.
>>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>>> index 05d2bd7..81039c7 100644
>>> --- a/arch/arm64/mm/fault.c
>>> +++ b/arch/arm64/mm/fault.c
>>> @@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>>> return 1;
>>> }
>>>
>>> +/*
>>> + * This abort handler deals with Synchronous External Abort.
>>> + * It calls notifiers, and then returns "fault".
>>> + */
>>> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>>> +{
>>> + struct siginfo info;
>>> +
>>> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>>> +
>>> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>>> + fault_name(esr), esr, addr);
>>> +
>>> + info.si_signo = SIGBUS;
>>> + info.si_errno = 0;
>>> + info.si_code = 0;
>>> + info.si_addr = (void __user *)addr;
>>> + arm64_notify_die("", regs, &info, esr);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static const struct fault_info {
>>> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
>>> int sig;
>>> @@ -502,22 +540,22 @@ static const struct fault_info {
>>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
>>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
>>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
>>> - { do_bad, SIGBUS, 0, "synchronous external abort" },
>>> + { do_sea, SIGBUS, 0, "synchronous external abort" },
>>> { do_bad, SIGBUS, 0, "unknown 17" },
>>> { do_bad, SIGBUS, 0, "unknown 18" },
>>> { do_bad, SIGBUS, 0, "unknown 19" },
>>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>>> - { do_bad, SIGBUS, 0, "synchronous parity error" },
>>> + { do_sea, SIGBUS, 0, "level 0 SEA (translation table walk)" },
>>> + { do_sea, SIGBUS, 0, "level 1 SEA (translation table walk)" },
>>> + { do_sea, SIGBUS, 0, "level 2 SEA (translation table walk)" },
>>> + { do_sea, SIGBUS, 0, "level 3 SEA (translation table walk)" },
>> Perhaps I wasn't clear enough in my previous review, but please expand the
>> acronym for strings and comments.
>
> The 'SEA' in this user-string doesn't add anything. Now that these use do_sea()
> instead of do_bad(), when they are printed won't it be:
>> Synchronous External Abort: level 3 SEA (translation table walk) (...) at ....
Good point, yes they will:
+ pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
+ fault_name(esr), esr, addr);
I can just remove SEA here then.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: smp: Remove CPU: shutdown notice
From: Florian Fainelli @ 2017-01-18 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118223948.GR27312@n2100.armlinux.org.uk>
On 01/18/2017 02:39 PM, Russell King - ARM Linux wrote:
> On Tue, Jan 17, 2017 at 03:39:45PM -0800, Florian Fainelli wrote:
>> Well, for one it's inconsistent, and it also leaves room for subtle
>> timing/caching issues with some platforms (OK, maybe not so much).
>> Improving the speed and consistency was the primary motive.
>
> Actually, it's not as inconsistent as you claim.
>
> c68b0274fb3c ("ARM: reduce "Booted secondary processor" message to debug level")
> dropped the corresponding pr_info() in the bringup path to debug level,
> so to be consistent, this one should be dropped to debug level too.
>
> Removing it arguably makes it more inconsistent!
OK, fair point, I missed that one.
>
> So, I'd be willing to accept a patch lowering this to a pr_debug()
> to make it more consistent with the bringup path, but otherwise the
> consistency argument doesn't really stand.
Sounds good, thanks!
--
Florian
^ permalink raw reply
* [PATCH v7 2/3] input: tm2-touchkey: Add touchkey driver support for TM2
From: Dmitry Torokhov @ 2017-01-18 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117181056.mrwyudslfgh2wfms@kozik-lap>
On Tue, Jan 17, 2017 at 08:10:56PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Jan 17, 2017 at 10:06:27AM -0800, Dmitry Torokhov wrote:
> > On Tue, Jan 17, 2017 at 9:20 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > On Tue, Jan 17, 2017 at 02:54:38PM +0900, Jaechul Lee wrote:
> > >> This patch adds support for the TM2 touch key and led
> > >> functionality.
> > >>
> > >> The driver interfaces with userspace through an input device and
> > >> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> > >> controlled by "/sys/class/leds/tm2-touchkey/brightness".
> > >>
> > >> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> > >> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> > >> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> > >> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
> > >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > >> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> > >> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> > >> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > >
> > > This looks unusual. How did Dmitry's Sob end here?
> >
> > I sent Jaechul a version of the patch to try out.
>
> Ah, makes sense then.
I picked up (and folded) the binding doc and driver patches, DTS should
go through some other tree I believe.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-18 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118222321.ec6p7oqwwqfiofhp@rob-hp-laptop>
On Wed, Jan 18, 2017 at 4:23 PM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Jan 13, 2017 at 03:35:38PM +0800, sean.wang at mediatek.com wrote:
>> From: Sean Wang <sean.wang@mediatek.com>
>>
>> This patch adds documentation for devicetree bindings for
>> consumer Mediatek IR controller.
>>
>> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> ---
>> .../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
>
> Acked-by: Rob Herring <robh@kernel.org>
I guess I rescind my ack if this email doesn't work:
"The response from the remote server was:
550 Relaying mail to sean.wang at mediatek.com is not allowed"
^ permalink raw reply
* [PATCH] ARM: smp: Remove CPU: shutdown notice
From: Russell King - ARM Linux @ 2017-01-18 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd4a4f48-f19e-dcac-c286-8e03db89e99a@gmail.com>
On Tue, Jan 17, 2017 at 03:39:45PM -0800, Florian Fainelli wrote:
> Well, for one it's inconsistent, and it also leaves room for subtle
> timing/caching issues with some platforms (OK, maybe not so much).
> Improving the speed and consistency was the primary motive.
Actually, it's not as inconsistent as you claim.
c68b0274fb3c ("ARM: reduce "Booted secondary processor" message to debug level")
dropped the corresponding pr_info() in the bringup path to debug level,
so to be consistent, this one should be dropped to debug level too.
Removing it arguably makes it more inconsistent!
So, I'd be willing to accept a patch lowering this to a pr_debug()
to make it more consistent with the bringup path, but otherwise the
consistency argument doesn't really stand.
--
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 10/10] fsl/qbman: Enable FSL_LAYERSCAPE config on ARM
From: Roy Pledge @ 2017-01-18 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484779180-1344-1-git-send-email-roy.pledge@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
[Stuart: changed to use ARCH_LAYERSCAPE]
Signed-off-by: Stuart Yoder <stuart.yoder@nxp.com>
---
drivers/soc/fsl/qbman/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig
index 757033c..fb4e6bf 100644
--- a/drivers/soc/fsl/qbman/Kconfig
+++ b/drivers/soc/fsl/qbman/Kconfig
@@ -1,6 +1,6 @@
menuconfig FSL_DPAA
bool "Freescale DPAA 1.x support"
- depends on FSL_SOC_BOOKE
+ depends on (FSL_SOC_BOOKE || ARCH_LAYERSCAPE)
select GENERIC_ALLOCATOR
help
The Freescale Data Path Acceleration Architecture (DPAA) is a set of
--
1.7.9.5
^ permalink raw reply related
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