* [PATCH 3/4] ARM: nommu: display vectors base
From: Russell King - ARM Linux @ 2017-01-18 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118203837.6536-1-afzal.mohd.ma@gmail.com>
On Thu, Jan 19, 2017 at 02:08:37AM +0530, afzal mohammed wrote:
> The exception base address is now dynamically estimated for no-MMU
> case, display it.
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
> ---
> arch/arm/mm/init.c | 5 +++++
> arch/arm/mm/mm.h | 5 +++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index cf47f86f79ed..9e11f255c3bf 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -522,7 +522,12 @@ void __init mem_init(void)
> " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> " .bss : 0x%p" " - 0x%p" " (%4td kB)\n",
>
> +#ifdef CONFIG_MMU
> MLK(UL(VECTORS_BASE), UL(VECTORS_BASE) + (PAGE_SIZE)),
> +#else
> + MLK_ROUNDUP(vectors_base, vectors_base + PAGE_SIZE),
I think MLK() will do here - no need to use the rounding-up version
as PAGE_SIZE is a multiple of 1k.
--
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 1/2] ARM64: dts: meson-gxm: Add R-Box Pro
From: Kevin Hilman @ 2017-01-18 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63fbfc68-917f-68b2-9e7d-e1834e2841d3@suse.de>
Andreas F?rber <afaerber@suse.de> writes:
> Am 17.01.2017 um 04:06 schrieb Andreas F?rber:
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + blue {
>> + label = "rbox-pro:blue:on";
>> + gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + red {
>> + label = "rbox-pro:red:standby";
>> + gpios = <&gpio GPIODV_28 GPIO_ACTIVE_HIGH>;
>> + default-state = "off";
>> + retain-state-suspended;
>> + panic-indicator;
>> + };
>> + };
>
> The original property names for these two were led and red. If anyone
> has better label names than the above, please speak up. Ditto for
> vega-s95. On the odroidc2 it's called alive but uses heartbeat there.
>
> The vendor device tree had a third "mcu" GPIO in the sysled node,
> GPIOAO_6, which leads to immediate power-off. I tried using
> "gpio-poweroff" to configure this pin, but that driver fails to
> initialize because some pm callback is already registered - I assume
> from psci, which apparently succeeds to power-off the system, too. For
> comparison, the S905 based Vega S95 Telos has no such mcu property. Any
> thoughts?
>
> Also, any ideas how best to switch from blue to red for suspend? Add
> pinctrl properties above? systemd service doing echo from userspace? I
> assume in Android the Amlogic sysled driver handles all that logic -
> didn't find any suspend equivalent to gpio-poweroff.
in leds-gpio, when retain-state-suspended is not set, the LED is
automatically set to value 0. I wonder if leds-gpio should grow support
to make the suspend value configurable? Or a property like
"toggle-state-suspended" ?
Kevin
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-18 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117143650.5db87148@free-electrons.com>
On Tue, Jan 17, 2017 at 02:36:50PM +1100, Thomas Petazzoni wrote:
> Hello,
>
> (Side note: you guys should learn about stripping irrelevant parts of
> an e-mail when replying!)
>
> On Mon, 16 Jan 2017 09:40:32 +0100, Boris Brezillon wrote:
>
> > > Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
> > > as the oldest supported compatible and be done with it, no ? It looks a
> > > bit crappy though, I admit that ...
> >
> > Let's stop bikeshedding and wait for DT maintainers feedback
> > before taking a decision ;-).
> >
> > Rob, Mark, any opinion?
>
Sigh, is how to do compatibles really not yet understood?
> I agree that a clarification would be good. There are really two
> options:
>
> 1. Have two compatible strings in the DT, the one that matches the
> exact SoC where the IP is found (first compatible string) and the
> one that matches some other SoC where the same IP is found (second
> compatible string). Originally, Linux only supports the second
> compatible string in its device driver, but if it happens that a
> difference is found between two IPs that we thought were the same,
> we can add support for the first compatible string in the driver,
> with a slightly different behavior.
This. And no wildcards in the compatible string.
> 2. Have a single compatible string in the DT, matching the exact SoC
> where the IP is found. This involves adding immediately this
> compatible string in the corresponding driver.
I wouldn't object to this from a DT perspective as I have no clue
generally if IP blocks are "the same" or not. Subsystem maintainers will
object though.
> I've not really been able to figure out which of the two options is the
> most future-proof/appropriate.
They are both future-proof. #2 has the disadvantage of requiring a
kernel update for a new SoC.
Rob
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Christopher Spinrath @ 2017-01-18 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ed3f695104044f18e98fc9619aab16e@rwthex-s1-b.rwth-ad.de>
Hi Philipp,
turns out I have a question on your comment after all:
On 01/17/2017 07:35 PM, Christopher Spinrath wrote:
> Hi Philipp,
>
> thanks for the review!
>
> On 01/17/2017 09:57 AM, Philipp Zabel wrote:
>> [...]
>>> +
>>> + parallel-display {
>>> + compatible = "fsl,imx-parallel-display";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pinctrl_ipu1>;
>>> +
>>> + interface-pix-fmt = "rgb24";
>>
>> This is not necessary if the connector created by the tpf410 has the
>> correct media bus format set in its display_info structure. This can be
>> done in tfp410_attach, before calling drm_mode_connector_attach_encoder:
>>
>> u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>>
>> drm_display_info_set_bus_formats(&dvi->connector.display_info,
>> &bus_format, 1);
>>
>> After this is done, the above line should be removed in a follow-up
>> patch.
On closer inspection the tfp410 can handle rgb12, rgb24, and DVI
formats. Considering this it feels wrong to hardcode the bus format to
rgb24 (isn't it?).
So a solution might be to add a property specifying the bus format to
the tfp410 binding. But then we would effectively just move this
property from one node to another. I wonder if this is still desireable...?
Cheers,
Christopher
> Ok, I will send a mini follow-up series doing that with your
> Suggested-by (unless you object) in the next few days.
>
> Cheers,
> Christopher
>
>>> + port at 0 {
>>> + reg = <0>;
>>> +
>>> + parallel_display_in: endpoint {
>>> + remote-endpoint = <&ipu1_di0_disp0>;
>>> + };
>>> + };
>>> +
>>> + port at 1 {
>>> + reg = <1>;
>>> +
>>> + parallel_display_out: endpoint {
>>> + remote-endpoint = <&tfp410_in>;
>>> + };
>>> + };
>>> + };
>>> };
>>> [...]
^ permalink raw reply
* [PATCH v3 1/3] Documentation: devicetree: move shared property used by rc into a common place
From: Rob Herring @ 2017-01-18 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484292939-9454-2-git-send-email-sean.wang@mediatek.com>
On Fri, Jan 13, 2017 at 03:35:37PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Most IR drivers uses the same label to identify the
> scancdoe/key table they used by multiple bindings and lack
> explanation well. So move the shared property into a common
> place and give better explanation.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> .../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +-
> .../devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
> Documentation/devicetree/bindings/media/rc.txt | 116 +++++++++++++++++++++
> .../devicetree/bindings/media/sunxi-ir.txt | 2 +-
> 4 files changed, 120 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/rc.txt
Acked-by: Rob Herring <robh@kernel.org>
Thanks for doing this.
Rob
^ permalink raw reply
* [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-18 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484292939-9454-3-git-send-email-sean.wang@mediatek.com>
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>
^ permalink raw reply
* [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC
From: Rob Herring @ 2017-01-18 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091222.7132-2-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 13, 2017 at 10:12:16PM +1300, Chris Packham wrote:
> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>
> The clock gating options are a subset of those on the Armada XP.
>
> The core clock divider is different to the Armada XP also.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>
> Notes:
> Changes in v2:
> - Update devicetree binding documentation for new compatible string
> Changes in v3:
> - Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new
> driver.
> - Document mv98dx3236-corediv-clock binding
> Changes in v4:
> - None
>
> .../bindings/clock/mvebu-corediv-clock.txt | 1 +
> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
Please add acks when posting new versions.
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clk/mvebu/armada-xp.c | 42 ++++++++++++++++++++++
> drivers/clk/mvebu/clk-corediv.c | 23 ++++++++++++
> drivers/clk/mvebu/clk-cpu.c | 31 ++++++++++++++--
> 5 files changed, 96 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 1/2] ARM64: dts: meson-gxm: Add R-Box Pro
From: Kevin Hilman @ 2017-01-18 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3005a457-b7cf-393b-42ff-4149e080321c@suse.de>
Andreas F?rber <afaerber@suse.de> writes:
> Am 17.01.2017 um 04:06 schrieb Andreas F?rber:
>> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
>> index 0d7bfbf7d922..66bc809a5eae 100644
>> --- a/arch/arm64/boot/dts/amlogic/Makefile
>> +++ b/arch/arm64/boot/dts/amlogic/Makefile
>> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb
>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
>
> What is the logic behind meson-gxm-s912-q201 vs. meson-gxm-nexbox-a1?
> Should it be renamed to include -s912 for consistency?
Oops, I think it should be renamed for consistency.
I believe there's only one chip in the GXM family (S912) so it might be
that we could either drop the -s912 from the q20x boards or, add it to
the nexbox.
I lean towards dropping the -s912 since there's a single chip in GXM.
(FWIW, GXL has more than one chip in the family so we added the chip
there.)
>> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
>
> Should this new board use meson-gxm-s912-?
No. Unless Neil or you thing otherwise, I think we should send a patch
to drop the -s912 from the q20x boards instead. (where "we" == Neil) ;)
Kevin
^ permalink raw reply
* [PATCH 2/2] ARM64: dts: meson-gxm-rbox-pro: Enable Bluetooth
From: Kevin Hilman @ 2017-01-18 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117030611.23827-3-afaerber@suse.de>
Andreas F?rber <afaerber@suse.de> writes:
> Add an SDIO reset GPIO and enable the serial used by the AP6255
> Bluetooth module. Based on work by Martin Blumenstingl.
>
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
> index 9f04fa4e5aec..6ea225f584bd 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts
> @@ -58,6 +58,7 @@
>
> aliases {
> serial0 = &uart_AO;
> + serial1 = &uart_A;
> };
>
> chosen {
> @@ -122,7 +123,8 @@
>
> sdio_pwrseq: sdio-pwrseq {
> compatible = "mmc-pwrseq-simple";
> - reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>,
> + <&gpio GPIOX_17 GPIO_ACTIVE_LOW>;
> clocks = <&wifi32k>;
> clock-names = "ext_clock";
c.f. thread on Martin's series. I don't like this (ab)use of
reset-gpios for sdio-pwrseq, and there's some work coming that will make
this much cleaner.
So, I'll hold off on this until the other solution is ready.
Kevin
^ permalink raw reply
* [PATCH 2/2] ARM64: dts: meson-gx: Add HDMI HPD/DDC pinctrl nodes
From: Kevin Hilman @ 2017-01-18 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484654738-5496-3-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Add pinctrl nodes for HDMI HPD and DDC pins modes for Amlogic Meson GXL
> and GXBB SoCs.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Applied to v4.11/dt64 with Linus' ack.
Kevin
^ permalink raw reply
* [PATCH] ARM: mm: add testcases for RODATA
From: Russell King - ARM Linux @ 2017-01-18 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5433e24-7a3d-25a4-26a3-9d02644cc3f4@redhat.com>
On Wed, Jan 18, 2017 at 11:20:54AM -0800, Laura Abbott wrote:
> On 01/18/2017 05:53 AM, Jinbum Park wrote:
> > diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
> > index bdd283b..741e2e8 100644
> > --- a/arch/arm/include/asm/cacheflush.h
> > +++ b/arch/arm/include/asm/cacheflush.h
> > @@ -498,6 +498,16 @@ static inline void set_kernel_text_rw(void) { }
> > static inline void set_kernel_text_ro(void) { }
> > #endif
> >
> > +#ifdef CONFIG_DEBUG_RODATA_TEST
> > +extern const int rodata_test_data;
> > +int rodata_test(void);
> > +#else
> > +static inline int rodata_test(void)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
I don't see why this needs to be in cacheflush.h - it doesn't seem to
have anything to do with cache flushing, and placing it in here means
that if you change the state of CONFIG_DEBUG_RODATA_TEST, most likely
the entire kernel gets rebuilt. Please put it in a separate header
file.
> > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > index 4127f57..3c15f3b 100644
> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -716,6 +716,7 @@ void fix_kernmem_perms(void)
> > int __mark_rodata_ro(void *unused)
> > {
> > update_sections_early(ro_perms, ARRAY_SIZE(ro_perms));
> > + rodata_test();
>
> We don't do anything with this return value, should we at least
> spit out a warning?
>
> > return 0;
> > }
> >
> > @@ -740,6 +741,11 @@ void set_kernel_text_ro(void)
> > static inline void fix_kernmem_perms(void) { }
> > #endif /* CONFIG_DEBUG_RODATA */
> >
> > +#ifdef CONFIG_DEBUG_RODATA_TEST
> > +const int rodata_test_data = 0xC3;
>
> This isn't accessed outside of test_rodata.c, it can just
> be moved there.
I think the intention was to place it in some .c file which gets built
into the kernel, rather than a module, so testing whether read-only
data in the kernel image is read-only.
If it's placed in a module, then you're only checking that read-only
data in the module is read-only (which is another test which should
be done!)
In any case, placing it in arch/arm/mm/init.c seems unnecessary, I'd
rather it went in its own separate file.
> > diff --git a/arch/arm/mm/test_rodata.c b/arch/arm/mm/test_rodata.c
> > new file mode 100644
> > index 0000000..133d092
> > --- /dev/null
> > +++ b/arch/arm/mm/test_rodata.c
> > @@ -0,0 +1,79 @@
> > +/*
> > + * test_rodata.c: functional test for mark_rodata_ro function
> > + *
> > + * (C) Copyright 2017 Jinbum Park <jinb.park7@gmail.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; version 2
> > + * of the License.
> > + */
> > +#include <asm/cacheflush.h>
> > +#include <asm/sections.h>
> > +
> > +int rodata_test(void)
> > +{
> > + unsigned long result;
> > + unsigned long start, end;
> > +
> > + /* test 1: read the value */
> > + /* If this test fails, some previous testrun has clobbered the state */
> > +
> > + if (!rodata_test_data) {
> > + pr_err("rodata_test: test 1 fails (start data)\n");
> > + return -ENODEV;
> > + }
> > +
> > + /* test 2: write to the variable; this should fault */
> > + /*
> > + * If this test fails, we managed to overwrite the data
> > + *
> > + * This is written in assembly to be able to catch the
> > + * exception that is supposed to happen in the correct
> > + * case
> > + */
> > +
> > + result = 1;
> > + asm volatile(
> > + "0: str %[zero], [%[rodata_test]]\n"
> > + " mov %[rslt], %[zero]\n"
> > + "1:\n"
> > + ".pushsection .text.fixup,\"ax\"\n"
> > + ".align 2\n"
> > + "2:\n"
> > + "b 1b\n"
> > + ".popsection\n"
> > + ".pushsection __ex_table,\"a\"\n"
> > + ".align 3\n"
> > + ".long 0b, 2b\n"
> > + ".popsection\n"
> > + : [rslt] "=r" (result)
> > + : [zero] "r" (0UL), [rodata_test] "r" (&rodata_test_data)
> > + );
> > +
> > + if (!result) {
> > + pr_err("rodata_test: test data was not read only\n");
> > + return -ENODEV;
> > + }
> > +
> > + /* test 3: check the value hasn't changed */
> > + /* If this test fails, we managed to overwrite the data */
> > + if (!rodata_test_data) {
> > + pr_err("rodata_test: Test 3 fails (end data)\n");
> > + return -ENODEV;
> > + }
>
> I'm confused why we are checking this again when we have the result
> check above. Is there a case where we would still have result = 1
> but rodata_test_data overwritten?
Seems sensible when you consider that "result" tests that _a_ fault
happened. Verifying that the data wasn't changed seems like a belt
and braces approach, which ensures that the location really has not
been modified.
IOW, the test is "make sure that read-only data is not modified" not
"make sure that writing to read-only data causes a fault". They're
two subtly different tests.
> As Mark mentioned, this is possibly redundant with LKDTM. It
> would be good to explain what benefit this is bringing in addition
> to LKDTM.
Finding https://lwn.net/Articles/198690/ and github links, it doesn't
seem obvious that LKDTM actually does this. It seems more focused on
creating crashdumps than testing that (in this instance) write
protection works - and it seems to be a destructive test.
--
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 v3 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
From: Rob Herring @ 2017-01-18 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484319953-6479-2-git-send-email-sergio.prado@e-labworks.com>
On Fri, Jan 13, 2017 at 01:05:52PM -0200, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C24XX
> MMC/SD/SDIO controller, used as a connectivity interface with external
> MMC, SD and SDIO storage mediums.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> .../devicetree/bindings/mmc/samsung,s3cmci.txt | 34 ++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> new file mode 100644
> index 000000000000..d09dbf4b3824
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> @@ -0,0 +1,34 @@
> +* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
> +
> +Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
> +with external MMC, SD and SDIO storage mediums.
> +
> +This file documents differences between the core mmc properties described by
> +mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
> +implementation.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> + - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
> + - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
> + - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
> +- clocks: Should reference the controller clock
> +- clock-names: Should contain "sdi"
You are missing things from the example.
> +
> +Example:
> + mmc0: mmc at 5a000000 {
> + compatible = "samsung,s3c2440-sdi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdi_pins>;
> + reg = <0x5a000000 0x100000>;
> + interrupts = <0 0 21 3>;
> + clocks = <&clocks PCLK_SDI>;
> + clock-names = "sdi";
> + bus-width = <4>;
> + cd-gpios = <&gpg 8 GPIO_ACTIVE_LOW>;
> + wp-gpios = <&gph 8 GPIO_ACTIVE_LOW>;
> + };
> +
> + Note: This example shows both SoC specific and board specific properties
> + in a single device node. The properties can be actually be separated
> + into SoC specific node and board specific node.
The source structure is not relavent to the binding.
Rob
^ permalink raw reply
* [PATCH 2/3] Documentation: devicetree: amlogic: Add R-Box Pro
From: Andreas Färber @ 2017-01-18 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <819ac0c0-92b7-bac7-dcfc-a56c34a6bf62@baylibre.com>
Am 18.01.2017 um 10:35 schrieb Neil Armstrong:
> On 01/17/2017 11:54 PM, Andreas F?rber wrote:
>> Cc: ada at kingnoval.com
>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>> ---
>> Originally I thought we would group by SoC (6, 8, 8b, gxbb, gxl, gmx, etc.)
>> but this got out of order with nexbox,a95x - so inserting kingnovel between
>> amlogic and nexbox here. If that's what we want going forward, we should move
>> the old entries to make the scheme clearer. The alternative would be to
>> reorder alphabetically within each SoC group, but nexbox,a95x with two SoCs
>> makes it difficult to categorize, we could choose gxbb as the earlier one.
>
> Andreas,
>
> Feel free to provide a fixup.
Sure, the question is which way. ;) Kevin? Carlo?
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH 00/10] fsl/qbman: ARM Enablement
From: Roy Pledge @ 2017-01-18 22:39 UTC (permalink / raw)
To: linux-arm-kernel
This patch series enables DPAA1 QBMan devices for ARM and
ARM64 architectures. This allows the LS1043A and LS1046A to use
QBMan functionality.
Claudiu Manoil (4):
soc/qbman: Use portable mapping for the FQD reserved memory
soc/qbman: Drop L1_CACHE_BYTES compile time check
soc/qbman: Add ARM equivalent for flush_dcache_range()
soc/qbman: Add missing headers on ARM
Madalin Bucur (4):
soc/qbman: Drop set/clear_bits usage
soc/qbman: add QMAN_REV32
soc/qbman: different register offsets on ARM
fsl/qbman: Enable FSL_LAYERSCAPE config on ARM
Roy Pledge (1):
soc/qbman: Rework ioremap() calls for ARM/PPC
Valentin Rothberg (1):
soc/qbman: Fix ARM32 typo
drivers/soc/fsl/qbman/Kconfig | 2 +-
drivers/soc/fsl/qbman/bman.c | 24 +++++++++++++++++-
drivers/soc/fsl/qbman/bman_portal.c | 16 +++++++++---
drivers/soc/fsl/qbman/dpaa_sys.h | 8 +++---
drivers/soc/fsl/qbman/qman.c | 46 ++++++++++++++++++++++++++++++++---
drivers/soc/fsl/qbman/qman_ccsr.c | 16 ++++++++----
drivers/soc/fsl/qbman/qman_portal.c | 16 +++++++++---
drivers/soc/fsl/qbman/qman_priv.h | 1 +
8 files changed, 107 insertions(+), 22 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 01/10] soc/qbman: Use portable mapping for the FQD reserved memory
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: Claudiu Manoil <claudiu.manoil@nxp.com>
Use memremap/memset to zero the private QBMan areas to ensure
portability.
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 | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c b/drivers/soc/fsl/qbman/qman_ccsr.c
index f4e6e70d..43feaa9 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -441,16 +441,14 @@ static unsigned int qm_get_fqid_maxcnt(void)
static int zero_priv_mem(struct device *dev, struct device_node *node,
phys_addr_t addr, size_t sz)
{
- /* map as cacheable, non-guarded */
- void __iomem *tmpp = ioremap_prot(addr, sz, 0);
-
+ void *tmpp = memremap(addr, sz, MEMREMAP_WB);
if (!tmpp)
return -ENOMEM;
- memset_io(tmpp, 0, sz);
+ memset(tmpp, 0, sz);
flush_dcache_range((unsigned long)tmpp,
(unsigned long)tmpp + sz);
- iounmap(tmpp);
+ memunmap(tmpp);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 02/10] soc/qbman: Drop set/clear_bits usage
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>
Replace PPC specific set/clear_bits API with standard
bit twiddling so driver is portalable outside PPC.
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/bman.c | 2 +-
drivers/soc/fsl/qbman/qman.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
index a3d6d7c..3acded1 100644
--- a/drivers/soc/fsl/qbman/bman.c
+++ b/drivers/soc/fsl/qbman/bman.c
@@ -607,7 +607,7 @@ int bman_p_irqsource_add(struct bman_portal *p, u32 bits)
unsigned long irqflags;
local_irq_save(irqflags);
- set_bits(bits & BM_PIRQ_VISIBLE, &p->irq_sources);
+ p->irq_sources |= bits & BM_PIRQ_VISIBLE;
bm_out(&p->p, BM_REG_IER, p->irq_sources);
local_irq_restore(irqflags);
return 0;
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 6f509f6..879e8f2 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -909,12 +909,12 @@ static inline int qm_mc_result_timeout(struct qm_portal *portal,
static inline void fq_set(struct qman_fq *fq, u32 mask)
{
- set_bits(mask, &fq->flags);
+ fq->flags |= mask;
}
static inline void fq_clear(struct qman_fq *fq, u32 mask)
{
- clear_bits(mask, &fq->flags);
+ fq->flags &= ~mask;
}
static inline int fq_isset(struct qman_fq *fq, u32 mask)
@@ -1561,7 +1561,7 @@ void qman_p_irqsource_add(struct qman_portal *p, u32 bits)
unsigned long irqflags;
local_irq_save(irqflags);
- set_bits(bits & QM_PIRQ_VISIBLE, &p->irq_sources);
+ p->irq_sources |= bits & QM_PIRQ_VISIBLE;
qm_out(&p->p, QM_REG_IER, p->irq_sources);
local_irq_restore(irqflags);
}
@@ -1584,7 +1584,7 @@ void qman_p_irqsource_remove(struct qman_portal *p, u32 bits)
*/
local_irq_save(irqflags);
bits &= QM_PIRQ_VISIBLE;
- clear_bits(bits, &p->irq_sources);
+ p->irq_sources &= ~bits;
qm_out(&p->p, QM_REG_IER, p->irq_sources);
ier = qm_in(&p->p, QM_REG_IER);
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH 03/10] soc/qbman: Drop L1_CACHE_BYTES compile time check
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: Claudiu Manoil <claudiu.manoil@nxp.com>
Not relevant and arch dependent. Overkill for PPC.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
drivers/soc/fsl/qbman/dpaa_sys.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h b/drivers/soc/fsl/qbman/dpaa_sys.h
index 2eaf318..4f1623b 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.h
+++ b/drivers/soc/fsl/qbman/dpaa_sys.h
@@ -48,10 +48,6 @@
#define DPAA_PORTAL_CE 0
#define DPAA_PORTAL_CI 1
-#if (L1_CACHE_BYTES != 32) && (L1_CACHE_BYTES != 64)
-#error "Unsupported Cacheline Size"
-#endif
-
static inline void dpaa_flush(void *p)
{
#ifdef CONFIG_PPC
--
1.7.9.5
^ permalink raw reply related
* [PATCH 04/10] soc/qbman: Fix ARM32 typo
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: Valentin Rothberg <valentinrothberg@gmail.com>
The Kconfig symbol for 32bit ARM is 'ARM', not 'ARM32'.
Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
drivers/soc/fsl/qbman/dpaa_sys.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h b/drivers/soc/fsl/qbman/dpaa_sys.h
index 4f1623b..ae65758 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.h
+++ b/drivers/soc/fsl/qbman/dpaa_sys.h
@@ -52,7 +52,7 @@ static inline void dpaa_flush(void *p)
{
#ifdef CONFIG_PPC
flush_dcache_range((unsigned long)p, (unsigned long)p+64);
-#elif defined(CONFIG_ARM32)
+#elif defined(CONFIG_ARM)
__cpuc_flush_dcache_area(p, 64);
#elif defined(CONFIG_ARM64)
__flush_dcache_area(p, 64);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 05/10] soc/qbman: Rework ioremap() calls for ARM/PPC
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>
Rework ioremap() for PPC and ARM. The PPC devices require a
non-coherent mapping while ARM will work with a non-cachable/write
combine mapping.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/bman_portal.c | 16 +++++++++++++---
drivers/soc/fsl/qbman/qman_portal.c | 16 +++++++++++++---
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/fsl/qbman/bman_portal.c b/drivers/soc/fsl/qbman/bman_portal.c
index 8354d4d..a661f30 100644
--- a/drivers/soc/fsl/qbman/bman_portal.c
+++ b/drivers/soc/fsl/qbman/bman_portal.c
@@ -125,7 +125,18 @@ static int bman_portal_probe(struct platform_device *pdev)
}
pcfg->irq = irq;
- va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]), 0);
+#ifdef CONFIG_PPC
+ /* PPC requires a cacheable/non-coherent mapping of the portal */
+ va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]),
+ (pgprot_val(PAGE_KERNEL) & ~_PAGE_COHERENT));
+#else
+ /*
+ * For ARM we can use write combine mapping. A cacheable/non shareable
+ * mapping will perform better but equires additional platform
+ * support which is not currently available
+ */
+ va = ioremap_wc(addr_phys[0]->start, resource_size(addr_phys[0]));
+#endif
if (!va) {
dev_err(dev, "ioremap::CE failed\n");
goto err_ioremap1;
@@ -133,8 +144,7 @@ static int bman_portal_probe(struct platform_device *pdev)
pcfg->addr_virt[DPAA_PORTAL_CE] = va;
- va = ioremap_prot(addr_phys[1]->start, resource_size(addr_phys[1]),
- _PAGE_GUARDED | _PAGE_NO_CACHE);
+ va = ioremap(addr_phys[1]->start, resource_size(addr_phys[1]));
if (!va) {
dev_err(dev, "ioremap::CI failed\n");
goto err_ioremap2;
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index adbaa30..e7a9eef 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -265,7 +265,18 @@ static int qman_portal_probe(struct platform_device *pdev)
}
pcfg->irq = irq;
- va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]), 0);
+#ifdef CONFIG_PPC
+ /* PPC requires a cacheable/non-coherent mapping of the portal */
+ va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]),
+ (pgprot_val(PAGE_KERNEL) & ~_PAGE_COHERENT));
+#else
+ /*
+ * For ARM we can use write combine mapping. A cacheable/non shareable
+ * mapping will perform better but equires additional platform
+ * support which is not currently available
+ */
+ va = ioremap_wc(addr_phys[0]->start, resource_size(addr_phys[0]));
+#endif
if (!va) {
dev_err(dev, "ioremap::CE failed\n");
goto err_ioremap1;
@@ -273,8 +284,7 @@ static int qman_portal_probe(struct platform_device *pdev)
pcfg->addr_virt[DPAA_PORTAL_CE] = va;
- va = ioremap_prot(addr_phys[1]->start, resource_size(addr_phys[1]),
- _PAGE_GUARDED | _PAGE_NO_CACHE);
+ va = ioremap(addr_phys[1]->start, resource_size(addr_phys[1]));
if (!va) {
dev_err(dev, "ioremap::CI failed\n");
goto err_ioremap2;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 06/10] soc/qbman: Add ARM equivalent for flush_dcache_range()
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: 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);
+#elif defined(CONFIG_ARM64)
+ __flush_dcache_area(tmpp, sz);
+#endif
memunmap(tmpp);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 07/10] soc/qbman: add QMAN_REV32
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>
Add revision 3.2 of the QBMan block. This is the version
for LS1043A and LS1046A SoCs.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/qbman/qman_ccsr.c | 2 ++
drivers/soc/fsl/qbman/qman_priv.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c b/drivers/soc/fsl/qbman/qman_ccsr.c
index 67ae073..e68793d 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -719,6 +719,8 @@ static int fsl_qman_probe(struct platform_device *pdev)
qman_ip_rev = QMAN_REV30;
else if (major == 3 && minor == 1)
qman_ip_rev = QMAN_REV31;
+ else if (major == 3 && minor == 2)
+ qman_ip_rev = QMAN_REV32;
else {
dev_err(dev, "Unknown QMan version\n");
return -ENODEV;
diff --git a/drivers/soc/fsl/qbman/qman_priv.h b/drivers/soc/fsl/qbman/qman_priv.h
index 53685b5..554d5d4 100644
--- a/drivers/soc/fsl/qbman/qman_priv.h
+++ b/drivers/soc/fsl/qbman/qman_priv.h
@@ -247,6 +247,7 @@ struct qm_portal_config {
#define QMAN_REV20 0x0200
#define QMAN_REV30 0x0300
#define QMAN_REV31 0x0301
+#define QMAN_REV32 0x0302
extern u16 qman_ip_rev; /* 0 if uninitialised, otherwise QMAN_REVx */
#define QM_FQID_RANGE_START 1 /* FQID 0 reserved for internal use */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 08/10] soc/qbman: different register offsets 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>
---
drivers/soc/fsl/qbman/bman.c | 22 ++++++++++++++++++++++
drivers/soc/fsl/qbman/qman.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
index 3acded1..1fa9099 100644
--- a/drivers/soc/fsl/qbman/bman.c
+++ b/drivers/soc/fsl/qbman/bman.c
@@ -35,6 +35,27 @@
/* Portal register assists */
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+/* Cache-inhibited register offsets */
+#define BM_REG_RCR_PI_CINH 0x3000
+#define BM_REG_RCR_CI_CINH 0x3100
+#define BM_REG_RCR_ITR 0x3200
+#define BM_REG_CFG 0x3300
+#define BM_REG_SCN(n) (0x3400 + ((n) << 6))
+#define BM_REG_ISR 0x3e00
+#define BM_REG_IER 0x3e40
+#define BM_REG_ISDR 0x3e80
+#define BM_REG_IIR 0x3ec0
+
+/* Cache-enabled register offsets */
+#define BM_CL_CR 0x0000
+#define BM_CL_RR0 0x0100
+#define BM_CL_RR1 0x0140
+#define BM_CL_RCR 0x1000
+#define BM_CL_RCR_PI_CENA 0x3000
+#define BM_CL_RCR_CI_CENA 0x3100
+
+#else
/* Cache-inhibited register offsets */
#define BM_REG_RCR_PI_CINH 0x0000
#define BM_REG_RCR_CI_CINH 0x0004
@@ -53,6 +74,7 @@
#define BM_CL_RCR 0x1000
#define BM_CL_RCR_PI_CENA 0x3000
#define BM_CL_RCR_CI_CENA 0x3100
+#endif
/*
* Portal modes.
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 879e8f2..d67b8e1 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -41,6 +41,43 @@
/* Portal register assists */
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+/* Cache-inhibited register offsets */
+#define QM_REG_EQCR_PI_CINH 0x3000
+#define QM_REG_EQCR_CI_CINH 0x3040
+#define QM_REG_EQCR_ITR 0x3080
+#define QM_REG_DQRR_PI_CINH 0x3100
+#define QM_REG_DQRR_CI_CINH 0x3140
+#define QM_REG_DQRR_ITR 0x3180
+#define QM_REG_DQRR_DCAP 0x31C0
+#define QM_REG_DQRR_SDQCR 0x3200
+#define QM_REG_DQRR_VDQCR 0x3240
+#define QM_REG_DQRR_PDQCR 0x3280
+#define QM_REG_MR_PI_CINH 0x3300
+#define QM_REG_MR_CI_CINH 0x3340
+#define QM_REG_MR_ITR 0x3380
+#define QM_REG_CFG 0x3500
+#define QM_REG_ISR 0x3600
+#define QM_REG_IER 0x3640
+#define QM_REG_ISDR 0x3680
+#define QM_REG_IIR 0x36C0
+#define QM_REG_ITPR 0x3740
+
+/* Cache-enabled register offsets */
+#define QM_CL_EQCR 0x0000
+#define QM_CL_DQRR 0x1000
+#define QM_CL_MR 0x2000
+#define QM_CL_EQCR_PI_CENA 0x3000
+#define QM_CL_EQCR_CI_CENA 0x3040
+#define QM_CL_DQRR_PI_CENA 0x3100
+#define QM_CL_DQRR_CI_CENA 0x3140
+#define QM_CL_MR_PI_CENA 0x3300
+#define QM_CL_MR_CI_CENA 0x3340
+#define QM_CL_CR 0x3800
+#define QM_CL_RR0 0x3900
+#define QM_CL_RR1 0x3940
+
+#else
/* Cache-inhibited register offsets */
#define QM_REG_EQCR_PI_CINH 0x0000
#define QM_REG_EQCR_CI_CINH 0x0004
@@ -75,6 +112,7 @@
#define QM_CL_CR 0x3800
#define QM_CL_RR0 0x3900
#define QM_CL_RR1 0x3940
+#endif
/*
* BTW, the drivers (and h/w programming model) already obtain the required
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09/10] soc/qbman: Add missing headers 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: Claudiu Manoil <claudiu.manoil@nxp.com>
Unlike PPC builds, ARM builds need following headers
explicitly:
+#include <linux/io.h> for ioread32be()
+#include <linux/delay.h> for udelay()
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
drivers/soc/fsl/qbman/dpaa_sys.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h b/drivers/soc/fsl/qbman/dpaa_sys.h
index ae65758..6239e18 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.h
+++ b/drivers/soc/fsl/qbman/dpaa_sys.h
@@ -43,6 +43,8 @@
#include <linux/prefetch.h>
#include <linux/genalloc.h>
#include <asm/cacheflush.h>
+#include <linux/io.h>
+#include <linux/delay.h>
/* For 2-element tables related to cache-inhibited and cache-enabled mappings */
#define DPAA_PORTAL_CE 0
--
1.7.9.5
^ permalink raw reply related
* [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
* [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
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