* [PATCH] clk: rockchip: fix the incorrect pclk_edp div width for RK3399
From: Heiko Stübner @ 2017-01-18 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484713256-3005-1-git-send-email-zhengxing@rock-chips.com>
Am Mittwoch, 18. Januar 2017, 12:20:56 CET schrieb Xing Zheng:
> The range of the pclk_edp_div_con is [13:8] and 6 bits, not 5.
>
> Reported-by: Lin Huang <hl@rock-chips.com>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
applied for 4.11 with Lin's test tag
Thanks
Heiko
^ permalink raw reply
* [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems
From: Jan Beulich @ 2017-01-18 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1701171309040.2347@sstabellini-ThinkPad-X260>
>>> On 17.01.17 at 23:20, <sstabellini@kernel.org> wrote:
> b) Otherwise, we could write an alternative implementation of ioremap
> on arm64. The Xen specific ioremap would request a stage-2 mapping
> first, then create the stage-1 mapping as usual. However, this means
> issuing an hypercall for every ioremap call.
+1 for this being the best choice among the ones listed. In fact
this may also be a reasonable approach for PVHv2, unless facing
resistance by the x86 maintainers.
Jan
^ permalink raw reply
* [PATCH 3/5] ARM64: dts: meson-gxbb-p20x: add reset for the ethernet PHY
From: Jerome Brunet @ 2017-01-18 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCBfJ4b1a1Bqn7kJHyj79i8UJnjJh00u3NvARzJPuUmrNA@mail.gmail.com>
On Tue, 2017-01-17 at 22:26 +0100, Martin Blumenstingl wrote:
> On Tue, Jan 17, 2017 at 8:22 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > On Sat, 2016-12-03 at 00:47 +0100, Martin Blumenstingl wrote:
> > >
> > > This resets the ethernet PHY during boot to get the PHY into a
> > > "clean"
> > > state. While here also specify the phy-handle of the ethmac node
> > > to
> > > make the PHY configuration similar to the one we have on GXL
> > > devices.
> > >
> > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemai
> > > l.co
> > > m>
> > > Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> > > ---
> > > ?arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 15
> > > +++++++++++++++
> > > ?1 file changed, 15 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > index 203be28..2abc553 100644
> > > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> > > @@ -134,10 +134,25 @@
> > > ??????pinctrl-names = "default";
> > > ?};
> > >
> > > +&mdio0 {
> > > +?????ethernet_phy0: ethernet-phy at 0 {
> > > +?????????????compatible = "ethernet-phy-ieee802.3-c22";
> > > +?????????????reg = <0>;
> >
> > Sorry for the late reply.
> > I just tried on the p200 and this patch (serie) breaks the network
> > on
> > it. The PHY is not detected anymore.
> >
> > From the KSZ9031 Datasheet : "PHY Address 0h is supported as the
> > unique
> > PHY address only; it is not supported as the broadcast PHY address
> > [...]"
> >
> > So we can't just use the broadcast address here:
> > reg should be <3>.
> OK, I'll fix that in a follow-up. as mentioned in the other thread:
> can you confirm that the PHY ID is 0x00221620?
That's right.
> It seems that I also broke meson-gxbb-nexbox-a95x.dts with that
> series
> (no idea why that slipped through): according to the photos from
> Neil's wiki [0] this seems to use an IC+ 10/100 ethernet PHY
> (probably
> an IP101A)
IP101GR from what I can see on the board.
>
> >
> > >
> > > +?????};
> > > +};
> > > +
> > > ?ðmac {
> > > ??????status = "okay";
> > > ??????pinctrl-0 = <ð_rgmii_pins>;
> > > ??????pinctrl-names = "default";
> > > +
> > > +?????phy-handle = <ðernet_phy0>;
> > > +
> > > +?????snps,reset-gpio = <&gpio GPIOZ_14 0>;
> > > +?????snps,reset-delays-us = <0 10000 1000000>;
> > > +?????snps,reset-active-low;
> > > +
> > > +?????phy-mode = "rgmii";
> >
> > We can't define this in p20x. actually the p201 uses an rmii.
> > I have not idea about gpio reset, or the phy address for the p201.
> >
> > I suppose it would be better to move this to meson-gxbb_p200.dts
> >
> > I don't know if anybody has a p201, but until we can confirm a
> > working
> > Ethernet configuration, we should probably drop it for the p201
> >
> > Of course the problem was already there before this patch ...
> indeed, that seems to be a problem.
> the GXBB Nexbox A95x I mentioned above is based on the p201 board.
> Amlogic's .dts also toggles GPIOZ_14 for it: [1]
> chances are high that it also features an IP101A PHY (this is pure
> speculation though).
Agreed, chances are high it'll be this way.
>
> I propose four patches to fix all this situation:
> - add the GPIOZ_14 reset and an ethernet_phy0 (with reg = <0>) to
> meson-gxbb-nexbox-a95x.dts
> - add the ethernet_phy0 node with reg = <0> (and ideally I also want
> to include the KSZ9031 PHY ID) to meson-gxbb-p200.dtsi along with
> phy-mode = "rgmii"
you mean with reg = <3> ?
> - add the ethernet_phy0 node with reg = <0> (without any PHY ID as we
> don't know which one is used) to meson-gxbb-p201.dtsi along with
> phy-mode = "rgmii"
> - remove "phy-mode" and ethernet_phy0 from meson-gxbb-p20x.dtsi and
> add a comment that both, the RGMII and the RMII PHY have GPIOZ_14
> connected to their reset line
I'm not too sure about these last 2 points. As you mentioned, we are
only speculating regarding the p201. I would prefer to avoid putting
things we are not sure about in the DT (as much as possible).
We could disable the ethernet for p201:
1) if nobody complains, situation remains unchanged, ethernet is not
working on that board
2) if someone complains, then we will be able to some facts from
him/her, and get it working properly.
After all, that's not a regression. With what we had in the meson-gxbb-
p20x.dtsi so far, ethernet never worked on that board.
?
>
> does that make sense?
>
>
> Regards,
> Martin
>
>
> [0] https://github.com/superna9999/linux/wiki/Boards#nexbox-a95x-s905
> [1] https://github.com/khadas/linux/blob/Vim/arch/arm64/boot/dts/amlo
> gic/gxbb_p201.dts#L186
^ permalink raw reply
* [PATCH 3/4] pinctrl: samsung: Remove support for Exynos4415 (SoC not supported anymore)
From: Linus Walleij @ 2017-01-18 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170114123642.15581-4-krzk@kernel.org>
On Sat, Jan 14, 2017 at 1:36 PM, Krzysztof Kozlowski <krzk@kernel.org> 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>
It can certainly be instantiated (from old DTBs...) but has
no DTS upstream. But I get what you mean.
Patch applied, if someone is unhappy they can always start
sending reverts.
Yours,
Linus Walleij
^ permalink raw reply
* arm: module: Add apply_relocate_add
From: Miroslav Benes @ 2017-01-18 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117044921.GI9045@packer-debian-8-amd64.digitalocean.com>
On Mon, 16 Jan 2017, Jessica Yu wrote:
> +++ Abel Vesa [06/12/16 17:06 +0000]:
> > It was only added to fix compiler error. It is not implemented
> > yet.
> >
> > Signed-off-by: Abel Vesa <abelvesa@linux.com>
> > ---
> > arch/arm/kernel/module.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> > index 4f14b5c..bf94922 100644
> > --- a/arch/arm/kernel/module.c
> > +++ b/arch/arm/kernel/module.c
> > @@ -52,6 +52,15 @@ void *module_alloc(unsigned long size)
> > #endif
> >
> > int
> > +apply_relocate_add(Elf32_Shdr *sechdrs, const char *strtab,
> > + unsigned int symindex, unsigned int relindex,
> > + struct module *module)
> > +{
> > + /* Not implemented yet */
> > + return 0;
> > +}
>
> Are SHT_RELA relocation sections actually supported on 32-bit arm? It looks
> like there's only support for SHT_REL.
>
> arch/arm/Kconfig:84: select MODULES_USE_ELF_REL
>
> If we support SHT_REL sections, the correct fix is to probably have
> klp_write_object_relocations() check if the relocation section is
> SHT_REL or SHT_RELA, and call the appropriate function (apply_relocate
> or apply_relocate_add), similar to how the module loader does it.
Agreed. According to arch/Kconfig and definitions you can use only one of
MODULES_USE_ELF_REL and MODULES_USE_ELF_RELA. arm arch uses the former. So
yes, I think we should use the same if/else construct from the module
loader in klp_write_object_relocations()... and it should go with this
patch set, because arm is the first arch to actually use SHT_REL and not
SHT_RELA (iiuc). x86, s390 and powerpc (archs we support) use SHT_RELA.
Miroslav
^ permalink raw reply
* [PATCH v2 00/13] Move pad retention control to Exynos pin controller driver
From: Linus Walleij @ 2017-01-18 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-1-git-send-email-m.szyprowski@samsung.com>
On Tue, Jan 17, 2017 at 1:44 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> This patchset is a follow-up of my work on adding runtime PM support
> to Exynos pin controller driver:
> http://www.spinics.net/lists/arm-kernel/msg550161.html
Nice, once you are done fixing the remaining nits, add Tomasz ACKs
and resend as v3 and I will apply it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4.9 032/120] efi/libstub/arm*: Pass latest memory map to the kernel
From: Greg Kroah-Hartman @ 2017-01-18 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118104648.120216880@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
commit abfb7b686a3e5be27bf81db62f9c5c895b76f5d1 upstream.
As reported by James Morse, the current libstub code involving the
annotated memory map only works somewhat correctly by accident, due
to the fact that a pool allocation happens to be reused immediately,
retaining its former contents on most implementations of the
UEFI boot services.
Instead of juggling memory maps, which makes the code more complex than
it needs to be, simply put placeholder values into the FDT for the memory
map parameters, and only write the actual values after ExitBootServices()
has been called.
Reported-by: James Morse <james.morse@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-efi at vger.kernel.org
Fixes: ed9cc156c42f ("efi/libstub: Use efi_exit_boot_services() in FDT")
Link: http://lkml.kernel.org/r/1482587963-20183-2-git-send-email-ard.biesheuvel at linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/libstub/efistub.h | 8 ---
drivers/firmware/efi/libstub/fdt.c | 87 +++++++++++++++++++++------------
2 files changed, 56 insertions(+), 39 deletions(-)
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -30,14 +30,6 @@ efi_status_t efi_file_close(void *handle
unsigned long get_dram_base(efi_system_table_t *sys_table_arg);
-efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
- unsigned long orig_fdt_size,
- void *fdt, int new_fdt_size, char *cmdline_ptr,
- u64 initrd_addr, u64 initrd_size,
- efi_memory_desc_t *memory_map,
- unsigned long map_size, unsigned long desc_size,
- u32 desc_ver);
-
efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table,
void *handle,
unsigned long *new_fdt_addr,
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -16,13 +16,10 @@
#include "efistub.h"
-efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
- unsigned long orig_fdt_size,
- void *fdt, int new_fdt_size, char *cmdline_ptr,
- u64 initrd_addr, u64 initrd_size,
- efi_memory_desc_t *memory_map,
- unsigned long map_size, unsigned long desc_size,
- u32 desc_ver)
+static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
+ unsigned long orig_fdt_size,
+ void *fdt, int new_fdt_size, char *cmdline_ptr,
+ u64 initrd_addr, u64 initrd_size)
{
int node, num_rsv;
int status;
@@ -101,25 +98,23 @@ efi_status_t update_fdt(efi_system_table
if (status)
goto fdt_set_fail;
- fdt_val64 = cpu_to_fdt64((u64)(unsigned long)memory_map);
+ fdt_val64 = U64_MAX; /* placeholder */
status = fdt_setprop(fdt, node, "linux,uefi-mmap-start",
&fdt_val64, sizeof(fdt_val64));
if (status)
goto fdt_set_fail;
- fdt_val32 = cpu_to_fdt32(map_size);
+ fdt_val32 = U32_MAX; /* placeholder */
status = fdt_setprop(fdt, node, "linux,uefi-mmap-size",
&fdt_val32, sizeof(fdt_val32));
if (status)
goto fdt_set_fail;
- fdt_val32 = cpu_to_fdt32(desc_size);
status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-size",
&fdt_val32, sizeof(fdt_val32));
if (status)
goto fdt_set_fail;
- fdt_val32 = cpu_to_fdt32(desc_ver);
status = fdt_setprop(fdt, node, "linux,uefi-mmap-desc-ver",
&fdt_val32, sizeof(fdt_val32));
if (status)
@@ -148,6 +143,43 @@ fdt_set_fail:
return EFI_LOAD_ERROR;
}
+static efi_status_t update_fdt_memmap(void *fdt, struct efi_boot_memmap *map)
+{
+ int node = fdt_path_offset(fdt, "/chosen");
+ u64 fdt_val64;
+ u32 fdt_val32;
+ int err;
+
+ if (node < 0)
+ return EFI_LOAD_ERROR;
+
+ fdt_val64 = cpu_to_fdt64((unsigned long)*map->map);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-start",
+ &fdt_val64, sizeof(fdt_val64));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ fdt_val32 = cpu_to_fdt32(*map->map_size);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-size",
+ &fdt_val32, sizeof(fdt_val32));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ fdt_val32 = cpu_to_fdt32(*map->desc_size);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-desc-size",
+ &fdt_val32, sizeof(fdt_val32));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ fdt_val32 = cpu_to_fdt32(*map->desc_ver);
+ err = fdt_setprop_inplace(fdt, node, "linux,uefi-mmap-desc-ver",
+ &fdt_val32, sizeof(fdt_val32));
+ if (err)
+ return EFI_LOAD_ERROR;
+
+ return EFI_SUCCESS;
+}
+
#ifndef EFI_FDT_ALIGN
#define EFI_FDT_ALIGN EFI_PAGE_SIZE
#endif
@@ -243,20 +275,10 @@ efi_status_t allocate_new_fdt_and_exit_b
goto fail;
}
- /*
- * Now that we have done our final memory allocation (and free)
- * we can get the memory map key needed for
- * exit_boot_services().
- */
- status = efi_get_memory_map(sys_table, &map);
- if (status != EFI_SUCCESS)
- goto fail_free_new_fdt;
-
status = update_fdt(sys_table,
(void *)fdt_addr, fdt_size,
(void *)*new_fdt_addr, new_fdt_size,
- cmdline_ptr, initrd_addr, initrd_size,
- memory_map, map_size, desc_size, desc_ver);
+ cmdline_ptr, initrd_addr, initrd_size);
/* Succeeding the first time is the expected case. */
if (status == EFI_SUCCESS)
@@ -266,20 +288,16 @@ efi_status_t allocate_new_fdt_and_exit_b
/*
* We need to allocate more space for the new
* device tree, so free existing buffer that is
- * too small. Also free memory map, as we will need
- * to get new one that reflects the free/alloc we do
- * on the device tree buffer.
+ * too small.
*/
efi_free(sys_table, new_fdt_size, *new_fdt_addr);
- sys_table->boottime->free_pool(memory_map);
new_fdt_size += EFI_PAGE_SIZE;
} else {
pr_efi_err(sys_table, "Unable to construct new device tree.\n");
- goto fail_free_mmap;
+ goto fail_free_new_fdt;
}
}
- sys_table->boottime->free_pool(memory_map);
priv.runtime_map = runtime_map;
priv.runtime_entry_count = &runtime_entry_count;
status = efi_exit_boot_services(sys_table, handle, &map, &priv,
@@ -288,6 +306,16 @@ efi_status_t allocate_new_fdt_and_exit_b
if (status == EFI_SUCCESS) {
efi_set_virtual_address_map_t *svam;
+ status = update_fdt_memmap((void *)*new_fdt_addr, &map);
+ if (status != EFI_SUCCESS) {
+ /*
+ * The kernel won't get far without the memory map, but
+ * may still be able to print something meaningful so
+ * return success here.
+ */
+ return EFI_SUCCESS;
+ }
+
/* Install the new virtual address map */
svam = sys_table->runtime->set_virtual_address_map;
status = svam(runtime_entry_count * desc_size, desc_size,
@@ -319,9 +347,6 @@ efi_status_t allocate_new_fdt_and_exit_b
pr_efi_err(sys_table, "Exit boot services failed.\n");
-fail_free_mmap:
- sys_table->boottime->free_pool(memory_map);
-
fail_free_new_fdt:
efi_free(sys_table, new_fdt_size, *new_fdt_addr);
^ permalink raw reply
* [PATCH] pwm: constify pwm_ops structures
From: Thierry Reding @ 2017-01-18 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484071926-21582-1-git-send-email-bhumirks@gmail.com>
On Tue, Jan 10, 2017 at 11:42:06PM +0530, Bhumika Goyal wrote:
> Declare pwm_ops structures as const as they are only stored in the ops
> field of a pwm_chip structure. This field is of type const struct pwm_ops
> *, so pwm_ops structures having this property can be declared as const.
> Done using Coccinelle:
>
> @r1 disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct pwm_ops i at p={...};
>
> @ok1@
> identifier r1.i;
> position p;
> struct pxa_pwm_chip pwm;
> struct bfin_pwm_chip bwm;
> struct vt8500_chip vp;
> struct imx_chip icp;
> @@
> (
> pwm.chip.ops=&i at p
> |
> bwm.chip.ops=&i at p
> |
> vp.chip.ops=&i at p
> |
> icp.chip.ops=&i at p
> )
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i at p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct pwm_ops i;
>
> File size details:
>
> text data bss dec hex filename
> 1646 328 0 1974 7b6 drivers/pwm/pwm-imx.o
> 1742 224 0 1966 7ae drivers/pwm/pwm-imx.o
>
> 1941 296 0 2237 8bd drivers/pwm/pwm-pxa.o
> 2037 192 0 2229 8b5 drivers/pwm/pwm-pxa.o
>
> 1946 296 0 2242 8c2 drivers/pwm/pwm-vt8500.o
> 2050 192 0 2242 8c2 drivers/pwm/pwm-vt8500.o
>
> The drivers/pwm/pwm-bfin.o file did not compile.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> File: drivers/pwm/pwm-bfin.c is not tested
>
> drivers/pwm/pwm-bfin.c | 2 +-
> drivers/pwm/pwm-imx.c | 2 +-
> drivers/pwm/pwm-pxa.c | 2 +-
> drivers/pwm/pwm-vt8500.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
Applied, thanks.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170118/34466a59/attachment-0001.sig>
^ permalink raw reply
* [PATCH 0/3] ARM64: meson-gxbb: Add WeTek Boards
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: linux-arm-kernel
This serie 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
Neil Armstrong (3):
dt-bindings: vendor-prefix: Add wetek vendor prefix
ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
dt-bindings: amlogic: Add WeTek boards
Documentation/devicetree/bindings/arm/amlogic.txt | 2 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 2 +
.../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 66 +++++++++++++++
.../boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 94 ++++++++++++++++++++++
5 files changed, 165 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: vendor-prefix: Add wetek vendor prefix
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484736642-5451-1-git-send-email-narmstrong@baylibre.com>
Add prefix for WeTek Electronics, limited, a company producing multimedia
Set-Top-Boxes and supporting KODI and OpenELEC distributions.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e..0c16d85 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -320,6 +320,7 @@ virtio Virtual I/O Device Specification, developed by the OASIS consortium
vivante Vivante Corporation
voipac Voipac Technologies s.r.o.
wd Western Digital Corp.
+wetek WeTek Electronics, limited.
wexler Wexler
winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ARM64: dts: meson-gxbb: Add support for WeTek Hub and Play
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484736642-5451-1-git-send-email-narmstrong@baylibre.com>
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>
---
arch/arm64/boot/dts/amlogic/Makefile | 2 +
.../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 66 +++++++++++++++
.../boot/dts/amlogic/meson-gxbb-wetek-play2.dts | 94 ++++++++++++++++++++++
3 files changed, 162 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 0d7bfbf..cc2e2dd 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -5,6 +5,8 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-p201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-meta.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-telos.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-hub.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-play2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
new file mode 100644
index 0000000..56f8559
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
@@ -0,0 +1,66 @@
+/*
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library 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; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+
+/ {
+ compatible = "wetek,hub", "amlogic,meson-gxbb";
+ model = "WeTek Hub";
+
+ leds {
+ compatible = "gpio-leds";
+
+ system {
+ label = "wetek-play:system-status";
+ gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ panic-indicator;
+ };
+ };
+
+ cvbs-connector {
+ status = "disabled";
+ };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
new file mode 100644
index 0000000..ea79fdd
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library 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; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ compatible = "wetek,play2", "amlogic,meson-gxbb";
+ model = "WeTek Play 2";
+
+ leds {
+ compatible = "gpio-leds";
+
+ system {
+ label = "wetek-play:system-status";
+ gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ panic-indicator;
+ };
+
+ wifi {
+ label = "wetek-play:wifi-status";
+ gpios = <&gpio GPIODV_26 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ ethernet {
+ label = "wetek-play:ethernet-status";
+ gpios = <&gpio GPIODV_27 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <100>;
+
+ button at 0 {
+ label = "reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&i2c_A {
+ status = "okay";
+ pinctrl-0 = <&i2c_a_pins>;
+ pinctrl-names = "default";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: amlogic: Add WeTek boards
From: Neil Armstrong @ 2017-01-18 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484736642-5451-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index 9b2b41a..c246cd2 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -40,6 +40,8 @@ Board compatible values:
- "hardkernel,odroid-c2" (Meson gxbb)
- "amlogic,p200" (Meson gxbb)
- "amlogic,p201" (Meson gxbb)
+ - "wetek,hub" (Meson gxbb)
+ - "wetek,play2" (Meson gxbb)
- "amlogic,p212" (Meson gxl s905x)
- "amlogic,p230" (Meson gxl s905d)
- "amlogic,p231" (Meson gxl s905d)
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] ARM: DTS: Fix broken GICv2 register maps
From: Marc Zyngier @ 2017-01-18 10:53 UTC (permalink / raw)
To: linux-arm-kernel
For a GICv2 (which happens to be virtualization capable), the
architecture mandates the following regions:
GICD: 4kB
GICC: 8kB
GICH: 8kB
GICV: 8kB
Unfortunately, I made a mistake in one of the examples contained in
the DT binding document, and everyone duplicated that same mistake all
over the map.
This small series fixes the DT binding, and hopefully updates all the
offending DTs to be compliant with the architecture.
Marc Zyngier (2):
dt-bindings: arm,gic: Fix binding example for a virt-capable GIC
ARM: DTS: Fix register map for virt-capable GIC
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt | 4 ++--
arch/arm/boot/dts/alpine.dtsi | 2 +-
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
arch/arm/boot/dts/imx6ul.dtsi | 4 ++--
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone.dtsi | 2 +-
arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
arch/arm/boot/dts/mt2701.dtsi | 2 +-
arch/arm/boot/dts/mt6580.dtsi | 2 +-
arch/arm/boot/dts/mt6589.dtsi | 2 +-
arch/arm/boot/dts/mt7623.dtsi | 2 +-
arch/arm/boot/dts/mt8127.dtsi | 2 +-
arch/arm/boot/dts/mt8135.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi | 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7743.dtsi | 2 +-
arch/arm/boot/dts/r8a7745.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/r8a7792.dtsi | 2 +-
arch/arm/boot/dts/r8a7793.dtsi | 2 +-
arch/arm/boot/dts/r8a7794.dtsi | 2 +-
arch/arm/boot/dts/rk1108.dtsi | 2 +-
arch/arm/boot/dts/rk3036.dtsi | 2 +-
arch/arm/boot/dts/rk322x.dtsi | 2 +-
arch/arm/boot/dts/rk3288.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 4 ++--
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
38 files changed, 42 insertions(+), 42 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm, gic: Fix binding example for a virt-capable GIC
From: Marc Zyngier @ 2017-01-18 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484736811-24002-1-git-send-email-marc.zyngier@arm.com>
The joys of copy/paste: the example of a virtualization capable GIC
in the DT binding was wrong, and propagated to dozens of platforms.
Oh well. Let's fix the source of the crap before tackling individual
offenders.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
index 5393e2a..a3d51ed 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
@@ -107,11 +107,11 @@ Required properties:
Example:
interrupt-controller at 2c001000 {
- compatible = "arm,cortex-a15-gic";
+ compatible = "arm,gic-400";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
- <0x2c002000 0x1000>,
+ <0x2c002000 0x2000>,
<0x2c004000 0x2000>,
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] ARM: DTS: Fix register map for virt-capable GIC
From: Marc Zyngier @ 2017-01-18 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484736811-24002-1-git-send-email-marc.zyngier@arm.com>
Since everybody copied my own mistake from the DT binding example,
let's address all the offenders in one swift go.
Most of them got the CPU interface size wrong (4kB, while it should
be 8kB), except for both keystone platforms which got the control
interface wrong (4kB instead of 8kB).
In the couple of cases were I knew for sure what implementation
was used, I've added the "arm,gic-400" compatible string. I'm 99%
sure that this is what everyong is using, but short of having the
TRM for all the other SoCs, I've let them alone.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/boot/dts/alpine.dtsi | 2 +-
arch/arm/boot/dts/axm55xx.dtsi | 2 +-
arch/arm/boot/dts/dra7.dtsi | 2 +-
arch/arm/boot/dts/ecx-2000.dts | 2 +-
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5260.dtsi | 2 +-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
arch/arm/boot/dts/imx6ul.dtsi | 4 ++--
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone.dtsi | 2 +-
arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
arch/arm/boot/dts/mt2701.dtsi | 2 +-
arch/arm/boot/dts/mt6580.dtsi | 2 +-
arch/arm/boot/dts/mt6589.dtsi | 2 +-
arch/arm/boot/dts/mt7623.dtsi | 2 +-
arch/arm/boot/dts/mt8127.dtsi | 2 +-
arch/arm/boot/dts/mt8135.dtsi | 2 +-
arch/arm/boot/dts/omap5.dtsi | 2 +-
arch/arm/boot/dts/r8a73a4.dtsi | 2 +-
arch/arm/boot/dts/r8a7743.dtsi | 2 +-
arch/arm/boot/dts/r8a7745.dtsi | 2 +-
arch/arm/boot/dts/r8a7790.dtsi | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 2 +-
arch/arm/boot/dts/r8a7792.dtsi | 2 +-
arch/arm/boot/dts/r8a7793.dtsi | 2 +-
arch/arm/boot/dts/r8a7794.dtsi | 2 +-
arch/arm/boot/dts/rk1108.dtsi | 2 +-
arch/arm/boot/dts/rk3036.dtsi | 2 +-
arch/arm/boot/dts/rk322x.dtsi | 2 +-
arch/arm/boot/dts/rk3288.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31.dtsi | 2 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 4 ++--
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
37 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/arch/arm/boot/dts/alpine.dtsi b/arch/arm/boot/dts/alpine.dtsi
index db8752f..d0eefc3 100644
--- a/arch/arm/boot/dts/alpine.dtsi
+++ b/arch/arm/boot/dts/alpine.dtsi
@@ -93,7 +93,7 @@
interrupt-controller;
reg = <0x0 0xfb001000 0x0 0x1000>,
<0x0 0xfb002000 0x0 0x2000>,
- <0x0 0xfb004000 0x0 0x1000>,
+ <0x0 0xfb004000 0x0 0x2000>,
<0x0 0xfb006000 0x0 0x2000>;
interrupts =
<GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/axm55xx.dtsi b/arch/arm/boot/dts/axm55xx.dtsi
index a9d6d59..47799f5 100644
--- a/arch/arm/boot/dts/axm55xx.dtsi
+++ b/arch/arm/boot/dts/axm55xx.dtsi
@@ -62,7 +62,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0x20 0x01001000 0 0x1000>,
- <0x20 0x01002000 0 0x1000>,
+ <0x20 0x01002000 0 0x2000>,
<0x20 0x01004000 0 0x2000>,
<0x20 0x01006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) |
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1faf24a..a9ffa49 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -57,7 +57,7 @@
interrupt-controller;
#interrupt-cells = <3>;
reg = <0x0 0x48211000 0x0 0x1000>,
- <0x0 0x48212000 0x0 0x1000>,
+ <0x0 0x48212000 0x0 0x2000>,
<0x0 0x48214000 0x0 0x2000>,
<0x0 0x48216000 0x0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/ecx-2000.dts b/arch/arm/boot/dts/ecx-2000.dts
index 2ccbb57f..c15e7e0 100644
--- a/arch/arm/boot/dts/ecx-2000.dts
+++ b/arch/arm/boot/dts/ecx-2000.dts
@@ -99,7 +99,7 @@
interrupt-controller;
interrupts = <1 9 0xf04>;
reg = <0xfff11000 0x1000>,
- <0xfff12000 0x1000>,
+ <0xfff12000 0x2000>,
<0xfff14000 0x2000>,
<0xfff16000 0x2000>;
};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index ba17ee1..9c28ef4 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -234,7 +234,7 @@
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x10481000 0x1000>,
- <0x10482000 0x1000>,
+ <0x10482000 0x2000>,
<0x10484000 0x2000>,
<0x10486000 0x2000>;
interrupts = <GIC_PPI 9
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 7fd870e..678c08e 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -94,7 +94,7 @@
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x10481000 0x1000>,
- <0x10482000 0x1000>,
+ <0x10482000 0x2000>,
<0x10484000 0x2000>,
<0x10486000 0x2000>;
interrupts = <GIC_PPI 9
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 5818718..5e88c96 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -167,7 +167,7 @@
#size-cells = <0>;
interrupt-controller;
reg = <0x10481000 0x1000>,
- <0x10482000 0x1000>,
+ <0x10482000 0x2000>,
<0x10484000 0x2000>,
<0x10486000 0x2000>;
interrupts = <GIC_PPI 9
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 2a2e570..77d35bb 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -40,7 +40,7 @@
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x2E1000 0x1000>,
- <0x2E2000 0x1000>,
+ <0x2E2000 0x2000>,
<0x2E4000 0x2000>,
<0x2E6000 0x2000>;
interrupts = <GIC_PPI 9
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 39845a7..ac5371a 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -91,11 +91,11 @@
};
intc: interrupt-controller@00a01000 {
- compatible = "arm,cortex-a7-gic";
+ compatible = "arm,gic-400", "arm,cortex-a7-gic";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x00a01000 0x1000>,
- <0x00a02000 0x1000>,
+ <0x00a02000 0x2000>,
<0x00a04000 0x2000>,
<0x00a06000 0x2000>;
};
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 63c7cf0..07bf300 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -45,7 +45,7 @@
interrupt-controller;
reg = <0x0 0x02561000 0x0 0x1000>,
<0x0 0x02562000 0x0 0x2000>,
- <0x0 0x02564000 0x0 0x1000>,
+ <0x0 0x02564000 0x0 0x2000>,
<0x0 0x02566000 0x0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba..aaff6816 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -35,7 +35,7 @@
interrupt-controller;
reg = <0x0 0x02561000 0x0 0x1000>,
<0x0 0x02562000 0x0 0x2000>,
- <0x0 0x02564000 0x0 0x1000>,
+ <0x0 0x02564000 0x0 0x2000>,
<0x0 0x02566000 0x0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 282d854..45ea57f 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -110,11 +110,11 @@
ranges;
gic: interrupt-controller at 1400000 {
- compatible = "arm,cortex-a7-gic";
+ compatible = "arm,gic-400", "arm,cortex-a7-gic";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x0 0x1401000 0x0 0x1000>,
- <0x0 0x1402000 0x0 0x1000>,
+ <0x0 0x1402000 0x0 0x2000>,
<0x0 0x1404000 0x0 0x2000>,
<0x0 0x1406000 0x0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 7eab6f4..454d099 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -170,7 +170,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0 0x10211000 0 0x1000>,
- <0 0x10212000 0 0x1000>,
+ <0 0x10212000 0 0x2000>,
<0 0x10214000 0 0x2000>,
<0 0x10216000 0 0x2000>;
};
diff --git a/arch/arm/boot/dts/mt6580.dtsi b/arch/arm/boot/dts/mt6580.dtsi
index 06fdf6c..a349dba 100644
--- a/arch/arm/boot/dts/mt6580.dtsi
+++ b/arch/arm/boot/dts/mt6580.dtsi
@@ -91,7 +91,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0x10211000 0x1000>,
- <0x10212000 0x1000>,
+ <0x10212000 0x2000>,
<0x10214000 0x2000>,
<0x10216000 0x2000>;
};
diff --git a/arch/arm/boot/dts/mt6589.dtsi b/arch/arm/boot/dts/mt6589.dtsi
index 88b3cb1..0d6f60a 100644
--- a/arch/arm/boot/dts/mt6589.dtsi
+++ b/arch/arm/boot/dts/mt6589.dtsi
@@ -102,7 +102,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0x10211000 0x1000>,
- <0x10212000 0x1000>,
+ <0x10212000 0x2000>,
<0x10214000 0x2000>,
<0x10216000 0x2000>;
};
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index fd2b614..19a54a3 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -104,7 +104,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0 0x10211000 0 0x1000>,
- <0 0x10212000 0 0x1000>,
+ <0 0x10212000 0 0x2000>,
<0 0x10214000 0 0x2000>,
<0 0x10216000 0 0x2000>;
};
diff --git a/arch/arm/boot/dts/mt8127.dtsi b/arch/arm/boot/dts/mt8127.dtsi
index 52086c8..916c095 100644
--- a/arch/arm/boot/dts/mt8127.dtsi
+++ b/arch/arm/boot/dts/mt8127.dtsi
@@ -129,7 +129,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0 0x10211000 0 0x1000>,
- <0 0x10212000 0 0x1000>,
+ <0 0x10212000 0 0x2000>,
<0 0x10214000 0 0x2000>,
<0 0x10216000 0 0x2000>;
};
diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index 1d7f92b..a97b4ee 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -221,7 +221,7 @@
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0 0x10211000 0 0x1000>,
- <0 0x10212000 0 0x1000>,
+ <0 0x10212000 0 0x2000>,
<0 0x10214000 0 0x2000>,
<0 0x10216000 0 0x2000>;
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cd92ba..71b4809 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -92,7 +92,7 @@
interrupt-controller;
#interrupt-cells = <3>;
reg = <0 0x48211000 0 0x1000>,
- <0 0x48212000 0 0x1000>,
+ <0 0x48212000 0 0x2000>,
<0 0x48214000 0 0x2000>,
<0 0x48216000 0 0x2000>;
interrupt-parent = <&gic>;
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 53183ff..14a66ca 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -465,7 +465,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 216cb1f..172a944 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -55,7 +55,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0b2e2f3..7390ec0 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -55,7 +55,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 0c8900d..ac38764 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -183,7 +183,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 8721466..28039db 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -114,7 +114,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 6ced3c1..1ed5c88 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -88,7 +88,7 @@
#interrupt-cells = <3>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 2fb527c..934c097 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -105,7 +105,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index fb576db..09f7823 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -71,7 +71,7 @@
#address-cells = <0>;
interrupt-controller;
reg = <0 0xf1001000 0 0x1000>,
- <0 0xf1002000 0 0x1000>,
+ <0 0xf1002000 0 0x2000>,
<0 0xf1004000 0 0x2000>,
<0 0xf1006000 0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/rk1108.dtsi b/arch/arm/boot/dts/rk1108.dtsi
index d770023..d6194bf 100644
--- a/arch/arm/boot/dts/rk1108.dtsi
+++ b/arch/arm/boot/dts/rk1108.dtsi
@@ -215,7 +215,7 @@
#address-cells = <0>;
reg = <0x32011000 0x1000>,
- <0x32012000 0x1000>,
+ <0x32012000 0x2000>,
<0x32014000 0x2000>,
<0x32016000 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 4ed49a2..ff9b90b 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -189,7 +189,7 @@
#address-cells = <0>;
reg = <0x10139000 0x1000>,
- <0x1013a000 0x1000>,
+ <0x1013a000 0x2000>,
<0x1013c000 0x2000>,
<0x1013e000 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 9d3aee5..9dff822 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -443,7 +443,7 @@
#address-cells = <0>;
reg = <0x32011000 0x1000>,
- <0x32012000 0x1000>,
+ <0x32012000 0x2000>,
<0x32014000 0x2000>,
<0x32016000 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 4fad133..af46cba 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1110,7 +1110,7 @@
#address-cells = <0>;
reg = <0xffc01000 0x1000>,
- <0xffc02000 0x1000>,
+ <0xffc02000 0x2000>,
<0xffc04000 0x2000>,
<0xffc06000 0x2000>;
interrupts = <GIC_PPI 9 0xf04>;
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 2b26175..6ed505a 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -861,7 +861,7 @@
gic: interrupt-controller at 01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
- <0x01c82000 0x1000>,
+ <0x01c82000 0x2000>,
<0x01c84000 0x2000>,
<0x01c86000 0x2000>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index f7db067..3c24832 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1686,9 +1686,9 @@
};
gic: interrupt-controller at 01c81000 {
- compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
+ compatible = "arm,gic-400", "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
- <0x01c82000 0x1000>,
+ <0x01c82000 0x2000>,
<0x01c84000 0x2000>,
<0x01c86000 0x2000>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index e4991a7..49dfe86 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -489,7 +489,7 @@
gic: interrupt-controller at 01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
- <0x01c82000 0x1000>,
+ <0x01c82000 0x2000>,
<0x01c84000 0x2000>,
<0x01c86000 0x2000>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index d3473f8..04c3fdd 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -217,7 +217,7 @@
gic: interrupt-controller at 01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
- <0x01c82000 0x1000>,
+ <0x01c82000 0x2000>,
<0x01c84000 0x2000>,
<0x01c86000 0x2000>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 6c14a6f..292abd0 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -580,7 +580,7 @@
gic: interrupt-controller at 01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
- <0x01c82000 0x1000>,
+ <0x01c82000 0x2000>,
<0x01c84000 0x2000>,
<0x01c86000 0x2000>;
interrupt-controller;
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 979ad1a..b7b5831 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -613,7 +613,7 @@
gic: interrupt-controller at 01c41000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c41000 0x1000>,
- <0x01c42000 0x1000>,
+ <0x01c42000 0x2000>,
<0x01c44000 0x2000>,
<0x01c46000 0x2000>;
interrupt-controller;
--
2.1.4
^ permalink raw reply related
* [GIT PULL] DaVinci fix for v4.10
From: Sekhar Nori @ 2017-01-18 10:53 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5:
Linux 4.10-rc4 (2017-01-15 16:21:59 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.10-part2
for you to fetch changes up to 6f042ee9cc09792c1c0f0cd8f275c2b4b29eaa96:
ARM: dts: da850-evm: fix read access to SPI flash (2017-01-18 15:38:08 +0530)
----------------------------------------------------------------
This patch uses fast-read opcode to read the
SPI flash. This is needed for error-free read
at 30Mhz.
----------------------------------------------------------------
Fabien Parent (1):
ARM: dts: da850-evm: fix read access to SPI flash
arch/arm/boot/dts/da850-evm.dts | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [PATCH RFC 0/5] mvebu cleanups and preparation for Armada 7k/8k
From: Thomas Petazzoni @ 2017-01-18 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYWV2N7JxyJiLNpygOSw308qTzdtv+5f6Ej-fU4pvM6ew@mail.gmail.com>
Hello,
On Wed, 18 Jan 2017 09:52:31 +0100, Linus Walleij wrote:
> > BTW, would be useful if MAINTAINERS could list maintainers for both
> > this code and the mvebu gpio code too. At the moment, it seems Linus
> > is the person responsible for both of those - but I suspect the mvebu
> > people want to be copied on patches...
>
> Agreed. Since they are silent I will likely simply apply the patches,
> they certainly look good to me.
Sorry, I'm away on travel. The patches looked generally good to me,
though I haven't had the time to do a thorough review. I'll post a
patch for the MAINTAINERS file, as suggested by Russell.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-18 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04113569-e342-77ff-f79a-2c9c4dc4c602@suse.de>
On 01/18/2017 01:00 AM, Andreas F?rber wrote:
> Hi Neil,
>
> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>> As I finally understand, the real issue here is the usage of the "linux,useable-memory" property that
>> overrides the reg property that is changed by the bootloader to provide the "real" memory size.
>
> Yes, exactly. It assured that 0..0x01000000 was always unavailable, as
> intended, but at the same time it ignored any lowered or heightened
> upper limit coming from the bootloader side.
>
> As a rule of thumb, any nodes that have device_type set can be expected
> to be modified during boot.
>
>> As I understand the mainline U-Boot does it right, and it's a good news, and it seems uEFI need to provide
>> some specialized memory range aswell, but the vendor U-Boot versions only provide the full memory range here.
>> It seems obvious that whatever range is provided by u-boot, the first 16MiB should be reserved.
>>
>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>> zones,
>
> Thanks, its binary is called stress-ng in openSUSE Tumbleweed. ;)
>
>> but I also got the issue while running a fully fledged Desktop Environment thanks to the
>> recently merged DRM driver.
>
> I'll happily test once HDMI is ready. :)
>
>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>> But it should be confirmed.
>
> Confirming no issues on three runs on meson-gxm-rbox-pro:
>
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
> [1] 2528
> boxer:~ # stress-ng: info: [2528] dispatching hogs: 4 vm
> stress-ng: info: [2528] cache allocate: default cache size: 256K
> stress-ng: info: [2528] successful run completed in 10.07s
>
> [1]+ Done stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info: [2537] dispatching hogs: 4 vm
> stress-ng: info: [2537] cache allocate: default cache size: 256K
> stress-ng: info: [2537] successful run completed in 10.07s
> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
> stress-ng: info: [2546] dispatching hogs: 4 vm
> stress-ng: info: [2546] cache allocate: default cache size: 256K
> stress-ng: info: [2546] successful run completed in 10.07s
> boxer:~ #
For 2 GiB boards, you may need to increase the vm threads :
# stress-ng --vm 16 --vm-bytes 128M --timeout 10s
stress-ng: info: [1292] dispatching hogs: 16 vm
stress-ng: info: [1292] cache allocate: default cache size: 512K
stress: info: [1275] dispatching hogs: 0 cpu, 0 io, 16 vm, 0 hdd
[ 948.832694] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
[ 948.832812] Bad mode in Error handler detected on CPU3, code 0xbf000000 -- SError
[ 948.832832] CPU: 3 PID: 1279 Comm: stress Not tainted 4.10.0-rc4-00004-gba7e7b8 #14
...
On a Wetek Play2 board with 2GiB.
>
>> Kevin asked me initially to handle this "start of ddr" reserved zone via a reserved-memory entry, but
>> at that time it seemed a better idea to use "linux,useable-memory", but I recon it may be an error.
>>
>> I will push a v5 with a supplementary reserved-memory entry and will postpone the boards memory size
>> fixup for a future DTS cleanup.
>>
>> Andreas, is this ok for you ?
>
> Yes, sounds fine to me, thanks. I'll note a few more nits to consider.
>
> Kevin, I noticed that this supposedly applied patch did not show up in
> linux-next for testing - could you merge your fixes branch into for-next
> please for those of us working on new stuff?
>
>> This issue exists since forever on mainline linux, and even 4.9 has it.
>> Olof, How could a similar fix go in 4.9 stable ?
>
> I guess it would then be best to consider splitting this patch up per
> board/SoC so that you can set appropriate Fixes: headers indicating how
> far back each one needs to be fixed.
>
> Regards,
> Andreas
>
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-18 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6bba535f-42bc-3e4b-129b-adc39152cfeb@suse.de>
On 01/18/2017 01:27 AM, Andreas F?rber wrote:
> Am 18.01.2017 um 01:00 schrieb Andreas F?rber:
>> Am 17.01.2017 um 09:21 schrieb Neil Armstrong:
>>> The stress-ng package provides this "stress" command and is used to force the kernel to map more memory
>>> zones, but I also got the issue while running a fully fledged Desktop Environment thanks to the
>>> recently merged DRM driver.
>>> You may not be able to trigger the issue since it seems Amlogic reduces this reserved size on GXL/GXM :
>>> https://github.com/khadas/linux/commit/698df2c6cfbb0d1a9359743208e83517b31da6ce
>>> But it should be confirmed.
>>
>> Confirming no issues on three runs on meson-gxm-rbox-pro:
>>
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s &
>> [1] 2528
>> boxer:~ # stress-ng: info: [2528] dispatching hogs: 4 vm
>> stress-ng: info: [2528] cache allocate: default cache size: 256K
>> stress-ng: info: [2528] successful run completed in 10.07s
>>
>> [1]+ Done stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> stress-ng: info: [2537] dispatching hogs: 4 vm
>> stress-ng: info: [2537] cache allocate: default cache size: 256K
>> stress-ng: info: [2537] successful run completed in 10.07s
>> boxer:~ # stress-ng --vm 4 --vm-bytes 128M --timeout 10s
>> stress-ng: info: [2546] dispatching hogs: 4 vm
>> stress-ng: info: [2546] cache allocate: default cache size: 256K
>> stress-ng: info: [2546] successful run completed in 10.07s
>> boxer:~ #
>
> Similar results on meson-gxbb-vega-s95-telos (except 512K cache size),
> with both mainline EFI and vendor U-Boot.
>
> I notice that I don't have CONFIG_DRM enabled - maybe related?
Yes, It may add more pressure on the memory allocation.
Neil
>
> Regards,
> Andreas
>
^ permalink raw reply
* [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems
From: Roger Pau Monné @ 2017-01-18 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1701171309040.2347@sstabellini-ThinkPad-X260>
On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:
> a) One option is to provide a Xen specific implementation of
> acpi_os_ioremap in Linux. I think this is the cleanest approach, but
> unfortunately, it doesn't cover cases where ioremap is used directly. (2)
> is one of such cases, see
> arch/arm64/kernel/pci.c:pci_acpi_setup_ecam_mapping and
> drivers/pci/ecam.c:pci_ecam_create. (3) is another one of these cases,
> see drivers/acpi/apei/bert.c:bert_init.
This is basically the same as b) from Xen's PoV, the only difference is where
you would call the hypercall from Dom0 to establish stage-2 mappings.
> b) Otherwise, we could write an alternative implementation of ioremap
> on arm64. The Xen specific ioremap would request a stage-2 mapping
> first, then create the stage-1 mapping as usual. However, this means
> issuing an hypercall for every ioremap call.
This seems fine to me, and at present is the only way to get something working.
As you said not being able to discover OperationRegions from Xen means that
there's a chance some MMIO might not be added to the stage-2 mappings.
Then what's the initial memory map state when Dom0 is booted? There are no MMIO
mappings at all, and Dom0 must request mappings for everything?
What happens to ACPI tables crafted for Dom0 that reside in RAM? That would
apply to the STAO and to the other tables that are crafted for Dom0 at build
time. Should Dom0 also request stage-2 mappings for them, and Xen simply ignore
those calls?
> c) Finally, a third option is to create the stage-2 mappings seamlessly
> in Xen upon Dom0 memory faults. Keeping in mind that SMMU and guest
> pagetables are shared in the Xen hypervisor, this approach does not work
> if one of the pages that need a stage-2 mapping is used as DMA target
> before Dom0 accesses it. No SMMU mappings would be available for the
> page yet, so the DMA transaction would fail. After Dom0 touches the
> page, the DMA transaction would succeed. I don't know how likely is this
> scenario to happen, but it seems fragile to rely on it.
Don't you get faults on SMMU failures? But I guess those are not synchronous,
so there's no way you can add mappings on fault, like you can for processor
accesses.
Roger.
^ permalink raw reply
* [RFC PATCH v5 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Vladimir Murzin @ 2017-01-18 11:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
It seem that addition of cache support for M-class CPUs uncovered
latent bug in DMA usage. NOMMU memory model has been treated as being
always consistent; however, for R/M CPU classes memory can be covered
by MPU which in turn might configure RAM as Normal i.e. bufferable and
cacheable. It breaks dma_alloc_coherent() and friends, since data can
stuck in caches now or be buffered.
This patch set is trying to address the issue by providing region of
memory suitable for consistent DMA operations. It is supposed that
such region is marked by MPU as non-cacheable. Robin suggested to
advertise such memory as reserved shared-dma-pool, rather then using
homebrew command line option, and extend dma-coherent to provide
default DMA area in the similar way as it is done for CMA (PATCH
4/7). It allows us to offload all bookkeeping on generic coherent DMA
framework, and it seems that it might be reused by other architectures
like c6x and blackfin.
While reviewing/testing previous vesrions of the patch set it turned
out that dma-coherent does not take into account "dma-ranges" device
tree property, so it is addressed in PATCH 3/7.
For ARM, dedicated DMA region is required for cases other than:
- MMU/MPU is off
- cpu is v7m w/o cache support
- device is coherent
In case one of the above conditions is true dma operations are forced
to be coherent and wired with dma_noop_ops.
To make life easier NOMMU dma operations are kept in separate
compilation unit.
Since the issue was reported in the same time as Benjamin sent his
patch [1] to allow mmap for NOMMU, his case is also addressed in this
series (PATCH 1/7 and PATCH 2/7).
Thanks!
[1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Vladimir Murzin (7):
dma: Take into account dma_pfn_offset
dma: Add simple dma_noop_mmap
drivers: dma-coherent: Account dma_pfn_offset when used with device
tree
drivers: dma-coherent: Introduce default DMA pool
ARM: NOMMU: Introduce dma operations for noMMU
ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
ARM: dma-mapping: Remove traces of NOMMU code
.../bindings/reserved-memory/reserved-memory.txt | 3 +
arch/arm/include/asm/dma-mapping.h | 3 +-
arch/arm/mm/Kconfig | 2 +-
arch/arm/mm/Makefile | 5 +-
arch/arm/mm/dma-mapping-nommu.c | 252 +++++++++++++++++++++
arch/arm/mm/dma-mapping.c | 26 +--
drivers/base/dma-coherent.c | 76 ++++++-
lib/dma-noop.c | 29 ++-
8 files changed, 355 insertions(+), 41 deletions(-)
create mode 100644 arch/arm/mm/dma-mapping-nommu.c
--
2.0.0
^ permalink raw reply
* [RFC PATCH v5 1/7] dma: Take into account dma_pfn_offset
From: Vladimir Murzin @ 2017-01-18 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484738003-29892-1-git-send-email-vladimir.murzin@arm.com>
Even though dma-noop-ops assumes 1:1 memory mapping DMA memory range
can be different to RAM. For example, ARM STM32F4 MCU offers the
possibility to remap SDRAM from 0xc000_0000 to 0x0 to get CPU
performance boost, but DMA continue to see SDRAM at 0xc000_0000. This
difference in mapping is handled via device-tree "dma-range" property
which leads to dev->dma_pfn_offset is set nonzero. To handle such
cases take dma_pfn_offset into account.
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Reported-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
lib/dma-noop.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index 3d766e7..a14eee5 100644
--- a/lib/dma-noop.c
+++ b/lib/dma-noop.c
@@ -7,6 +7,7 @@
#include <linux/mm.h>
#include <linux/dma-mapping.h>
#include <linux/scatterlist.h>
+#include <linux/pfn.h>
static void *dma_noop_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp,
@@ -16,7 +17,8 @@ static void *dma_noop_alloc(struct device *dev, size_t size,
ret = (void *)__get_free_pages(gfp, get_order(size));
if (ret)
- *dma_handle = virt_to_phys(ret);
+ *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
+
return ret;
}
@@ -32,7 +34,7 @@ static dma_addr_t dma_noop_map_page(struct device *dev, struct page *page,
enum dma_data_direction dir,
unsigned long attrs)
{
- return page_to_phys(page) + offset;
+ return page_to_phys(page) + offset - PFN_PHYS(dev->dma_pfn_offset);
}
static int dma_noop_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
@@ -47,7 +49,7 @@ static int dma_noop_map_sg(struct device *dev, struct scatterlist *sgl, int nent
BUG_ON(!sg_page(sg));
va = sg_virt(sg);
- sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
+ sg_dma_address(sg) = (dma_addr_t)(virt_to_phys(va) - PFN_PHYS(dev->dma_pfn_offset));
sg_dma_len(sg) = sg->length;
}
--
2.0.0
^ permalink raw reply related
* [RFC PATCH v5 2/7] dma: Add simple dma_noop_mmap
From: Vladimir Murzin @ 2017-01-18 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484738003-29892-1-git-send-email-vladimir.murzin@arm.com>
This patch adds a simple implementation of mmap to dma_noop_ops.
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Reported-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
lib/dma-noop.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index a14eee5..70504eb 100644
--- a/lib/dma-noop.c
+++ b/lib/dma-noop.c
@@ -66,6 +66,26 @@ static int dma_noop_supported(struct device *dev, u64 mask)
return 1;
}
+static int dma_noop_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+ unsigned long user_count = vma_pages(vma);
+ unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
+ unsigned long off = vma->vm_pgoff;
+ int ret = -ENXIO;
+
+ if (off < count && user_count <= (count - off)) {
+ ret = remap_pfn_range(vma, vma->vm_start,
+ pfn + off,
+ user_count << PAGE_SHIFT,
+ vma->vm_page_prot);
+ }
+
+ return ret;
+}
+
struct dma_map_ops dma_noop_ops = {
.alloc = dma_noop_alloc,
.free = dma_noop_free,
@@ -73,6 +93,7 @@ struct dma_map_ops dma_noop_ops = {
.map_sg = dma_noop_map_sg,
.mapping_error = dma_noop_mapping_error,
.dma_supported = dma_noop_supported,
+ .mmap = dma_noop_mmap,
};
EXPORT_SYMBOL(dma_noop_ops);
--
2.0.0
^ permalink raw reply related
* [RFC PATCH v5 3/7] drivers: dma-coherent: Account dma_pfn_offset when used with device tree
From: Vladimir Murzin @ 2017-01-18 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484738003-29892-1-git-send-email-vladimir.murzin@arm.com>
dma_declare_coherent_memory() and friends are designed to account
difference in CPU and device addresses. However, when it is used with
reserved memory regions there is assumption that CPU and device have
the same view on address space. This assumption gets invalid when
reserved memory for coherent DMA allocations is referenced by device
with non-empty "dma-range" property.
Simply feeding device address as rmem->base + dev->dma_pfn_offset
would not work due to reserved memory region can be shared, so this
patch turns device address to be expressed with help of CPU address
and device's dma_pfn_offset.
For the case where device tree is not used and device sees memory
different to CPU we explicitly set device's dma_pfn_offset to
accomplish such difference. The latter might look controversial, but
it seems only a few drivers set device address different to CPU's:
- drivers/usb/host/ohci-sm501.c
- arch/sh/drivers/pci/fixups-dreamcast.c
so they can be screwed only if dma_pfn_offset there is set and not in
sync with device address range - we try to catch such cases with
WARN_ON.
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/base/dma-coherent.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 640a7e6..c59708c 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -18,6 +18,12 @@ struct dma_coherent_mem {
spinlock_t spinlock;
};
+static inline dma_addr_t dma_get_device_base(struct device *dev,
+ struct dma_coherent_mem * mem)
+{
+ return (mem->pfn_base - dev->dma_pfn_offset) << PAGE_SHIFT;
+}
+
static bool dma_init_coherent_memory(
phys_addr_t phys_addr, dma_addr_t device_addr, size_t size, int flags,
struct dma_coherent_mem **mem)
@@ -83,9 +89,16 @@ static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
static int dma_assign_coherent_memory(struct device *dev,
struct dma_coherent_mem *mem)
{
+ unsigned long dma_pfn_offset = mem->pfn_base - PFN_DOWN(mem->device_base);
+
if (dev->dma_mem)
return -EBUSY;
+ if (dev->dma_pfn_offset)
+ WARN_ON(dma_pfn_offset && (dev->dma_pfn_offset != dma_pfn_offset));
+ else
+ dev->dma_pfn_offset = dma_pfn_offset;
+
dev->dma_mem = mem;
/* FIXME: this routine just ignores DMA_MEMORY_INCLUDES_CHILDREN */
@@ -133,7 +146,7 @@ void *dma_mark_declared_memory_occupied(struct device *dev,
return ERR_PTR(-EINVAL);
spin_lock_irqsave(&mem->spinlock, flags);
- pos = (device_addr - mem->device_base) >> PAGE_SHIFT;
+ pos = PFN_DOWN(device_addr - dma_get_device_base(dev, mem));
err = bitmap_allocate_region(mem->bitmap, pos, get_order(size));
spin_unlock_irqrestore(&mem->spinlock, flags);
@@ -186,7 +199,7 @@ int dma_alloc_from_coherent(struct device *dev, ssize_t size,
/*
* Memory was found in the per-device area.
*/
- *dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
+ *dma_handle = dma_get_device_base(dev, mem) + (pageno << PAGE_SHIFT);
*ret = mem->virt_base + (pageno << PAGE_SHIFT);
dma_memory_map = (mem->flags & DMA_MEMORY_MAP);
spin_unlock_irqrestore(&mem->spinlock, flags);
--
2.0.0
^ permalink raw reply related
* [RFC PATCH v5 4/7] drivers: dma-coherent: Introduce default DMA pool
From: Vladimir Murzin @ 2017-01-18 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484738003-29892-1-git-send-email-vladimir.murzin@arm.com>
This patch introduces default coherent DMA pool similar to default CMA
area concept. To keep other users safe code kept under CONFIG_ARM.
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
.../bindings/reserved-memory/reserved-memory.txt | 3 ++
drivers/base/dma-coherent.c | 59 +++++++++++++++++++---
2 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index 3da0ebd..16291f2 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -68,6 +68,9 @@ Linux implementation note:
- If a "linux,cma-default" property is present, then Linux will use the
region for the default pool of the contiguous memory allocator.
+- If a "linux,dma-default" property is present, then Linux will use the
+ region for the default pool of the consistent DMA allocator.
+
Device node references to reserved memory
-----------------------------------------
Regions in the /reserved-memory node may be referenced by other device
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index c59708c..0c577ea 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -18,6 +18,15 @@ struct dma_coherent_mem {
spinlock_t spinlock;
};
+static struct dma_coherent_mem *dma_coherent_default_memory __ro_after_init;
+
+static inline struct dma_coherent_mem *dev_get_coherent_memory(struct device *dev)
+{
+ if (dev && dev->dma_mem)
+ return dev->dma_mem;
+ return dma_coherent_default_memory;
+}
+
static inline dma_addr_t dma_get_device_base(struct device *dev,
struct dma_coherent_mem * mem)
{
@@ -91,6 +100,9 @@ static int dma_assign_coherent_memory(struct device *dev,
{
unsigned long dma_pfn_offset = mem->pfn_base - PFN_DOWN(mem->device_base);
+ if (!dev)
+ return -ENODEV;
+
if (dev->dma_mem)
return -EBUSY;
@@ -174,15 +186,12 @@ EXPORT_SYMBOL(dma_mark_declared_memory_occupied);
int dma_alloc_from_coherent(struct device *dev, ssize_t size,
dma_addr_t *dma_handle, void **ret)
{
- struct dma_coherent_mem *mem;
+ struct dma_coherent_mem *mem = dev_get_coherent_memory(dev);
int order = get_order(size);
unsigned long flags;
int pageno;
int dma_memory_map;
- if (!dev)
- return 0;
- mem = dev->dma_mem;
if (!mem)
return 0;
@@ -236,7 +245,7 @@ EXPORT_SYMBOL(dma_alloc_from_coherent);
*/
int dma_release_from_coherent(struct device *dev, int order, void *vaddr)
{
- struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
+ struct dma_coherent_mem *mem = dev_get_coherent_memory(dev);
if (mem && vaddr >= mem->virt_base && vaddr <
(mem->virt_base + (mem->size << PAGE_SHIFT))) {
@@ -270,7 +279,7 @@ EXPORT_SYMBOL(dma_release_from_coherent);
int dma_mmap_from_coherent(struct device *dev, struct vm_area_struct *vma,
void *vaddr, size_t size, int *ret)
{
- struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
+ struct dma_coherent_mem *mem = dev_get_coherent_memory(dev);
if (mem && vaddr >= mem->virt_base && vaddr + size <=
(mem->virt_base + (mem->size << PAGE_SHIFT))) {
@@ -300,6 +309,8 @@ EXPORT_SYMBOL(dma_mmap_from_coherent);
#include <linux/of_fdt.h>
#include <linux/of_reserved_mem.h>
+static struct reserved_mem *dma_reserved_default_memory __initdata;
+
static int rmem_dma_device_init(struct reserved_mem *rmem, struct device *dev)
{
struct dma_coherent_mem *mem = rmem->priv;
@@ -320,7 +331,8 @@ static int rmem_dma_device_init(struct reserved_mem *rmem, struct device *dev)
static void rmem_dma_device_release(struct reserved_mem *rmem,
struct device *dev)
{
- dev->dma_mem = NULL;
+ if (dev)
+ dev->dma_mem = NULL;
}
static const struct reserved_mem_ops rmem_dma_ops = {
@@ -340,6 +352,12 @@ static int __init rmem_dma_setup(struct reserved_mem *rmem)
pr_err("Reserved memory: regions without no-map are not yet supported\n");
return -EINVAL;
}
+
+ if (of_get_flat_dt_prop(node, "linux,dma-default", NULL)) {
+ WARN(dma_reserved_default_memory,
+ "Reserved memory: region for default DMA coherent area is redefined\n");
+ dma_reserved_default_memory = rmem;
+ }
#endif
rmem->ops = &rmem_dma_ops;
@@ -347,5 +365,32 @@ static int __init rmem_dma_setup(struct reserved_mem *rmem)
&rmem->base, (unsigned long)rmem->size / SZ_1M);
return 0;
}
+
+static int __init dma_init_reserved_memory(void)
+{
+ const struct reserved_mem_ops *ops;
+ int ret;
+
+ if (!dma_reserved_default_memory)
+ return -ENOMEM;
+
+ ops = dma_reserved_default_memory->ops;
+
+ /*
+ * We rely on rmem_dma_device_init() does not propagate error of
+ * dma_assign_coherent_memory() for "NULL" device.
+ */
+ ret = ops->device_init(dma_reserved_default_memory, NULL);
+
+ if (!ret) {
+ dma_coherent_default_memory = dma_reserved_default_memory->priv;
+ pr_info("DMA: default coherent area is set\n");
+ }
+
+ return ret;
+}
+
+core_initcall(dma_init_reserved_memory);
+
RESERVEDMEM_OF_DECLARE(dma, "shared-dma-pool", rmem_dma_setup);
#endif
--
2.0.0
^ 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