* [PATCH v1 1/2] Documentation: mtk-quadspi: update DT bindings
From: Rob Herring @ 2017-01-18 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113151326.11e9451a@bbrezillon>
On Fri, Jan 13, 2017 at 03:13:26PM +0100, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 15:13:28 +0800
> Guochun Mao <guochun.mao@mediatek.com> wrote:
>
> > Add "mediatek,mt2701-nor" for nor flash node's compatible.
> >
> > Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> > ---
> > .../devicetree/bindings/mtd/mtk-quadspi.txt | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > index fb314f0..f83d31d 100644
> > --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > @@ -1,7 +1,9 @@
> > * Serial NOR flash controller for MTK MT81xx (and similar)
> >
> > Required properties:
> > -- compatible: should be "mediatek,mt8173-nor";
> > +- compatible: should contain:
> > + "mediatek,mt2701-nor" for MT2701,
> > + "mediatek,mt8173-nor" for MT8173.
>
> Do you need to define a new compatible? If the IPs are exactly the same
> in both SoCs it shouldn't be needed.
Rather the 2701 should contain both strings in that case.
Rob
^ permalink raw reply
* [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
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