* Re: [PATCH 5/8] arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitions
From: Mark Rutland @ 2019-08-14 13:18 UTC (permalink / raw)
To: Will Deacon
Cc: Steve Capper, Andrey Konovalov, Geert Uytterhoeven,
Catalin Marinas, Qian Cai, linux-arm-kernel
In-Reply-To: <20190814115959.7epzszx53bidti7m@willie-the-truck>
On Wed, Aug 14, 2019 at 01:00:00PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 12:23:39PM +0100, Mark Rutland wrote:
> > On Tue, Aug 13, 2019 at 06:01:46PM +0100, Will Deacon wrote:
> > > Rather than subtracting from -1 and then adding 1, we can simply
> > > subtract from 0.
> > >
> > > Cc: Steve Capper <steve.capper@arm.com>
> > > Signed-off-by: Will Deacon <will@kernel.org>
> > > ---
> > > arch/arm64/include/asm/memory.h | 6 ++----
> > > 1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index 56be462c69ce..5552c8cba1e2 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -44,8 +44,7 @@
> > > * VA_START - the first kernel virtual address.
> > > */
> > > #define VA_BITS (CONFIG_ARM64_VA_BITS)
> > > -#define _PAGE_OFFSET(va) (UL(0xffffffffffffffff) - \
> > > - (UL(1) << (va)) + 1)
> > > +#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
> > > #define PAGE_OFFSET (_PAGE_OFFSET(VA_BITS))
> > > #define KIMAGE_VADDR (MODULES_END)
> > > #define BPF_JIT_REGION_START (KASAN_SHADOW_END)
> > > @@ -63,8 +62,7 @@
> > > #else
> > > #define VA_BITS_MIN (VA_BITS)
> > > #endif
> > > -#define _VA_START(va) (UL(0xffffffffffffffff) - \
> > > - (UL(1) << ((va) - 1)) + 1)
> > > +#define _VA_START(va) (-(UL(1) << ((va) - 1)))
> >
> > This didn't make any sense to me until I realised that we changed the
> > meaning of VA_START when flippnig the VA space. Given that, this cleanup
> > looks sound to me.
> >
> > However...
> >
> > VA_START used to be the start of the TTBR1 address space, which was what
> > the "first kernel virtual address" comment was trying to say. Now it's
> > the first non-linear kernel virtual addres, which I think is very
> > confusing.
> >
> > AFAICT, that change breaks at least:
> >
> > * is_ttbr1_addr() -- now returns false for linear map addresses
> > * ptdump_check_wx() -- now skips the linear map
> > * ptdump_init() -- initialises start_address inccorrectly.
> >
> > ... so could we please find a new name for the first non-linear address,
> > e.g. PAGE_END, and leave VA_START as the first TTBR1 address?
>
> I think VA_START becomes PAGE_END and then things like is_ttbr1_addr()
> just refer to PAGE_OFFSET instead. ptdump_init() looks ok to me, but I could
> be missing something.
Yes; you're right about ptdump_init().
> Anyway, these seem to be comments on the original patches from Steve rather
> than my fixes, so please send additional fixes on top. I'll push out an
> updated branch for you to work with...
Sure, I'll post a couple of patches momentarily...
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-14 13:20 UTC (permalink / raw)
To: Jernej Škrabec
Cc: mark.rutland, devicetree, wens, mripard, linux-kernel,
linux-sunxi, robh+dt, linux-arm-kernel
In-Reply-To: <1648748.TWHgARQioU@jernej-laptop>
On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe napisal(a):
> > This patch adds the evaluation variant of the model A of the PineH64.
> > The model A has the same size of the pine64 and has a PCIE slot.
> >
> > The only devicetree difference with current pineH64, is the PHY
> > regulator.
>
> I have Model A board which also needs ddc-en-gpios property for HDMI connector
> in order for HDMI to work correctly. Otherwise it will just use 1024x768
> resolution. Can you confirm that?
>
> Best regards,
> Jernej
>
Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
Could you send me a patch against my future v2 and I could test with/without.
Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Clément Péron @ 2019-08-14 13:28 UTC (permalink / raw)
To: clabbe.montjoie
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Maxime Ripard,
linux-kernel, linux-sunxi, Rob Herring, Jernej Škrabec,
linux-arm-kernel
In-Reply-To: <20190814132001.GC24324@Red>
Hi,
On Wed, 14 Aug 2019 at 15:20, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>
> On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe napisal(a):
> > > This patch adds the evaluation variant of the model A of the PineH64.
> > > The model A has the same size of the pine64 and has a PCIE slot.
> > >
> > > The only devicetree difference with current pineH64, is the PHY
> > > regulator.
> >
> > I have Model A board which also needs ddc-en-gpios property for HDMI connector
> > in order for HDMI to work correctly. Otherwise it will just use 1024x768
> > resolution. Can you confirm that?
Schematics Rev A:
http://files.pine64.org/doc/Pine%20H64/Pine%20H64%20Ver1.1-20180104.pdf
Rev B:
http://files.pine64.org/doc/Pine%20H64/PINE-H6-model-B-20181212-schematic.pdf
There is a DDC_EN on REV A not on REV B
Regards,
Clément
> >
> > Best regards,
> > Jernej
> >
>
> Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
>
> Could you send me a patch against my future v2 and I could test with/without.
>
> Regards
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190814132001.GC24324%40Red.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/2] arm64: memory: VA_START fixups
From: Mark Rutland @ 2019-08-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will, steve.capper
Hi all,
These patches address my concerns with the new VA_START semantic as I
spotted while reviewing Will's 52-bit VA cleanup. The first patch
corrects the newly broken usage of VA_START, and the second renames
VA_START to PAGE_END to make the new semantic clearer.
Both patches are based on the arm64 for-next/52-bit-kva branch, and I've
given a 52-bit VA configuration a build+boot test (on HW without 52-bit
VA support).
Thanks,
Mark.
Mark Rutland (2):
arm64: memory: fix flipped VA space fallout
arm64: memory: rename VA_START to PAGE_END
arch/arm64/include/asm/memory.h | 20 ++++++++++----------
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/arm64/kernel/hibernate.c | 2 +-
arch/arm64/mm/dump.c | 8 ++++----
arch/arm64/mm/fault.c | 2 +-
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 4 ++--
7 files changed, 21 insertions(+), 21 deletions(-)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] arm64: memory: fix flipped VA space fallout
From: Mark Rutland @ 2019-08-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will, steve.capper
In-Reply-To: <20190814132848.24295-1-mark.rutland@arm.com>
VA_START used to be the start of the TTBR1 address space, but now it's a
point midway though. In a couple of places we still use VA_START to get
the start of the TTBR1 address space, so let's fix these up to use
PAGE_OFFSET instead.
Fixes: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/mm/dump.c | 2 +-
arch/arm64/mm/fault.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 6ec75305828e..8e10b4ba215a 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -400,7 +400,7 @@ void ptdump_check_wx(void)
.check_wx = true,
};
- walk_pgd(&st, &init_mm, VA_START);
+ walk_pgd(&st, &init_mm, PAGE_OFFSET);
note_page(&st, 0, 0, 0);
if (st.wx_pages || st.uxn_pages)
pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found, %lu non-UXN pages found\n",
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 75eff57bd9ef..bb4e4f3fffd8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -109,7 +109,7 @@ static inline bool is_ttbr0_addr(unsigned long addr)
static inline bool is_ttbr1_addr(unsigned long addr)
{
/* TTBR1 addresses may have a tag if KASAN_SW_TAGS is in use */
- return arch_kasan_reset_tag(addr) >= VA_START;
+ return arch_kasan_reset_tag(addr) >= PAGE_OFFSET;
}
/*
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] arm64: memory: rename VA_START to PAGE_END
From: Mark Rutland @ 2019-08-14 13:28 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will, steve.capper
In-Reply-To: <20190814132848.24295-1-mark.rutland@arm.com>
Prior to commit:
14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
... VA_START described the start of the TTBR1 address space for a given
VA size described by VA_BITS, where all kernel mappings began.
Since that commit, VA_START described a portion midway through the
address space, where the linear map ends and other kernel mappings
begin.
To avoid confusion, let's rename VA_START to PAGE_END, making it clear
that it's not the start of the TTBR1 address space and implying that
it's related to PAGE_OFFSET. Comments and other mnemonics are updated
accordingly, along with a typo fix in the decription of VMEMMAP_SIZE.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/memory.h | 20 ++++++++++----------
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/arm64/kernel/hibernate.c | 2 +-
arch/arm64/mm/dump.c | 6 +++---
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 4 ++--
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d69c2865ae40..a713bad71db5 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -28,20 +28,20 @@
* a struct page array
*
* If we are configured with a 52-bit kernel VA then our VMEMMAP_SIZE
- * neads to cover the memory region from the beginning of the 52-bit
- * PAGE_OFFSET all the way to VA_START for 48-bit. This allows us to
+ * needs to cover the memory region from the beginning of the 52-bit
+ * PAGE_OFFSET all the way to PAGE_END for 48-bit. This allows us to
* keep a constant PAGE_OFFSET and "fallback" to using the higher end
* of the VMEMMAP where 52-bit support is not available in hardware.
*/
-#define VMEMMAP_SIZE ((_VA_START(VA_BITS_MIN) - PAGE_OFFSET) \
+#define VMEMMAP_SIZE ((_PAGE_END(VA_BITS_MIN) - PAGE_OFFSET) \
>> (PAGE_SHIFT - STRUCT_PAGE_MAX_SHIFT))
/*
- * PAGE_OFFSET - the virtual address of the start of the linear map (top
- * (VA_BITS - 1))
- * KIMAGE_VADDR - the virtual address of the start of the kernel image
+ * PAGE_OFFSET - the virtual address of the start of the linear map, at the
+ * start of the TTBR1 address space.
+ * PAGE_END - the end of the linear map, where all other kernel mappings begin.
+ * KIMAGE_VADDR - the virtual address of the start of the kernel image.
* VA_BITS - the maximum number of bits for virtual addresses.
- * VA_START - the first kernel virtual address.
*/
#define VA_BITS (CONFIG_ARM64_VA_BITS)
#define _PAGE_OFFSET(va) (-(UL(1) << (va)))
@@ -64,7 +64,7 @@
#define VA_BITS_MIN (VA_BITS)
#endif
-#define _VA_START(va) (-(UL(1) << ((va) - 1)))
+#define _PAGE_END(va) (-(UL(1) << ((va) - 1)))
#define KERNEL_START _text
#define KERNEL_END _end
@@ -87,7 +87,7 @@
#define KASAN_THREAD_SHIFT 1
#else
#define KASAN_THREAD_SHIFT 0
-#define KASAN_SHADOW_END (_VA_START(VA_BITS_MIN))
+#define KASAN_SHADOW_END (_PAGE_END(VA_BITS_MIN))
#endif /* CONFIG_KASAN */
#define MIN_THREAD_SHIFT (14 + KASAN_THREAD_SHIFT)
@@ -173,7 +173,7 @@
#ifndef __ASSEMBLY__
extern u64 vabits_actual;
-#define VA_START (_VA_START(vabits_actual))
+#define PAGE_END (_PAGE_END(vabits_actual))
#include <linux/bitops.h>
#include <linux/mmdebug.h>
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4a695b9ee0f0..979e24fadf35 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -856,8 +856,8 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
#define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
-#define kc_vaddr_to_offset(v) ((v) & ~VA_START)
-#define kc_offset_to_vaddr(o) ((o) | VA_START)
+#define kc_vaddr_to_offset(v) ((v) & ~PAGE_END)
+#define kc_offset_to_vaddr(o) ((o) | PAGE_END)
#ifdef CONFIG_ARM64_PA_BITS_52
#define phys_to_ttbr(addr) (((addr) | ((addr) >> 46)) & TTBR_BADDR_MASK_52)
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index e130db05d932..e0a7fce0e01c 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -496,7 +496,7 @@ int swsusp_arch_resume(void)
rc = -ENOMEM;
goto out;
}
- rc = copy_page_tables(tmp_pg_dir, PAGE_OFFSET, VA_START);
+ rc = copy_page_tables(tmp_pg_dir, PAGE_OFFSET, PAGE_END);
if (rc)
goto out;
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 8e10b4ba215a..93f9f77582ae 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -28,7 +28,7 @@
enum address_markers_idx {
PAGE_OFFSET_NR = 0,
- VA_START_NR,
+ PAGE_END_NR,
#ifdef CONFIG_KASAN
KASAN_START_NR,
#endif
@@ -36,7 +36,7 @@ enum address_markers_idx {
static struct addr_marker address_markers[] = {
{ PAGE_OFFSET, "Linear Mapping start" },
- { 0 /* VA_START */, "Linear Mapping end" },
+ { 0 /* PAGE_END */, "Linear Mapping end" },
#ifdef CONFIG_KASAN
{ 0 /* KASAN_SHADOW_START */, "Kasan shadow start" },
{ KASAN_SHADOW_END, "Kasan shadow end" },
@@ -411,7 +411,7 @@ void ptdump_check_wx(void)
static int ptdump_init(void)
{
- address_markers[VA_START_NR].start_address = VA_START;
+ address_markers[PAGE_END_NR].start_address = PAGE_END;
#ifdef CONFIG_KASAN
address_markers[KASAN_START_NR].start_address = KASAN_SHADOW_START;
#endif
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 725222271474..f87a32484ea8 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -226,7 +226,7 @@ void __init kasan_init(void)
kasan_map_populate(kimg_shadow_start, kimg_shadow_end,
early_pfn_to_nid(virt_to_pfn(lm_alias(_text))));
- kasan_populate_early_shadow(kasan_mem_to_shadow((void *) VA_START),
+ kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
(void *)mod_shadow_start);
kasan_populate_early_shadow((void *)kimg_shadow_end,
(void *)KASAN_SHADOW_END);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 0c8f7e55f859..8e4b7eaff8ce 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -399,7 +399,7 @@ static phys_addr_t pgd_pgtable_alloc(int shift)
static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
phys_addr_t size, pgprot_t prot)
{
- if ((virt >= VA_START) && (virt < VMALLOC_START)) {
+ if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
pr_warn("BUG: not creating mapping for %pa at 0x%016lx - outside kernel range\n",
&phys, virt);
return;
@@ -426,7 +426,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
phys_addr_t size, pgprot_t prot)
{
- if ((virt >= VA_START) && (virt < VMALLOC_START)) {
+ if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
pr_warn("BUG: not updating mapping for %pa at 0x%016lx - outside kernel range\n",
&phys, virt);
return;
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Maxime Ripard @ 2019-08-14 13:33 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, wens,
robh+dt, linux-arm-kernel
In-Reply-To: <20190814131741.GB24324@Red>
[-- Attachment #1.1: Type: text/plain, Size: 3004 bytes --]
On Wed, Aug 14, 2019 at 03:17:41PM +0200, Corentin Labbe wrote:
> On Mon, Aug 12, 2019 at 11:40:00AM +0200, Maxime Ripard wrote:
> > On Thu, Aug 08, 2019 at 10:42:53AM +0200, Corentin Labbe wrote:
> > > This patch adds the evaluation variant of the model A of the PineH64.
> > > The model A has the same size of the pine64 and has a PCIE slot.
> > >
> > > The only devicetree difference with current pineH64, is the PHY
> > > regulator.
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > .../sun50i-h6-pine-h64-modelA-eval.dts | 26 +++++++++++++++++++
> > > 2 files changed, 27 insertions(+)
> > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > > index f6db0611cb85..9a02166cbf72 100644
> > > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > > @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > new file mode 100644
> > > index 000000000000..d8ff02747efe
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > @@ -0,0 +1,26 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > +/*
> > > + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> > > + */
> > > +
> > > +#include "sun50i-h6-pine-h64.dts"
> > > +
> > > +/ {
> > > + model = "Pine H64 model A evaluation board";
> > > + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> > > +
> > > + reg_gmac_3v3: gmac-3v3 {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "vcc-gmac-3v3";
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + startup-delay-us = <100000>;
> > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > + };
> > > +
> > > +};
> > > +
> > > +&emac {
> > > + phy-supply = <®_gmac_3v3>;
> > > +};
> >
> > I might be missing some context here, but I'm pretty sure that the
> > initial intent of the pine h64 DTS was to support the model A all
> > along.
> >
>
> The regulator changed between modelA and B.
> See this old patchset (supporting modelA) https://patchwork.kernel.org/patch/10539149/ for example.
I'm not sure what your point is, but mine is that everything about the
model A should be in sun50i-h6-pine-h64.dts.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: arm: fsl: add Hummingboard Pulse
From: Baruch Siach @ 2019-08-14 13:37 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: Baruch Siach, Marco Felsch, linux-arm-kernel
In-Reply-To: <6bd3249a5f8ecd8af376145781c3f4345f198bdd.1565789825.git.baruch@tkos.co.il>
Add binding documentation for the SolidRun Hummingboard Pulse board.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v3: No change
v2: New patch suggested by Fabio
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..14ca94928677 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -219,6 +219,7 @@ properties:
- enum:
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- purism,librem5-devkit # Purism Librem5 devkit
+ - solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse
- const: fsl,imx8mq
- description: i.MX8QXP based Boards
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/2] arm64: dts: fsl: add support for Hummingboard Pulse
From: Baruch Siach @ 2019-08-14 13:37 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: Baruch Siach, Jon Nettleton, Marco Felsch, linux-arm-kernel
From: Jon Nettleton <jon@solid-run.com>
The SolidRun Hummingboard Pulse carrier board carries the SolidRun
i.MX8MQ based SOM.
Notably missing is PCIe support that depends on analog PLLOUT clock.
Current imx clk driver does not support this clock.
Signed-off-by: Jon Nettleton <jon@solid-run.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
v3:
Fix SD card power regulator enable gpio
Address Marco's comments:
- Reorder pinctrl properties
- Move imx8mq.dtsi include to the SOM .dtsi
- Add reg_ prefix to regulator labels
- Add pinctrl node to SD card regulator gpio
- Add label to SPI flash node
v2: Address Fabio's comments:
- Remove redundant node nesting
- Fix comments style
- Use mainline DT bindings in UART and USB type C
- Fix node names
- Move &iomuxc to the end of file
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../freescale/imx8mq-hummingboard-pulse.dts | 256 +++++++++++++++
.../boot/dts/freescale/imx8mq-sr-som.dtsi | 309 ++++++++++++++++++
3 files changed, 566 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c043aca66572..6833b23e2dd2 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
new file mode 100644
index 000000000000..4beb3c456448
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Jon Nettleton <jon@solid-run.com>
+ */
+
+/dts-v1/;
+
+#include "dt-bindings/usb/pd.h"
+#include "imx8mq-sr-som.dtsi"
+
+/ {
+ model = "SolidRun i.MX8MQ HummingBoard Pulse";
+ compatible = "solidrun,hummingboard-pulse", "fsl,imx8mq";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2_vmmc>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 13 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_v_5v0: regulator-v-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "v_5v0";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ typec_ptn5100: usb-typec@50 {
+ compatible = "nxp,ptn5110";
+ reg = <0x50>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+
+ connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ source-pdos = <PDO_FIXED(5000, 2000,
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_SUSPEND |
+ PDO_FIXED_EXTPOWER)>;
+ sink-pdos = <PDO_FIXED(5000, 2000,
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_SUSPEND |
+ PDO_FIXED_EXTPOWER)
+ PDO_FIXED(9000, 2000,
+ PDO_FIXED_USB_COMM |
+ PDO_FIXED_SUSPEND |
+ PDO_FIXED_EXTPOWER)>;
+ op-sink-microwatt = <9000000>;
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+ };
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ rtc@69 {
+ compatible = "abracon,ab1805";
+ reg = <0x69>;
+ abracon,tc-diode = "schottky";
+ abracon,tc-resistor = <3>;
+ };
+};
+
+&uart2 { /* J35 header */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ status = "okay";
+};
+
+&uart3 { /* Mikrobus */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART3>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ status = "okay";
+ dr_mode = "otg";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usb_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+&usb3_phy1 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* MikroBus Analog */
+ MX8MQ_IOMUXC_NAND_DATA05_GPIO3_IO11 0x41
+ /* MikroBus Reset */
+ MX8MQ_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x41
+ /*
+ * The following 2 pins need to be commented out and
+ * reconfigured to enable RTS/CTS on UART3
+ */
+ /* MikroBus PWM */
+ MX8MQ_IOMUXC_ECSPI1_MISO_GPIO5_IO8 0x41
+ /* MikroBus INT */
+ MX8MQ_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x41
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C3_SCL_I2C3_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C3_SDA_I2C3_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_typec: typecgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_NAND_RE_B_GPIO3_IO15 0x16
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x17059
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x49
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
+ /*
+ * These pins are by default GPIO on the Mikro Bus
+ * Header. To use RTS/CTS on UART3 comment them out
+ * of the hoggrp and enable them here
+ */
+ /* MX8MQ_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x49 */
+ /* MX8MQ_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x49 */
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO12 0x41
+ >;
+ };
+
+ pinctrl_usdhc2_vmmc: usdhc2vmmcgpio {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x41
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x83
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc3
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc3
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc3
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc3
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc3
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcd
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcd
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcd
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcd
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xdf
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xdf
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xdf
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xdf
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xdf
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
new file mode 100644
index 000000000000..cd22d085d6c7
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
@@ -0,0 +1,309 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Jon Nettleton <jon@solid-run.com>
+ */
+
+#include "imx8mq.dtsi"
+
+/ {
+ reg_vdd_3v3: regulator-vdd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-name = "vdd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&pgc_gpu{
+ power-supply = <&sw1a_reg>;
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ phy-reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <2>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <4>;
+ };
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ pmic: pmic@8 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3ab {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ regulator-always-on;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+};
+
+&qspi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi>;
+ status = "okay";
+
+ /* SPI flash; not assembled by default */
+ spi_flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ compatible = "micron,n25q256a", "jedec,spi-nor";
+ spi-max-frequency = <29000000>;
+ status = "disabled";
+ };
+};
+
+&uart1 { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ assigned-clock-rates = <25000000>;
+ status = "okay";
+};
+
+&uart4 { /* ublox BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ assigned-clock-rates = <80000000>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&pgc_vpu {
+ power-supply = <&sw1c_reg>;
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MQ_IOMUXC_ENET_MDIO_ENET1_MDIO 0x23
+ MX8MQ_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MQ_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MQ_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MQ_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MQ_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MQ_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MQ_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MQ_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MQ_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MQ_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MQ_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MQ_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x74
+ MX8MQ_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 0x16
+ MX8MQ_IOMUXC_SAI2_RXFS_GPIO4_IO21 0x16
+ >;
+ };
+
+ pinctrl_qspi: qspigrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_NAND_ALE_QSPI_A_SCLK 0x82
+ MX8MQ_IOMUXC_NAND_CE0_B_QSPI_A_SS0_B 0x82
+ MX8MQ_IOMUXC_NAND_DATA00_QSPI_A_DATA0 0x82
+ MX8MQ_IOMUXC_NAND_DATA01_QSPI_A_DATA1 0x82
+ MX8MQ_IOMUXC_NAND_DATA02_QSPI_A_DATA2 0x82
+ MX8MQ_IOMUXC_NAND_DATA03_QSPI_A_DATA3 0x82
+
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49
+ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
+ MX8MQ_IOMUXC_NAND_CE1_B_GPIO3_IO2 0x19
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART4_TXD_UART4_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART4_RXD_UART4_DCE_RX 0x49
+ MX8MQ_IOMUXC_SAI3_TXD_GPIO5_IO1 0x19
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x83
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x8d
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x9f
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/3] hwmon: raspberrypi: update MODULE_AUTHOR() email address
From: Guenter Roeck @ 2019-08-14 13:39 UTC (permalink / raw)
To: Stefan Wahren
Cc: linux-hwmon, Jean Delvare, Fabio Estevam, Sascha Hauer,
linux-kernel, Srinivas Kandagatla, NXP Linux Team,
Pengutronix Kernel Team, netdev, Shawn Guo, David S. Miller,
linux-arm-kernel
In-Reply-To: <1565720249-6549-2-git-send-email-wahrenst@gmx.net>
On Tue, Aug 13, 2019 at 08:17:28PM +0200, Stefan Wahren wrote:
> The email address listed in MODULE_AUTHOR() will be disabled in the
> near future. Replace it with my private one.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Applied to hwmon-next.
Thanks,
Guenter
> ---
> drivers/hwmon/raspberrypi-hwmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --
> 2.7.4
>
> diff --git a/drivers/hwmon/raspberrypi-hwmon.c b/drivers/hwmon/raspberrypi-hwmon.c
> index efe4bb1..d3a64a3 100644
> --- a/drivers/hwmon/raspberrypi-hwmon.c
> +++ b/drivers/hwmon/raspberrypi-hwmon.c
> @@ -146,7 +146,7 @@ static struct platform_driver rpi_hwmon_driver = {
> };
> module_platform_driver(rpi_hwmon_driver);
>
> -MODULE_AUTHOR("Stefan Wahren <stefan.wahren@i2se.com>");
> +MODULE_AUTHOR("Stefan Wahren <wahrenst@gmx.net>");
> MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
> MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("platform:raspberrypi-hwmon");
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Tony Lindgren @ 2019-08-14 13:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Aaro Koskinen, Greg Kroah-Hartman, Linus Walleij,
Bartlomiej Zolnierkiewicz, Linux Kernel Mailing List,
Dominik Brodowski, Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a3k_HOGqzMGjtc+7NSaK0Bsa_vxxRFLzY8aP6ev4wa9iA@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [190814 10:37]:
> On Wed, Aug 14, 2019 at 9:49 AM Tony Lindgren <tony@atomide.com> wrote:
> > * Arnd Bergmann <arnd@arndb.de> [190813 19:34]:
> > > On Tue, Aug 13, 2019 at 8:12 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > > diff --git a/arch/arm/mach-omap1/hardware.h b/arch/arm/mach-omap1/hardware.h
> > > index 232b8deef907..9fc76a3c9e57 100644
> > > --- a/arch/arm/mach-omap1/hardware.h
> > > +++ b/arch/arm/mach-omap1/hardware.h
> > > @@ -61,7 +61,7 @@ static inline u32 omap_cs3_phys(void)
> > >
> > > #endif /* ifndef __ASSEMBLER__ */
> > >
> > > -#define OMAP1_IO_OFFSET 0x01000000 /* Virtual IO
> > > = 0xfefb0000 */
> > > +#define OMAP1_IO_OFFSET 0x00fb0000 /* Virtual IO
> > > = 0xff000000 */
> > > #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
> > >
> > > #include "serial.h"
> >
> > Oh OK yeah sounds like that's the issue.
> >
> > > There may be additional locations that hardcode the virtual address.
> >
> > Those should be in mach-omap1/io.c, and I recall innovator had some
> > hardcoded fpga address that should also be checked.
>
> I see four boards with hardcoded I/O addresses, but they are all below
> the PCI I/O virtual address range, and are not affected by that change.
>
> For the innovator FPGA access, this was ok, it uses the correct address
> in the OMAP1_IO_OFFSET range.
OK thanks for checking. I tried to apply your virtual address patch to
test boot it, but could not get it to apply. What tree is it against?
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/4] media: stm32-dcmi: improve sensor subdev naming
From: Hugues Fruchet @ 2019-08-14 13:48 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1565790533-10043-1-git-send-email-hugues.fruchet@st.com>
Rename "subdev" entity struct field to "source"
to prepare for several subdev support.
Move asd field on top of entity struct.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 46 +++++++++++++++----------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b9dad0a..b462f71 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -100,10 +100,10 @@ enum state {
#define OVERRUN_ERROR_THRESHOLD 3
struct dcmi_graph_entity {
- struct device_node *node;
-
struct v4l2_async_subdev asd;
- struct v4l2_subdev *subdev;
+
+ struct device_node *remote_node;
+ struct v4l2_subdev *source;
};
struct dcmi_format {
@@ -595,7 +595,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
}
/* Enable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 1);
+ ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 1);
if (ret && ret != -ENOIOCTLCMD) {
dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
__func__);
@@ -685,7 +685,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
err_subdev_streamoff:
- v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
+ v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
err_pm_put:
pm_runtime_put(dcmi->dev);
@@ -713,7 +713,7 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
int ret;
/* Disable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
+ ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
if (ret && ret != -ENOIOCTLCMD)
dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
__func__, ret);
@@ -857,7 +857,7 @@ static int dcmi_try_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f,
}
v4l2_fill_mbus_format(&format.format, pix, sd_fmt->mbus_code);
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, set_fmt,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, set_fmt,
&pad_cfg, &format);
if (ret < 0)
return ret;
@@ -934,7 +934,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
mf->width = sd_framesize.width;
mf->height = sd_framesize.height;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad,
set_fmt, NULL, &format);
if (ret < 0)
return ret;
@@ -991,7 +991,7 @@ static int dcmi_get_sensor_format(struct stm32_dcmi *dcmi,
};
int ret;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, get_fmt, NULL, &fmt);
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, get_fmt, NULL, &fmt);
if (ret)
return ret;
@@ -1020,7 +1020,7 @@ static int dcmi_set_sensor_format(struct stm32_dcmi *dcmi,
}
v4l2_fill_mbus_format(&format.format, pix, sd_fmt->mbus_code);
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, set_fmt,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, set_fmt,
&pad_cfg, &format);
if (ret < 0)
return ret;
@@ -1043,7 +1043,7 @@ static int dcmi_get_sensor_bounds(struct stm32_dcmi *dcmi,
/*
* Get sensor bounds first
*/
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, get_selection,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, get_selection,
NULL, &bounds);
if (!ret)
*r = bounds.r;
@@ -1224,7 +1224,7 @@ static int dcmi_enum_framesizes(struct file *file, void *fh,
fse.code = sd_fmt->mbus_code;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, enum_frame_size,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, enum_frame_size,
NULL, &fse);
if (ret)
return ret;
@@ -1241,7 +1241,7 @@ static int dcmi_g_parm(struct file *file, void *priv,
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- return v4l2_g_parm_cap(video_devdata(file), dcmi->entity.subdev, p);
+ return v4l2_g_parm_cap(video_devdata(file), dcmi->entity.source, p);
}
static int dcmi_s_parm(struct file *file, void *priv,
@@ -1249,7 +1249,7 @@ static int dcmi_s_parm(struct file *file, void *priv,
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- return v4l2_s_parm_cap(video_devdata(file), dcmi->entity.subdev, p);
+ return v4l2_s_parm_cap(video_devdata(file), dcmi->entity.source, p);
}
static int dcmi_enum_frameintervals(struct file *file, void *fh,
@@ -1271,7 +1271,7 @@ static int dcmi_enum_frameintervals(struct file *file, void *fh,
fie.code = sd_fmt->mbus_code;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad,
enum_frame_interval, NULL, &fie);
if (ret)
return ret;
@@ -1291,7 +1291,7 @@ MODULE_DEVICE_TABLE(of, stm32_dcmi_of_match);
static int dcmi_open(struct file *file)
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- struct v4l2_subdev *sd = dcmi->entity.subdev;
+ struct v4l2_subdev *sd = dcmi->entity.source;
int ret;
if (mutex_lock_interruptible(&dcmi->lock))
@@ -1322,7 +1322,7 @@ static int dcmi_open(struct file *file)
static int dcmi_release(struct file *file)
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- struct v4l2_subdev *sd = dcmi->entity.subdev;
+ struct v4l2_subdev *sd = dcmi->entity.source;
bool fh_singular;
int ret;
@@ -1433,7 +1433,7 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
{
const struct dcmi_format *sd_fmts[ARRAY_SIZE(dcmi_formats)];
unsigned int num_fmts = 0, i, j;
- struct v4l2_subdev *subdev = dcmi->entity.subdev;
+ struct v4l2_subdev *subdev = dcmi->entity.source;
struct v4l2_subdev_mbus_code_enum mbus_code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
@@ -1479,7 +1479,7 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
static int dcmi_framesizes_init(struct stm32_dcmi *dcmi)
{
unsigned int num_fsize = 0;
- struct v4l2_subdev *subdev = dcmi->entity.subdev;
+ struct v4l2_subdev *subdev = dcmi->entity.source;
struct v4l2_subdev_frame_size_enum fse = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
.code = dcmi->sd_format->mbus_code,
@@ -1526,7 +1526,7 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
int ret;
- dcmi->vdev->ctrl_handler = dcmi->entity.subdev->ctrl_handler;
+ dcmi->vdev->ctrl_handler = dcmi->entity.source->ctrl_handler;
ret = dcmi_formats_init(dcmi);
if (ret) {
dev_err(dcmi->dev, "No supported mediabus format found\n");
@@ -1582,7 +1582,7 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
- dcmi->entity.subdev = subdev;
+ dcmi->entity.source = subdev;
return 0;
}
@@ -1608,7 +1608,7 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
return -EINVAL;
/* Remote node to connect */
- dcmi->entity.node = remote;
+ dcmi->entity.remote_node = remote;
dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
return 0;
@@ -1631,7 +1631,7 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
&dcmi->entity.asd);
if (ret) {
dev_err(dcmi->dev, "Failed to add subdev notifier\n");
- of_node_put(dcmi->entity.node);
+ of_node_put(dcmi->entity.remote_node);
return ret;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 0/4] DCMI bridge support
From: Hugues Fruchet @ 2019-08-14 13:48 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
This patch serie allows to connect non-parallel camera sensor to
DCMI thanks to a bridge connected in between such as STMIPID02 [1].
Media controller support is introduced first, then support of
several sub-devices within pipeline with dynamic linking
between them.
In order to keep backward compatibility with applications
relying on V4L2 interface only, format set on video node
is propagated to all sub-devices connected to camera interface.
[1] https://www.spinics.net/lists/devicetree/msg278002.html
===========
= history =
===========
version 6:
- As per Sakari remark: add a FIXME explaining that this
version only supports subdevices which expose RGB & YUV
"parallel form" mbus code (_2X8)
- Add some trace around subdev_call(s_fmt) error & format
changes to debug subdev which only expose serial mbus code
- Conform to "<name>":<pad index> when tracing subdev infos
version 5:
- Remove remaining Change-Id
- Add Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
version 4:
- Also drop subdev nodes registry as suggested by Hans:
https://www.spinics.net/lists/arm-kernel/msg743375.html
version 3:
- Drop media device registry to not expose media controller
interface to userspace as per Laurent' suggestion:
https://www.spinics.net/lists/linux-media/msg153417.html
- Prefer "source" instead of "sensor" and keep it in
dcmi_graph_entity struct, move asd as first member
of struct as per Sakari' suggestion:
https://www.spinics.net/lists/linux-media/msg153119.html
- Drop dcmi_graph_deinit() as per Sakari' suggestion:
https://www.spinics.net/lists/linux-media/msg153417.html
version 2:
- Fix bus_info not consistent between media and V4L:
https://www.spinics.net/lists/arm-kernel/msg717676.html
- Propagation of format set on video node to the sub-devices
chain connected on camera interface
version 1:
- Initial submission
Hugues Fruchet (4):
media: stm32-dcmi: improve sensor subdev naming
media: stm32-dcmi: trace the supported fourcc/mbus_code
media: stm32-dcmi: add media controller support
media: stm32-dcmi: add support of several sub-devices
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c | 317 +++++++++++++++++++++++++-----
2 files changed, 267 insertions(+), 52 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Hugues Fruchet @ 2019-08-14 13:48 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1565790533-10043-1-git-send-email-hugues.fruchet@st.com>
Add a trace of the set of supported fourcc/mbus_code which
intersect between DCMI and source sub-device.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b462f71..18acecf 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -1447,12 +1447,20 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
/* Code supported, have we got this fourcc yet? */
for (j = 0; j < num_fmts; j++)
if (sd_fmts[j]->fourcc ==
- dcmi_formats[i].fourcc)
+ dcmi_formats[i].fourcc) {
/* Already available */
+ dev_dbg(dcmi->dev, "Skipping fourcc/code: %4.4s/0x%x\n",
+ (char *)&sd_fmts[j]->fourcc,
+ mbus_code.code);
break;
- if (j == num_fmts)
+ }
+ if (j == num_fmts) {
/* New */
sd_fmts[num_fmts++] = dcmi_formats + i;
+ dev_dbg(dcmi->dev, "Supported fourcc/code: %4.4s/0x%x\n",
+ (char *)&sd_fmts[num_fmts - 1]->fourcc,
+ sd_fmts[num_fmts - 1]->mbus_code);
+ }
}
mbus_code.index++;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 4/4] media: stm32-dcmi: add support of several sub-devices
From: Hugues Fruchet @ 2019-08-14 13:48 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1565790533-10043-1-git-send-email-hugues.fruchet@st.com>
Add support of several sub-devices within pipeline instead
of a single one.
This allows to support a CSI-2 camera sensor connected
through a CSI-2 to parallel bridge.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 217 +++++++++++++++++++++++++++---
1 file changed, 198 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index 302c40e..b6ef229 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -172,6 +172,7 @@ struct stm32_dcmi {
struct media_device mdev;
struct media_pad vid_cap_pad;
+ struct media_pipeline pipeline;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -583,6 +584,144 @@ static void dcmi_buf_queue(struct vb2_buffer *vb)
spin_unlock_irq(&dcmi->irqlock);
}
+static struct media_entity *dcmi_find_source(struct stm32_dcmi *dcmi)
+{
+ struct media_entity *entity = &dcmi->vdev->entity;
+ struct media_pad *pad;
+
+ /* Walk searching for entity having no sink */
+ while (1) {
+ pad = &entity->pads[0];
+ if (!(pad->flags & MEDIA_PAD_FL_SINK))
+ break;
+
+ pad = media_entity_remote_pad(pad);
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+ break;
+
+ entity = pad->entity;
+ }
+
+ return entity;
+}
+
+static int dcmi_pipeline_s_fmt(struct stm32_dcmi *dcmi,
+ struct v4l2_subdev_pad_config *pad_cfg,
+ struct v4l2_subdev_format *format)
+{
+ struct media_entity *entity = &dcmi->entity.source->entity;
+ struct v4l2_subdev *subdev;
+ struct media_pad *sink_pad = NULL;
+ struct media_pad *src_pad = NULL;
+ struct media_pad *pad = NULL;
+ struct v4l2_subdev_format fmt = *format;
+ bool found = false;
+ int ret;
+
+ /*
+ * Starting from sensor subdevice, walk within
+ * pipeline and set format on each subdevice
+ */
+ while (1) {
+ unsigned int i;
+
+ /* Search if current entity has a source pad */
+ for (i = 0; i < entity->num_pads; i++) {
+ pad = &entity->pads[i];
+ if (pad->flags & MEDIA_PAD_FL_SOURCE) {
+ src_pad = pad;
+ found = true;
+ break;
+ }
+ }
+ if (!found)
+ break;
+
+ subdev = media_entity_to_v4l2_subdev(entity);
+
+ /* Propagate format on sink pad if any, otherwise source pad */
+ if (sink_pad)
+ pad = sink_pad;
+
+ dev_dbg(dcmi->dev, "\"%s\":%d pad format set to 0x%x %ux%u\n",
+ subdev->name, pad->index, format->format.code,
+ format->format.width, format->format.height);
+
+ fmt.pad = pad->index;
+ ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, &fmt);
+ if (ret < 0) {
+ dev_err(dcmi->dev, "%s: Failed to set format 0x%x %ux%u on \"%s\":%d pad (%d)\n",
+ __func__, format->format.code,
+ format->format.width, format->format.height,
+ subdev->name, pad->index, ret);
+ return ret;
+ }
+
+ if (fmt.format.code != format->format.code ||
+ fmt.format.width != format->format.width ||
+ fmt.format.height != format->format.height) {
+ dev_dbg(dcmi->dev, "\"%s\":%d pad format has been changed to 0x%x %ux%u\n",
+ subdev->name, pad->index, fmt.format.code,
+ fmt.format.width, fmt.format.height);
+ }
+
+ /* Walk to next entity */
+ sink_pad = media_entity_remote_pad(src_pad);
+ if (!sink_pad || !is_media_entity_v4l2_subdev(sink_pad->entity))
+ break;
+
+ entity = sink_pad->entity;
+ }
+ *format = fmt;
+
+ return 0;
+}
+
+static int dcmi_pipeline_s_stream(struct stm32_dcmi *dcmi, int state)
+{
+ struct media_entity *entity = &dcmi->vdev->entity;
+ struct v4l2_subdev *subdev;
+ struct media_pad *pad;
+ int ret;
+
+ /* Start/stop all entities within pipeline */
+ while (1) {
+ pad = &entity->pads[0];
+ if (!(pad->flags & MEDIA_PAD_FL_SINK))
+ break;
+
+ pad = media_entity_remote_pad(pad);
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+ break;
+
+ entity = pad->entity;
+ subdev = media_entity_to_v4l2_subdev(entity);
+
+ ret = v4l2_subdev_call(subdev, video, s_stream, state);
+ if (ret < 0 && ret != -ENOIOCTLCMD) {
+ dev_err(dcmi->dev, "%s: \"%s\" failed to %s streaming (%d)\n",
+ __func__, subdev->name,
+ state ? "start" : "stop", ret);
+ return ret;
+ }
+
+ dev_dbg(dcmi->dev, "\"%s\" is %s\n",
+ subdev->name, state ? "started" : "stopped");
+ }
+
+ return 0;
+}
+
+static int dcmi_pipeline_start(struct stm32_dcmi *dcmi)
+{
+ return dcmi_pipeline_s_stream(dcmi, 1);
+}
+
+static void dcmi_pipeline_stop(struct stm32_dcmi *dcmi)
+{
+ dcmi_pipeline_s_stream(dcmi, 0);
+}
+
static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
@@ -597,14 +736,17 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
goto err_release_buffers;
}
- /* Enable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 1);
- if (ret && ret != -ENOIOCTLCMD) {
- dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
- __func__);
+ ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
+ if (ret < 0) {
+ dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
+ __func__, ret);
goto err_pm_put;
}
+ ret = dcmi_pipeline_start(dcmi);
+ if (ret)
+ goto err_media_pipeline_stop;
+
spin_lock_irq(&dcmi->irqlock);
/* Set bus width */
@@ -676,7 +818,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
if (ret) {
dev_err(dcmi->dev, "%s: Start streaming failed, cannot start capture\n",
__func__);
- goto err_subdev_streamoff;
+ goto err_pipeline_stop;
}
/* Enable interruptions */
@@ -687,8 +829,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
-err_subdev_streamoff:
- v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
+err_pipeline_stop:
+ dcmi_pipeline_stop(dcmi);
+
+err_media_pipeline_stop:
+ media_pipeline_stop(&dcmi->vdev->entity);
err_pm_put:
pm_runtime_put(dcmi->dev);
@@ -713,13 +858,10 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
struct dcmi_buf *buf, *node;
- int ret;
- /* Disable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
- if (ret && ret != -ENOIOCTLCMD)
- dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
- __func__, ret);
+ dcmi_pipeline_stop(dcmi);
+
+ media_pipeline_stop(&dcmi->vdev->entity);
spin_lock_irq(&dcmi->irqlock);
@@ -937,8 +1079,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
mf->width = sd_framesize.width;
mf->height = sd_framesize.height;
- ret = v4l2_subdev_call(dcmi->entity.source, pad,
- set_fmt, NULL, &format);
+ ret = dcmi_pipeline_s_fmt(dcmi, NULL, &format);
if (ret < 0)
return ret;
@@ -1412,6 +1553,12 @@ static int dcmi_set_default_fmt(struct stm32_dcmi *dcmi)
return 0;
}
+/*
+ * FIXME: For the time being we only support subdevices
+ * which expose RGB & YUV "parallel form" mbus code (_2X8).
+ * Nevertheless, this allows to support serial source subdevices
+ * and serial to parallel bridges which conform to this.
+ */
static const struct dcmi_format dcmi_formats[] = {
{
.fourcc = V4L2_PIX_FMT_RGB565,
@@ -1537,7 +1684,20 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
int ret;
+ /*
+ * Now that the graph is complete,
+ * we search for the source subdevice
+ * in order to expose it through V4L2 interface
+ */
+ dcmi->entity.source =
+ media_entity_to_v4l2_subdev(dcmi_find_source(dcmi));
+ if (!dcmi->entity.source) {
+ dev_err(dcmi->dev, "Source subdevice not found\n");
+ return -ENODEV;
+ }
+
dcmi->vdev->ctrl_handler = dcmi->entity.source->ctrl_handler;
+
ret = dcmi_formats_init(dcmi);
if (ret) {
dev_err(dcmi->dev, "No supported mediabus format found\n");
@@ -1582,12 +1742,31 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
struct v4l2_async_subdev *asd)
{
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
+ unsigned int ret;
+ int src_pad;
- dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
+ dev_dbg(dcmi->dev, "Subdev \"%s\" bound\n", subdev->name);
- dcmi->entity.source = subdev;
+ /*
+ * Link this sub-device to DCMI, it could be
+ * a parallel camera sensor or a bridge
+ */
+ src_pad = media_entity_get_fwnode_pad(&subdev->entity,
+ subdev->fwnode,
+ MEDIA_PAD_FL_SOURCE);
+
+ ret = media_create_pad_link(&subdev->entity, src_pad,
+ &dcmi->vdev->entity, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ dev_err(dcmi->dev, "Failed to create media pad link with subdev \"%s\"\n",
+ subdev->name);
+ else
+ dev_dbg(dcmi->dev, "DCMI is now linked to \"%s\"\n",
+ subdev->name);
- return 0;
+ return ret;
}
static const struct v4l2_async_notifier_operations dcmi_graph_notify_ops = {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 3/4] media: stm32-dcmi: add media controller support
From: Hugues Fruchet @ 2019-08-14 13:48 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1565790533-10043-1-git-send-email-hugues.fruchet@st.com>
Add media controller support to dcmi in order
to walk within remote subdevices pipeline.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c | 52 ++++++++++++++++++++++++-------
2 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 8a19654..de7e21f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -121,7 +121,7 @@ config VIDEO_S3C_CAMIF
config VIDEO_STM32_DCMI
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
- depends on VIDEO_V4L2 && OF
+ depends on VIDEO_V4L2 && OF && MEDIA_CONTROLLER
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index 18acecf..302c40e 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -169,6 +169,9 @@ struct stm32_dcmi {
/* Ensure DMA operations atomicity */
struct mutex dma_lock;
+
+ struct media_device mdev;
+ struct media_pad vid_cap_pad;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -1559,14 +1562,6 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
return ret;
}
- ret = video_register_device(dcmi->vdev, VFL_TYPE_GRABBER, -1);
- if (ret) {
- dev_err(dcmi->dev, "Failed to register video device\n");
- return ret;
- }
-
- dev_dbg(dcmi->dev, "Device registered as %s\n",
- video_device_node_name(dcmi->vdev));
return 0;
}
@@ -1759,10 +1754,19 @@ static int dcmi_probe(struct platform_device *pdev)
q = &dcmi->queue;
+ dcmi->v4l2_dev.mdev = &dcmi->mdev;
+
+ /* Initialize media device */
+ strscpy(dcmi->mdev.model, DRV_NAME, sizeof(dcmi->mdev.model));
+ snprintf(dcmi->mdev.bus_info, sizeof(dcmi->mdev.bus_info),
+ "platform:%s", DRV_NAME);
+ dcmi->mdev.dev = &pdev->dev;
+ media_device_init(&dcmi->mdev);
+
/* Initialize the top-level structure */
ret = v4l2_device_register(&pdev->dev, &dcmi->v4l2_dev);
if (ret)
- goto err_dma_release;
+ goto err_media_device_cleanup;
dcmi->vdev = video_device_alloc();
if (!dcmi->vdev) {
@@ -1782,6 +1786,25 @@ static int dcmi_probe(struct platform_device *pdev)
V4L2_CAP_READWRITE;
video_set_drvdata(dcmi->vdev, dcmi);
+ /* Media entity pads */
+ dcmi->vid_cap_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(&dcmi->vdev->entity,
+ 1, &dcmi->vid_cap_pad);
+ if (ret) {
+ dev_err(dcmi->dev, "Failed to init media entity pad\n");
+ goto err_device_release;
+ }
+ dcmi->vdev->entity.flags |= MEDIA_ENT_FL_DEFAULT;
+
+ ret = video_register_device(dcmi->vdev, VFL_TYPE_GRABBER, -1);
+ if (ret) {
+ dev_err(dcmi->dev, "Failed to register video device\n");
+ goto err_media_entity_cleanup;
+ }
+
+ dev_dbg(dcmi->dev, "Device registered as %s\n",
+ video_device_node_name(dcmi->vdev));
+
/* Buffer queue */
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_READ | VB2_DMABUF;
@@ -1797,12 +1820,12 @@ static int dcmi_probe(struct platform_device *pdev)
ret = vb2_queue_init(q);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to initialize vb2 queue\n");
- goto err_device_release;
+ goto err_media_entity_cleanup;
}
ret = dcmi_graph_init(dcmi);
if (ret < 0)
- goto err_device_release;
+ goto err_media_entity_cleanup;
/* Reset device */
ret = reset_control_assert(dcmi->rstc);
@@ -1829,11 +1852,14 @@ static int dcmi_probe(struct platform_device *pdev)
err_cleanup:
v4l2_async_notifier_cleanup(&dcmi->notifier);
+err_media_entity_cleanup:
+ media_entity_cleanup(&dcmi->vdev->entity);
err_device_release:
video_device_release(dcmi->vdev);
err_device_unregister:
v4l2_device_unregister(&dcmi->v4l2_dev);
-err_dma_release:
+err_media_device_cleanup:
+ media_device_cleanup(&dcmi->mdev);
dma_release_channel(dcmi->dma_chan);
return ret;
@@ -1847,7 +1873,9 @@ static int dcmi_remove(struct platform_device *pdev)
v4l2_async_notifier_unregister(&dcmi->notifier);
v4l2_async_notifier_cleanup(&dcmi->notifier);
+ media_entity_cleanup(&dcmi->vdev->entity);
v4l2_device_unregister(&dcmi->v4l2_dev);
+ media_device_cleanup(&dcmi->mdev);
dma_release_channel(dcmi->dma_chan);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 1/3] media: stm32-dcmi: improve sensor subdev naming
From: Hugues FRUCHET @ 2019-08-14 14:17 UTC (permalink / raw)
To: Sakari Ailus, Hans Verkuil
Cc: Alexandre TORGUE, Mickael GUENE, linux-kernel@vger.kernel.org,
Philippe CORNU, Yannick FERTRE, Benjamin Gaignard,
Mauro Carvalho Chehab, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <20190809160121.GA6194@paasikivi.fi.intel.com>
Hi Sakari, Hans,
I've just pushed a v6 with the FIXME we discussed on IRC about
"parallel" mbus code versus "serial" mbus code. I have also added
some traces to help in debugging if such case occurs.
version 6:
- As per Sakari remark: add a FIXME explaining that this
version only supports subdevices which expose RGB & YUV
"parallel form" mbus code (_2X8)
- Add some trace around subdev_call(s_fmt) error & format
changes to debug subdev which only expose serial mbus code
- Conform to "<name>":<pad index> when tracing subdev infos
Best regards,
Hugues.
On 8/9/19 6:01 PM, Sakari Ailus wrote:
> Hi Hugues,
>
> Thanks for teh update.
>
> On Wed, Jul 31, 2019 at 02:56:21PM +0200, Hugues Fruchet wrote:
>> Rename "subdev" entity struct field to "source"
>> to prepare for several subdev support.
>> Move asd field on top of entity struct.
>>
>> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
>> Change-Id: I1545a1a29a8061ee67cc6e4b799e9a69071911e7
>
> No Change-Id tags in the kernel, please. Check the other two as well.
>
> With that fixed,
>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/9] arm64: Stolen time support
From: Marc Zyngier @ 2019-08-14 14:19 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini, Steven Price, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <8ca5c106-7c12-4c6e-6d81-a90f281a9894@amazon.com>
On Wed, 14 Aug 2019 14:02:25 +0100,
Alexander Graf <graf@amazon.com> wrote:
>
>
>
> On 05.08.19 15:06, Steven Price wrote:
> > On 03/08/2019 19:05, Marc Zyngier wrote:
> >> On Fri, 2 Aug 2019 15:50:08 +0100
> >> Steven Price <steven.price@arm.com> wrote:
> >>
> >> Hi Steven,
> >>
> >>> This series add support for paravirtualized time for arm64 guests and
> >>> KVM hosts following the specification in Arm's document DEN 0057A:
> >>>
> >>> https://developer.arm.com/docs/den0057/a
> >>>
> >>> It implements support for stolen time, allowing the guest to
> >>> identify time when it is forcibly not executing.
> >>>
> >>> It doesn't implement support for Live Physical Time (LPT) as there are
> >>> some concerns about the overheads and approach in the above
> >>> specification, and I expect an updated version of the specification to
> >>> be released soon with just the stolen time parts.
> >>
> >> Thanks for posting this.
> >>
> >> My current concern with this series is around the fact that we allocate
> >> memory from the kernel on behalf of the guest. It is the first example
> >> of such thing in the ARM port, and I can't really say I'm fond of it.
> >>
> >> x86 seems to get away with it by having the memory allocated from
> >> userspace, why I tend to like more. Yes, put_user is more
> >> expensive than a straight store, but this isn't done too often either.
> >>
> >> What is the rational for your current approach?
> >
> > As I see it there are 3 approaches that can be taken here:
> >
> > 1. Hypervisor allocates memory and adds it to the virtual machine. This
> > means that everything to do with the 'device' is encapsulated behind the
> > KVM_CREATE_DEVICE / KVM_[GS]ET_DEVICE_ATTR ioctls. But since we want the
> > stolen time structure to be fast it cannot be a trapping region and has
> > to be backed by real memory - in this case allocated by the host kernel.
> >
> > 2. Host user space allocates memory. Similar to above, but this time
> > user space needs to manage the memory region as well as the usual
> > KVM_CREATE_DEVICE dance. I've no objection to this, but it means
> > kvmtool/QEMU needs to be much more aware of what is going on (e.g. how
> > to size the memory region).
>
> You ideally want to get the host overhead for a VM to as little as you
> can. I'm not terribly fond of the idea of reserving a full page just
> because we're too afraid of having the guest donate memory.
Well, reduce the amount of memory you give to the guest by one page,
and allocate that page to the stolen time device. Problem solved!
Seriously, if you're worried about the allocation of a single page,
you should first look at how many holes we have in the vcpu structure,
for example (even better, with the 8.4 NV patches applied). Just
fixing that would give you that page back *per vcpu*.
> > 3. Guest kernel "donates" the memory to the hypervisor for the
> > structure. As far as I'm aware this is what x86 does. The problems I see
> > this approach are:
> >
> > a) kexec becomes much more tricky - there needs to be a disabling
> > mechanism for the guest to stop the hypervisor scribbling on memory
> > before starting the new kernel.
>
> I wouldn't call "quiesce a device" much more tricky. We have to do
> that for other devices as well today.
And since there is no standard way of doing it, we keep inventing
weird and wonderful ways of doing so -- cue the terrible GICv3 LPI
situation, and all the various hacks to keep existing IOMMU mappings
around across firmware/kernel handovers as well as kexec.
>
> > b) If there is more than one entity that is interested in the
> > information (e.g. firmware and kernel) then this requires some form of
> > arbitration in the guest because the hypervisor doesn't want to have to
> > track an arbitrary number of regions to update.
>
> Why would FW care?
Exactly. It doesn't care. Not caring means it doesn't know about the
page the guest has allocated for stolen time, and starts using it for
its own purposes. Hello, memory corruption. Same thing goes if you
reboot into a non stolen time aware kernel.
>
> > c) Performance can suffer if the host kernel doesn't have a suitably
> > aligned/sized area to use. As you say - put_user() is more expensive.
>
> Just define the interface to always require natural alignment when
> donating a memory location?
>
> > The structure is updated on every return to the VM.
>
> If you really do suffer from put_user(), there are alternatives. You
> could just map the page on the registration hcall and then leave it
> pinned until the vcpu gets destroyed again.
put_user() should be cheap enough. It is one of the things we tend to
optimise anyway. And yes, worse case, we pin the page.
>
> > Of course x86 does prove the third approach can work, but I'm not sure
> > which is actually better. Avoid the kexec cancellation requirements was
> > the main driver of the current approach. Although many of the
>
> I really don't understand the problem with kexec cancellation. Worst
> case, let guest FW set it up for you and propagate only the address
> down via ACPI/DT. That way you can mark the respective memory as
> reserved too.
We already went down that road with the LPI hack. I'm not going there
again if we can avoid it. And it turn out that we can. Just allocate
the stolen time page as a separate memblock, give it to KVM for that
purpose.
Your suggestion of letting the guest firmware set something up only
works if whatever you're booting after that understands it. If it
doesn't, you're screwed.
> But even with a Linux only mechanism, just take a look at
> arch/x86/kernel/kvmclock.c. All they do to remove the map is to hook
> into machine_crash_shutdown() and machine_shutdown().
I'm not going to take something that is Linux specific. It has to work
for all guests, at all times, whether they know about the hypervisor
service or not.
M.
>
>
> Alex
>
> > conversations about this were also tied up with Live Physical Time which
> > adds its own complications.
> >
> > Steve
> > _______________________________________________
> > kvmarm mailing list
> > kvmarm@lists.cs.columbia.edu
> > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
> >
--
Jazz is not dead, it just smells funny.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/6] dt-bindings: arm: coresight: Add support for coresight-needs-save-restore
From: Mike Leach @ 2019-08-14 14:20 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Al Grant, Mathieu Poirier, Alexander Shishkin, Coresight ML,
Sudeep Holla, Leo Yan, Andrew Murray, linux-arm-kernel
In-Reply-To: <718b5bdf-9828-f215-9a81-637308be3b49@arm.com>
Hi Suzuki,
On Wed, 14 Aug 2019 at 13:35, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> Hi Mike,
>
> On 14/08/2019 12:06, Mike Leach wrote:
> > Hi,
> >
> > On Wed, 14 Aug 2019 at 11:01, Andrew Murray <andrew.murray@arm.com> wrote:
> >>
> >> On Sun, Aug 04, 2019 at 07:13:45AM -0600, Mathieu Poirier wrote:
> >>> On Fri, 2 Aug 2019 at 08:37, Andrew Murray <andrew.murray@arm.com> wrote:
> >>>>
> >>>> On Fri, Aug 02, 2019 at 11:40:54AM +0100, Suzuki K Poulose wrote:
> >>>>> Hi Andrew,
> >>>>>
> >>>>> On 30/07/2019 13:51, Andrew Murray wrote:
> >>>>>> Some coresight components, because of choices made during hardware
> >>>>>> integration, require their state to be saved and restored across CPU low
> >>>>>> power states.
>
> ...
>
> >>>>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> >>>>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> >>>>>> @@ -92,6 +92,9 @@ its hardware characteristcs.
> >>>>>> * arm,cp14: must be present if the system accesses ETM/PTM management
> >>>>>> registers via co-processor 14.
> >>>>>> + * arm,coresight-needs-save-restore: boolean. Indicates that software
> >>>>>> + should save/restore state across power down.
> >>>>>> +
> >>>>>
> >>>>> Do you think we could be a bit more descriptive here about when people could add
> >>>>> it to the DT ? Here we don't mention when someone should use this property and
> >>>>> it may be added to platforms where it may be absolutely unnecessary. How about :
> >>>>>
> >>>>> "Indicates that the hardware implementation may not honor the Powerup request
> >>>>> from the software and thus might loose the register context on CPU power
> >>>>> down (e.g, during CPUIdle). Software must save/restore the context during a
> >>>>> CPU power transition cycle."
> >>>>
> >>>> How about the following:
> >>>>
> >>>> "Indicates that the hardware will loose register context on CPU power down (e.g.
> >>>> CPUIdle), despite the TRCPDCR.PU bit being set."
> >>>>
> >>>> I'm keen to avoid making suggestions about what the kernel will do when it sees
> >>>> this flag and thus prefer to focus on describing what the hardware does. So I
> >>>> dropped your last sentence. However the name of the flag still implies policy
> >>>> which I don't like.
> >>>>
> >>>> I also changed the 'may not honor' wording, I'm not sure if this is really the
> >>>> case or if the spec is open to interpretation.
> >>>>
> >>>> It would great for this wording to also apply to other CS components though I
> >>>> haven't investigated if these have a PU bit or something different.
> >>>
> >>> Exactly - the definition needs to be broad enough to apply to other CS
> >>> components. Mike what do you think would be appropriate for CTIs?
> >>
> > CTIs have no power control at all - i.e. no PU bit to request we stay
> > up - and reside in the debug power domain. So they are coupled to the
> > CS/CPU/ETM/ power domains and reliant on outside forces to request
> > power.
> > The expectation is that for a PE bound CTI, if debug is powered then
> > it will be fully powered - so an ETM with PU respected, or the
> > external debug logic with DBGNOPWRDWN respected should be sufficient
> > for CTI to stay alive.
>
> I am trying to understand why we need this property for CTI.
> Don't we always need to save-restore the CTI controls on a CPU_DOWN for the
> associated CTI ? Since it may not be really tied to an ETM (e.g, if the CTI is
> purely used to handle CPU triggers, PMU etc,). If that is the case, do we need
> this property for CTI at all ?
>
CTI will be in use for one of two reasons:-
1) External Debug - in which case the DBGNOPOWERDOWN bit should be set
and the debug domain remains powered.
2) Trace (self hosted or external) - so we have an ETM and PU is set
and the debug power domain remains powered.
In these ideal cases we never need to save and restore as the debug
power domain remains powered.
Now in this phase of development we are disregarding external debug
and trace. So we are only in self hosted trace mode - which is
probably the most common use case for a linux system.
Therefore the CTI will only be in use if there is an ETM tracing self
hosted. If PU is not working and the parameter is set then we know we
need to hook CPUIdle notifications and save and restore (thought in
the case of CTI it is really restore only for self hosted as there are
no dynamic registers.). If we are not saving and restoring then we do
not need to register for CPUIdle notifiers (which like hotplug need to
be centralised, not re-implemented in each and every driver), saving
some latency.
The architecture specifically precludes using the CTI PMU trigger to
the generic CTI PE interrupt - so the PMU overflow trigger will only
ever be used to activate some debug event (e.g. debug halt, trace halt
etc).
Regards
Mike
> >
> >> How about we keep this short and simple:
> >>
> >> * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
>
> nit: s/loses/looses ?
>
> >> will lose register context on CPU power down (e.g. CPUIdle).
> >>
> >
> > So the above name is generic enough to encompass the CTI as well.
> >
> >> I could have added something like "... despite TRCPDCR.PU being set", or to
> >> apply more generically: "... despite available register controls being set to
> >> prevent such context loss". However whilst these are more informative - they
> >> elude to some of reasons as to why context is lost and as we cannot be
> >> exhaustive I'd rather not give a limited example.
> >>
> >> However if a longer explaination is required:
> >>
> >> * arm,coresight-loses-context-with-cpu : boolean. Indicates that the hardware
> >> will lose register context on CPU power down (e.g. CPUIdle). An example of
> >> where this may be needed are systems which contain a coresight component and
> >> CPU in the same power domain. When the CPU powers down the coresight
> >> component also powers down and loses its context.
>
> This looks fine for me. But I am trying to understand the rationale behind
> using this for CTI
>
> Suzuki
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 00/14] arm64: dts: meson: fixes following YAML bindings schemas conversion
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
This is the first set of DT fixes following the first YAML bindings conversion
at [1], [2] and [3].
After this set of fixes, the remaining errors are :
meson-axg-s400.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
meson-g12a-sei510.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
meson-g12b-odroid-n2.dt.yaml: usb-hub: gpios:0:0: 20 is not valid under any of the given schemas
meson-g12b-odroid-n2.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
meson-g12a-x96-max.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
These are only cosmetic changes, and should not break drivers implementation
following the bindings.
Neil Armstrong (14):
arm64: dts: meson: fix ethernet mac reg format
arm64: dts: meson-gx: drop the vpu dmc memory cell
arm64: dts: meson-gx: fix reset controller compatible
arm64: dts: meson-gx: fix spifc compatible
arm64: dts: meson-gx: fix watchdog compatible
arm64: dts: meson-gx: fix mhu compatible
arm64: dts: meson-gx: fix periphs bus node name
arm64: dts: meson-gxl: fix internal phy compatible
arm64: dts: meson-axg: fix MHU compatible
arm64: dts: meson-g12a: fix reset controller compatible
arm64: dts: meson-g12a-x96-max: fix compatible
arm64: dts: meson-gxbb-nanopi-k2: add missing model
arm64: dts: meson-gxbb-p201: fix snps,reset-delays-us format
arm64: dts: meson: fix boards regulators states format
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 +++---
.../boot/dts/amlogic/meson-g12a-x96-max.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 7 +++----
.../boot/dts/amlogic/meson-g12b-odroid-n2.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +++++++++----------
.../boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 1 +
.../dts/amlogic/meson-gxbb-nexbox-a95x.dts | 4 ++--
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++--
.../boot/dts/amlogic/meson-gxbb-p201.dts | 2 +-
.../boot/dts/amlogic/meson-gxbb-p20x.dtsi | 4 ++--
.../meson-gxl-s905x-hwacom-amazetv.dts | 4 ++--
.../amlogic/meson-gxl-s905x-nexbox-a95x.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 5 +----
13 files changed, 31 insertions(+), 35 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 03/14] arm64: dts: meson-gx: fix reset controller compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: reset-controller@4404: compatible:0: 'amlogic,meson-gx-reset' is not one of ['amlogic,meson8b-reset', 'amlogic,meson-gxbb-reset', 'amlogic,meson-axg-reset']
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index c2d3fffea8a7..5b3dfd03c3d3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -220,7 +220,7 @@
};
reset: reset-controller@4404 {
- compatible = "amlogic,meson-gx-reset", "amlogic,meson-gxbb-reset";
+ compatible = "amlogic,meson-gxbb-reset";
reg = <0x0 0x04404 0x0 0x9c>;
#reset-cells = <1>;
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/14] arm64: dts: meson-gx: drop the vpu dmc memory cell
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxl-s805x-libretech-ac.dt.yaml: vpu@d0100000: reg-names: Additional items are not allowed ('dmc' was unexpected)
meson-gxl-s805x-libretech-ac.dt.yaml: vpu@d0100000: reg-names: ['vpu', 'hhi', 'dmc'] is too long
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index faff77175486..c2d3fffea8a7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -528,9 +528,8 @@
vpu: vpu@d0100000 {
compatible = "amlogic,meson-gx-vpu";
reg = <0x0 0xd0100000 0x0 0x100000>,
- <0x0 0xc883c000 0x0 0x1000>,
- <0x0 0xc8838000 0x0 0x1000>;
- reg-names = "vpu", "hhi", "dmc";
+ <0x0 0xc883c000 0x0 0x1000>;
+ reg-names = "vpu", "hhi";
interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
#address-cells = <1>;
#size-cells = <0>;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/14] arm64: dts: meson-gx: fix watchdog compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: watchdog@98d0: compatible:0: 'amlogic,meson-gx-wdt' is not one of ['amlogic,meson-gxbb-wdt']
meson-gxl-s805x-libretech-ac.dt.yaml: watchdog@98d0: compatible:0: 'amlogic,meson-gx-wdt' is not one of ['amlogic,meson-gxbb-wdt']
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index e2cdc9fce21c..00215ece17c8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -325,7 +325,7 @@
};
watchdog@98d0 {
- compatible = "amlogic,meson-gx-wdt", "amlogic,meson-gxbb-wdt";
+ compatible = "amlogic,meson-gxbb-wdt";
reg = <0x0 0x098d0 0x0 0x10>;
clocks = <&xtal>;
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 01/14] arm64: dts: meson: fix ethernet mac reg format
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-axg-s400.dt.yaml: soc: ethernet@ff3f0000:reg:0: [0, 4282318848, 0, 65536, 0, 4284695872, 0, 8] is too long
meson-axg-s400.dt.yaml: ethernet@ff3f0000: reg: [[0, 4282318848, 0, 65536, 0, 4284695872, 0, 8]] is too short
meson-g12a-u200.dt.yaml: soc: ethernet@ff3f0000:reg:0: [0, 4282318848, 0, 65536, 0, 4284695872, 0, 8] is too long
meson-g12a-u200.dt.yaml: ethernet@ff3f0000: reg: [[0, 4282318848, 0, 65536, 0, 4284695872, 0, 8]] is too short
meson-gxbb-nanopi-k2.dt.yaml: soc: ethernet@c9410000:reg:0: [0, 3376480256, 0, 65536, 0, 3364046144, 0, 4] is too long
meson-gxl-s805x-libretech-ac.dt.yaml: soc: ethernet@c9410000:reg:0: [0, 3376480256, 0, 65536, 0, 3364046144, 0, 4] is too lon
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 3 ---
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6219337033a0..4a134d29491d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -174,8 +174,8 @@
compatible = "amlogic,meson-axg-dwmac",
"snps,dwmac-3.70a",
"snps,dwmac";
- reg = <0x0 0xff3f0000 0x0 0x10000
- 0x0 0xff634540 0x0 0x8>;
+ reg = <0x0 0xff3f0000 0x0 0x10000>,
+ <0x0 0xff634540 0x0 0x8>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
clocks = <&clkc CLKID_ETH>,
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
index f8d43e3dcf20..465106d37289 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -141,8 +141,8 @@
compatible = "amlogic,meson-axg-dwmac",
"snps,dwmac-3.70a",
"snps,dwmac";
- reg = <0x0 0xff3f0000 0x0 0x10000
- 0x0 0xff634540 0x0 0x8>;
+ reg = <0x0 0xff3f0000 0x0 0x10000>,
+ <0x0 0xff634540 0x0 0x8>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
clocks = <&clkc CLKID_ETH>,
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 74d03fc706be..faff77175486 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -489,8 +489,8 @@
compatible = "amlogic,meson-gxbb-dwmac",
"snps,dwmac-3.70a",
"snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000
- 0x0 0xc8834540 0x0 0x4>;
+ reg = <0x0 0xc9410000 0x0 0x10000>,
+ <0x0 0xc8834540 0x0 0x4>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
status = "disabled";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index c959456bacc6..ee1ecdbcc958 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -80,9 +80,6 @@
};
ðmac {
- reg = <0x0 0xc9410000 0x0 0x10000
- 0x0 0xc8834540 0x0 0x4>;
-
clocks = <&clkc CLKID_ETH>,
<&clkc CLKID_FCLK_DIV2>,
<&clkc CLKID_MPLL2>;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/14] arm64: dts: meson-gx: fix mhu compatible
From: Neil Armstrong @ 2019-08-14 14:29 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, Neil Armstrong, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190814142918.11636-1-narmstrong@baylibre.com>
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: mailbox@404: compatible:0: 'amlogic,meson-gx-mhu' is not one of ['amlogic,meson-gxbb-mhu']
meson-gxl-s805x-libretech-ac.dt.yaml: mailbox@404: compatible:0: 'amlogic,meson-gx-mhu' is not one of ['amlogic,meson-gxbb-mhu']
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 00215ece17c8..d8127f863b55 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -476,7 +476,7 @@
};
mailbox: mailbox@404 {
- compatible = "amlogic,meson-gx-mhu", "amlogic,meson-gxbb-mhu";
+ compatible = "amlogic,meson-gxbb-mhu";
reg = <0 0x404 0 0x4c>;
interrupts = <GIC_SPI 208 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 209 IRQ_TYPE_EDGE_RISING>,
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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