* [PATCH v2 04/11] of/fdt: add early_init_dt_get_dma_zone_size()
From: Nicolas Saenz Julienne @ 2019-08-20 14:58 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
Robin Murphy, linux-arm-kernel, devicetree, linux-arch, iommu,
linux-mm, linux-riscv, Frank Rowand
Cc: phill, f.fainelli, linux-kernel, eric, mbrugger, linux-rpi-kernel,
akpm, will, nsaenzjulienne, m.szyprowski
In-Reply-To: <20190820145821.27214-1-nsaenzjulienne@suse.de>
Some devices might have weird DMA addressing limitations that only apply
to a subset of the available peripherals. For example the Raspberry Pi 4
has two interconnects, one able to address the whole lower 4G memory
area and another one limited to the lower 1G.
Being an uncommon situation we simply hardcode the device wide DMA
addressable memory size conditionally to the machine compatible name and
set 'dma_zone_size' accordingly.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes in v2:
- New approach to getting dma_zone_size, instead of parsing the dts we
hardcode it conditionally to the machine compatible name.
drivers/of/fdt.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 06ffbd39d9af..f756e8c05a77 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -27,6 +27,7 @@
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#include <asm/page.h>
+#include <asm/dma.h> /* for dma_zone_size */
#include "of_private.h"
@@ -1195,6 +1196,12 @@ void __init early_init_dt_scan_nodes(void)
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
}
+void __init early_init_dt_get_dma_zone_size(void)
+{
+ if (of_fdt_machine_is_compatible("brcm,bcm2711"))
+ dma_zone_size = 0x3c000000;
+}
+
bool __init early_init_dt_scan(void *params)
{
bool status;
@@ -1204,6 +1211,7 @@ bool __init early_init_dt_scan(void *params)
return false;
early_init_dt_scan_nodes();
+ early_init_dt_get_dma_zone_size();
return true;
}
--
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 v2 03/11] of/fdt: add of_fdt_machine_is_compatible function
From: Nicolas Saenz Julienne @ 2019-08-20 14:58 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
Robin Murphy, linux-arm-kernel, devicetree, linux-arch, iommu,
linux-mm, linux-riscv, Frank Rowand
Cc: phill, f.fainelli, linux-kernel, eric, mbrugger, linux-rpi-kernel,
akpm, will, nsaenzjulienne, m.szyprowski
In-Reply-To: <20190820145821.27214-1-nsaenzjulienne@suse.de>
Provides the same functionality as of_machine_is_compatible.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes in v2: None
drivers/of/fdt.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9cdf14b9aaab..06ffbd39d9af 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -802,6 +802,13 @@ const char * __init of_flat_dt_get_machine_name(void)
return name;
}
+static const int __init of_fdt_machine_is_compatible(char *name)
+{
+ unsigned long dt_root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(dt_root, name);
+}
+
/**
* of_flat_dt_match_machine - Iterate match tables to find matching machine.
*
--
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 v2 02/11] arm: use generic dma_zone_size
From: Nicolas Saenz Julienne @ 2019-08-20 14:58 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
Robin Murphy, linux-arm-kernel, devicetree, linux-arch, iommu,
linux-mm, linux-riscv, linux-kernel
Cc: phill, f.fainelli, frowand.list, Russell King, eric, mbrugger,
linux-rpi-kernel, akpm, will, nsaenzjulienne, m.szyprowski
In-Reply-To: <20190820145821.27214-1-nsaenzjulienne@suse.de>
'dma_zone_size' was created as a generic replacement to
'arm_dma_zone_size'. Use it accordingly.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes in v2: None
arch/arm/include/asm/dma.h | 8 +++++---
arch/arm/mm/init.c | 12 ++++--------
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index a81dda65c576..52d19ffd92b4 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -2,16 +2,18 @@
#ifndef __ASM_ARM_DMA_H
#define __ASM_ARM_DMA_H
+#include <asm-generic/dma.h>
+
/*
* This is the maximum virtual address which can be DMA'd from.
*/
+#undef MAX_DMA_ADDRESS
#ifndef CONFIG_ZONE_DMA
#define MAX_DMA_ADDRESS 0xffffffffUL
#else
#define MAX_DMA_ADDRESS ({ \
- extern phys_addr_t arm_dma_zone_size; \
- arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
- (PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })
+ dma_zone_size && dma_zone_size < (0x10000000 - PAGE_OFFSET) ? \
+ (PAGE_OFFSET + dma_zone_size) : 0xffffffffUL; })
#endif
#ifdef CONFIG_ISA_DMA_API
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 16d373d587c4..95680bad245a 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -79,10 +79,6 @@ static void __init find_limits(unsigned long *min, unsigned long *max_low,
}
#ifdef CONFIG_ZONE_DMA
-
-phys_addr_t arm_dma_zone_size __read_mostly;
-EXPORT_SYMBOL(arm_dma_zone_size);
-
/*
* The DMA mask corresponding to the maximum bus address allocatable
* using GFP_DMA. The default here places no restriction on DMA
@@ -109,8 +105,8 @@ void __init setup_dma_zone(const struct machine_desc *mdesc)
{
#ifdef CONFIG_ZONE_DMA
if (mdesc->dma_zone_size) {
- arm_dma_zone_size = mdesc->dma_zone_size;
- arm_dma_limit = PHYS_OFFSET + arm_dma_zone_size - 1;
+ dma_zone_size = mdesc->dma_zone_size;
+ arm_dma_limit = PHYS_OFFSET + dma_zone_size - 1;
} else
arm_dma_limit = 0xffffffff;
arm_dma_pfn_limit = arm_dma_limit >> PAGE_SHIFT;
@@ -164,9 +160,9 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max_low,
* Adjust the sizes according to any special requirements for
* this machine type.
*/
- if (arm_dma_zone_size)
+ if (dma_zone_size)
arm_adjust_dma_zone(zone_size, zhole_size,
- arm_dma_zone_size >> PAGE_SHIFT);
+ dma_zone_size >> PAGE_SHIFT);
#endif
free_area_init_node(0, zone_size, min, zhole_size);
--
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 v2 00/11] Raspberry Pi 4 DMA addressing support
From: Nicolas Saenz Julienne @ 2019-08-20 14:58 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
Robin Murphy, linux-arm-kernel, devicetree, linux-arch, iommu,
linux-mm, linux-riscv
Cc: phill, linux-s390, f.fainelli, frowand.list, linuxppc-dev,
linux-kernel, eric, mbrugger, linux-rpi-kernel, akpm, will,
nsaenzjulienne, m.szyprowski
Hi all,
this series attempts to address some issues we found while bringing up
the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
up of these discussions:
v1: https://lkml.org/lkml/2019/7/31/922
RFC: https://lkml.org/lkml/2019/7/17/476
The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
only address the first GB: their DMA address range is
0xc0000000-0xfc000000 which is aliased to the first GB of physical
memory 0x00000000-0x3c000000. Note that only some peripherals have these
limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
view of the address space by virtue of being hooked up trough a second
interconnect.
Part of this is solved in arm32 by setting up the machine specific
'.dma_zone_size = SZ_1G', which takes care of reserving the coherent
memory area at the right spot. That said no buffer bouncing (needed for
dma streaming) is available at the moment, but that's a story for
another series.
Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
arch code as if all peripherals where be able to address the first 4GB
of memory.
In the light of this, the series implements the following changes:
- Create generic 'dma_zone_size' in order for hardware description code
to set it up when needed.
- Add a function in early_init_dt_scan() to setup 'dma_zone_size' for
the RPi4.
- Create both DMA zones in arm64, ZONE_DMA will contain the area
addressable by all peripherals and ZONE_DMA32 the rest of the 32 bit
addressable memory. ZONE_DMA32 might be left empty.
- Reserve the CMA area in a place suitable for all peripherals.
- Inform dma-direct of the new runtime calculated min_mask.
This series has been tested on multiple devices both by checking the
zones setup matches the expectations and by double-checking physical
addresses on pages allocated on the three relevant areas GFP_DMA,
GFP_DMA32, GFP_KERNEL:
- On an RPi4 with variations on the ram memory size. But also forcing
the situation where all three memory zones are nonempty by setting a 3G
ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
- On a Synquacer box[1] with 32G of memory.
- On an ACPI based Huawei TaiShan server[2] with 256G of memory.
- On a QEMU virtual machine running arm64's OpenSUSE Tumbleweed.
That's all.
Regards,
Nicolas
[1] https://www.96boards.org/product/developerbox/
[2] https://e.huawei.com/en/products/cloud-computing-dc/servers/taishan-server/taishan-2280-v2
---
Changes in v2:
- More in depth testing.
- Create new global 'dma_zone_size'.
- New approach to getting the dma_zone_size, instead of parsing the dts
we hardcode it conditionally to the machine compatible name.
- Fix ZONE_DMA and ZONE_DMA32 split, now ZONE_DMA32 remains empty if
ZONE_DMA fits the whole 32 bit addressable space.
- Take into account devices with DMA offset.
- Rename new dma-direct variable to zone_dma_bits.
- Try new approach by merging both ZONE_DMA and ZONE_DMA32 comments
in mmzone.h, add new up to date examples.
Nicolas Saenz Julienne (11):
asm-generic: add dma_zone_size
arm: use generic dma_zone_size
of/fdt: add of_fdt_machine_is_compatible function
of/fdt: add early_init_dt_get_dma_zone_size()
arm64: mm: use arm64_dma_phys_limit instead of calling
max_zone_dma_phys()
arm64: rename variables used to calculate ZONE_DMA32's size
arm64: re-introduce max_zone_dma_phys()
arm64: use both ZONE_DMA and ZONE_DMA32
dma-direct: turn ARCH_ZONE_DMA_BITS into a variable
arm64: edit zone_dma_bits to fine tune dma-direct min mask
mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type'
arch/arm/include/asm/dma.h | 8 ++--
arch/arm/mm/init.c | 12 ++----
arch/arm64/Kconfig | 4 ++
arch/arm64/mm/init.c | 73 +++++++++++++++++++++++++--------
arch/powerpc/include/asm/page.h | 9 ----
arch/powerpc/mm/mem.c | 16 +++++---
arch/s390/include/asm/page.h | 2 -
arch/s390/mm/init.c | 1 +
drivers/of/fdt.c | 15 +++++++
include/asm-generic/dma.h | 8 +++-
include/linux/dma-direct.h | 2 +
include/linux/mmzone.h | 46 ++++++++++++---------
kernel/dma/direct.c | 13 +++---
mm/page_alloc.c | 3 ++
14 files changed, 140 insertions(+), 72 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 v2 01/11] asm-generic: add dma_zone_size
From: Nicolas Saenz Julienne @ 2019-08-20 14:58 UTC (permalink / raw)
To: catalin.marinas, hch, wahrenst, marc.zyngier, robh+dt,
Robin Murphy, linux-arm-kernel, devicetree, linux-arch, iommu,
linux-mm, linux-riscv, Arnd Bergmann
Cc: phill, f.fainelli, frowand.list, linux-kernel, eric, mbrugger,
linux-rpi-kernel, akpm, will, nsaenzjulienne, m.szyprowski
In-Reply-To: <20190820145821.27214-1-nsaenzjulienne@suse.de>
Some architectures have platform specific DMA addressing limitations.
This will allow for hardware description code to provide the constraints
in a generic manner, so as for arch code to properly setup it's memory
zones and DMA mask.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes in v2: None
include/asm-generic/dma.h | 8 +++++++-
mm/page_alloc.c | 3 +++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/dma.h b/include/asm-generic/dma.h
index 43d0c8af8058..c2f39cdb64f6 100644
--- a/include/asm-generic/dma.h
+++ b/include/asm-generic/dma.h
@@ -8,7 +8,13 @@
*
* Some code relies on seeing MAX_DMA_ADDRESS though.
*/
-#define MAX_DMA_ADDRESS PAGE_OFFSET
+#define MAX_DMA_ADDRESS (PAGE_OFFSET + dma_zone_size)
+
+/*
+ * Some architectures may have platform specific DMA addressing constraints.
+ * Firmware can use this to fine tune the device's DMA memory zone.
+ */
+extern u64 dma_zone_size __ro_after_init;
extern int request_dma(unsigned int dmanr, const char *device_id);
extern void free_dma(unsigned int dmanr);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 272c6de1bf4e..b514afee5451 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -133,6 +133,9 @@ EXPORT_SYMBOL(_totalram_pages);
unsigned long totalreserve_pages __read_mostly;
unsigned long totalcma_pages __read_mostly;
+u64 dma_zone_size __ro_after_init;
+EXPORT_SYMBOL(dma_zone_size);
+
int percpu_pagelist_fraction;
gfp_t gfp_allowed_mask __read_mostly = GFP_BOOT_MASK;
#ifdef CONFIG_INIT_ON_ALLOC_DEFAULT_ON
--
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
* Re: [RFC 04/11] soc: amlogic: Add support for SM1 power controller
From: Neil Armstrong @ 2019-08-20 14:55 UTC (permalink / raw)
To: Kevin Hilman, jbrunet; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <7hftlwvhdk.fsf@baylibre.com>
On 20/08/2019 01:56, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> Add support for the General Purpose Amlogic SM1 Power controller,
>> dedicated to the PCIe, USB, NNA and GE2D Power Domains.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> I like this driver in general, but as I look at all the EE power domains
> for GX, G12 and SM1 they are really very similar. I had started to
> generalize the gx-pwrc-vpu driver and it ends up looking just like this.
Yes I developed it to be generic, but when starting to fill up the GXBB/GXL/G12A
domains, except the VPU, they only need the PD parts.
>
> I think this driver could be generalized just a little bit more and then
> replace the the GX-specific VPU one, and AFAICT, then be used across all
> the 64-bit SoCs, and be called "meson-pwrc-ee" or something like that...
>
>> ---
>> drivers/soc/amlogic/Kconfig | 11 ++
>> drivers/soc/amlogic/Makefile | 1 +
>> drivers/soc/amlogic/meson-sm1-pwrc.c | 245 +++++++++++++++++++++++++++
>> 3 files changed, 257 insertions(+)
>> create mode 100644 drivers/soc/amlogic/meson-sm1-pwrc.c
>>
>> diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
>> index 5501ad5650b2..596f1afef1a7 100644
>> --- a/drivers/soc/amlogic/Kconfig
>> +++ b/drivers/soc/amlogic/Kconfig
>> @@ -36,6 +36,17 @@ config MESON_GX_PM_DOMAINS
>> Say yes to expose Amlogic Meson GX Power Domains as
>> Generic Power Domains.
>>
>> +config MESON_SM1_PM_DOMAINS
>> + bool "Amlogic Meson SM1 Power Domains driver"
>> + depends on ARCH_MESON || COMPILE_TEST
>> + depends on PM && OF
>> + default ARCH_MESON
>> + select PM_GENERIC_DOMAINS
>> + select PM_GENERIC_DOMAINS_OF
>> + help
>> + Say yes to expose Amlogic Meson SM1 Power Domains as
>> + Generic Power Domains.
>> +
>> config MESON_MX_SOCINFO
>> bool "Amlogic Meson MX SoC Information driver"
>> depends on ARCH_MESON || COMPILE_TEST
>> diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
>> index bf2d109f61e9..f99935499ee6 100644
>> --- a/drivers/soc/amlogic/Makefile
>> +++ b/drivers/soc/amlogic/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_MESON_CLK_MEASURE) += meson-clk-measure.o
>> obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
>> obj-$(CONFIG_MESON_GX_PM_DOMAINS) += meson-gx-pwrc-vpu.o
>> obj-$(CONFIG_MESON_MX_SOCINFO) += meson-mx-socinfo.o
>> +obj-$(CONFIG_MESON_SM1_PM_DOMAINS) += meson-sm1-pwrc.o
>> diff --git a/drivers/soc/amlogic/meson-sm1-pwrc.c b/drivers/soc/amlogic/meson-sm1-pwrc.c
>> new file mode 100644
>> index 000000000000..9ece1d06f417
>> --- /dev/null
>> +++ b/drivers/soc/amlogic/meson-sm1-pwrc.c
>> @@ -0,0 +1,245 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (c) 2017 BayLibre, SAS
>> + * Author: Neil Armstrong <narmstrong@baylibre.com>
>> + */
>> +
>> +#include <linux/of_address.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_domain.h>
>> +#include <linux/bitfield.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/of_device.h>
>> +#include <dt-bindings/power/meson-sm1-power.h>
>> +
>> +/* AO Offsets */
>> +
>> +#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
>> +#define AO_RTI_GEN_PWR_ISO0 (0x3b << 2)
>> +
>> +/* HHI Offsets */
>> +
>> +#define HHI_MEM_PD_REG0 (0x40 << 2)
>> +#define HHI_NANOQ_MEM_PD_REG0 (0x46 << 2)
>> +#define HHI_NANOQ_MEM_PD_REG1 (0x47 << 2)
>> +
>> +struct meson_sm1_pwrc;
>> +
>> +struct meson_sm1_pwrc_mem_domain {
>> + unsigned int reg;
>> + unsigned int mask;
>> +};
>> +
>> +struct meson_sm1_pwrc_domain_desc {
>> + char *name;
>> + unsigned int sleep_reg;
>> + unsigned int sleep_bit;
>> + unsigned int iso_reg;
>> + unsigned int iso_bit;
>> + unsigned int mem_pd_count;
>> + struct meson_sm1_pwrc_mem_domain *mem_pd;
>> +};
>
> If you add resets and clocks (using clk bulk like my other proposed
> patch to gx-pwrc-vpu) then this could be used for VPU also. We could
> ignore my clk bulk patch and then just deprecate the old driver and use
> this one for everything.
>
> We would just need SoC-specific tables selected by compatible-string to
> select the memory pds, and the clocks and resets could (optionaly) come
> from the DT.
Could you elaborate ?
Do you mean I should slit out the memory PDs as different compatible ?
Let me try to fit the VPU stuff in it.
Neil
>
> Kevin
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 6/6] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has two regulators that power the Realtek RTL8211E
PHY. According to the datasheet, both regulators need to be enabled
at the same time, or that "phy-io" should be enabled slightly earlier
than "phy" regulator.
RTL8211E/RTL8211EG datasheet says:
Note 4: 2.5V (or 1.8/1.5V) RGMII power should be risen simultaneously
or slightly earlier than 3.3V power. Rising 2.5V (or 1.8/1.5V) power
later than 3.3V power may lead to errors.
The driver ensures the regulator enable ordering. The timing is set
in DT via startup-delay-us.
We also need to wait at least 30ms after power-up/reset, before
accessing the PHY registers.
All values of RX/TX delay were tested exhaustively and a middle one
of the range of working values was chosen.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index eda9d5f640b9..18349e60b8c6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -15,6 +15,7 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &emac;
};
chosen {
@@ -56,6 +57,15 @@
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
+
+ reg_gmac_2v5: gmac-2v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "gmac-2v5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ enable-active-high;
+ gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+ };
};
&cpu0 {
@@ -74,6 +84,35 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ext_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ /*
+ * The board uses 2.5V RGMII signalling. Power sequence to enable
+ * the phy is to enable GMAC-2V5 and GMAC-3V (aldo2) power rails
+ * at the same time and to wait 100ms. The driver enables phy-io
+ * first. Delay is achieved with enable-ramp-delay on reg_aldo2.
+ */
+ phy-supply = <®_aldo2>;
+ phy-io-supply = <®_gmac_2v5>;
+ allwinner,rx-delay-ps = <1500>;
+ allwinner,tx-delay-ps = <700>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+ reset-assert-us = <15000>;
+ reset-deassert-us = <40000>;
+ };
+};
+
&hdmi {
status = "okay";
};
@@ -136,6 +175,7 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-name = "vcc33-audio-tv-ephy-mac";
+ regulator-enable-ramp-delay = <100000>;
};
/* ALDO3 is shorted to CLDO1 */
--
2.22.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 5/6] net: stmmac: sun8i: Add support for enabling a regulator for PHY I/O pins
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
to the phy datasheet, both regulators need to be enabled at the same time.
Add support for the second optional regulator, "phy-io", to the glue
driver.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 31 ++++++++++++++++---
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index e7df30d3cab1..e96337b7cd12 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -61,6 +61,8 @@ struct emac_variant {
* @ephy_clk: reference to the optional EPHY clock for
* the internal PHY
* @regulator_phy: reference to the optional regulator
+ * @regulator_phy_io: reference to the optional regulator for
+ * PHY I/O pins
* @rst_ephy: reference to the optional EPHY reset for
* the internal PHY
* @variant: reference to the current board variant
@@ -72,6 +74,7 @@ struct sunxi_priv_data {
struct clk *tx_clk;
struct clk *ephy_clk;
struct regulator *regulator_phy;
+ struct regulator *regulator_phy_io;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
struct regmap_field *regmap_field;
@@ -530,21 +533,30 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
+ ret = regulator_enable(gmac->regulator_phy_io);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable PHY I/O regulator\n");
+ return ret;
+ }
+
ret = regulator_enable(gmac->regulator_phy);
if (ret) {
dev_err(&pdev->dev, "Fail to enable PHY regulator\n");
- return ret;
+ goto err_disable_regulator_phy_io;
}
ret = clk_prepare_enable(gmac->tx_clk);
if (ret) {
- if (gmac->regulator)
- regulator_disable(gmac->regulator);
dev_err(&pdev->dev, "Could not enable AHB clock\n");
- return ret;
+ goto err_disable_regulator_phy;
}
return 0;
+err_disable_regulator_phy:
+ regulator_disable(gmac->regulator_phy);
+err_disable_regulator_phy_io:
+ regulator_disable(gmac->regulator_phy_io);
+ return ret;
}
static void sun8i_dwmac_core_init(struct mac_device_info *hw,
@@ -993,6 +1005,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
regulator_disable(gmac->regulator_phy);
+ regulator_disable(gmac->regulator_phy_io);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1136,6 +1149,16 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
return ret;
}
+ /* Optional regulator for PHY I/O pins */
+ gmac->regulator_phy_io = devm_regulator_get(dev, "phy-io");
+ if (IS_ERR(gmac->regulator_phy_io)) {
+ ret = PTR_ERR(gmac->regulator_phy_io);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get PHY I/O regulator (%d)\n",
+ ret);
+ return ret;
+ }
+
/* The "GMAC clock control" register might be located in the
* CCU address range (on the R40), or the system control address
* range (on most other sun8i and later SoCs).
--
2.22.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 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Use devm_regulator_get instead of devm_regulator_get_optional and rely
on dummy supply. This avoids NULL checks before regulator_enable/disable
calls.
This path also improves error reporting, because we now report both
use of dummy supply and error during registration with more detail,
instead of generic info level message "No regulator found" that
was reported previously on errors and lack of regulator property in DT.
Finally, we'll be adding further optional regulators, and the overall
code will be simpler.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 23 ++++++++-----------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4083019c547a..3e951a11aec3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -528,12 +528,10 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
- if (gmac->regulator) {
- ret = regulator_enable(gmac->regulator);
- if (ret) {
- dev_err(&pdev->dev, "Fail to enable regulator\n");
- return ret;
- }
+ ret = regulator_enable(gmac->regulator);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable regulator\n");
+ return ret;
}
ret = clk_prepare_enable(gmac->tx_clk);
@@ -992,8 +990,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
- if (gmac->regulator)
- regulator_disable(gmac->regulator);
+ regulator_disable(gmac->regulator);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1129,12 +1126,12 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
/* Optional regulator for PHY */
- gmac->regulator = devm_regulator_get_optional(dev, "phy");
+ gmac->regulator = devm_regulator_get(dev, "phy");
if (IS_ERR(gmac->regulator)) {
- if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- dev_info(dev, "No regulator found\n");
- gmac->regulator = NULL;
+ ret = PTR_ERR(gmac->regulator);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get PHY regulator (%d)\n", ret);
+ return ret;
}
/* The "GMAC clock control" register might be located in the
--
2.22.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 4/6] net: stmmac: sun8i: Rename PHY regulator variable to regulator_phy
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
We'll be adding further optional regulators, and this makes it clearer
what the regulator is for.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 ++++++++++---------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 3e951a11aec3..e7df30d3cab1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -57,19 +57,21 @@ struct emac_variant {
};
/* struct sunxi_priv_data - hold all sunxi private data
- * @tx_clk: reference to MAC TX clock
- * @ephy_clk: reference to the optional EPHY clock for the internal PHY
- * @regulator: reference to the optional regulator
- * @rst_ephy: reference to the optional EPHY reset for the internal PHY
- * @variant: reference to the current board variant
- * @regmap: regmap for using the syscon
- * @internal_phy_powered: Does the internal PHY is enabled
- * @mux_handle: Internal pointer used by mdio-mux lib
+ * @tx_clk: reference to MAC TX clock
+ * @ephy_clk: reference to the optional EPHY clock for
+ * the internal PHY
+ * @regulator_phy: reference to the optional regulator
+ * @rst_ephy: reference to the optional EPHY reset for
+ * the internal PHY
+ * @variant: reference to the current board variant
+ * @regmap: regmap for using the syscon
+ * @internal_phy_powered: Does the internal PHY is enabled
+ * @mux_handle: Internal pointer used by mdio-mux lib
*/
struct sunxi_priv_data {
struct clk *tx_clk;
struct clk *ephy_clk;
- struct regulator *regulator;
+ struct regulator *regulator_phy;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
struct regmap_field *regmap_field;
@@ -528,9 +530,9 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
- ret = regulator_enable(gmac->regulator);
+ ret = regulator_enable(gmac->regulator_phy);
if (ret) {
- dev_err(&pdev->dev, "Fail to enable regulator\n");
+ dev_err(&pdev->dev, "Fail to enable PHY regulator\n");
return ret;
}
@@ -990,7 +992,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
- regulator_disable(gmac->regulator);
+ regulator_disable(gmac->regulator_phy);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1126,9 +1128,9 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
/* Optional regulator for PHY */
- gmac->regulator = devm_regulator_get(dev, "phy");
- if (IS_ERR(gmac->regulator)) {
- ret = PTR_ERR(gmac->regulator);
+ gmac->regulator_phy = devm_regulator_get(dev, "phy");
+ if (IS_ERR(gmac->regulator_phy)) {
+ ret = PTR_ERR(gmac->regulator_phy);
if (ret != -EPROBE_DEFER)
dev_err(dev, "Failed to get PHY regulator (%d)\n", ret);
return ret;
--
2.22.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 1/6] dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
This is already supported by the driver, but is missing from the
bindings.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 3fb0714e761e..304f244e9ab5 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -43,6 +43,10 @@ properties:
Phandle to the device containing the EMAC or GMAC clock
register
+ phy-supply:
+ description:
+ PHY regulator
+
required:
- compatible
- reg
--
2.22.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 2/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Some PHYs require separate power supply for I/O pins in some modes
of operation. Add phy-io-supply property, to allow enabling this
power supply.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 304f244e9ab5..782e202aa124 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -47,6 +47,10 @@ properties:
description:
PHY regulator
+ phy-io-supply:
+ description:
+ PHY I/O pins regulator
+
required:
- compatible
- reg
--
2.22.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 0/6] Add ethernet support for Orange Pi 3
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
This series implements ethernet support for Xunlong Orange Pi 3 board, by:
- making small cleanups of existing dwmac-sun8i code
- adding DT bindings docummentation
- adding support for phy-io-supply to dwmac-sun8i code
- adding DT configuration for Orange Pi 3 board
For some people, ethernet doesn't work after reboot because u-boot doesn't
support AXP805 PMIC, and will not turn off the etherent PHY regulators.
So the regulator controlled by gpio will be shut down, but the other one
controlled by the AXP PMIC will not.
This is a problem only when running with a builtin driver. This needs
to be fixed in u-boot and should not prevent these patches from being
merged.
This evolved out of the Orange Pi 3 patches series, as I didn't want
to stretch that out any longer.
Please take a look.
thank you and regards,
Ondrej Jirman
Ondrej Jirman (6):
dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
net: stmmac: sun8i: Rename PHY regulator variable to regulator_phy
net: stmmac: sun8i: Add support for enabling a regulator for PHY I/O
pins
arm64: dts: allwinner: orange-pi-3: Enable ethernet
.../net/allwinner,sun8i-a83t-emac.yaml | 8 ++
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 40 ++++++++++
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 74 ++++++++++++-------
3 files changed, 96 insertions(+), 26 deletions(-)
--
2.22.1
_______________________________________________
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 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Robin Murphy @ 2019-08-20 14:51 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190820103048.xacfbtn5o4wermhi@willie-the-truck>
On 20/08/2019 11:30, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
>> Now that callers are free to use a given table for TTBR1 if they wish
>> (all they need do is shift the provided attributes when constructing
>> their final TCR value), the only remaining impediment is the address
>> validation on map/unmap. The fact that the LPAE address space split is
>> symmetric makes this easy to accommodate - by simplifying the current
>> range checks into explicit tests that address bits above IAS are all
>> zero, it then follows straightforwardly to add the inverse test to
>> allow the all-ones case as well.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/io-pgtable-arm.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index 09cb20671fbb..f39c50356351 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>> arm_lpae_iopte *ptep = data->pgd;
>> int ret, lvl = ARM_LPAE_START_LVL(data);
>> arm_lpae_iopte prot;
>> + long iaext = (long)iova >> data->iop.cfg.ias;
>>
>> /* If no access, then nothing to do */
>> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
>> return 0;
>>
>> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
>> - paddr >= (1ULL << data->iop.cfg.oas)))
>> + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
>
> I had to read that '&&' twice, but I see what you're doing now :)
>
>> return -ERANGE;
>
> This doesn't seem sufficient to prevent a mixture of TTBR1 and TTBR0
> addresses from being mapped in the same TTBR. Perhaps we need a quirk for
> TTBR1, which could then take care of setting EPDx appropriately?
Right, that's the one downside of going for the minimalist "io-pgtable
doesn't even have to know" approach. On reflection, though, in that
paradigm it should probably be the caller's responsibility to convert
TTBR1 addresses to preserve the "as if TTBR0" illusion anyway :/
The advantage of not having a quirk is that it allows split address
spaces to fit more closely with the aux_domain idea, i.e. we could
allocate and initialise a domain without having to assume, or even care,
whether it will end up attached as a primary or aux domain. It *might*
even be potentially useful to have a domain attached to TTBR0 of one
device's context and TTBR1 of another's at the same time, although
that's pretty niche.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 6/6] arm64: dts: add support for SM1 based SEI Robotics SEI610
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add support for the Amlogic SM1 Based SEI610 board.
The SM1 SoC is a derivative of the G12A SoC Family with :
- Cortex-A55 core instead of A53
- more power domains, including USB & PCIe
- a neural network co-processor (NNA)
- a CSI input and image processor
- some changes in the audio complex, thus not yet enabled
The SEI610 board is a derivative of the SEI510 board with :
- removed ADC based touch button, replaced with 3x GPIO buttons
- physical switch disabling on-board MICs
- USB-C port for USB 2.0 OTG
- On-board FTDI USB2SERIAL port for Linux console
Audio, Display and USB support will be added later when support of the
corresponding power domains will be added, for now they are kept disabled.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-sm1-sei610.dts | 300 ++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 68 ++++
3 files changed, 369 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index ae5e8d0c08da..edbf128e7707 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -34,3 +34,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
new file mode 100644
index 000000000000..12dab0ba2f26
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre SAS. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-sm1.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/meson-g12a-gpio.h>
+
+/ {
+ compatible = "seirobotics,sei610", "amlogic,sm1";
+ model = "SEI Robotics SEI610";
+
+ aliases {
+ serial0 = &uart_AO;
+ ethernet0 = ðmac;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ key1 {
+ label = "A";
+ linux,code = <BTN_0>;
+ gpios = <&gpio GPIOH_6 GPIO_ACTIVE_LOW>;
+ };
+
+ key2 {
+ label = "B";
+ linux,code = <BTN_1>;
+ gpios = <&gpio GPIOH_7 GPIO_ACTIVE_LOW>;
+ };
+
+ key3 {
+ label = "C";
+ linux,code = <BTN_2>;
+ gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ bluetooth {
+ label = "sei610:blue:bt";
+ gpios = <&gpio GPIOC_7 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+ default-state = "off";
+ };
+ };
+
+ pwmleds {
+ compatible = "pwm-leds";
+
+ power {
+ label = "sei610:red:power";
+ pwms = <&pwm_AO_ab 0 30518 0>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
+ active-low;
+ };
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ ao_5v: regulator-ao_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "AO_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ dc_in: regulator-dc_in {
+ compatible = "regulator-fixed";
+ regulator-name = "DC_IN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ emmc_1v8: regulator-emmc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "EMMC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ vddao_3v3: regulator-vddao_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ /* Used by Tuner, RGB Led & IR Emitter LED array */
+ vddao_3v3_t: regultor-vddao_3v3_t {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3_T";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vddao_3v3>;
+ gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
+ enable-active-low;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio_ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ reserved-memory {
+ /* TEE Reserved Memory */
+ bl32_reserved: bl32@5000000 {
+ reg = <0x0 0x05300000 0x0 0x2000000>;
+ no-map;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+};
+
+&cec_AO {
+ pinctrl-0 = <&cec_ao_a_h_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&cecb_AO {
+ pinctrl-0 = <&cec_ao_b_h_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&i2c3 {
+ status = "okay";
+ pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sck_a_pins>;
+ pinctrl-names = "default";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_AO_ab {
+ status = "okay";
+ pinctrl-0 = <&pwm_ao_a_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vddio_ao1v8>;
+};
+
+/* SDIO */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_c_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_c_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&emmc_1v8>;
+};
+
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ vbat-supply = <&vddao_3v3>;
+ vddio-supply = <&vddio_ao1v8>;
+ };
+};
+
+/* Exposed via the on-board USB to Serial FT232RL IC */
+&uart_AO {
+ status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
new file mode 100644
index 000000000000..e902d4f9165f
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+#include "meson-g12-common.dtsi"
+
+/ {
+ compatible = "amlogic,sm1";
+
+ cpus {
+ #address-cells = <0x2>;
+ #size-cells = <0x0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+};
+
+&cecb_AO {
+ compatible = "amlogic,meson-sm1-ao-cec";
+};
+
+&clk_msr {
+ compatible = "amlogic,meson-sm1-clk-measure";
+};
+
+&pwrc_vpu {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
--
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 3/6] soc: amlogic: clk-measure: Add support for SM1
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the clk-measurer clocks IDs for the Amlogic SM1 SoC family.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/soc/amlogic/meson-clk-measure.c | 134 ++++++++++++++++++++++++
1 file changed, 134 insertions(+)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index f09b404b39d3..0fa47d77577d 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -357,6 +357,136 @@ static struct meson_msr_id clk_msr_g12a[CLK_MSR_MAX] = {
CLK_MSR_ID(122, "audio_pdm_dclk"),
};
+static struct meson_msr_id clk_msr_sm1[CLK_MSR_MAX] = {
+ CLK_MSR_ID(0, "ring_osc_out_ee_0"),
+ CLK_MSR_ID(1, "ring_osc_out_ee_1"),
+ CLK_MSR_ID(2, "ring_osc_out_ee_2"),
+ CLK_MSR_ID(3, "ring_osc_out_ee_3"),
+ CLK_MSR_ID(4, "gp0_pll"),
+ CLK_MSR_ID(5, "gp1_pll"),
+ CLK_MSR_ID(6, "enci"),
+ CLK_MSR_ID(7, "clk81"),
+ CLK_MSR_ID(8, "encp"),
+ CLK_MSR_ID(9, "encl"),
+ CLK_MSR_ID(10, "vdac"),
+ CLK_MSR_ID(11, "eth_tx"),
+ CLK_MSR_ID(12, "hifi_pll"),
+ CLK_MSR_ID(13, "mod_tcon"),
+ CLK_MSR_ID(14, "fec_0"),
+ CLK_MSR_ID(15, "fec_1"),
+ CLK_MSR_ID(16, "fec_2"),
+ CLK_MSR_ID(17, "sys_pll_div16"),
+ CLK_MSR_ID(18, "sys_cpu_div16"),
+ CLK_MSR_ID(19, "lcd_an_ph2"),
+ CLK_MSR_ID(20, "rtc_osc_out"),
+ CLK_MSR_ID(21, "lcd_an_ph3"),
+ CLK_MSR_ID(22, "eth_phy_ref"),
+ CLK_MSR_ID(23, "mpll_50m"),
+ CLK_MSR_ID(24, "eth_125m"),
+ CLK_MSR_ID(25, "eth_rmii"),
+ CLK_MSR_ID(26, "sc_int"),
+ CLK_MSR_ID(27, "in_mac"),
+ CLK_MSR_ID(28, "sar_adc"),
+ CLK_MSR_ID(29, "pcie_inp"),
+ CLK_MSR_ID(30, "pcie_inn"),
+ CLK_MSR_ID(31, "mpll_test_out"),
+ CLK_MSR_ID(32, "vdec"),
+ CLK_MSR_ID(34, "eth_mpll_50m"),
+ CLK_MSR_ID(35, "mali"),
+ CLK_MSR_ID(36, "hdmi_tx_pixel"),
+ CLK_MSR_ID(37, "cdac"),
+ CLK_MSR_ID(38, "vdin_meas"),
+ CLK_MSR_ID(39, "bt656"),
+ CLK_MSR_ID(40, "arm_ring_osc_out_4"),
+ CLK_MSR_ID(41, "eth_rx_or_rmii"),
+ CLK_MSR_ID(42, "mp0_out"),
+ CLK_MSR_ID(43, "fclk_div5"),
+ CLK_MSR_ID(44, "pwm_b"),
+ CLK_MSR_ID(45, "pwm_a"),
+ CLK_MSR_ID(46, "vpu"),
+ CLK_MSR_ID(47, "ddr_dpll_pt"),
+ CLK_MSR_ID(48, "mp1_out"),
+ CLK_MSR_ID(49, "mp2_out"),
+ CLK_MSR_ID(50, "mp3_out"),
+ CLK_MSR_ID(51, "sd_emmc_c"),
+ CLK_MSR_ID(52, "sd_emmc_b"),
+ CLK_MSR_ID(53, "sd_emmc_a"),
+ CLK_MSR_ID(54, "vpu_clkc"),
+ CLK_MSR_ID(55, "vid_pll_div_out"),
+ CLK_MSR_ID(56, "wave420l_a"),
+ CLK_MSR_ID(57, "wave420l_c"),
+ CLK_MSR_ID(58, "wave420l_b"),
+ CLK_MSR_ID(59, "hcodec"),
+ CLK_MSR_ID(60, "arm_ring_osc_out_5"),
+ CLK_MSR_ID(61, "gpio_msr"),
+ CLK_MSR_ID(62, "hevcb"),
+ CLK_MSR_ID(63, "dsi_meas"),
+ CLK_MSR_ID(64, "spicc_1"),
+ CLK_MSR_ID(65, "spicc_0"),
+ CLK_MSR_ID(66, "vid_lock"),
+ CLK_MSR_ID(67, "dsi_phy"),
+ CLK_MSR_ID(68, "hdcp22_esm"),
+ CLK_MSR_ID(69, "hdcp22_skp"),
+ CLK_MSR_ID(70, "pwm_f"),
+ CLK_MSR_ID(71, "pwm_e"),
+ CLK_MSR_ID(72, "pwm_d"),
+ CLK_MSR_ID(73, "pwm_c"),
+ CLK_MSR_ID(74, "arm_ring_osc_out_6"),
+ CLK_MSR_ID(75, "hevcf"),
+ CLK_MSR_ID(76, "arm_ring_osc_out_7"),
+ CLK_MSR_ID(77, "rng_ring_osc_0"),
+ CLK_MSR_ID(78, "rng_ring_osc_1"),
+ CLK_MSR_ID(79, "rng_ring_osc_2"),
+ CLK_MSR_ID(80, "rng_ring_osc_3"),
+ CLK_MSR_ID(81, "vapb"),
+ CLK_MSR_ID(82, "ge2d"),
+ CLK_MSR_ID(83, "co_rx"),
+ CLK_MSR_ID(84, "co_tx"),
+ CLK_MSR_ID(85, "arm_ring_osc_out_8"),
+ CLK_MSR_ID(86, "arm_ring_osc_out_9"),
+ CLK_MSR_ID(87, "mipi_dsi_phy"),
+ CLK_MSR_ID(88, "cis2_adapt"),
+ CLK_MSR_ID(89, "hdmi_todig"),
+ CLK_MSR_ID(90, "hdmitx_sys"),
+ CLK_MSR_ID(91, "nna_core"),
+ CLK_MSR_ID(92, "nna_axi"),
+ CLK_MSR_ID(93, "vad"),
+ CLK_MSR_ID(94, "eth_phy_rx"),
+ CLK_MSR_ID(95, "eth_phy_pll"),
+ CLK_MSR_ID(96, "vpu_b"),
+ CLK_MSR_ID(97, "cpu_b_tmp"),
+ CLK_MSR_ID(98, "ts"),
+ CLK_MSR_ID(99, "arm_ring_osc_out_10"),
+ CLK_MSR_ID(100, "arm_ring_osc_out_11"),
+ CLK_MSR_ID(101, "arm_ring_osc_out_12"),
+ CLK_MSR_ID(102, "arm_ring_osc_out_13"),
+ CLK_MSR_ID(103, "arm_ring_osc_out_14"),
+ CLK_MSR_ID(104, "arm_ring_osc_out_15"),
+ CLK_MSR_ID(105, "arm_ring_osc_out_16"),
+ CLK_MSR_ID(106, "ephy_test"),
+ CLK_MSR_ID(107, "au_dac_g128x"),
+ CLK_MSR_ID(108, "audio_locker_out"),
+ CLK_MSR_ID(109, "audio_locker_in"),
+ CLK_MSR_ID(110, "audio_tdmout_c_sclk"),
+ CLK_MSR_ID(111, "audio_tdmout_b_sclk"),
+ CLK_MSR_ID(112, "audio_tdmout_a_sclk"),
+ CLK_MSR_ID(113, "audio_tdmin_lb_sclk"),
+ CLK_MSR_ID(114, "audio_tdmin_c_sclk"),
+ CLK_MSR_ID(115, "audio_tdmin_b_sclk"),
+ CLK_MSR_ID(116, "audio_tdmin_a_sclk"),
+ CLK_MSR_ID(117, "audio_resample"),
+ CLK_MSR_ID(118, "audio_pdm_sys"),
+ CLK_MSR_ID(119, "audio_spdifout_b"),
+ CLK_MSR_ID(120, "audio_spdifout"),
+ CLK_MSR_ID(121, "audio_spdifin"),
+ CLK_MSR_ID(122, "audio_pdm_dclk"),
+ CLK_MSR_ID(123, "audio_resampled"),
+ CLK_MSR_ID(124, "earcrx_pll"),
+ CLK_MSR_ID(125, "earcrx_pll_test"),
+ CLK_MSR_ID(126, "csi_phy0"),
+ CLK_MSR_ID(127, "csi2_data"),
+};
+
static int meson_measure_id(struct meson_msr_id *clk_msr_id,
unsigned int duration)
{
@@ -545,6 +675,10 @@ static const struct of_device_id meson_msr_match_table[] = {
.compatible = "amlogic,meson-g12a-clk-measure",
.data = (void *)clk_msr_g12a,
},
+ {
+ .compatible = "amlogic,meson-sm1-clk-measure",
+ .data = (void *)clk_msr_sm1,
+ },
{ /* sentinel */ }
};
--
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 5/6] dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the compatible for the Amlogic SM1 Based SEI610 board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index d701e8447363..b48ea1e4913a 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -152,5 +152,7 @@ properties:
- description: Boards with the Amlogic Meson SM1 S905X3 SoC
items:
+ - enum:
+ - seirobotics,sei610
- const: amlogic,sm1
...
--
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 0/6] arm64: Add support for Amlogic SM1 SoC Family
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
The new Amlogic SM1 SoC Family is a derivative of the Amlogic G12A
SoC Family, with the following changes :
- Cortex-A55 cores instead of A53
- more power domains, including USB & PCIe
- a neural network co-processor (NNA)
- a CSI input and image processor
- some changes in the audio complex, thus not yet enabled
- new clocks, for NNA, CSI and a clock tree for each CPU Core
This serie does not add support for NNA, CSI, Audio, USB, Display
or DVFS, it only aligns with the current G12A Support.
With this serie, the SEI610 Board has supported :
- Default-boot CPU frequency
- Ethernet
- LEDs
- IR
- GPIO Buttons
- eMMC
- SDCard
- SDIO WiFi
- UART Bluetooth
Audio (HDMI, Embedded HP, MIcs), USB, HDMI, IR Output, & RGB Led
would be supported in following patchsets.
Dependencies:
- g12-common.dtsi from the DVFS patchset at [1]
Changes from rfc at [2]:
- Removed Power domain patches & display/USB support, will resend separately
- Removed applied AO-CEC patches
- Fixed clk-measure IDs
- Collected reviewed-by tags
[1] https://patchwork.kernel.org/cover/11025309/
[2] https://patchwork.kernel.org/cover/11025511/
Neil Armstrong (6):
soc: amlogic: meson-gx-socinfo: Add SM1 and S905X3 IDs
dt-bindings: soc: amlogic: clk-measure: Add SM1 compatible
soc: amlogic: clk-measure: Add support for SM1
dt-bindings: arm: amlogic: add SM1 bindings
dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
arm64: dts: add support for SM1 based SEI Robotics SEI610
.../devicetree/bindings/arm/amlogic.yaml | 5 +
.../bindings/soc/amlogic/clk-measure.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-sm1-sei610.dts | 300 ++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 68 ++++
drivers/soc/amlogic/meson-clk-measure.c | 134 ++++++++
drivers/soc/amlogic/meson-gx-socinfo.c | 2 +
7 files changed, 511 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
--
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 1/6] soc: amlogic: meson-gx-socinfo: Add SM1 and S905X3 IDs
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: Neil Armstrong, Martin Blumenstingl, linux-kernel, linux-amlogic,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the SoC IDs for the S905X3 Amlogic SM1 SoC.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/soc/amlogic/meson-gx-socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
index ff86a75939e8..b9f4c6f4fd03 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -39,6 +39,7 @@ static const struct meson_gx_soc_id {
{ "TXHD", 0x27 },
{ "G12A", 0x28 },
{ "G12B", 0x29 },
+ { "SM1", 0x2b },
};
static const struct meson_gx_package_id {
@@ -66,6 +67,7 @@ static const struct meson_gx_package_id {
{ "S905X2", 0x28, 0x40, 0xf0 },
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
+ { "S905X3", 0x2b, 0x5, 0xf },
};
static inline unsigned int socinfo_to_major(u32 socinfo)
--
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 4/6] dt-bindings: arm: amlogic: add SM1 bindings
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add bindings for the new Amlogic SM1 SoC Family.
It a derivative of the G12A SoC Family with :
- Cortex-A55 core instead of A53
- more power domains
- a neural network co-processor
- a CSI input and image processor
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 96f66911e3c6..d701e8447363 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -150,4 +150,7 @@ properties:
- const: amlogic,s922x
- const: amlogic,g12b
+ - description: Boards with the Amlogic Meson SM1 S905X3 SoC
+ items:
+ - const: amlogic,sm1
...
--
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 2/6] dt-bindings: soc: amlogic: clk-measure: Add SM1 compatible
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: devicetree, Neil Armstrong, Martin Blumenstingl, linux-kernel,
linux-amlogic, Rob Herring, linux-arm-kernel
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the Amlogic SM1 Compatible for the clk-measurer IP.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
index 6bf6b43f8dd8..3dd563cec794 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
+++ b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
@@ -11,6 +11,7 @@ Required properties:
"amlogic,meson8b-clk-measure" for Meson8b SoCs
"amlogic,meson-axg-clk-measure" for AXG SoCs
"amlogic,meson-g12a-clk-measure" for G12a SoCs
+ "amlogic,meson-sm1-clk-measure" for SM1 SoCs
- reg: base address and size of the Clock Measurer register space.
Example:
--
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
* Re: [PATCH] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
From: Marc Gonzalez @ 2019-08-20 14:39 UTC (permalink / raw)
To: Andrey Smirnov, Linux ARM; +Cc: Fabio Estevam, Shawn Guo, LKML, Chris Healy
In-Reply-To: <20190820030804.8892-1-andrew.smirnov@gmail.com>
On 20/08/2019 05:08, Andrey Smirnov wrote:
> Fiber-optic module attached to the bus is only rated to work at
> 100kHz, so drop the bus frequncy to accomodate that.
s/100kHz/100 kHz
s/frequncy/frequency
s/accomodate/accommodate
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: [PATCH 2/4] iommu/io-pgtable-arm: Rationalise TTBRn handling
From: Robin Murphy @ 2019-08-20 14:17 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190820101911.ndwtaf76kn3zplk2@willie-the-truck>
On 20/08/2019 11:19, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
>> TTBR1 values have so far been redundant since no users implement any
>> support for split address spaces. Crucially, though, one of the main
>> reasons for wanting to do so is to be able to manage each half entirely
>> independently, e.g. context-switching one set of mappings without
>> disturbing the other. Thus it seems unlikely that tying two tables
>> together in a single io_pgtable_cfg would ever be particularly desirable
>> or useful.
>>
>> Streamline the configs to just a single conceptual TTBR value
>> representing the allocated table. This paves the way for future users to
>> support split address spaces by simply allocating a table and dealing
>> with the detailed TTBRn logistics themselves.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 2 +-
>> drivers/iommu/arm-smmu.c | 9 ++++-----
>> drivers/iommu/io-pgtable-arm-v7s.c | 16 +++++++---------
>> drivers/iommu/io-pgtable-arm.c | 7 +++----
>> drivers/iommu/ipmmu-vmsa.c | 2 +-
>> drivers/iommu/msm_iommu.c | 4 ++--
>> drivers/iommu/mtk_iommu.c | 4 ++--
>> drivers/iommu/qcom_iommu.c | 3 +--
>> include/linux/io-pgtable.h | 4 ++--
>> 9 files changed, 23 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 2a8db896d698..2e50cf49c3c4 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -1722,7 +1722,7 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
>> }
>>
>> cfg->cd.asid = (u16)asid;
>> - cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
>> cfg->cd.tcr = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
>> cfg->cd.mair = pgtbl_cfg->arm_lpae_s1_cfg.mair;
>> return 0;
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 184ca41e9de7..19030c4b5904 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -473,13 +473,12 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>> /* TTBRs */
>> if (stage1) {
>> if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH32_S) {
>> - cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr[0];
>> - cb->ttbr[1] = pgtbl_cfg->arm_v7s_cfg.ttbr[1];
>> + cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
>> + cb->ttbr[1] = 0;
>> } else {
>> - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
>> cb->ttbr[0] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
>> - cb->ttbr[1] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> - cb->ttbr[1] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
>> + cb->ttbr[1] = FIELD_PREP(TTBRn_ASID, cfg->asid);
>
> Why do you continue to put the ASID in here?
For the same reason we put it there before ;)
Although I guess if TCR.A1 were ever to get flipped accidentally then
we're still cool.
>> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
>> index 34bb357b3cfa..de55b6d82ef1 100644
>> --- a/drivers/iommu/qcom_iommu.c
>> +++ b/drivers/iommu/qcom_iommu.c
>> @@ -247,10 +247,9 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
>>
>> /* TTBRs */
>> iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
>> - pgtbl_cfg.arm_lpae_s1_cfg.ttbr[0] |
>> + pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
>> FIELD_PREP(TTBRn_ASID, ctx->asid));
>> iommu_writeq(ctx, ARM_SMMU_CB_TTBR1,
>> - pgtbl_cfg.arm_lpae_s1_cfg.ttbr[1] |
>> FIELD_PREP(TTBRn_ASID, ctx->asid));
>
> Same here.
>
>> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
>> index a6c8aa204733..7a0905d7a006 100644
>> --- a/include/linux/io-pgtable.h
>> +++ b/include/linux/io-pgtable.h
>> @@ -90,7 +90,7 @@ struct io_pgtable_cfg {
>> /* Low-level data specific to the table format */
>> union {
>> struct {
>> - u64 ttbr[2];
>> + u64 ttbr;
>> u64 tcr;
>> u64 mair;
>> } arm_lpae_s1_cfg;
>> @@ -101,7 +101,7 @@ struct io_pgtable_cfg {
>> } arm_lpae_s2_cfg;
>>
>> struct {
>> - u32 ttbr[2];
>> + u32 ttbr;
>
> We could probably do with a comment for these 'ttbr' field now saying that
> they refer to ttbr0 (since the tcr will have EPD1 set).
Yeah, I did wonder whether this might want elaboration, or whether the
commit messages plus the code consuming it made the idea sufficiently
clear - I guess that's my answer...
Robin.
_______________________________________________
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 v2] iommu/arm-smmu: Break insecure users by disabling bypass by default
From: Robin Murphy @ 2019-08-20 14:10 UTC (permalink / raw)
To: Marc Gonzalez, Will Deacon, Jean-Philippe Brucker,
Michael S. Tsirkin
Cc: Joerg Roedel, Will Deacon, Douglas Anderson, Jon Hunter,
Thierry Reding, Linux ARM
In-Reply-To: <ada29112-87c1-e223-aa66-b7871e20a49a@free.fr>
On 20/08/2019 14:55, Marc Gonzalez wrote:
> On 19/08/2019 16:48, Will Deacon wrote:
>
>> If we can get by with extending the iommu-map entries for the masters,
>> that would certainly be the neatest imo. Sounds like it's worth a quick
>> hack, if nothing else.
>
> Tangent: I've been meaning to ask about some iommu-map shenanigan.
>
> My kernel reports:
>
> OF: /soc/pci@1c00000: no iommu-map translation for rid 0x0 on (null)
>
> Errr... "Is that a problem, doctor?"
>
> It's a pr_info() message from of_map_rid() in drivers/of/base.c
> I note that it used to be an error before fb709b5e1cca5
It means your host bridge doesn't have a stream ID. Depending on how the
root complex is wired up to the SMMU that may or may not be technically
accurate, but either way if your host bridge ever starts doing DMA for
itself then you should probably be more concerned with tracking down PCI
SIG's exorcism spec.
Robin.
_______________________________________________
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] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
From: Chris Healy @ 2019-08-20 14:08 UTC (permalink / raw)
To: Andrey Smirnov; +Cc: Fabio Estevam, Shawn Guo, linux-kernel, linux ARM
In-Reply-To: <20190820030804.8892-1-andrew.smirnov@gmail.com>
On Mon, Aug 19, 2019 at 8:08 PM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
>
> Fiber-optic module attached to the bus is only rated to work at
> 100kHz, so drop the bus frequncy to accomodate that.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> index ff460a1de85a..28732249cfc0 100644
> --- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> +++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> @@ -207,7 +207,7 @@
> };
>
> &i2c0 {
> - clock-frequency = <400000>;
> + clock-frequency = <100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_i2c0>;
> status = "okay";
> --
> 2.21.0
>
Reviewed-by: Chris Healy <cphealy@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox