* [PATCH 2/3] ARM: configs: stm32: Enable ARM_MPU
From: Vladimir Murzin @ 2017-12-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-3-git-send-email-alexandre.torgue@st.com>
On 12/12/17 18:02, Alexandre Torgue wrote:
> STM32 MCUs embed a Memory Protection Unit. Enabling this setting will
> allow the Kernel to configure the MPU according to devicetree.
Would it be better to "select ARM_MPU" for machines with Cortex-M7?
Vladimir
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index bb358ff..e642bdf9 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -24,6 +24,7 @@ CONFIG_SET_MEM_PARAM=y
> CONFIG_DRAM_BASE=0x90000000
> CONFIG_FLASH_MEM_BASE=0x08000000
> CONFIG_FLASH_SIZE=0x00200000
> +CONFIG_ARM_MPU=y
> CONFIG_PREEMPT=y
> # CONFIG_ATAGS is not set
> CONFIG_ZBOOT_ROM_TEXT=0x0
>
^ permalink raw reply
* [PATCH V4 10/12] boot_constraint: Add support for Hisilicon platforms
From: Viresh Kumar @ 2017-12-13 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213094718.GE13194@kroah.com>
On 13-12-17, 10:47, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:58PM +0530, Viresh Kumar wrote:
> > +static const struct of_device_id machines[] __initconst = {
> > + { .compatible = "hisilicon,hi3660", .data = &hikey3660_constraints },
> > + { .compatible = "hisilicon,hi3798cv200", .data = &hikey3798cv200_constraints },
> > + { .compatible = "hisilicon,hi6220", .data = &hikey6220_constraints },
> > + { }
> > +};
> > +
> > +static int __init hikey_constraints_init(void)
> > +{
> > + const struct hikey_machine_constraints *constraints;
> > + const struct of_device_id *match;
> > + struct device_node *np;
> > +
> > + if (!boot_constraint_earlycon_enabled())
> > + return 0;
> > +
> > + np = of_find_node_by_path("/");
>
> What is this for?
We need to match the above list of "machines" with the root node and "np" here
points to the root node.. and ...
> > + if (!np)
> > + return -ENODEV;
> > +
> > + match = of_match_node(machines, np);
Its used here.
> > + of_node_put(np);
> > +/*
> > + * The amba-pl011 driver registers itself from arch_initcall level. Setup the
> > + * serial boot constraints before that in order not to miss any boot messages.
> > + */
> > +postcore_initcall_sync(hikey_constraints_init);
>
> Now you have to worry about the bootconstraints earlycon being called
> before/after your code.
For boot-constraints to work for any device, it is extremely important to add
the constraint before the device is probed by its driver, otherwise the driver
would end up re-configuring the resources. There is no other way then having
this order dependency here.
> That's another linking order dependancy you
> just created. It feels more complex for something so "simple" as
> looking for the earlycon flag...
--
viresh
^ permalink raw reply
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: Dongjiu Geng @ 2017-12-13 10:13 UTC (permalink / raw)
To: linux-arm-kernel
ARM v8.4 extensions add new neon instructions for performing a
multiplication of each FP16 element of one vector with the corresponding
FP16 element of a second vector, and to add or subtract this without an
intermediate rounding to the corresponding FP32 element in a third vector.
This patch detects this feature and let the userspace know about it via a
HWCAP bit and MRS emulation.
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
---
Change since v2:
1. Change the HWCAP_FHM to HWCAP_ASIMDFHM
Change since v1:
1. Address Dave and Suzuki's comments to update the commit message.
2. Address Dave's comments to update Documentation/arm64/elf_hwcaps.txt.
---
Documentation/arm64/cpu-feature-registers.txt | 4 +++-
Documentation/arm64/elf_hwcaps.txt | 4 ++++
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c | 2 ++
arch/arm64/kernel/cpuinfo.c | 1 +
6 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt
index bd9b3fa..a70090b 100644
--- a/Documentation/arm64/cpu-feature-registers.txt
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -110,7 +110,9 @@ infrastructure:
x--------------------------------------------------x
| Name | bits | visible |
|--------------------------------------------------|
- | RES0 | [63-48] | n |
+ | RES0 | [63-52] | n |
+ |--------------------------------------------------|
+ | FHM | [51-48] | y |
|--------------------------------------------------|
| DP | [47-44] | y |
|--------------------------------------------------|
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index 89edba1..57324ee 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -158,3 +158,7 @@ HWCAP_SHA512
HWCAP_SVE
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_ASIMDFHM
+
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..1818077 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -419,6 +419,7 @@
#define SCTLR_EL1_CP15BEN (1 << 5)
/* id_aa64isar0 */
+#define ID_AA64ISAR0_FHM_SHIFT 48
#define ID_AA64ISAR0_DP_SHIFT 44
#define ID_AA64ISAR0_SM4_SHIFT 40
#define ID_AA64ISAR0_SM3_SHIFT 36
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index cda76fa..f018c3d 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -43,5 +43,6 @@
#define HWCAP_ASIMDDP (1 << 20)
#define HWCAP_SHA512 (1 << 21)
#define HWCAP_SVE (1 << 22)
+#define HWCAP_ASIMDFHM (1 << 23)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..bc7e707 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
* sync with the documentation of the CPU feature register ABI.
*/
static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_FHM_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_DP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM4_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM3_SHIFT, 4, 0),
@@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unus
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM3),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM4),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDDP),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDFHM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 1e25545..7f94623 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -76,6 +76,7 @@
"asimddp",
"sha512",
"sve",
+ "asimdfhm",
NULL
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-13 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWEFttz_Shve+D1Ku2NoUYX-AomzXY9JFGRjzzM=hOc_A@mail.gmail.com>
Hello Geert,
thank you for your feedback.
> Hi Fabrizio,
>
> On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> >> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
> >> > Add CMT[01] support to SoC DT.
> >> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> >> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >> > ---
> >> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
> >> > 1 file changed, 30 insertions(+)
> >>
> >> I was expecting the cmt nodes to be "disabled" in the SoC file
> >> and then enabled selectively in board files. Am I missing something?
> >
> > Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific DT.
> > The system will park it and leave its clock disabled until actually needed for something.
> > The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it
> disabled by default?
>
> It's debatable (thus up to Simon the maintainer ;-).
> For I/O devices, we disable them in the SoC .dtsi file.
> For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
> them enabled.
>
> Timers are core functionality, but who's actually using these timers?
I don't have a use case in mind unfortunately, but it's still core functionality and pretty harmless as far as I can tell. Let's see what Simon thinks about this.
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Will Deacon @ 2017-12-13 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdX1emac77CnKRbL_xEq4CFm6YyeNMHimFDUhEsDoeWBOw@mail.gmail.com>
Hi Geert,
Thanks for trying to bisect this.
On Tue, Dec 12, 2017 at 09:54:05PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
> > reproduce this on any of our systems, unfortunately.
>
> I've tried, but ended up on an unrelated XFS merge commit. Probably I
> marked a few commits good due to not seeing this heisenbug.
>
> For reference, here's the bisect log.
>
> Bad commits showed one or both of "unhandled level 0 translation fault" and
> "invalid pointer". Good commits didn't show any during 6 tries.
>
> git bisect start
> # bad: [ae64f9bd1d3621b5e60d7363bc20afb46aede215] Linux 4.15-rc2
> git bisect bad ae64f9bd1d3621b5e60d7363bc20afb46aede215
> # good: [4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323] Linux 4.15-rc1
> git bisect good 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
> # good: [9e0600f5cf6cecfcab5046d1453a9538c054d8a7] Merge tag
> 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> git bisect good 9e0600f5cf6cecfcab5046d1453a9538c054d8a7
> # good: [503505bfea19b7d69e2572297e6defa0f9c2404e] Merge branch
> 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into
> drm-fixes
> git bisect good 503505bfea19b7d69e2572297e6defa0f9c2404e
> # good: [ae753ee2771a1bacade56411bb98037b2545c929] Merge tag
> 'afs-fixes-20171201' of
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
> git bisect good ae753ee2771a1bacade56411bb98037b2545c929
> # good: [e1ba1c99dad92c5917b22b1047cf36e4426b124a] Merge tag
> 'riscv-for-linus-4.15-rc2_cleanups' of
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux
> git bisect good e1ba1c99dad92c5917b22b1047cf36e4426b124a
^^ This one is the first "good" commit containing the arm64-fixes pull.
Maybe try stressing it a bit more and see if it also fails?
That said, I'm still suspicious that nobody else is seeing this -- I also
checked the various build/boot farms and everything looks ok.
Will
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-13 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpOZ=WOx14gTwH5jfLozepT2Jw8JSY5x+bfEZ_YaiQvFpw@mail.gmail.com>
Bhupesh, Ard,
On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> Hi Ard, Akashi
>
(snip)
> Looking deeper into the issue, since the arm64 kexec-tools uses the
> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> identify its own usable memory and exclude, at its boot time, any
> other memory areas that are part of the panicked kernel's memory.
> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> , for details)
Right.
> 1). Now when 'kexec -p' is executed, this node is patched up only
> with the crashkernel memory range:
>
> /* add linux,usable-memory-range */
> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> result = fdt_setprop_range(new_buf, nodeoffset,
> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> address_cells, size_cells);
>
> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> , for details)
>
> 2). This excludes the ACPI reclaim regions irrespective of whether
> they are marked as System RAM or as RESERVED. As,
> 'linux,usable-memory-range' dt node is patched up only with
> 'crash_reserved_mem' and not 'system_memory_ranges'
>
> 3). As a result when the crashkernel boots up it doesn't find this
> ACPI memory and crashes while trying to access the same:
>
> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> -r`.img --reuse-cmdline -d
>
> [snip..]
>
> Reserved memory range
> 000000000e800000-000000002e7fffff (0)
>
> Coredump memory ranges
> 0000000000000000-000000000e7fffff (0)
> 000000002e800000-000000003961ffff (0)
> 0000000039d40000-000000003ed2ffff (0)
> 000000003ed60000-000000003fbfffff (0)
> 0000001040000000-0000001ffbffffff (0)
> 0000002000000000-0000002ffbffffff (0)
> 0000009000000000-0000009ffbffffff (0)
> 000000a000000000-000000affbffffff (0)
>
> 4). So if we revert Ard's patch or just comment the fixing up of the
> memory cap'ing passed to the crash kernel inside
> 'arch/arm64/mm/init.c' (see below):
>
> static void __init fdt_enforce_memory_region(void)
> {
> struct memblock_region reg = {
> .size = 0,
> };
>
> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>
> if (reg.size)
> //memblock_cap_memory_range(reg.base, reg.size); /*
> comment this out */
> }
Please just don't do that. It can cause a fatal damage on
memory contents of the *crashed* kernel.
> 5). Both the above temporary solutions fix the problem.
>
> 6). However exposing all System RAM regions to the crashkernel is not
> advisable and may cause the crashkernel or some crashkernel drivers to
> fail.
>
> 6a). I am trying an approach now, where the ACPI reclaim regions are
> added to '/proc/iomem' separately as ACPI reclaim regions by the
> kernel code and on the other hand the user-space 'kexec-tools' will
> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> dt node 'linux,usable-memory-range'
I still don't understand why we need to carry over the information
about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
such regions are free to be reused by the kernel after some point of
initialization. Why does crash dump kernel need to know about them?
(In other words, can or should we skip some part of ACPI-related init code
on crash dump kernel?)
Thanks,
-Takahiro AKASHI
> 6b). The kernel code currently looks like the following:
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 30ad2f085d1f..867bdec7c692 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -206,6 +206,7 @@ static void __init request_standard_resources(void)
> {
> struct memblock_region *region;
> struct resource *res;
> + phys_addr_t addr_start, addr_end;
>
> kernel_code.start = __pa_symbol(_text);
> kernel_code.end = __pa_symbol(__init_begin - 1);
> @@ -218,9 +219,17 @@ static void __init request_standard_resources(void)
> res->name = "reserved";
> res->flags = IORESOURCE_MEM;
> } else {
> - res->name = "System RAM";
> - res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> + addr_start =
> __pfn_to_phys(memblock_region_reserved_base_pfn(region));
> + addr_end =
> __pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1;
> + if ((efi_mem_type(addr_start) == EFI_ACPI_RECLAIM_MEMORY)
> || (efi_mem_type(addr_end) == EFI_ACPI_RECLAIM_MEMORY)) {
> + res->name = "ACPI reclaim region";
> + res->flags = IORESOURCE_MEM;
> + } else {
> + res->name = "System RAM";
> + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> + }
> }
> +
> res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
> res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
>
> @@ -292,6 +301,7 @@ void __init setup_arch(char **cmdline_p)
>
> request_standard_resources();
>
> + efi_memmap_unmap();
> early_ioremap_reset();
>
> if (acpi_disabled)
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 80d1a885def5..a7c522eac640 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -259,7 +259,6 @@ void __init efi_init(void)
>
> reserve_regions();
> efi_esrt_init();
> - efi_memmap_unmap();
>
> memblock_reserve(params.mmap & PAGE_MASK,
> PAGE_ALIGN(params.mmap_size +
>
>
> After this change the ACPI reclaim regions are properly recognized in
> '/proc/iomem':
>
> # cat /proc/iomem | grep -i ACPI
> 396c0000-3975ffff : ACPI reclaim region
> 39770000-397affff : ACPI reclaim region
> 398a0000-398bffff : ACPI reclaim region
>
> 6c). I am currently changing the 'kexec-tools' and will finish the
> testing over the next few days.
>
> I just wanted to know your opinion on this issue, so that I will be
> able to propose a fix on the above lines.
>
> Also Cc'ing kexec mailing list for more inputs on changes proposed to
> kexec-tools.
>
> Thanks,
> Bhupesh
^ permalink raw reply
* [PATCH V4 08/12] boot_constraint: Manage deferrable constraints
From: Viresh Kumar @ 2017-12-13 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213095345.GJ13194@kroah.com>
On 13-12-17, 10:53, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:56PM +0530, Viresh Kumar wrote:
> > +static void add_deferrable_of_single(struct device_node *np,
> > + struct dev_boot_constraint *constraints,
> > + int count)
> > +{
> > + struct device *dev;
> > + int ret;
> > +
> > + if (!of_device_is_available(np))
> > + return;
> > +
> > + ret = of_platform_bus_create(np, NULL, NULL, NULL, false);
> > + if (ret)
> > + return;
> > +
> > + if (of_device_is_compatible(np, "arm,primecell")) {
>
> Why is "arm,primecell" in the core code here?
All we need here is a struct device pointer to add constraints. But how we get
the device node depends on what bus type the device corresponds to. Currently
this only support amba and platform devices, but we may need to get spi, i2c,
etc later on.
How do you suggest to keep this stuff out of core here ? Are you asking me to
add a generic API in the OF core to find the struct device pointer using a node
pointer ?
> > + struct amba_device *adev = of_find_amba_device_by_node(np);
> > +
> > + if (!adev) {
> > + pr_err("Failed to find amba dev: %s\n", np->full_name);
>
> Never use pr_* when you have a valid struct device to use.
Sure. I agree.
> Don't you
> have one from the struct device_node * passed in here?
The struct device_node doesn't contain a struct device * unfortunately. Will it
be acceptable to add one ? That will solve some controversial part of this
function for sure :)
--
viresh
^ permalink raw reply
* [PATCH V4 00/12] drivers: Boot Constraints core
From: Viresh Kumar @ 2017-12-13 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213095529.GK13194@kroah.com>
On 13-12-17, 10:55, Greg Kroah-Hartman wrote:
> On Tue, Nov 28, 2017 at 09:48:18AM +0530, Viresh Kumar wrote:
> > On 29-10-17, 19:18, Viresh Kumar wrote:
> > > Here is V4 of the boot constraints core based on your feedback from V3.
> > > We now have support for three platforms (as you suggested) included in
> > > this series: Hisilicon, IMX and Qualcomm.
> >
> > Hi Greg,
> >
> > I was waiting for rc1 to come out before sending a reminder for this
> > series and so here is one :)
>
> I've reviewed it enough for now, needs a tiny bit of work, but looking
> much better, nice job!
Thanks a lot for finding time to get this reviewed. Really appreciate that.
--
viresh
^ permalink raw reply
* [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
From: Alexandre TORGUE @ 2017-12-13 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ab9a2ef4-4944-c935-af6e-12503b477879@arm.com>
-----Original Message-----
From: Vladimir Murzin [mailto:vladimir.murzin at arm.com]
Sent: mercredi 13 d?cembre 2017 11:07
To: Alexandre TORGUE <alexandre.torgue@st.com>; Maxime Coquelin <mcoquelin.stm32@gmail.com>; arnd at arndb.de; robh+dt at kernel.org; mark.rutland at arm.com; linux at armlinux.org.uk; Patrice CHOTARD <patrice.chotard@st.com>; lee.jones at linaro.org
Cc: devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
On 12/12/17 18:02, Alexandre Torgue wrote:
> On cortex-M7 MCU, DMA have to use a non cache-able memory area. For
> this reason a dedicated memory pool is created for DMA.
> This patch creates a DMA memory pool of 1MB of each STM32 MCU which
> embeds a cortex-M7 expect stm32f746-disco. Indeed, as stm32f746-disco
> has
^^^^^^
except?
Sorry, Is there a typo issue (or just wording issue) ?
> only a 8MB SDRAM and it's tricky to reduce memory used by Kernel.
I guess that 1MB is a kind of "should be enough" estimate, probably something along with [1] would give you exact numbers...
Exactly, 1MB is a kind "should be enough" and code is here to show that we need a dedicated memory area for DMA. But this value has
to be adapt regarding to use case needed by users. Thanks for the lkml link. It will help users to adapt DMA area and thanks for reviewing.
Regards
Alex
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>
> diff --git a/arch/arm/boot/dts/stm32746g-eval.dts
> b/arch/arm/boot/dts/stm32746g-eval.dts
> index 2d4e717..3f52a7b 100644
> --- a/arch/arm/boot/dts/stm32746g-eval.dts
> +++ b/arch/arm/boot/dts/stm32746g-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xc0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts
> b/arch/arm/boot/dts/stm32f769-disco.dts
> index 4463ca1..08699a2 100644
> --- a/arch/arm/boot/dts/stm32f769-disco.dts
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xC0000000 0x1000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc0f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts
> b/arch/arm/boot/dts/stm32h743i-disco.dts
> index 79e841d..104545a 100644
> --- a/arch/arm/boot/dts/stm32h743i-disco.dts
> +++ b/arch/arm/boot/dts/stm32h743i-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart2;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts
> b/arch/arm/boot/dts/stm32h743i-eval.dts
> index 9f0e72c..5bd4b16 100644
> --- a/arch/arm/boot/dts/stm32h743i-eval.dts
> +++ b/arch/arm/boot/dts/stm32h743i-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
>
Usage of dma-default looks correct to me, so FWIW
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
[1] https://lkml.org/lkml/2017/7/7/296
Vladimir
^ permalink raw reply
* [PATCH 3/3] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Enric Balletbo Serra @ 2017-12-13 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206172919.GA87458@google.com>
Hi Brian,
2017-12-06 18:29 GMT+01:00 Brian Norris <briannorris@chromium.org>:
> + Alex, Jeffy, Frank Wang
>
> Hi,
>
> On Wed, Dec 06, 2017 at 12:10:08PM +0100, Enric Balletbo i Serra wrote:
>> Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
>>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> index 470105d..03f1950 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> @@ -855,6 +855,20 @@ ap_i2c_audio: &i2c8 {
>> compatible = "google,cros-ec-pwm";
>> #pwm-cells = <1>;
>> };
>> +
>> + usbc_extcon0: extcon at 0 {
>> + compatible = "google,extcon-usbc-cros-ec";
>> + google,usb-port-id = <0>;
>> +
>> + #extcon-cells = <0>;
>> + };
>> +
>> + usbc_extcon1: extcon at 1 {
>> + compatible = "google,extcon-usbc-cros-ec";
>> + google,usb-port-id = <1>;
>> +
>> + #extcon-cells = <0>;
>> + };
>> };
>> };
>>
>> @@ -865,6 +879,16 @@ ap_i2c_audio: &i2c8 {
>> rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
>> };
>>
>> +&tcphy0 {
>> + status = "okay";
>> + extcon = <&usbc_extcon0>;
>> +};
>> +
>> +&tcphy1 {
>> + status = "okay";
>> + extcon = <&usbc_extcon1>;
>> +};
>> +
>> &u2phy0 {
>> status = "okay";
>> };
>> @@ -911,6 +935,7 @@ ap_i2c_audio: &i2c8 {
>>
>> &usbdrd3_0 {
>> status = "okay";
>> + extcon = <&usbc_extcon0>;
>> };
>>
>> &usbdrd_dwc3_0 {
>> @@ -920,6 +945,7 @@ ap_i2c_audio: &i2c8 {
>>
>> &usbdrd3_1 {
>> status = "okay";
>> + extcon = <&usbc_extcon1>;
>> };
>>
>> &usbdrd_dwc3_1 {
>
> Seems OK.
>
> Also, IIUC, I think if we ever want to support dual-role/OTG, we need an
> extcon reference in the USB2/OTG PHY that serves these ports too. i.e.,
> u2phy0 and u2phy1? Notably, the PHY driver supports the extcon
> properties, but it's not documented in
> Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt yet (we
> should probably get that fixed).
>
I'll take a look at this and send a separate patchset. Thanks.
Enric
> So, anyway, maybe the above isn't a blocker for this patch. Just noticed
> it while reading. Assuming the driver stuff falls into place:
>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
^ permalink raw reply
* [PATCH v2 1/5] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Benson Leung <bleung@chromium.org>
Extend the driver to notify host and device type cables and the presence
of power.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
---
Changes since v1:
- Use the BIT macro. Requested by Lee Jones.
- Add the Reviewed-by: Chanwoo Choi.
drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
include/linux/mfd/cros_ec_commands.h | 17 +++++
2 files changed, 155 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-usbc-cros-ec.c b/drivers/extcon/extcon-usbc-cros-ec.c
index 6187f73..6721ab0 100644
--- a/drivers/extcon/extcon-usbc-cros-ec.c
+++ b/drivers/extcon/extcon-usbc-cros-ec.c
@@ -34,16 +34,26 @@ struct cros_ec_extcon_info {
struct notifier_block notifier;
+ unsigned int dr; /* data role */
+ bool pr; /* power role (true if VBUS enabled) */
bool dp; /* DisplayPort enabled */
bool mux; /* SuperSpeed (usb3) enabled */
unsigned int power_type;
};
static const unsigned int usb_type_c_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
EXTCON_DISP_DP,
EXTCON_NONE,
};
+enum usb_data_roles {
+ DR_NONE,
+ DR_HOST,
+ DR_DEVICE,
+};
+
/**
* cros_ec_pd_command() - Send a command to the EC.
* @info: pointer to struct cros_ec_extcon_info
@@ -150,6 +160,7 @@ static int cros_ec_usb_get_role(struct cros_ec_extcon_info *info,
pd_control.port = info->port_id;
pd_control.role = USB_PD_CTRL_ROLE_NO_CHANGE;
pd_control.mux = USB_PD_CTRL_MUX_NO_CHANGE;
+ pd_control.swap = USB_PD_CTRL_SWAP_NONE;
ret = cros_ec_pd_command(info, EC_CMD_USB_PD_CONTROL, 1,
&pd_control, sizeof(pd_control),
&resp, sizeof(resp));
@@ -183,11 +194,72 @@ static int cros_ec_pd_get_num_ports(struct cros_ec_extcon_info *info)
return resp.num_ports;
}
+static const char *cros_ec_usb_role_string(unsigned int role)
+{
+ return role == DR_NONE ? "DISCONNECTED" :
+ (role == DR_HOST ? "DFP" : "UFP");
+}
+
+static const char *cros_ec_usb_power_type_string(unsigned int type)
+{
+ switch (type) {
+ case USB_CHG_TYPE_NONE:
+ return "USB_CHG_TYPE_NONE";
+ case USB_CHG_TYPE_PD:
+ return "USB_CHG_TYPE_PD";
+ case USB_CHG_TYPE_PROPRIETARY:
+ return "USB_CHG_TYPE_PROPRIETARY";
+ case USB_CHG_TYPE_C:
+ return "USB_CHG_TYPE_C";
+ case USB_CHG_TYPE_BC12_DCP:
+ return "USB_CHG_TYPE_BC12_DCP";
+ case USB_CHG_TYPE_BC12_CDP:
+ return "USB_CHG_TYPE_BC12_CDP";
+ case USB_CHG_TYPE_BC12_SDP:
+ return "USB_CHG_TYPE_BC12_SDP";
+ case USB_CHG_TYPE_OTHER:
+ return "USB_CHG_TYPE_OTHER";
+ case USB_CHG_TYPE_VBUS:
+ return "USB_CHG_TYPE_VBUS";
+ case USB_CHG_TYPE_UNKNOWN:
+ return "USB_CHG_TYPE_UNKNOWN";
+ default:
+ return "USB_CHG_TYPE_UNKNOWN";
+ }
+}
+
+static bool cros_ec_usb_power_type_is_wall_wart(unsigned int type,
+ unsigned int role)
+{
+ switch (type) {
+ /* FIXME : Guppy, Donnettes, and other chargers will be miscategorized
+ * because they identify with USB_CHG_TYPE_C, but we can't return true
+ * here from that code because that breaks Suzy-Q and other kinds of
+ * USB Type-C cables and peripherals.
+ */
+ case USB_CHG_TYPE_PROPRIETARY:
+ case USB_CHG_TYPE_BC12_DCP:
+ return true;
+ case USB_CHG_TYPE_PD:
+ case USB_CHG_TYPE_C:
+ case USB_CHG_TYPE_BC12_CDP:
+ case USB_CHG_TYPE_BC12_SDP:
+ case USB_CHG_TYPE_OTHER:
+ case USB_CHG_TYPE_VBUS:
+ case USB_CHG_TYPE_UNKNOWN:
+ case USB_CHG_TYPE_NONE:
+ default:
+ return false;
+ }
+}
+
static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
bool force)
{
struct device *dev = info->dev;
int role, power_type;
+ unsigned int dr = DR_NONE;
+ bool pr = false;
bool polarity = false;
bool dp = false;
bool mux = false;
@@ -206,9 +278,12 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
dev_err(dev, "failed getting role err = %d\n", role);
return role;
}
+ dev_dbg(dev, "disconnected\n");
} else {
int pd_mux_state;
+ dr = (role & PD_CTRL_RESP_ROLE_DATA) ? DR_HOST : DR_DEVICE;
+ pr = (role & PD_CTRL_RESP_ROLE_POWER);
pd_mux_state = cros_ec_usb_get_pd_mux_state(info);
if (pd_mux_state < 0)
pd_mux_state = USB_PD_MUX_USB_ENABLED;
@@ -216,20 +291,62 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
dp = pd_mux_state & USB_PD_MUX_DP_ENABLED;
mux = pd_mux_state & USB_PD_MUX_USB_ENABLED;
hpd = pd_mux_state & USB_PD_MUX_HPD_IRQ;
- }
- if (force || info->dp != dp || info->mux != mux ||
- info->power_type != power_type) {
+ dev_dbg(dev,
+ "connected role 0x%x pwr type %d dr %d pr %d pol %d mux %d dp %d hpd %d\n",
+ role, power_type, dr, pr, polarity, mux, dp, hpd);
+ }
+ /*
+ * When there is no USB host (e.g. USB PD charger),
+ * we are not really a UFP for the AP.
+ */
+ if (dr == DR_DEVICE &&
+ cros_ec_usb_power_type_is_wall_wart(power_type, role))
+ dr = DR_NONE;
+
+ if (force || info->dr != dr || info->pr != pr || info->dp != dp ||
+ info->mux != mux || info->power_type != power_type) {
+ bool host_connected = false, device_connected = false;
+
+ dev_dbg(dev, "Type/Role switch! type = %s role = %s\n",
+ cros_ec_usb_power_type_string(power_type),
+ cros_ec_usb_role_string(dr));
+ info->dr = dr;
+ info->pr = pr;
info->dp = dp;
info->mux = mux;
info->power_type = power_type;
- extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
+ if (dr == DR_DEVICE)
+ device_connected = true;
+ else if (dr == DR_HOST)
+ host_connected = true;
+ extcon_set_state(info->edev, EXTCON_USB, device_connected);
+ extcon_set_state(info->edev, EXTCON_USB_HOST, host_connected);
+ extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
+ extcon_set_property(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_VBUS,
+ (union extcon_property_value)(int)pr);
+ extcon_set_property(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_VBUS,
+ (union extcon_property_value)(int)pr);
+ extcon_set_property(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_TYPEC_POLARITY,
+ (union extcon_property_value)(int)polarity);
+ extcon_set_property(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY,
+ (union extcon_property_value)(int)polarity);
extcon_set_property(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_TYPEC_POLARITY,
(union extcon_property_value)(int)polarity);
+ extcon_set_property(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_SS,
+ (union extcon_property_value)(int)mux);
+ extcon_set_property(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_SS,
+ (union extcon_property_value)(int)mux);
extcon_set_property(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_SS,
(union extcon_property_value)(int)mux);
@@ -237,6 +354,8 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
EXTCON_PROP_DISP_HPD,
(union extcon_property_value)(int)hpd);
+ extcon_sync(info->edev, EXTCON_USB);
+ extcon_sync(info->edev, EXTCON_USB_HOST);
extcon_sync(info->edev, EXTCON_DISP_DP);
} else if (hpd) {
@@ -322,13 +441,28 @@ static int extcon_cros_ec_probe(struct platform_device *pdev)
return ret;
}
+ extcon_set_property_capability(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_VBUS);
+ extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_VBUS);
+ extcon_set_property_capability(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_TYPEC_POLARITY);
+ extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY);
extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_TYPEC_POLARITY);
+ extcon_set_property_capability(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_SS);
+ extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_SS);
extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_SS);
extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_DISP_HPD);
+ info->dr = DR_NONE;
+ info->pr = false;
+
platform_set_drvdata(pdev, info);
/* Get PD events from the EC */
diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
index 2b16e95..a83f649 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -2904,16 +2904,33 @@ enum usb_pd_control_mux {
USB_PD_CTRL_MUX_AUTO = 5,
};
+enum usb_pd_control_swap {
+ USB_PD_CTRL_SWAP_NONE = 0,
+ USB_PD_CTRL_SWAP_DATA = 1,
+ USB_PD_CTRL_SWAP_POWER = 2,
+ USB_PD_CTRL_SWAP_VCONN = 3,
+ USB_PD_CTRL_SWAP_COUNT
+};
+
struct ec_params_usb_pd_control {
uint8_t port;
uint8_t role;
uint8_t mux;
+ uint8_t swap;
} __packed;
#define PD_CTRL_RESP_ENABLED_COMMS (1 << 0) /* Communication enabled */
#define PD_CTRL_RESP_ENABLED_CONNECTED (1 << 1) /* Device connected */
#define PD_CTRL_RESP_ENABLED_PD_CAPABLE (1 << 2) /* Partner is PD capable */
+#define PD_CTRL_RESP_ROLE_POWER BIT(0) /* 0=SNK/1=SRC */
+#define PD_CTRL_RESP_ROLE_DATA BIT(1) /* 0=UFP/1=DFP */
+#define PD_CTRL_RESP_ROLE_VCONN BIT(2) /* Vconn status */
+#define PD_CTRL_RESP_ROLE_DR_POWER BIT(3) /* Partner is dualrole power */
+#define PD_CTRL_RESP_ROLE_DR_DATA BIT(4) /* Partner is dualrole data */
+#define PD_CTRL_RESP_ROLE_USB_COMM BIT(5) /* Partner USB comm capable */
+#define PD_CTRL_RESP_ROLE_EXT_POWERED BIT(6) /* Partner externally powerd */
+
struct ec_response_usb_pd_control_v1 {
uint8_t enabled;
uint8_t role;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
---
Changes since v1:
- Add the Reviewed-by: Brian Norris
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 470105d..03f1950 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -855,6 +855,20 @@ ap_i2c_audio: &i2c8 {
compatible = "google,cros-ec-pwm";
#pwm-cells = <1>;
};
+
+ usbc_extcon0: extcon at 0 {
+ compatible = "google,extcon-usbc-cros-ec";
+ google,usb-port-id = <0>;
+
+ #extcon-cells = <0>;
+ };
+
+ usbc_extcon1: extcon at 1 {
+ compatible = "google,extcon-usbc-cros-ec";
+ google,usb-port-id = <1>;
+
+ #extcon-cells = <0>;
+ };
};
};
@@ -865,6 +879,16 @@ ap_i2c_audio: &i2c8 {
rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
};
+&tcphy0 {
+ status = "okay";
+ extcon = <&usbc_extcon0>;
+};
+
+&tcphy1 {
+ status = "okay";
+ extcon = <&usbc_extcon1>;
+};
+
&u2phy0 {
status = "okay";
};
@@ -911,6 +935,7 @@ ap_i2c_audio: &i2c8 {
&usbdrd3_0 {
status = "okay";
+ extcon = <&usbc_extcon0>;
};
&usbdrd_dwc3_0 {
@@ -920,6 +945,7 @@ ap_i2c_audio: &i2c8 {
&usbdrd3_1 {
status = "okay";
+ extcon = <&usbc_extcon1>;
};
&usbdrd_dwc3_1 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: rockchip: add the aclk_usb3 clocks for USB3.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
The aclk_usb3 must be enabled to support USB3 for rk3399.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Changes since v1:
- Split the original patch in different commits
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 17e5e1a..f32e9c4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -397,9 +397,11 @@
#size-cells = <2>;
ranges;
clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
- <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+ <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
clock-names = "ref_clk", "suspend_clk",
- "bus_clk", "grf_clk";
+ "bus_clk", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "grf_clk";
status = "disabled";
usbdrd_dwc3_0: dwc3 {
@@ -425,9 +427,11 @@
#size-cells = <2>;
ranges;
clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
- <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+ <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
clock-names = "ref_clk", "suspend_clk",
- "bus_clk", "grf_clk";
+ "bus_clk", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "grf_clk";
status = "disabled";
usbdrd_dwc3_1: dwc3 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: rockchip: add usb3-phy otg-port support for rk3399.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
Add the usb3 phyter for the USB3.0 OTG controller.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Changes since v1:
- Split the original patch in different commits
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f32e9c4..ea91f25 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -409,8 +409,8 @@
reg = <0x0 0xfe800000 0x0 0x100000>;
interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
dr_mode = "otg";
- phys = <&u2phy0_otg>;
- phy-names = "usb2-phy";
+ phys = <&u2phy0_otg>, <&tcphy0_usb3>;
+ phy-names = "usb2-phy", "usb3-phy";
phy_type = "utmi_wide";
snps,dis_enblslpm_quirk;
snps,dis-u2-freeclk-exists-quirk;
@@ -439,8 +439,8 @@
reg = <0x0 0xfe900000 0x0 0x100000>;
interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
dr_mode = "otg";
- phys = <&u2phy1_otg>;
- phy-names = "usb2-phy";
+ phys = <&u2phy1_otg>, <&tcphy1_usb3>;
+ phy-names = "usb2-phy", "usb3-phy";
phy_type = "utmi_wide";
snps,dis_enblslpm_quirk;
snps,dis-u2-freeclk-exists-quirk;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/5] arm64: dts: rockchip: add pd_usb3 power-domain node for rk3399
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
Add the usb3 power-domain, its qos area and assign it to the usb device
node.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Changes since v1:
- Split the original patch in different commits
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index ea91f25..c18ff88 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -417,6 +417,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,dis-tx-ipgap-linecheck-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -447,6 +448,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,dis-tx-ipgap-linecheck-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -995,6 +997,12 @@
clocks = <&cru HCLK_SDIO>;
pm_qos = <&qos_sdioaudio>;
};
+ pd_usb3 at RK3399_PD_USB3 {
+ reg = <RK3399_PD_USB3>;
+ clocks = <&cru ACLK_USB3>;
+ pm_qos = <&qos_usb_otg0>,
+ <&qos_usb_otg1>;
+ };
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: gengdongjiu @ 2017-12-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73019dea-3e2c-8d03-fe1a-6c54527fa401@arm.com>
On 2017/12/13 18:09, Suzuki K Poulose wrote:
>> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
>
> Looks good to me.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Thanks a lot to Suzuki's review.
^ permalink raw reply
* [PATCH V4 08/12] boot_constraint: Manage deferrable constraints
From: Russell King - ARM Linux @ 2017-12-13 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213102707.GD3322@vireshk-i7>
On Wed, Dec 13, 2017 at 03:57:07PM +0530, Viresh Kumar wrote:
> On 13-12-17, 10:53, Greg Kroah-Hartman wrote:
> > On Sun, Oct 29, 2017 at 07:18:56PM +0530, Viresh Kumar wrote:
> > > +static void add_deferrable_of_single(struct device_node *np,
> > > + struct dev_boot_constraint *constraints,
> > > + int count)
> > > +{
> > > + struct device *dev;
> > > + int ret;
> > > +
> > > + if (!of_device_is_available(np))
> > > + return;
> > > +
> > > + ret = of_platform_bus_create(np, NULL, NULL, NULL, false);
> > > + if (ret)
> > > + return;
> > > +
> > > + if (of_device_is_compatible(np, "arm,primecell")) {
> >
> > Why is "arm,primecell" in the core code here?
>
> All we need here is a struct device pointer to add constraints. But how we get
> the device node depends on what bus type the device corresponds to. Currently
> this only support amba and platform devices, but we may need to get spi, i2c,
> etc later on.
>
> How do you suggest to keep this stuff out of core here ? Are you asking me to
> add a generic API in the OF core to find the struct device pointer using a node
> pointer ?
Why do we need this? Why can't we lookup the "struct device" by DT
node, and then look at the device's bus type and decide what to do
from that?
Wouldn't a better solution be to use fwnode stuff for this, and
make the bus-type handling a property of the bus type itself,
pushing the bus specific code into the bus layer?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Tegra baseline test results for v4.15-rc3
From: Jon Hunter @ 2017-12-13 10:36 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.15-rc3.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.15-rc3/20171212080102/
Test summary - 81% Success
--------------------------
Build: zImage:
Pass: ( 3/ 3): multi_v7_defconfig, tegra_defconfig,
tegra_defconfig%tegra-fw
Build: Image:
Pass: ( 3/ 3): defconfig, defconfig%jetson-tx2,
defconfig%jetson-tx1
Boot to userspace: defconfig:
FAIL: ( 1/ 4): qemu-vexpress64
Pass: ( 3/ 4): tegra132-norrin, tegra210-p2371-0000, tegra210-smaug
Boot to userspace: defconfig%jetson-tx1:
Pass: ( 2/ 2): tegra210-p2371-0000, tegra210-p2371-2180
Boot to userspace: defconfig%jetson-tx2:
Pass: ( 1/ 1): tegra186-p2771-0000
Boot to userspace: multi_v7_defconfig:
FAIL: ( 1/ 5): tegra124-nyan-big
Pass: ( 4/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
FAIL: ( 1/ 5): tegra124-nyan-big
Pass: ( 4/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig%tegra-fw:
FAIL: ( 1/ 2): tegra124-nyan-big
Pass: ( 1/ 2): tegra124-jetson-tk1
PM: System suspend: multi_v7_defconfig:
FAIL: ( 1/ 5): tegra124-nyan-big
Pass: ( 4/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
FAIL: ( 1/ 5): tegra124-nyan-big
Pass: ( 4/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig%tegra-fw:
FAIL: ( 1/ 2): tegra124-nyan-big
Pass: ( 1/ 2): tegra124-jetson-tk1
vmlinux object size
(delta in bytes from test_v4.15-rc2 (ae64f9bd1d3621b5e60d7363bc20afb46aede215)):
text data bss total kernel
+3152 +832 0 +3984 defconfig
+820 -128 +64 +756 multi_v7_defconfig
+2120 +4108 0 +6228 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.15-rc2 (ae64f9bd1d3621b5e60d7363bc20afb46aede215))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig%tegr tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig%tegr tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra186-p2771-0000 defconfig%jetson-tx2 tegra186-p2771-0000
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig%jetson-tx1 tegra210-p2371-0000
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-p2371-2180 defconfig%jetson-tx1 tegra210-p2371-2180
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH v3] arm64: fault: avoid send SIGBUS two times
From: Dongjiu Geng @ 2017-12-13 10:36 UTC (permalink / raw)
To: linux-arm-kernel
do_sea() calls arm64_notify_die() which will always signal
user-space. It also returns whether APEI claimed the external
abort as a RAS notification. If it returns failure do_mem_abort()
will signal user-space too.
do_mem_abort() wants to know if we handled the error, we always
call arm64_notify_die() so can always return success.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
---
Change since V2:
1. Address James's comments to not change the si_code for SIGBUS
Change since V1:
1. Address James's comments to update the commit messages
---
arch/arm64/mm/fault.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 22168cd..9b7f89d 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -574,7 +574,6 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
{
struct siginfo info;
const struct fault_info *inf;
- int ret = 0;
inf = esr_to_fault_info(esr);
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
@@ -589,7 +588,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
- ret = ghes_notify_sea();
+ ghes_notify_sea();
if (interrupts_enabled(regs))
nmi_exit();
@@ -604,7 +603,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
info.si_addr = (void __user *)addr;
arm64_notify_die("", regs, &info, esr);
- return ret;
+ return 0;
}
static const struct fault_info fault_info[] = {
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: allwinner: a64: a64-olinuxino: add usb otg
From: Maxime Ripard @ 2017-12-13 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZDEhXjHTE4WsJK8=yAayuR=qvJQaZEjGq=LDS6Y4V7RFw@mail.gmail.com>
On Tue, Dec 12, 2017 at 02:57:01PM +0530, Jagan Teki wrote:
> On Tue, Dec 12, 2017 at 1:43 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Tue, Dec 12, 2017 at 11:26:09AM +0530, Jagan Teki wrote:
> >> Add usb otg support for a64-olinuxino board,
> >> - USB0-ID connected with PH9
> >> - USB0-VBUSDET connected with PH6
> >> - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
> >>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >
> > How was this tested? Did you test the OTG part, or only the peripheral
> > part?
>
> Yes peripheral.
Please test the switching between host and peripheral then, and the
same comment applies to your bananapi-m64.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171213/d8867d92/attachment-0001.sig>
^ permalink raw reply
* [PATCH] drm: Fix possible deadlock in drm_mode_config_cleanup()
From: Daniel Vetter @ 2017-12-13 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213085720.6059-1-m.szyprowski@samsung.com>
On Wed, Dec 13, 2017 at 09:57:20AM +0100, Marek Szyprowski wrote:
> drm_mode_config_cleanup() might be called from a workqueue context (for
> example in error path handling of deferred probe), so it must not call
> flush_scheduled_work(), because it would deadlock in such case. Replace
> that call with explicit counting of the scheduled connector free works
> and waiting until it reaches zero.
>
> Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
I don't like hand-rolling wait stuff if it's avoidable (although
cross-release will catch all the fun nowadays). I'm working on a patch to
rework the cleanup logic so we can flush stuff directly. Bit more work,
but imo cleaner logic.
-Daniel
> ---
> This fixes the issue discussed in the following thread:
> https://www.spinics.net/lists/arm-kernel/msg622332.html
> ---
> drivers/gpu/drm/drm_connector.c | 6 +++++-
> drivers/gpu/drm/drm_mode_config.c | 6 +++++-
> include/drm/drm_mode_config.h | 13 +++++++++++++
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 0b7e0974e6da..7620ac1ad1b1 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -161,6 +161,8 @@ static void drm_connector_free_work_fn(struct work_struct *work)
>
> drm_mode_object_unregister(dev, &connector->base);
> connector->funcs->destroy(connector);
> + atomic_dec(&dev->mode_config.connector_free_works);
> + wake_up_all(&dev->mode_config.connector_free_queue);
> }
>
> /**
> @@ -552,8 +554,10 @@ EXPORT_SYMBOL(drm_connector_list_iter_begin);
> static void
> drm_connector_put_safe(struct drm_connector *conn)
> {
> - if (refcount_dec_and_test(&conn->base.refcount.refcount))
> + if (refcount_dec_and_test(&conn->base.refcount.refcount)) {
> + atomic_inc(&conn->dev->mode_config.connector_free_works);
> schedule_work(&conn->free_work);
> + }
> }
>
> /**
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 6ffe952142e6..cca443faebd8 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -381,6 +381,7 @@ void drm_mode_config_init(struct drm_device *dev)
> idr_init(&dev->mode_config.tile_idr);
> ida_init(&dev->mode_config.connector_ida);
> spin_lock_init(&dev->mode_config.connector_list_lock);
> + init_waitqueue_head(&dev->mode_config.connector_free_queue);
>
> drm_mode_create_standard_properties(dev);
>
> @@ -431,8 +432,11 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> drm_connector_put(connector);
> }
> drm_connector_list_iter_end(&conn_iter);
> +
> /* connector_iter drops references in a work item. */
> - flush_scheduled_work();
> + wait_event(dev->mode_config.connector_free_queue,
> + !atomic_read(&dev->mode_config.connector_free_works));
> +
> if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) {
> drm_connector_list_iter_begin(dev, &conn_iter);
> drm_for_each_connector_iter(connector, &conn_iter)
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index a0afeb591dcb..83a7db997e83 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -413,6 +413,19 @@ struct drm_mode_config {
> * &struct drm_connector_list_iter to walk this list.
> */
> struct list_head connector_list;
> + /**
> + * @pending_connector_free_works:
> + *
> + * Number of scheduled connector->free_work instances, see
> + * drm_connector_put_safe().
> + */
> + atomic_t connector_free_works;
> + /**
> + * @pending_connector_free_queue:
> + *
> + * Wait queue for waiting until connector->free_work is finished.
> + */
> + wait_queue_head_t connector_free_queue;
> /**
> * @num_encoder:
> *
> --
> 2.15.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v8 0/9] Handle forwarded level-triggered interrupts
From: Christoffer Dall @ 2017-12-13 10:45 UTC (permalink / raw)
To: linux-arm-kernel
This series is an alternative approach to Eric Auger's direct EOI setup
patches [1] in terms of the KVM VGIC support.
The idea is to maintain existing semantics for the VGIC for mapped
level-triggered IRQs and also support the timer using mapped IRQs with
the same VGIC support as VFIO interrupts.
Based on v4.15-rc1.
Also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git level-mapped-v8
Changes since v7:
- Cleanup stale commentary
- Updated documentation (patch 9/9 is new in this version)
- Added Eric's reviewed-by tags
Changes since v6:
- Removed double semi-colon
- Changed another confusing conditional in patch 6
- Fixed typos in commit message and comments
Changes since v5:
- Rebased on v4.15-rc1
- Changed comment on preemption code as suggested by Andre
- Fixed white space and confusing conditionals as suggested by Drew
Changes since v4:
- Rebased on the timer optimization series merged in the v4.15 merge
window, which caused a fair amount of modifications to patch 3.
- Added a static key to disable the sync operations when no VMs are
using userspace irqchips to further optimize the performance
- Fixed extra semicolon in vgic-mmio.c
- Added commentary as requested during review
- Dropped what was patch 4, because it was merged as part of GICv4
support.
- Factored out the VGIC input level function change as separate patch
(helps bisect and debugging), before providing a function for the
timer.
Changes since v3:
- Added a number of patches and moved patches around a bit.
- Check for uaccesses in the mmio handler functions
- Fixed bugs in the mmio handler functions
Changes since v2:
- Removed patch 5 from v2 and integrating the changes in what's now
patch 5 to make it easier to reuse code when adding VFIO integration.
- Changed the virtual distributor MMIO handling to use the
pending_latch and more closely match the semantics of SPENDR and
CPENDR for both level and edge mapped interrupts.
Changes since v1:
- Added necessary changes to the timer (Patch 1)
- Added handling of guest MMIO accesses to the virtual distributor
(Patch 4)
- Addressed Marc's comments from the initial RFC (mostly renames)
Thanks,
-Christoffer
[1]: https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/026072.html
Christoffer Dall (9):
KVM: arm/arm64: Remove redundant preemptible checks
KVM: arm/arm64: Factor out functionality to get vgic mmio
requester_vcpu
KVM: arm/arm64: Don't cache the timer IRQ level
KVM: arm/arm64: vgic: Support level-triggered mapped interrupts
KVM: arm/arm64: Support a vgic interrupt line level sample function
KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
KVM: arm/arm64: Provide a get_input_level for the arch timer
KVM: arm/arm64: Avoid work when userspace iqchips are not used
KVM: arm/arm64: Update timer and forwarded irq documentation
Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt | 50 +++++----
include/kvm/arm_arch_timer.h | 2 +
include/kvm/arm_vgic.h | 13 ++-
virt/kvm/arm/arch_timer.c | 112 ++++++++++----------
virt/kvm/arm/arm.c | 2 -
virt/kvm/arm/vgic/vgic-mmio.c | 115 +++++++++++++++++----
virt/kvm/arm/vgic/vgic-v2.c | 29 ++++++
virt/kvm/arm/vgic/vgic-v3.c | 29 ++++++
virt/kvm/arm/vgic/vgic.c | 41 +++++++-
virt/kvm/arm/vgic/vgic.h | 8 ++
10 files changed, 292 insertions(+), 109 deletions(-)
--
2.14.2
^ permalink raw reply
* [PATCH v8 1/9] KVM: arm/arm64: Remove redundant preemptible checks
From: Christoffer Dall @ 2017-12-13 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213104602.16383-1-christoffer.dall@linaro.org>
The __this_cpu_read() and __this_cpu_write() functions already implement
checks for the required preemption levels when using
CONFIG_DEBUG_PREEMPT which gives you nice error messages and such.
Therefore there is no need to explicitly check this using a BUG_ON() in
the code (which we don't do for other uses of per cpu variables either).
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a6524ff27de4..859ff7e3a1eb 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -71,7 +71,6 @@ static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
{
- BUG_ON(preemptible());
__this_cpu_write(kvm_arm_running_vcpu, vcpu);
}
@@ -81,7 +80,6 @@ static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
*/
struct kvm_vcpu *kvm_arm_get_running_vcpu(void)
{
- BUG_ON(preemptible());
return __this_cpu_read(kvm_arm_running_vcpu);
}
--
2.14.2
^ permalink raw reply related
* [PATCH v8 2/9] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu
From: Christoffer Dall @ 2017-12-13 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213104602.16383-1-christoffer.dall@linaro.org>
We are about to distinguish between userspace accesses and mmio traps
for a number of the mmio handlers. When the requester vcpu is NULL, it
means we are handling a userspace access.
Factor out the functionality to get the request vcpu into its own
function, mostly so we have a common place to document the semantics of
the return value.
Also take the chance to move the functionality outside of holding a
spinlock and instead explicitly disable and enable preemption. This
supports PREEMPT_RT kernels as well.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/vgic/vgic-mmio.c | 44 +++++++++++++++++++++++++++----------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index deb51ee16a3d..fdad95f62fa3 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -122,6 +122,27 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
return value;
}
+/*
+ * This function will return the VCPU that performed the MMIO access and
+ * trapped from within the VM, and will return NULL if this is a userspace
+ * access.
+ *
+ * We can disable preemption locally around accessing the per-CPU variable,
+ * and use the resolved vcpu pointer after enabling preemption again, because
+ * even if the current thread is migrated to another CPU, reading the per-CPU
+ * value later will give us the same value as we update the per-CPU variable
+ * in the preempt notifier handlers.
+ */
+static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
+{
+ struct kvm_vcpu *vcpu;
+
+ preempt_disable();
+ vcpu = kvm_arm_get_running_vcpu();
+ preempt_enable();
+ return vcpu;
+}
+
void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
gpa_t addr, unsigned int len,
unsigned long val)
@@ -184,24 +205,10 @@ unsigned long vgic_mmio_read_active(struct kvm_vcpu *vcpu,
static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
bool new_active_state)
{
- struct kvm_vcpu *requester_vcpu;
unsigned long flags;
- spin_lock_irqsave(&irq->irq_lock, flags);
+ struct kvm_vcpu *requester_vcpu = vgic_get_mmio_requester_vcpu();
- /*
- * The vcpu parameter here can mean multiple things depending on how
- * this function is called; when handling a trap from the kernel it
- * depends on the GIC version, and these functions are also called as
- * part of save/restore from userspace.
- *
- * Therefore, we have to figure out the requester in a reliable way.
- *
- * When accessing VGIC state from user space, the requester_vcpu is
- * NULL, which is fine, because we guarantee that no VCPUs are running
- * when accessing VGIC state from user space so irq->vcpu->cpu is
- * always -1.
- */
- requester_vcpu = kvm_arm_get_running_vcpu();
+ spin_lock_irqsave(&irq->irq_lock, flags);
/*
* If this virtual IRQ was written into a list register, we
@@ -213,6 +220,11 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
* vgic_change_active_prepare) and still has to sync back this IRQ,
* so we release and re-acquire the spin_lock to let the other thread
* sync back the IRQ.
+ *
+ * When accessing VGIC state from user space, requester_vcpu is
+ * NULL, which is fine, because we guarantee that no VCPUs are running
+ * when accessing VGIC state from user space so irq->vcpu->cpu is
+ * always -1.
*/
while (irq->vcpu && /* IRQ may have state in an LR somewhere */
irq->vcpu != requester_vcpu && /* Current thread is not the VCPU thread */
--
2.14.2
^ permalink raw reply related
* [PATCH v8 3/9] KVM: arm/arm64: Don't cache the timer IRQ level
From: Christoffer Dall @ 2017-12-13 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213104602.16383-1-christoffer.dall@linaro.org>
The timer was modeled after a strict idea of modelling an interrupt line
level in software, meaning that only transitions in the level needed to
be reported to the VGIC. This works well for the timer, because the
arch timer code is in complete control of the device and can track the
transitions of the line.
However, as we are about to support using the HW bit in the VGIC not
just for the timer, but also for VFIO which cannot track transitions of
the interrupt line, we have to decide on an interface for level
triggered mapped interrupts to the GIC, which both the timer and VFIO
can use.
VFIO only sees an asserting transition of the physical interrupt line,
and tells the VGIC when that happens. That means that part of the
interrupt flow is offloaded to the hardware.
To use the same interface for VFIO devices and the timer, we therefore
have to change the timer (we cannot change VFIO because it doesn't know
the details of the device it is assigning to a VM).
Luckily, changing the timer is simple, we just need to stop 'caching'
the line level, but instead let the VGIC know the state of the timer
every time there is a potential change in the line level, and when the
line level should be asserted from the timer ISR. The VGIC can ignore
extra notifications using its validate mechanism.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 4151250ce8da..dd5aca05c500 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
}
vtimer = vcpu_vtimer(vcpu);
- if (!vtimer->irq.level) {
- vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
- if (kvm_timer_irq_can_fire(vtimer))
- kvm_timer_update_irq(vcpu, true, vtimer);
- }
+ vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
+ if (kvm_timer_irq_can_fire(vtimer))
+ kvm_timer_update_irq(vcpu, true, vtimer);
if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
kvm_vtimer_update_mask_user(vcpu);
@@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
+ bool level;
if (unlikely(!timer->enabled))
return;
- if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
- kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
+ /*
+ * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
+ * of its lifecycle is offloaded to the hardware, and we therefore may
+ * not have lowered the irq.level value before having to signal a new
+ * interrupt, but have to signal an interrupt every time the level is
+ * asserted.
+ */
+ level = kvm_timer_should_fire(vtimer);
+ kvm_timer_update_irq(vcpu, level, vtimer);
if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
--
2.14.2
^ 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