* [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled
From: Ard Biesheuvel @ 2018-01-04 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-9-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
>
Why does bp hardening require per-cpu vectors?
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/kvm_mmu.h | 10 ++++++++++
> arch/arm64/include/asm/kvm_mmu.h | 38 ++++++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/switch.c | 2 +-
> virt/kvm/arm/arm.c | 8 +++++++-
> 4 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index fa6f2174276b..eb46fc81a440 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -221,6 +221,16 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return 8;
> }
>
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + return kvm_ksym_ref(__kvm_hyp_vector);
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return 0;
> +}
> +
> #endif /* !__ASSEMBLY__ */
>
> #endif /* __ARM_KVM_MMU_H__ */
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 672c8684d5c2..2d6d4bd9de52 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -309,5 +309,43 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return (cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
> }
>
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> +#include <asm/mmu.h>
> +
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + struct bp_hardening_data *data = arm64_get_bp_hardening_data();
> + void *vect = kvm_ksym_ref(__kvm_hyp_vector);
> +
> + if (data->fn) {
> + vect = __bp_harden_hyp_vecs_start +
> + data->hyp_vectors_slot * SZ_2K;
> +
> + if (!has_vhe())
> + vect = lm_alias(vect);
> + }
> +
> + return vect;
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return create_hyp_mappings(kvm_ksym_ref(__bp_harden_hyp_vecs_start),
> + kvm_ksym_ref(__bp_harden_hyp_vecs_end),
> + PAGE_HYP_EXEC);
> +}
> +
> +#else
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + return kvm_ksym_ref(__kvm_hyp_vector);
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return 0;
> +}
> +#endif
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __ARM64_KVM_MMU_H__ */
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index f7c651f3a8c0..8d4f3c9d6dc4 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -52,7 +52,7 @@ static void __hyp_text __activate_traps_vhe(void)
> val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
> write_sysreg(val, cpacr_el1);
>
> - write_sysreg(__kvm_hyp_vector, vbar_el1);
> + write_sysreg(kvm_get_hyp_vector(), vbar_el1);
> }
>
> static void __hyp_text __activate_traps_nvhe(void)
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 6b60c98a6e22..1c9fdb6db124 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1158,7 +1158,7 @@ static void cpu_init_hyp_mode(void *dummy)
> pgd_ptr = kvm_mmu_get_httbr();
> stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
> hyp_stack_ptr = stack_page + PAGE_SIZE;
> - vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
> + vector_ptr = (unsigned long)kvm_get_hyp_vector();
>
> __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
> __cpu_init_stage2();
> @@ -1403,6 +1403,12 @@ static int init_hyp_mode(void)
> goto out_err;
> }
>
> + err = kvm_map_vectors();
> + if (err) {
> + kvm_err("Cannot map vectors\n");
> + goto out_err;
> + }
> +
> /*
> * Map the Hyp stack pages
> */
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()
From: Gary R Hook @ 2018-01-04 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a5dad82-2886-2a51-28bc-b84ab253c361@codeaurora.org>
On 01/04/2018 06:25 AM, Sinan Kaya wrote:
> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>> where a PCI device is present. This restricts the device drivers to be
>> reused for other domain numbers.
>>
>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>> pci_get_domain_bus_and_slot().
>>
>> Hard-code the domain number as 0 for the AMD IOMMU driver.
<snip>
>
> Any comments from the IOMMU people?
>
pci_get_bus_and_slot() appears to (now) be a convenience function that
wraps pci_get_domain_bus_and_slot() while using a 0 for the domain
value. Exactly what you are doing here, albeit in a more overt way.
How is this patch advantageous? Seems to me that if other domains need
to be enabled, that driver could be changed if and when that requirement
arises.
But perhaps I'm missing a nuance here.
^ permalink raw reply
* [PATCH 06/11] arm64: Move post_ttbr_update_workaround to C code
From: Ard Biesheuvel @ 2018-01-04 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-7-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> We will soon need to invoke a CPU-specific function pointer after changing
> page tables, so move post_ttbr_update_workaround out into C code to make
> this possible.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/assembler.h | 13 -------------
> arch/arm64/kernel/entry.S | 2 +-
> arch/arm64/mm/context.c | 9 +++++++++
> arch/arm64/mm/proc.S | 3 +--
> 4 files changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index c45bc94f15d0..cee60ce0da52 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -476,17 +476,4 @@ alternative_endif
> mrs \rd, sp_el0
> .endm
>
> -/*
> - * Errata workaround post TTBRx_EL1 update.
> - */
> - .macro post_ttbr_update_workaround
> -#ifdef CONFIG_CAVIUM_ERRATUM_27456
> -alternative_if ARM64_WORKAROUND_CAVIUM_27456
> - ic iallu
> - dsb nsh
> - isb
> -alternative_else_nop_endif
> -#endif
> - .endm
> -
> #endif /* __ASM_ASSEMBLER_H */
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index b9feb587294d..6aa112baf601 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -277,7 +277,7 @@ alternative_else_nop_endif
> * Cavium erratum 27456 (broadcast TLBI instructions may cause I-cache
> * corruption).
> */
> - post_ttbr_update_workaround
> + bl post_ttbr_update_workaround
> .endif
> 1:
> .if \el != 0
> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
> index 1cb3bc92ae5c..c1e3b6479c8f 100644
> --- a/arch/arm64/mm/context.c
> +++ b/arch/arm64/mm/context.c
> @@ -239,6 +239,15 @@ void check_and_switch_context(struct mm_struct *mm, unsigned int cpu)
> cpu_switch_mm(mm->pgd, mm);
> }
>
> +/* Errata workaround post TTBRx_EL1 update. */
> +asmlinkage void post_ttbr_update_workaround(void)
> +{
> + asm volatile(ALTERNATIVE("nop; nop; nop",
What does 'volatile' add here?
> + "ic iallu; dsb nsh; isb",
> + ARM64_WORKAROUND_CAVIUM_27456,
> + CONFIG_CAVIUM_ERRATUM_27456));
> +}
> +
> static int asids_init(void)
> {
> asid_bits = get_cpu_asid_bits();
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 3146dc96f05b..6affb68a9a14 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -145,8 +145,7 @@ ENTRY(cpu_do_switch_mm)
> isb
> msr ttbr0_el1, x0 // now update TTBR0
> isb
> - post_ttbr_update_workaround
> - ret
> + b post_ttbr_update_workaround // Back to C code...
> ENDPROC(cpu_do_switch_mm)
>
> .pushsection ".idmap.text", "ax"
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 01/11] arm64: use RET instruction for exiting the trampoline
From: Ard Biesheuvel @ 2018-01-04 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-2-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> Speculation attacks against the entry trampoline can potentially resteer
> the speculative instruction stream through the indirect branch and into
> arbitrary gadgets within the kernel.
>
> This patch defends against these attacks by forcing a misprediction
> through the return stack: a dummy BL instruction loads an entry into
> the stack, so that the predicted program flow of the subsequent RET
> instruction is to a branch-to-self instruction which is finally resolved
> as a branch to the kernel vectors with speculation suppressed.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/entry.S | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 031392ee5f47..b9feb587294d 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -1029,6 +1029,9 @@ alternative_else_nop_endif
> .if \regsize == 64
> msr tpidrro_el0, x30 // Restored in kernel_ventry
> .endif
> + bl 2f
> + b .
> +2:
This deserves a comment, I guess?
Also, is deliberately unbalancing the return stack likely to cause
performance problems, e.g., in libc hot paths?
> tramp_map_kernel x30
> #ifdef CONFIG_RANDOMIZE_BASE
> adr x30, tramp_vectors + PAGE_SIZE
> @@ -1041,7 +1044,7 @@ alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> msr vbar_el1, x30
> add x30, x30, #(1b - tramp_vectors)
> isb
> - br x30
> + ret
> .endm
>
> .macro tramp_exit, regsize = 64
> --
> 2.1.4
>
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104160939.GA7785@xora-haswell>
> > I already agreed with 'reg' being awkward in the later emails.
> > Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> >
> Ah it is an actual address, then yes _ADR is probably more appropriate.
Newbie ACPI question. What is the definition of an address?
In this cause, we are talking about an address of a device on an MDIO
bus. It takes a value between 0 and 31.
How are IC2 device addresses represented in ACPI? MDIO devices and I2C
devices are pretty similar. So it would make sense to use the same as
what I2C uses.
Andrew
^ permalink raw reply
* [GIT PULL] ARM: uniphier: fixes for v4.15 (2nd)
From: Arnd Bergmann @ 2018-01-04 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAQodyYzeD9kujN05EQQzfZPwWOq1AmBCvKd2FDnnRF7AQ@mail.gmail.com>
On Fri, Dec 29, 2017 at 1:30 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Arnd, Olof,
>
> This is the 2nd bug-fix pull request for v4.15.
> Just one DT fix. Please pull!
I've ended up cherry-picking that commit manually into the fixes branch:
We haven't updated the fixes branch to a later -rc, and your pull request
was based on -rc3, so pulling it would create an ugly backmerge.
You did nothing wrong here, so it seemed unnecessary to ask you for
a respin based on -rc1. Hope that works for you.
Arnd
^ permalink raw reply
* [PATCH 05/11] drivers/firmware: Expose psci_get_version through psci_ops structure
From: Lorenzo Pieralisi @ 2018-01-04 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-6-git-send-email-will.deacon@arm.com>
On Thu, Jan 04, 2018 at 03:08:29PM +0000, Will Deacon wrote:
> Entry into recent versions of ARM Trusted Firmware will invalidate the CPU
> branch predictor state in order to protect against aliasing attacks.
>
> This patch exposes the PSCI "VERSION" function via psci_ops, so that it
> can be invoked outside of the PSCI driver where necessary.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> drivers/firmware/psci.c | 2 ++
> include/linux/psci.h | 1 +
> 2 files changed, 3 insertions(+)
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index d687ca3d5049..8b25d31e8401 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -496,6 +496,8 @@ static void __init psci_init_migrate(void)
> static void __init psci_0_2_set_functions(void)
> {
> pr_info("Using standard PSCI v0.2 function IDs\n");
> + psci_ops.get_version = psci_get_version;
> +
> psci_function_id[PSCI_FN_CPU_SUSPEND] =
> PSCI_FN_NATIVE(0_2, CPU_SUSPEND);
> psci_ops.cpu_suspend = psci_cpu_suspend;
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index bdea1cb5e1db..6306ab10af18 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -26,6 +26,7 @@ int psci_cpu_init_idle(unsigned int cpu);
> int psci_cpu_suspend_enter(unsigned long index);
>
> struct psci_operations {
> + u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> int (*cpu_off)(u32 state);
> int (*cpu_on)(unsigned long cpuid, unsigned long entry_point);
> --
> 2.1.4
>
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Graeme Gregory @ 2018-01-04 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKcM8WWvh64A=FTtuWkEr6V_QSKjBpNpWnMpp_P=cMU9sw@mail.gmail.com>
On Wed, Jan 03, 2018 at 12:12:06PM +0100, Marcin Wojtas wrote:
> Hi Graeme,
>
> 2018-01-03 12:00 GMT+01:00 Graeme Gregory <graeme.gregory@linaro.org>:
> > On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> >> On 18 December 2017 at 10:17, Marcin Wojtas <mw@semihalf.com> wrote:
> >> > Hi,
> >> >
> >> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> >> > First three patches introduce fwnode helpers for obtaining PHY
> >> > information from nodes and also MDIO fwnode API for registering
> >> > the bus with its PHY/devices.
> >> >
> >> > Following patches update code of the mvmdio and mvpp2 drivers
> >> > to support ACPI tables handling. The latter is done in 4 steps,
> >> > as can be seen in the commits. For the details, please
> >> > refer to the commit messages.
> >> >
> >> > Drivers operation was tested on top of the net-next branch
> >> > with both DT and ACPI. Although for compatibility reasons
> >> > with older platforms, the mvmdio driver keeps using
> >> > of_ MDIO registering, new fwnode_ one proved to fully work
> >> > with DT as well (tested on MacchiatoBin board).
> >> >
> >> > mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> >> > on a public branch:
> >> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> >> > It was compiled together with the most recent Tianocore EDK2 revision.
> >> > Please refer to the firmware build instruction on MacchiatoBin board:
> >> > http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
> >> >
> >> > Above support configures 1G to use its PHY normally. 10G can work now
> >> > only with the link interrupt mode. Somehow reading of the
> >> > string property in fwnode_mdiobus_child_is_phy works only with
> >> > DT and cannot cope with 10G PHY nodes as in:
> >> > https://pastebin.com/3JnYpU0A
> >> >
> >> > Above root cause will be further checked. In the meantime I will
> >> > appreciate any comments or remarks for the kernel patches.
> >> >
> >>
> >> Hi Marcin,
> >>
> >> I have added linux-acpi and Graeme to cc. I think it makes sense to
> >> discuss the way you describe the device topology before looking at the
> >> patches in more detail.
> >>
> >> In particular, I would like to request feedback on the use of
> >> [redundant] 'reg' properties and the use of _DSD + compatible to
> >> describe PHYs. Usually, we try to avoid this, given that it is
> >> essentially a ACPI encapsulated DT dialect that is difficult to
> >> support in drivers unless they are based on DT to begin with. Also,
> >> non-standard _DSD properties require a vendor prefix, it is not
> >> freeform.
> >>
> >> For reference, the ACPI description is here (starting at line 175)
> >> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/72d5ac23b20dd74d479daa5e40ba443264b31261/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl
> >>
> > So the representation of PHY's with _DSD was kind of formalised here
> >
> > http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
> >
> > This is already in use in the kernel, and that DSDT seems to be along the same
> > lines. So seems ok in that manner.
> >
> > The "reg", 0 property seems a little odd, it would probably make more
> > sense to check for the lack of ranges passed in in ACPI manner _CRS.
> >
>
> I already agreed with 'reg' being awkward in the later emails.
> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
>
Ah it is an actual address, then yes _ADR is probably more appropriate.
Graeme
-------------- 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/20180104/4dffe9ca/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.15
From: Arnd Bergmann @ 2018-01-04 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228032240.GA2951@wens.csie.org>
On Thu, Dec 28, 2017 at 4:22 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-fixes-for-4.15
>
> for you to fetch changes up to eac6a3639decefcc8eb0941dd3cebe79993670ad:
>
> ARM: dts: sun8i: a711: Reinstate the PMIC compatible (2017-12-19 09:56:57 +0100)
>
> ----------------------------------------------------------------
> Allwinner fixes for 4.15
>
> First, one fix that adds proper regulator references for the EMAC
> external PHYs on A64 boards. The EMAC bindings were developed for 4.13,
> but reverted at the last minute. They were finalized and brought back
> for 4.15. However in the time between, regulator support for the A64
> boards was merged. When EMAC device tree changes were reintroduced,
> this was not taken into account.
>
> Second, a patch that adds OF based modalias uevent for RSB slave devices.
> This has been missing since the introduction of RSB, and recently with
> PMIC regulator support introduced for the A64, has been seen affecting
> distributions, which have the all-important PMIC mfd drivers built as
> modules, which then don't get loaded.
>
> Other minor cleanups include final conversion of raw indices to CCU
> binding macros for sun[4567]i HDMI, cleanup of dummy regulators on the
> A64 SOPINE, a SD card detection polarity fix for the Orange Pi Zero
> Plus2, and adding a missing compatible for the PMIC on the TBS A711
> tablet.
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Fixes for v4.15
From: Arnd Bergmann @ 2018-01-04 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513938447.git.horms+renesas@verge.net.au>
On Fri, Dec 22, 2017 at 11:30 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Renesas ARM Based SoC Fixes for v4.15
>
> Vladimir Zapolskiy says:
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the change is also a safety improvement because it
> removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Note that DTS files for V3M Starter Kit, Draak and Eagle boards
> contain the same property, the files are untouched due to unavailable
> schematics to verify if the fix applies to these boards as well.
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Andy Shevchenko @ 2018-01-04 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e985f68-5887-b0d5-8c45-e22b5d8f60cf@codeaurora.org>
On Thu, 2018-01-04 at 09:46 -0600, Timur Tabi wrote:
> On 12/21/2017 07:46 PM, Stephen Boyd wrote:
> >
> > Maybe future HIDs could follow the DT design and then we can look
> > for the same device property name in both firmwares.
>
> DSDs generally don't have the vendor prefix that DT properties do.
There are more means to check hardware revisions:
HID - Hardware ID
CID - Compatible ID
UID - Unique ID (good to distinguish instances of the same device on the
board)
_HRV - Hardware Revision (6.1.6 describes this one)
Everything is described in the spec. Does anybody care to read?
P.S. More I reading this thread more I become thinking that people screw
ACPI use in many ways...
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v2] soc: Add SoC driver for Gemini
From: Arnd Bergmann @ 2018-01-04 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221231908.9664-1-linus.walleij@linaro.org>
On Fri, Dec 22, 2017 at 12:19 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> This adds an SoC driver for the Gemini. Currently there
> is only one thing not fitting into any other framework,
> and that is the bus arbitration setting.
>
> All Gemini vendor trees seem to be setting this register to
> exactly the same arbitration so we just add a small code
> snippet to do this at subsys_init() time before any other
> drivers kick in.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Add a multiplatform guard, bail out silently if we are not
> running on Gemini.
>
> ARM SoC folks: please just apply this patch directly somewhere
> if you're pleased with it, it is fully idependent.
Applied to next/soc, thanks!
> Arnd wanted some rewording of the commit message but I can't
> figure out what, please entertain yourself editing it any way
> you like :)
The patch commit message is fine, the part I wanted to have
reworded was the "SoC driver for the Gemini. See the commit
for details." text in the pull request that did not seem right as
a git changelog message. As I applied the patch by itself now,
it's all good.
Arnd
^ permalink raw reply
* [PATCH 08/11] drm/sun4i: Add support for A83T second DE2 mixer
From: Maxime Ripard @ 2018-01-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-9-jernej.skrabec@siol.net>
On Sat, Dec 30, 2017 at 10:02:00PM +0100, Jernej Skrabec wrote:
> It supports 1 VI and 1 UI plane and HW scaling on both planes.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
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/20180104/a550298e/attachment-0001.sig>
^ permalink raw reply
* [PATCH 07/11] drm/sun4i: Add support for A83T second TCON
From: Maxime Ripard @ 2018-01-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-8-jernej.skrabec@siol.net>
Hi,
On Sat, Dec 30, 2017 at 10:01:59PM +0100, Jernej Skrabec wrote:
> This TCON doesn't have channel 0, so quirk has_channel_0 is added in the
> process.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Ideally, this should be split in two patches, one to add the new flag,
and one to add the support for the A83t TCON-TV.
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/20180104/f97ff576/attachment.sig>
^ permalink raw reply
* [PATCH v2 09/12] drm/sun4i: backend: Add a custom atomic_check for the frontend
From: Chen-Yu Tsai @ 2018-01-04 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c6cddb9eb16a8c4bdab2e66c072b2bc9a10fcd4.1513609024.git-series.maxime.ripard@free-electrons.com>
On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Now that we have everything in place, we can start enabling the frontend.
> This is more difficult than one would assume since there can only be one
> plane using the frontend per-backend.
>
> We therefore need to make sure that the userspace will not try to setup
> multiple planes using it, since that would be impossible. In order to
> prevent that, we can create an atomic_check callback that will check that
> only one plane will effectively make use of the frontend in a given
> configuration, and will toggle the switch in that plane state so that the
> proper setup function can do their role.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 08/12] drm/sun4i: backend: Wire in the frontend
From: Chen-Yu Tsai @ 2018-01-04 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9e8c0ce7192dc9ec59da6906e8f6e8f282ac3809.1513609024.git-series.maxime.ripard@free-electrons.com>
On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Now that we have a driver, we can make use of it. This is done by
> adding a flag to our custom plane state that will trigger whether we should
> use the frontend on that particular plane or not.
>
> The rest is just plumbing to set up the backend to not perform the DMA but
> receive its data from the frontend.
>
> Note that we're still not making any use of the frontend itself, as no one
> is setting the flag yet.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 90 ++++++++++++++++++++++++++++-
> drivers/gpu/drm/sun4i/sun4i_backend.h | 8 ++-
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 1 +-
> drivers/gpu/drm/sun4i/sun4i_layer.c | 33 +++++++++-
> drivers/gpu/drm/sun4i/sun4i_layer.h | 1 +-
> 5 files changed, 130 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index f971d3fb5ee4..29e1ca7e01fe 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -26,6 +26,7 @@
>
> #include "sun4i_backend.h"
> #include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
> #include "sun4i_layer.h"
> #include "sunxi_engine.h"
>
> @@ -203,6 +204,30 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend *backend,
> return 0;
> }
>
> +int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
> + int layer, uint32_t fmt)
> +{
> + u32 val;
> + int ret;
> +
> + ret = sun4i_backend_drm_format_to_layer(NULL, fmt, &val);
> + if (ret) {
> + DRM_DEBUG_DRIVER("Invalid format\n");
> + return ret;
> + }
> +
> + regmap_update_bits(backend->engine.regs,
> + SUN4I_BACKEND_ATTCTL_REG0(layer),
> + SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN,
> + SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN);
You also need to select which frontend to use by setting LAY_VDOSEL.
> +
> + regmap_update_bits(backend->engine.regs,
> + SUN4I_BACKEND_ATTCTL_REG1(layer),
> + SUN4I_BACKEND_ATTCTL_REG1_LAY_FBFMT, val);
> +
> + return 0;
> +}
> +
> int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
> int layer, struct drm_plane *plane)
> {
> @@ -246,6 +271,36 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
> return 0;
> }
>
> +static void sun4i_backend_vblank_quirk(struct sunxi_engine *engine)
> +{
> + struct sun4i_backend *backend = engine_to_sun4i_backend(engine);
> + struct sun4i_frontend *frontend = backend->frontend;
> +
> + if (!frontend)
> + return;
> +
> + /*
> + * In a teardown scenario with the frontend involved, we have
> + * to keep the frontend enabled until the next vblank, and
> + * only then disable it.
> + *
> + * This is due to the fact that the backend will not take into
> + * account the new configuration (with the plane that used to
> + * be fed by the frontend now disabled) until we write to the
> + * commit bit and the hardware fetches the new configuration
> + * during the next vblank.
> + *
> + * So we keep the frontend around in order to prevent any
> + * visual artifacts.
> + */
> + spin_lock(&backend->frontend_lock);
> + if (backend->frontend_teardown) {
> + sun4i_frontend_exit(frontend);
> + backend->frontend_teardown = false;
> + }
> + spin_unlock(&backend->frontend_lock);
> +};
> +
> static int sun4i_backend_init_sat(struct device *dev) {
> struct sun4i_backend *backend = dev_get_drvdata(dev);
> int ret;
> @@ -330,11 +385,40 @@ static int sun4i_backend_of_get_id(struct device_node *node)
> return ret;
> }
>
> +static struct sun4i_frontend *sun4i_backend_find_frontend(struct sun4i_drv *drv,
> + struct device_node *node)
> +{
> + struct device_node *port, *ep, *remote;
> + struct sun4i_frontend *frontend;
> +
> + port = of_graph_get_port_by_id(node, 0);
> + if (!port)
> + return ERR_PTR(-EINVAL);
> +
> + for_each_available_child_of_node(port, ep) {
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote)
> + continue;
> +
> + /* does this node match any registered engines? */
> + list_for_each_entry(frontend, &drv->frontend_list, list) {
> + if (remote == frontend->node) {
> + of_node_put(remote);
> + of_node_put(port);
> + return frontend;
This would return the same frontend for both backends in a dual pipeline setup.
Remember that we now have cross-connecting links between frontends and backends
of both pipelines.
Instead just match the frontend's ID to the backend's ID. BTW I think you left
out the ID thing in the frontend driver.
The rest looks good.
ChenYu
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2018-01-04 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222014633.GD7997@codeaurora.org>
On 12/21/2017 07:46 PM, Stephen Boyd wrote:
> Ok. That's testable with acpi_match_device_ids() though. I can
> add that into pinctrl-msm.c so we don't have to pass info about
> available gpios from ACPI specific driver into the pinctrl-msm
> core driver. That's why I'm trying to avoid doing it in the ACPI
> specific driver. Do it close to where the gpiochip is created
> instead.
I guess we're just going to have to agree to disagree. I see the DSDs
as being SOC-specific, and therefore belong in the SOC driver. I'm
still going to need an SOC driver to define the TLMM register layout.
But as I said earlier, I've already spent way too much time working on a
driver that, in all likelihood, never be used in any production system
anyway.
I look forward to reviewing the next version of your patch.
> Maybe future HIDs could follow the DT design and then we can look
> for the same device property name in both firmwares.
DSDs generally don't have the vendor prefix that DT properties do.
> Parsing
> ranges is simpler.
I'm not sure I agree with that.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 02/11] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry
From: Christoph Hellwig @ 2018-01-04 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-3-git-send-email-will.deacon@arm.com>
On Thu, Jan 04, 2018 at 03:08:26PM +0000, Will Deacon wrote:
> Although CONFIG_UNMAP_KERNEL_AT_EL0 does make KASLR more robust, it's
> actually more useful as a mitigation against speculation attacks that
> can leak arbitrary kernel data to userspace through speculation.
>
> Reword the Kconfig help message to reflect this, and make the option
> depend on EXPERT so that it is on by default for the majority of users.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Why is this not reusing the PAGE_TABLE_ISOLATION setting in
security/Kconfig ?
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: select the CONFIG_CPUFREQ_DT
From: Anson Huang @ 2018-01-04 15:36 UTC (permalink / raw)
To: linux-arm-kernel
Select CONFIG_CPUFREQ_DT by default to enable
cpu-freq driver for i.MX7D.
The rest changes are generated by "make savedefconfig".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 0d44949..d4c8f35 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -48,9 +48,7 @@ CONFIG_PCI_IMX6=y
CONFIG_SMP=y
CONFIG_ARM_PSCI=y
CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_AEABI=y
CONFIG_HIGHMEM=y
-CONFIG_CMA=y
CONFIG_FORCE_MAX_ZONEORDER=14
CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
CONFIG_KEXEC=y
@@ -59,6 +57,7 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPUFREQ_DT=y
CONFIG_ARM_IMX6Q_CPUFREQ=y
CONFIG_CPU_IDLE=y
CONFIG_VFP=y
@@ -81,7 +80,6 @@ CONFIG_CAN_FLEXCAN=y
CONFIG_BT=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
-CONFIG_BT_HCIUART_LL=y
CONFIG_CFG80211=y
CONFIG_CFG80211_WEXT=y
CONFIG_MAC80211=y
@@ -90,7 +88,6 @@ CONFIG_RFKILL_INPUT=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
-CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=64
CONFIG_IMX_WEIM=y
CONFIG_CONNECTOR=y
@@ -167,9 +164,9 @@ CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ADS7846=y
CONFIG_TOUCHSCREEN_EGALAX=y
+CONFIG_TOUCHSCREEN_MAX11801=y
CONFIG_TOUCHSCREEN_IMX6UL_TSC=y
CONFIG_TOUCHSCREEN_EDT_FT5X06=y
-CONFIG_TOUCHSCREEN_MAX11801=y
CONFIG_TOUCHSCREEN_MC13783=y
CONFIG_TOUCHSCREEN_TSC2004=y
CONFIG_TOUCHSCREEN_TSC2007=y
@@ -178,7 +175,6 @@ CONFIG_TOUCHSCREEN_SX8654=y
CONFIG_TOUCHSCREEN_COLIBRI_VF50=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MMA8450=y
-CONFIG_HID_MULTITOUCH=y
CONFIG_SERIO_SERPORT=m
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_IMX=y
@@ -210,7 +206,6 @@ CONFIG_POWER_RESET_SYSCON_POWEROFF=y
CONFIG_POWER_SUPPLY=y
CONFIG_SENSORS_GPIO_FAN=y
CONFIG_SENSORS_IIO_HWMON=y
-CONFIG_THERMAL=y
CONFIG_THERMAL_WRITABLE_TRIPS=y
CONFIG_CPU_THERMAL=y
CONFIG_IMX_THERMAL=y
@@ -228,13 +223,13 @@ CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_MC13783=y
CONFIG_REGULATOR_MC13892=y
CONFIG_REGULATOR_PFUZE100=y
+CONFIG_RC_CORE=y
+CONFIG_RC_DEVICES=y
+CONFIG_IR_GPIO_CIR=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
-CONFIG_RC_CORE=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
-CONFIG_RC_DEVICES=y
-CONFIG_IR_GPIO_CIR=y
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_V4L_PLATFORM_DRIVERS=y
@@ -245,7 +240,6 @@ CONFIG_VIDEO_CODA=m
# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
CONFIG_VIDEO_ADV7180=m
CONFIG_VIDEO_OV5640=m
-CONFIG_SOC_CAMERA_OV2640=y
CONFIG_IMX_IPUV3_CORE=y
CONFIG_DRM=y
CONFIG_DRM_PANEL_SIMPLE=y
@@ -283,6 +277,7 @@ CONFIG_SND_SOC_CS42XX8_I2C=y
CONFIG_SND_SOC_TLV320AIC3X=y
CONFIG_SND_SOC_WM8960=y
CONFIG_SND_SIMPLE_CARD=y
+CONFIG_HID_MULTITOUCH=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_MXC=y
--
1.9.1
^ permalink raw reply related
* [PATCH v2 07/12] drm/sun4i: Add a driver for the display frontend
From: Chen-Yu Tsai @ 2018-01-04 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78c17058b8a38a4e38005aec451dd22e9a329e05.1513609024.git-series.maxime.ripard@free-electrons.com>
On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The display frontend is an hardware block that can be used to implement
> some more advanced features like hardware scaling or colorspace
> conversions. It can also be used to implement the output format of the VPU.
>
> Let's create a minimal driver for it that will only enable the hardware
> scaling features.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/sun4i/Makefile | 3 +-
> drivers/gpu/drm/sun4i/sun4i_drv.c | 16 +-
> drivers/gpu/drm/sun4i/sun4i_drv.h | 1 +-
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 392 ++++++++++++++++++++++++++-
> drivers/gpu/drm/sun4i/sun4i_frontend.h | 96 ++++++-
> 5 files changed, 503 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_frontend.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 0c2f8c7facae..b660d82011f4 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> sun4i-backend-y += sun4i_backend.o sun4i_layer.o
> +sun4i-frontend-y += sun4i_frontend.o
>
> sun4i-drm-y += sun4i_drv.o
> sun4i-drm-y += sun4i_framebuffer.o
> @@ -21,6 +22,6 @@ obj-$(CONFIG_DRM_SUN4I) += sun4i-tcon.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
> obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
>
> -obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o
> +obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o sun4i-frontend.o
> obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
> obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 75c76cdd82bc..17bf9bfd98ba 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -98,6 +98,7 @@ static int sun4i_drv_bind(struct device *dev)
> goto free_drm;
> }
> drm->dev_private = drv;
> + INIT_LIST_HEAD(&drv->frontend_list);
> INIT_LIST_HEAD(&drv->engine_list);
> INIT_LIST_HEAD(&drv->tcon_list);
>
> @@ -239,9 +240,11 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> int count = 0;
>
> /*
> - * We don't support the frontend for now, so we will never
> - * have a device bound. Just skip over it, but we still want
> - * the rest our pipeline to be added.
> + * The frontend has been disabled in all of our old device
Not quite... I left them enabled in all the ones I did (A10/A20/A31)...
> + * trees. If we find a node that is the frontend and is
> + * disabled, we should just follow through and parse its
> + * child, but without adding it to the component list.
> + * Otherwise, we obviously want to add it to the list.
> */
> if (!sun4i_drv_node_is_frontend(node) &&
> !of_device_is_available(node))
> @@ -254,7 +257,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> if (sun4i_drv_node_is_connector(node))
> return 0;
>
> - if (!sun4i_drv_node_is_frontend(node)) {
> + /*
> + * If the device is either just a regular device, or an
> + * enabled frontend, we add it to our component list.
> + */
> + if (!sun4i_drv_node_is_frontend(node) ||
> + (sun4i_drv_node_is_frontend(node) && of_device_is_available(node))) {
> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %pOF\n", node);
> drm_of_component_match_add(dev, match, compare_of, node);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h b/drivers/gpu/drm/sun4i/sun4i_drv.h
> index a960c89270cc..9c26a345f85c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> @@ -19,6 +19,7 @@
>
> struct sun4i_drv {
> struct list_head engine_list;
> + struct list_head frontend_list;
> struct list_head tcon_list;
>
> struct drm_fbdev_cma *fbdev;
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> new file mode 100644
> index 000000000000..fb3e96ab57f7
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> @@ -0,0 +1,392 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Free Electrons
> + * Maxime Ripard <maxime.ripard@free-electrons.com>
> + */
> +#include <drm/drmP.h>
> +#include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_fb_cma_helper.h>
> +
> +#include <linux/clk.h>
> +#include <linux/component.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +
> +#include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
> +
> +static const u32 sun4i_frontend_vert_coef[32] = {
> + 0x00004000, 0x000140ff, 0x00033ffe, 0x00043ffd,
> + 0x00063efc, 0xff083dfc, 0x000a3bfb, 0xff0d39fb,
> + 0xff0f37fb, 0xff1136fa, 0xfe1433fb, 0xfe1631fb,
> + 0xfd192ffb, 0xfd1c2cfb, 0xfd1f29fb, 0xfc2127fc,
> + 0xfc2424fc, 0xfc2721fc, 0xfb291ffd, 0xfb2c1cfd,
> + 0xfb2f19fd, 0xfb3116fe, 0xfb3314fe, 0xfa3611ff,
> + 0xfb370fff, 0xfb390dff, 0xfb3b0a00, 0xfc3d08ff,
> + 0xfc3e0600, 0xfd3f0400, 0xfe3f0300, 0xff400100,
> +};
> +
> +static const u32 sun4i_frontend_horz_coef[64] = {
> + 0x40000000, 0x00000000, 0x40fe0000, 0x0000ff03,
> + 0x3ffd0000, 0x0000ff05, 0x3ffc0000, 0x0000ff06,
> + 0x3efb0000, 0x0000ff08, 0x3dfb0000, 0x0000ff09,
> + 0x3bfa0000, 0x0000fe0d, 0x39fa0000, 0x0000fe0f,
> + 0x38fa0000, 0x0000fe10, 0x36fa0000, 0x0000fe12,
> + 0x33fa0000, 0x0000fd16, 0x31fa0000, 0x0000fd18,
> + 0x2ffa0000, 0x0000fd1a, 0x2cfa0000, 0x0000fc1e,
> + 0x29fa0000, 0x0000fc21, 0x27fb0000, 0x0000fb23,
> + 0x24fb0000, 0x0000fb26, 0x21fb0000, 0x0000fb29,
> + 0x1ffc0000, 0x0000fa2b, 0x1cfc0000, 0x0000fa2e,
> + 0x19fd0000, 0x0000fa30, 0x16fd0000, 0x0000fa33,
> + 0x14fd0000, 0x0000fa35, 0x11fe0000, 0x0000fa37,
> + 0x0ffe0000, 0x0000fa39, 0x0dfe0000, 0x0000fa3b,
> + 0x0afe0000, 0x0000fa3e, 0x08ff0000, 0x0000fb3e,
> + 0x06ff0000, 0x0000fb40, 0x05ff0000, 0x0000fc40,
> + 0x03ff0000, 0x0000fd41, 0x01ff0000, 0x0000fe42,
> +};
> +
> +static void sun4i_frontend_scaler_init(struct sun4i_frontend *frontend)
> +{
> + int i;
> +
> + for (i = 0; i < 32; i++) {
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZCOEF0_REG(i),
> + sun4i_frontend_horz_coef[2 * i]);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZCOEF0_REG(i),
> + sun4i_frontend_horz_coef[2 * i]);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZCOEF1_REG(i),
> + sun4i_frontend_horz_coef[2 * i + 1]);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZCOEF1_REG(i),
> + sun4i_frontend_horz_coef[2 * i + 1]);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTCOEF_REG(i),
> + sun4i_frontend_vert_coef[i]);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTCOEF_REG(i),
> + sun4i_frontend_vert_coef[i]);
> + }
> +
> + regmap_update_bits(frontend->regs, SUN4I_FRONTEND_FRM_CTRL_REG, BIT(23), BIT(23));
> +}
> +
> +int sun4i_frontend_init(struct sun4i_frontend *frontend)
> +{
> + return pm_runtime_get_sync(frontend->dev);
> +}
> +EXPORT_SYMBOL(sun4i_frontend_init);
> +
> +void sun4i_frontend_exit(struct sun4i_frontend *frontend)
> +{
> + pm_runtime_put(frontend->dev);
> +}
> +EXPORT_SYMBOL(sun4i_frontend_exit);
> +
> +void sun4i_frontend_update_buffer(struct sun4i_frontend *frontend,
> + struct drm_plane *plane)
> +{
> + struct drm_plane_state *state = plane->state;
> + struct drm_framebuffer *fb = state->fb;
> + struct drm_gem_cma_object *gem;
> + dma_addr_t paddr;
> + int bpp;
> +
> + /* Get the physical address of the buffer in memory */
> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> +
> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
> +
> + /* Set the line width */
> + DRM_DEBUG_DRIVER("Frontend stride: %d bytes\n", fb->pitches[0]);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_LINESTRD0_REG,
> + fb->pitches[0]);
> +
> + /* Compute the start of the displayed memory */
> + bpp = fb->format->cpp[0];
> + paddr = gem->paddr + fb->offsets[0];
> + paddr += (state->src_x >> 16) * bpp;
> + paddr += (state->src_y >> 16) * fb->pitches[0];
You can use drm_fb_cma_get_gem_addr(fb, state, 0), instead of open
coding it.
Do we need to convert the address, like with the backend?
> +
> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_BUF_ADDR0_REG, paddr);
> +}
> +EXPORT_SYMBOL(sun4i_frontend_update_buffer);
> +
> +static int sun4i_frontend_drm_format_to_input_fmt(uint32_t fmt, u32 *val)
> +{
> + switch (fmt) {
> + case DRM_FORMAT_ARGB8888:
> + case DRM_FORMAT_XRGB8888:
> + *val = 3;
> + return 0;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int sun4i_frontend_drm_format_to_output_fmt(uint32_t fmt, u32 *val)
> +{
> + switch (fmt) {
> + case DRM_FORMAT_ARGB8888:
> + *val = 2;
> + return 0;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
> + struct drm_plane *plane, uint32_t out_fmt)
> +{
> + struct drm_plane_state *state = plane->state;
> + struct drm_framebuffer *fb = state->fb;
> + u32 out_fmt_val;
> + u32 in_fmt_val;
> + int ret;
> +
> + ret = sun4i_frontend_drm_format_to_input_fmt(fb->format->format,
> + &in_fmt_val);
> + if (ret) {
> + DRM_DEBUG_DRIVER("Invalid input format\n");
> + return ret;
> + }
> +
> + ret = sun4i_frontend_drm_format_to_output_fmt(out_fmt, &out_fmt_val);
> + if (ret) {
> + DRM_DEBUG_DRIVER("Invalid output format\n");
> + return ret;
> + }
> +
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, 0x400);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, 0x400);
> +
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, 0x400);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, 0x400);
> +
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, 0x400);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, 0x400);
I really don't understand any of this. :(
> +
> + regmap_write(frontend->regs, SUN4I_FRONTEND_INPUT_FMT_REG,
> + SUN4I_FRONTEND_INPUT_FMT_DATA_MOD(1) |
> + SUN4I_FRONTEND_INPUT_FMT_DATA_FMT(5) |
> + SUN4I_FRONTEND_INPUT_FMT_PS(1));
> + regmap_write(frontend->regs, SUN4I_FRONTEND_OUTPUT_FMT_REG,
> + SUN4I_FRONTEND_OUTPUT_FMT_DATA_FMT(1));
You don't seem to be using the values you got from the helper functions.
Moreover, they don't match the values you claim to support.
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(sun4i_frontend_update_formats);
> +
> +void sun4i_frontend_update_coord(struct sun4i_frontend *frontend,
> + struct drm_plane *plane)
> +{
> + struct drm_plane_state *state = plane->state;
> +
> + /* Set height and width */
> + DRM_DEBUG_DRIVER("Frontend size W: %u H: %u\n",
> + state->crtc_w, state->crtc_h);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_INSIZE_REG,
> + SUN4I_FRONTEND_INSIZE(state->src_h >> 16,
> + state->src_w >> 16));
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_INSIZE_REG,
> + SUN4I_FRONTEND_INSIZE(state->src_h >> 16,
> + state->src_w >> 16));
Slighty off-topic, but does the kernel provide helpers for 16.16
fixed point arithmetic?
> +
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_OUTSIZE_REG,
> + SUN4I_FRONTEND_OUTSIZE(state->crtc_h, state->crtc_w));
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_OUTSIZE_REG,
> + SUN4I_FRONTEND_OUTSIZE(state->crtc_h, state->crtc_w));
Do you need to set the line stride registers?
> +
> + DRM_DEBUG_DRIVER("Frontend horizontal scaling factor %d.%d\n", 1, 0);
Value doesn't match what is programmed.
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZFACT_REG,
> + state->src_w / state->crtc_w);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZFACT_REG,
> + state->src_w / state->crtc_w);
> +
> + DRM_DEBUG_DRIVER("Frontend vertical scaling factor %d.%d\n", 1, 0);
Neither does this.
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTFACT_REG,
> + state->src_h / state->crtc_h);
> + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTFACT_REG,
> + state->src_h / state->crtc_h);
I don't think you need to program any of the channel 1 registers for
interleaved data.
> +
> + regmap_write_bits(frontend->regs, SUN4I_FRONTEND_FRM_CTRL_REG,
> + SUN4I_FRONTEND_FRM_CTRL_REG_RDY,
> + SUN4I_FRONTEND_FRM_CTRL_REG_RDY);
> +}
> +EXPORT_SYMBOL(sun4i_frontend_update_coord);
> +
> +int sun4i_frontend_enable(struct sun4i_frontend *frontend)
> +{
> + regmap_write_bits(frontend->regs, SUN4I_FRONTEND_FRM_CTRL_REG,
> + SUN4I_FRONTEND_FRM_CTRL_FRM_START,
> + SUN4I_FRONTEND_FRM_CTRL_FRM_START);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(sun4i_frontend_enable);
> +
> +static struct regmap_config sun4i_frontend_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = 0x0a14,
> +};
> +
> +static int sun4i_frontend_bind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sun4i_frontend *frontend;
> + struct drm_device *drm = data;
> + struct sun4i_drv *drv = drm->dev_private;
> + struct resource *res;
> + void __iomem *regs;
> +
> + frontend = devm_kzalloc(dev, sizeof(*frontend), GFP_KERNEL);
> + if (!frontend)
> + return -ENOMEM;
> +
> + dev_set_drvdata(dev, frontend);
> + frontend->dev = dev;
> + frontend->node = dev->of_node;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> +
> + frontend->regs = devm_regmap_init_mmio(dev, regs,
> + &sun4i_frontend_regmap_config);
> + if (IS_ERR(frontend->regs)) {
> + dev_err(dev, "Couldn't create the frontend regmap\n");
> + return PTR_ERR(frontend->regs);
> + }
> +
> + frontend->reset = devm_reset_control_get(dev, NULL);
> + if (IS_ERR(frontend->reset)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(frontend->reset);
> + }
> +
> + frontend->bus_clk = devm_clk_get(dev, "ahb");
> + if (IS_ERR(frontend->bus_clk)) {
> + dev_err(dev, "Couldn't get our bus clock\n");
> + return PTR_ERR(frontend->bus_clk);
> + }
> +
> + frontend->mod_clk = devm_clk_get(dev, "mod");
> + if (IS_ERR(frontend->mod_clk)) {
> + dev_err(dev, "Couldn't get our mod clock\n");
> + return PTR_ERR(frontend->mod_clk);
> + }
> +
> + frontend->ram_clk = devm_clk_get(dev, "ram");
> + if (IS_ERR(frontend->ram_clk)) {
> + dev_err(dev, "Couldn't get our ram clock\n");
> + return PTR_ERR(frontend->ram_clk);
> + }
> +
> + list_add_tail(&frontend->list, &drv->frontend_list);
Maybe force a reset here?
> + pm_runtime_enable(dev);
> +
> + return 0;
> +}
> +
> +static void sun4i_frontend_unbind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct sun4i_frontend *frontend = dev_get_drvdata(dev);
> +
> + list_del(&frontend->list);
> + pm_runtime_force_suspend(dev);
> +}
> +
> +static const struct component_ops sun4i_frontend_ops = {
> + .bind = sun4i_frontend_bind,
> + .unbind = sun4i_frontend_unbind,
> +};
> +
> +static int sun4i_frontend_probe(struct platform_device *pdev)
> +{
> + return component_add(&pdev->dev, &sun4i_frontend_ops);
> +}
> +
> +static int sun4i_frontend_remove(struct platform_device *pdev)
> +{
> + component_del(&pdev->dev, &sun4i_frontend_ops);
> +
> + return 0;
> +}
> +
> +static int sun4i_frontend_runtime_resume(struct device *dev)
> +{
> + struct sun4i_frontend *frontend = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = reset_control_deassert(frontend->reset);
> + if (ret) {
> + dev_err(dev, "Couldn't deassert our reset line\n");
> + return ret;
> + }
> +
> + clk_set_rate(frontend->mod_clk, 300000000);
> +
> + clk_prepare_enable(frontend->bus_clk);
> + clk_prepare_enable(frontend->mod_clk);
> + clk_prepare_enable(frontend->ram_clk);
I wonder if the clocks should be enabled first, so the registers
and internal state gets properly reset?
> +
> + regmap_update_bits(frontend->regs, SUN4I_FRONTEND_EN_REG,
> + SUN4I_FRONTEND_EN_EN,
> + SUN4I_FRONTEND_EN_EN);
> +
You also need to set OUT_PORT_SEL in FRM_CTRL_REG so that frontend1
correctly outputs to backend1, assuming a static mapping.
> + regmap_update_bits(frontend->regs, SUN4I_FRONTEND_BYPASS_REG,
> + SUN4I_FRONTEND_BYPASS_CSC_EN,
> + SUN4I_FRONTEND_BYPASS_CSC_EN);
> +
> + sun4i_frontend_scaler_init(frontend);
> +
> + return 0;
> +}
> +
> +static int sun4i_frontend_runtime_suspend(struct device *dev)
> +{
> + struct sun4i_frontend *frontend = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(frontend->ram_clk);
> + clk_disable_unprepare(frontend->mod_clk);
> + clk_disable_unprepare(frontend->bus_clk);
> +
> + reset_control_assert(frontend->reset);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops sun4i_frontend_pm_ops = {
> + .runtime_resume = sun4i_frontend_runtime_resume,
> + .runtime_suspend = sun4i_frontend_runtime_suspend,
> +};
> +
> +static const struct of_device_id sun4i_frontend_of_table[] = {
> + { .compatible = "allwinner,sun5i-a13-display-frontend" },
> + { .compatible = "allwinner,sun6i-a31-display-frontend" },
What about A10 and A20?
Regards
ChenYu
> + { .compatible = "allwinner,sun8i-a33-display-frontend" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sun4i_frontend_of_table);
> +
> +static struct platform_driver sun4i_frontend_driver = {
> + .probe = sun4i_frontend_probe,
> + .remove = sun4i_frontend_remove,
> + .driver = {
> + .name = "sun4i-frontend",
> + .of_match_table = sun4i_frontend_of_table,
> + .pm = &sun4i_frontend_pm_ops,
> + },
> +};
> +module_platform_driver(sun4i_frontend_driver);
> +
> +MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
> +MODULE_DESCRIPTION("Allwinner A10 Display Engine Frontend Driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h b/drivers/gpu/drm/sun4i/sun4i_frontend.h
> new file mode 100644
> index 000000000000..5adc2c7266bc
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
> @@ -0,0 +1,96 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Free Electrons
> + * Maxime Ripard <maxime.ripard@free-electrons.com>
> + */
> +
> +#ifndef _SUN4I_FRONTEND_H_
> +#define _SUN4I_FRONTEND_H_
> +
> +#include <linux/list.h>
> +
> +#define SUN4I_FRONTEND_EN_REG 0x000
> +#define SUN4I_FRONTEND_EN_EN BIT(0)
> +
> +#define SUN4I_FRONTEND_FRM_CTRL_REG 0x004
> +#define SUN4I_FRONTEND_FRM_CTRL_FRM_START BIT(16)
> +#define SUN4I_FRONTEND_FRM_CTRL_COEF_RDY BIT(1)
> +#define SUN4I_FRONTEND_FRM_CTRL_REG_RDY BIT(0)
> +
> +#define SUN4I_FRONTEND_BYPASS_REG 0x008
> +#define SUN4I_FRONTEND_BYPASS_CSC_EN BIT(1)
> +
> +#define SUN4I_FRONTEND_BUF_ADDR0_REG 0x020
> +
> +#define SUN4I_FRONTEND_LINESTRD0_REG 0x040
> +
> +#define SUN4I_FRONTEND_INPUT_FMT_REG 0x04c
> +#define SUN4I_FRONTEND_INPUT_FMT_DATA_MOD(mod) ((mod) << 8)
> +#define SUN4I_FRONTEND_INPUT_FMT_DATA_FMT(fmt) ((fmt) << 4)
> +#define SUN4I_FRONTEND_INPUT_FMT_PS(ps) (ps)
> +
> +#define SUN4I_FRONTEND_OUTPUT_FMT_REG 0x05c
> +#define SUN4I_FRONTEND_OUTPUT_FMT_DATA_FMT(fmt) (fmt)
> +
> +#define SUN4I_FRONTEND_CH0_INSIZE_REG 0x100
> +#define SUN4I_FRONTEND_INSIZE(h, w) ((((h) - 1) << 16) | (((w) - 1)))
> +
> +#define SUN4I_FRONTEND_CH0_OUTSIZE_REG 0x104
> +#define SUN4I_FRONTEND_OUTSIZE(h, w) ((((h) - 1) << 16) | (((w) - 1)))
> +
> +#define SUN4I_FRONTEND_CH0_HORZFACT_REG 0x108
> +#define SUN4I_FRONTEND_HORZFACT(i, f) (((i) << 16) | (f))
> +
> +#define SUN4I_FRONTEND_CH0_VERTFACT_REG 0x10c
> +#define SUN4I_FRONTEND_VERTFACT(i, f) (((i) << 16) | (f))
> +
> +#define SUN4I_FRONTEND_CH0_HORZPHASE_REG 0x110
> +#define SUN4I_FRONTEND_CH0_VERTPHASE0_REG 0x114
> +#define SUN4I_FRONTEND_CH0_VERTPHASE1_REG 0x118
> +
> +#define SUN4I_FRONTEND_CH1_INSIZE_REG 0x200
> +#define SUN4I_FRONTEND_CH1_OUTSIZE_REG 0x204
> +#define SUN4I_FRONTEND_CH1_HORZFACT_REG 0x208
> +#define SUN4I_FRONTEND_CH1_VERTFACT_REG 0x20c
> +
> +#define SUN4I_FRONTEND_CH1_HORZPHASE_REG 0x210
> +#define SUN4I_FRONTEND_CH1_VERTPHASE0_REG 0x214
> +#define SUN4I_FRONTEND_CH1_VERTPHASE1_REG 0x218
> +
> +#define SUN4I_FRONTEND_CH0_HORZCOEF0_REG(i) (0x400 + i * 4)
> +#define SUN4I_FRONTEND_CH0_HORZCOEF1_REG(i) (0x480 + i * 4)
> +#define SUN4I_FRONTEND_CH0_VERTCOEF_REG(i) (0x500 + i * 4)
> +#define SUN4I_FRONTEND_CH1_HORZCOEF0_REG(i) (0x600 + i * 4)
> +#define SUN4I_FRONTEND_CH1_HORZCOEF1_REG(i) (0x680 + i * 4)
> +#define SUN4I_FRONTEND_CH1_VERTCOEF_REG(i) (0x700 + i * 4)
> +
> +struct clk;
> +struct device_node;
> +struct drm_plane;
> +struct regmap;
> +struct reset_control;
> +
> +struct sun4i_frontend {
> + struct list_head list;
> + struct device *dev;
> + struct device_node *node;
> +
> + struct clk *bus_clk;
> + struct clk *mod_clk;
> + struct clk *ram_clk;
> + struct regmap *regs;
> + struct reset_control *reset;
> +};
> +
> +int sun4i_frontend_init(struct sun4i_frontend *frontend);
> +void sun4i_frontend_exit(struct sun4i_frontend *frontend);
> +int sun4i_frontend_enable(struct sun4i_frontend *frontend);
> +
> +void sun4i_frontend_update_buffer(struct sun4i_frontend *frontend,
> + struct drm_plane *plane);
> +void sun4i_frontend_update_coord(struct sun4i_frontend *frontend,
> + struct drm_plane *plane);
> +int sun4i_frontend_update_formats(struct sun4i_frontend *frontend,
> + struct drm_plane *plane, uint32_t out_fmt);
> +
> +#endif /* _SUN4I_FRONTEND_H_ */
> --
> git-series 0.9.1
^ permalink raw reply
* [PATCH][v2] arm64: Allocate elfcorehdr & crashkernel mem before any reservation
From: Poonam Aggrwal @ 2018-01-04 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Address for both crashkernel memory and elfcorehdr can be assigned
statically. For crashkernel memory it is via crashkernel=SIZE at ADDRESS
and elfcorehdr_addr via by kexec-utils in dump kernel device tree.
So memory should be reserved for both the above areas before any
other memory reservations are done. Otherwise overlaps may happen and
memory allocations will fail leading to failure in booting the
dump capture kernel.
Signed-off-by: Guanhua <guanhua.gao@nxp.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
---
v2:
corrected the email address
reworked based on the discussions:(with Will Deacon and Takahiro)
https://patchwork.kernel.org/patch/10104249/
arch/arm64/mm/init.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 00e7b90..24ce15d 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -453,6 +453,14 @@ void __init arm64_memblock_init(void)
* Register the kernel text, kernel data, initrd, and initial
* pagetables with memblock.
*/
+
+ /* make these the first reservations to avoid chances of
+ * overlap
+ */
+ reserve_elfcorehdr();
+
+ reserve_crashkernel();
+
memblock_reserve(__pa_symbol(_text), _end - _text);
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start) {
@@ -472,10 +480,6 @@ void __init arm64_memblock_init(void)
else
arm64_dma_phys_limit = PHYS_MASK + 1;
- reserve_crashkernel();
-
- reserve_elfcorehdr();
-
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
dma_contiguous_reserve(arm64_dma_phys_limit);
--
2.7.4
^ permalink raw reply related
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
From: Ondřej Jirman @ 2018-01-04 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104140625.5gbeaj5vgetusjlf@flea.lan>
On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ond?ej Jirman wrote:
> > Hello,
> >
> > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > Hi,
> > >
> > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > Ond?ej Jirman <megous@megous.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > > >
> > > > > Test input 0:
> > > > >
> > > > > Control ioctls:
> > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > Standard Controls: 0 Private Controls: 0
> > > >
> > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > did not originally, and I'm not sure you picked up the change from my
> > > > version of the driver. "Not supported" here seems to indicate that it
> > > > does not.
> > > >
> > > > I'd be interested what's the recommended practice here. It sure helps
> > > > with some apps that expect to be able to modify various input controls
> > > > directly on the /dev/video# device. These are then supported out of the
> > > > box.
> > > >
> > > > It's a one-line change. See:
> > > >
> > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > heriting-controls
> > >
> > > I think this is a feature and not affect the driver's main function.
> > > I just focused on making the CSI main function to work properly in
> > > the initial version. Is this feature mandatory or most commonly used?
> >
> > I grepped the platform/ code and it seems, that inheriting controls
> > from subdevs is pretty common for input drivers. (there are varying
> > approaches though, some inherit by hand in the link function, some
> > just register and empty ctrl_handler on the v4l2_dev and leave the
> > rest to the core).
> >
> > Practically, I haven't found a common app that would allow me to enter
> > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > themselves, but it would be better if current controls were available
> > at the /dev/video0 device automatically.
> >
> > It's much simpler for the userspace apps than the alternative, which
> > is trying to identify the correct subdev that is currently
> > associated with the CSI driver at runtime, which is not exactly
> > straightforward and requires much more code, than a few lines in
> > the kernel, that are required to inherit controls:
>
> And it becomes much more complicated once you have the same controls
> on the v4l2 device and subdevice, which is not that uncommon.
Hi Maxime,
I don't think you understand the issue. In your hypothetical situation, if the
CSI device will have any controls in the future, the merging of controls from
subdev will be done automatically anyway, it's not some optional feature.
Also userspace will not get any more complicated than without my proposed change
to the driver. It will be at most the same as without the change if any subdev
controls are masked by the CSI device controls.
This CSI driver has no controls anyway. All my change does is create an empty
handler for future controls of the CSI driver, so that apps can depend on this
merging behavior right now, and not wait until someone adds the first control
to the CSI driver.
regards,
o.j.
>
> Maxime
>
>
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels
From: Eugen Hristev @ 2018-01-04 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229170236.06bf6394@archlinux>
On 29.12.2017 19:02, Jonathan Cameron wrote:
> On Fri, 22 Dec 2017 17:07:19 +0200
> Eugen Hristev <eugen.hristev@microchip.com> wrote:
>
>> The ADC IP supports position and pressure measurements for a touchpad
>> connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure
>> measurement support.
>> Using the inkern API, a driver can request a trigger and read the
>> channel values from the ADC.
>> The implementation provides a trigger named "touch" which can be
>> connected to a consumer driver.
>> Once a driver connects and attaches a pollfunc to this trigger, the
>> configure trigger callback is called, and then the ADC driver will
>> initialize pad measurement.
>> First step is to enable touchscreen 4wire support and enable
>> pen detect IRQ.
>> Once a pen is detected, a periodic trigger is setup to trigger every
>> 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll
>> is called, and the consumer driver is then woke up, and it can read the
>> respective channels for the values : X, and Y for position and pressure
>> channel.
>> Because only one trigger can be active in hardware in the same time,
>> while touching the pad, the ADC will block any attempt to use the
>> triggered buffer. Same, conversions using the software trigger are also
>> impossible (since the periodic trigger is setup).
>> If some driver wants to attach while the trigger is in use, it will
>> also fail.
>> Once the pen is not detected anymore, the trigger is free for use (hardware
>> or software trigger, with or without DMA).
>> Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled.
>>
>> Some parts of this patch are based on initial original work by
>> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
>>
> OK, so comments inline.
>
> What I'm missing currently though is an explanation of why the slightly
> more standard arrangement of using a callback buffer doesn't work here.
> The only addition I think you need to do that is to allow a consumer to
> request a particular trigger. I also think some of the other provisions
> could be handled using standard features and slightly reducing the flexibility.
> I don't know for example if it's useful to allow other channels to be
> read when touch is not in progress or not.
>
> So restrictions:
>
> 1. Touch screen channels can only be read when touch is enabled.
> - use the available_scan_masks to control this. Or the callback that lets
> you do the same dynamically.
> 2. You need to push these channels to your consumer driver.
> - register a callback buffer rather than jumping through the hoops to
> insert your own pollfunc. That will call a function in your
> consumer, providing the data from the 3 channels directly.
> 3. You need to make sure it is using the right driver. For that you
> will I think need a new interface.
>
> Various other comments inline. I may well be missing something as this is
> a fair bit of complex code to read - if so then next version should have
> a clear cover letter describing why this more standard approach can't be
> used.
Hello Jonathan and thanks for the review of my patch series,
before starting and working over the required modifications and
suggestions that you sent me, I want to be a little more explicit about
the design of my implementation.
Hope this will clarify some things, and maybe I can as well understand
better what you have in mind to support this feature set.
Why have I picked a pollfunction: We discussed a while back on the
mailing list that you do not have an inkern mechanism to expose the
triggers to other drivers, and that it may be a good idea to have it for
such kind of actually multi function device, instead of having a MFD
driver, an ADC driver, and an Input driver, all sharing the same
register map, the same IRQ , etc, with some kind of synchronization to
avoid stepping on each other for the hardware resource.
So I considered to expose the trigger by attaching and detaching
pollfunctions to it. Which is the main thing what we use a trigger for.
So, what I had in mind, was to create a consumer driver that will
request triggers from the IIO device just like other drivers request
channels (part which is already done in IIO).
In order to do this I had to somehow wake up the consumer driver when
new data was available from the touchscreen. So, having the IRQ only in
the ADC device, and then on Pen detect and No pen detect just start or
stop the periodic trigger, which needs to be polled. The magic part is
that the consumer driver has a poll function already attached to this
trigger, so the poll function is just called every time we have new
data. The poll function is attached as an irq handler, and then we can
reuse all the read_raw data by using a scheduled work from the consumer
driver, to read the channels.
To do this, the ADC registers a special trigger named "touch trigger"
which is never enabled by the ADC driver. Instead, when a pollfunc is
attached to it, the attach function will also configure it with enabled
state. In the ADC, this means to start the touchscreen functionality. If
the touch is requested, it will standby and wait for pen detect IRQ.
Once we have pen detect, we can use a periodic trigger to sample the
touch data, and poll the "touch" trigger. The consumer driver will wake
up and schedule a work , that will use the standard read raw interface
(inkern) that will read three virtual channels (position + pressure).
They are not actual hardware channels, as the touch information is being
received on channels 0,1,2,3, but reading these virtual channels will
read from different registers inside the ADC IP ( x position, y
position, pressure), do some computations on the data, and feed the
consumer with the values , hiding the behind the scenes hardware
specific calculations.
After trigger is polled , the ADC will resume normal functionality, and
the consumer driver will continue to sleep.
We need to have a periodic trigger to sample the data because the actual
analog to digital conversion inside the IP block needs to be triggered.
The touchscreen data measurements cannot happen in hardware without
being triggered. If I try with a hrtimer to get a periodic IRQ to just
read the data, it will never be ready. The datasheet states that the
touchscreen measurements "will be attached to the conversion sequence".
So the periodic trigger is forcing a conversion sequence. This could be
done with a software trigger as well, but why the hassle to start it
every 2 milliseconds (or other time interval), if we can do it by
periodic trigger ?
Once we get the No pen IRQ, we stop the periodic trigger and it can be
used in another purpose (software or external as of now in the driver,
in the future we can add PWM trigger and Timer trigger)
In short, the ADC in Sama5D2 also supports touchscreen, and in
touchscreen mode , 4 of the channels are being used for this purpose.
This however, doesn't stop the ADC to use the other channels . The
hardware has 12 total single channels and they can be paired to have 6
more differential channels. The only thing that is blocked is the
trigger, but only if the pen is touching (when we start the periodic
trigger to sample the touchscreen). If the pen is not touching, an
external trigger or software trigger can be used without any issues (so
why limit the functionality, if this is available from hardware ?).
Because of the reason I discussed above (touchscreen sequence must be
triggered), we cannot use another trigger in the same time.
I see your idea with the callback buffer and it's worth exploring.
Mainly this series was to actually show you what I had in mind about
supporting the resistive touchscreen, and to give you some actually
working code/patch, so we can discuss based on real implementation, not
just suppositions.
You are right in many of the other comments that you said, and I will
come up with a v2 to this series. For now, I need to know if this is a
good or right direction in which I am going, or I should try to change
all the mechanism to callback buffer ? Or maybe I am totally in a bad
direction ?
The requirements are that the consumer driver needs to be somehow woke
up for every new touch data available, and report to the input
subsystem. As it was done before, the at91 old driver, just creates and
registers an input device by itself, and then reports the position and
touches. I was thinking that with this trigger consumer implementation,
things can be better in terms of subsystem separation and support.
Thanks again and let me know of your thoughts,
Eugen
[...]
^ permalink raw reply
* [PATCH 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Will Deacon @ 2018-01-04 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-1-git-send-email-will.deacon@arm.com>
Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
and can theoretically be attacked by malicious code.
This patch implements a PSCI-based mitigation for these CPUs when available.
The call into firmware will invalidate the branch predictor state, preventing
any malicious entries from affecting other victim contexts.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++
arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
index 06a931eb2673..2b10d52a0321 100644
--- a/arch/arm64/kernel/bpi.S
+++ b/arch/arm64/kernel/bpi.S
@@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
vectors __kvm_hyp_vector
.endr
ENTRY(__bp_harden_hyp_vecs_end)
+ENTRY(__psci_hyp_bp_inval_start)
+ stp x0, x1, [sp, #-16]!
+ stp x2, x3, [sp, #-16]!
+ stp x4, x5, [sp, #-16]!
+ stp x6, x7, [sp, #-16]!
+ stp x8, x9, [sp, #-16]!
+ stp x10, x11, [sp, #-16]!
+ stp x12, x13, [sp, #-16]!
+ stp x14, x15, [sp, #-16]!
+ stp x16, x17, [sp, #-16]!
+ stp x18, x19, [sp, #-16]!
+ mov x0, #0x84000000
+ smc #0
+ ldp x18, x19, [sp], #16
+ ldp x16, x17, [sp], #16
+ ldp x14, x15, [sp], #16
+ ldp x12, x13, [sp], #16
+ ldp x10, x11, [sp], #16
+ ldp x8, x9, [sp], #16
+ ldp x6, x7, [sp], #16
+ ldp x4, x5, [sp], #16
+ ldp x2, x3, [sp], #16
+ ldp x0, x1, [sp], #16
+ENTRY(__psci_hyp_bp_inval_end)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 16ea5c6f314e..cb0fb3796bb8 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -53,6 +53,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data);
#ifdef CONFIG_KVM
+extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+
static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
const char *hyp_vecs_end)
{
@@ -94,6 +96,9 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
spin_unlock(&bp_lock);
}
#else
+#define __psci_hyp_bp_inval_start NULL
+#define __psci_hyp_bp_inval_end NULL
+
static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
const char *hyp_vecs_start,
const char *hyp_vecs_end)
@@ -118,6 +123,21 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
__install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
}
+
+#include <linux/psci.h>
+
+static int enable_psci_bp_hardening(void *data)
+{
+ const struct arm64_cpu_capabilities *entry = data;
+
+ if (psci_ops.get_version)
+ install_bp_hardening_cb(entry,
+ (bp_hardening_cb_t)psci_ops.get_version,
+ __psci_hyp_bp_inval_start,
+ __psci_hyp_bp_inval_end);
+
+ return 0;
+}
#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
#define MIDR_RANGE(model, min, max) \
@@ -261,6 +281,28 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
},
#endif
+#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
+ .enable = enable_psci_bp_hardening,
+ },
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
+ .enable = enable_psci_bp_hardening,
+ },
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
+ .enable = enable_psci_bp_hardening,
+ },
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
+ .enable = enable_psci_bp_hardening,
+ },
+#endif
{
}
};
--
2.1.4
^ permalink raw reply related
* [PATCH 10/11] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75
From: Will Deacon @ 2018-01-04 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-1-git-send-email-will.deacon@arm.com>
Hook up MIDR values for the Cortex-A72 and Cortex-A75 CPUs, since they
will soon need MIDR matches for hardening the branch predictor.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/cputype.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d98261..84385b94e70b 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -79,8 +79,10 @@
#define ARM_CPU_PART_AEM_V8 0xD0F
#define ARM_CPU_PART_FOUNDATION 0xD00
#define ARM_CPU_PART_CORTEX_A57 0xD07
+#define ARM_CPU_PART_CORTEX_A72 0xD08
#define ARM_CPU_PART_CORTEX_A53 0xD03
#define ARM_CPU_PART_CORTEX_A73 0xD09
+#define ARM_CPU_PART_CORTEX_A75 0xD0A
#define APM_CPU_PART_POTENZA 0x000
@@ -94,7 +96,9 @@
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
+#define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A72)
#define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A73)
+#define MIDR_CORTEX_A75 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A75)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
--
2.1.4
^ 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