* [RESEND PATCH 4/4] drm/meson: Add missing VPU init
From: Chris Wilson @ 2017-12-06 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50101688-72c0-565e-bc15-9c229fd1a167@baylibre.com>
Quoting Neil Armstrong (2017-12-06 12:03:59)
> On 06/12/2017 13:02, Chris Wilson wrote:
> > Quoting Neil Armstrong (2017-12-06 11:54:28)
> >> The VPU init misses these configurations values.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> drivers/gpu/drm/meson/meson_drv.c | 9 +++++++++
> >> drivers/gpu/drm/meson/meson_registers.h | 4 ++++
> >> 2 files changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> >> index 3b804fd..f9ad0e9 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.c
> >> +++ b/drivers/gpu/drm/meson/meson_drv.c
> >> @@ -151,6 +151,14 @@ static struct regmap_config meson_regmap_config = {
> >> .max_register = 0x1000,
> >> };
> >>
> >> +static void meson_vpu_init(struct meson_drm *priv)
> >> +{
> >> + writel_relaxed(0x210000, priv->io_base + _REG(VPU_RDARB_MODE_L1C1));
> >> + writel_relaxed(0x10000, priv->io_base + _REG(VPU_RDARB_MODE_L1C2));
> >> + writel_relaxed(0x900000, priv->io_base + _REG(VPU_RDARB_MODE_L2C1));
> >> + writel_relaxed(0x20000, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
> >> +}
> >
> >> diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h
> >> index 2847381..bca8714 100644
> >> --- a/drivers/gpu/drm/meson/meson_registers.h
> >> +++ b/drivers/gpu/drm/meson/meson_registers.h
> >> @@ -1363,6 +1363,10 @@
> >> #define VPU_PROT3_STAT_1 0x277a
> >> #define VPU_PROT3_STAT_2 0x277b
> >> #define VPU_PROT3_REQ_ONOFF 0x277c
> >> +#define VPU_RDARB_MODE_L1C1 0x2790
> >> +#define VPU_RDARB_MODE_L1C2 0x2799
> >
> > Hmm, not naturally aligned for writel. Is the register width correct,
> > address correct, or this really is an unaligned iowrite?
>
> The registers are aligned with the documentation, then are used with the _REG() macro
> to align them with the bus (on top of the file).
Oh, that surprised me.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
^ permalink raw reply
* [PATCH 1/2] arm64: SW PAN: Point saved ttbr0 at the zero page when switching to init_mm
From: Mark Rutland @ 2017-12-06 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512558968-28980-2-git-send-email-will.deacon@arm.com>
Hi Will,
On Wed, Dec 06, 2017 at 11:16:07AM +0000, Will Deacon wrote:
> update_saved_ttbr0 mandates that mm->pgd is not swapper, since swapper
> contains kernel mappings and should never be installed into ttbr0. However,
> this means that callers must avoid passing the init_mm to update_saved_ttbr0
> which in turn can cause the saved ttbr0 value to be out-of-date in the context
> of the idle thread. For example, EFI runtime services may leave the saved ttbr0
> pointing at the EFI page table, and kernel threads may end up with stale
> references to freed page tables.
I think we should s/the idle thread/a kernel thread/ here, since IIUC
this could happen in the context of any kernel thread, and there are
multiple idle threads.
> This patch changes update_saved_ttbr0 so that the init_mm points the saved
> ttbr0 value to the empty zero page, which always exists and never contains
> valid translations. EFI and switch can then call into update_saved_ttbr0
> unconditionally.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Vinayak Menon <vinmenon@codeaurora.org>
> Reported-by: Vinayak Menon <vinmenon@codeaurora.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
I guess this should have:
Fixes: 39bc88e5e38e9b21 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
Otherwise, looks good to me.
Mark.
> ---
> arch/arm64/include/asm/efi.h | 4 +---
> arch/arm64/include/asm/mmu_context.h | 22 +++++++++++++---------
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> index 650344d01124..c4cd5081d78b 100644
> --- a/arch/arm64/include/asm/efi.h
> +++ b/arch/arm64/include/asm/efi.h
> @@ -132,11 +132,9 @@ static inline void efi_set_pgd(struct mm_struct *mm)
> * Defer the switch to the current thread's TTBR0_EL1
> * until uaccess_enable(). Restore the current
> * thread's saved ttbr0 corresponding to its active_mm
> - * (if different from init_mm).
> */
> cpu_set_reserved_ttbr0();
> - if (current->active_mm != &init_mm)
> - update_saved_ttbr0(current, current->active_mm);
> + update_saved_ttbr0(current, current->active_mm);
> }
> }
> }
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index 3257895a9b5e..f7773f90546e 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -174,11 +174,17 @@ enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
> static inline void update_saved_ttbr0(struct task_struct *tsk,
> struct mm_struct *mm)
> {
> - if (system_uses_ttbr0_pan()) {
> - BUG_ON(mm->pgd == swapper_pg_dir);
> - task_thread_info(tsk)->ttbr0 =
> - virt_to_phys(mm->pgd) | ASID(mm) << 48;
> - }
> + u64 ttbr;
> +
> + if (!system_uses_ttbr0_pan())
> + return;
> +
> + if (mm == &init_mm)
> + ttbr = __pa_symbol(empty_zero_page);
> + else
> + ttbr = virt_to_phys(mm->pgd) | ASID(mm) << 48;
> +
> + task_thread_info(tsk)->ttbr0 = ttbr;
> }
> #else
> static inline void update_saved_ttbr0(struct task_struct *tsk,
> @@ -214,11 +220,9 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
> * Update the saved TTBR0_EL1 of the scheduled-in task as the previous
> * value may have not been initialised yet (activate_mm caller) or the
> * ASID has changed since the last run (following the context switch
> - * of another thread of the same process). Avoid setting the reserved
> - * TTBR0_EL1 to swapper_pg_dir (init_mm; e.g. via idle_task_exit).
> + * of another thread of the same process).
> */
> - if (next != &init_mm)
> - update_saved_ttbr0(tsk, next);
> + update_saved_ttbr0(tsk, next);
> }
>
> #define deactivate_mm(tsk,mm) do { } while (0)
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 3/6] cpufreq: sort the drivers in ARM part
From: Gregory CLEMENT @ 2017-12-06 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204091850.iamq5uslv3hv6bez@vireshk-mac-ubuntu>
Hi Viresh,
On lun., d?c. 04 2017, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 01-12-17, 12:25, Gregory CLEMENT wrote:
>> Keep the driver files alphabetically sorted.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> drivers/cpufreq/Makefile | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index 812f9e0d01a3..d762e76887e7 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -53,22 +53,24 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o
>> obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o
>>
>> obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o
>> +obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
>
> Shouldn't we add them in ascending order of the whole config name and not just
> CPPC_CPUFREQ ?
Here it is the object name that are sorted not the CONFIG_ name. So
cppc_cpufreq comes after brcmstb-avs-cpufreq.
Thanks,
Gregory
>
> --
> viresh
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Fabrizio Castro @ 2017-12-06 12:05 UTC (permalink / raw)
To: linux-arm-kernel
Add DT node for the Advanced Power Management Unit (APMU), add the
second CPU core, and use "renesas,apmu" as "enable-method".
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
Dear All,
I am reposting this patch now that its dependecy ("ARM: shmobile: rcar-gen2:
Make sure CNTVOFF is initialized on CA7/15") is part of v4.15-rc1, similarly
to patch "ARM: dts: r8a7794: Add SMP support".
v2:
- rebased against renesas-devel-20171205-v4.15-rc2
Thanks
arch/arm/boot/dts/r8a7745.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index de13e15..0fa7861 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -38,6 +38,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "renesas,apmu";
cpu0: cpu at 0 {
device_type = "cpu";
@@ -49,6 +50,15 @@
next-level-cache = <&L2_CA7>;
};
+ cpu1: cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <1>;
+ clock-frequency = <1000000000>;
+ power-domains = <&sysc R8A7745_PD_CA7_CPU1>;
+ next-level-cache = <&L2_CA7>;
+ };
+
L2_CA7: cache-controller-0 {
compatible = "cache";
cache-unified;
@@ -65,6 +75,12 @@
#size-cells = <2>;
ranges;
+ apmu at e6151000 {
+ compatible = "renesas,r8a7745-apmu", "renesas,apmu";
+ reg = <0 0xe6151000 0 0x188>;
+ cpus = <&cpu0 &cpu1>;
+ };
+
gic: interrupt-controller at f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH 4/4] drm/meson: Add missing VPU init
From: Neil Armstrong @ 2017-12-06 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <151256172859.3497.16672223686685414318@mail.alporthouse.com>
On 06/12/2017 13:02, Chris Wilson wrote:
> Quoting Neil Armstrong (2017-12-06 11:54:28)
>> The VPU init misses these configurations values.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/gpu/drm/meson/meson_drv.c | 9 +++++++++
>> drivers/gpu/drm/meson/meson_registers.h | 4 ++++
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
>> index 3b804fd..f9ad0e9 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.c
>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>> @@ -151,6 +151,14 @@ static struct regmap_config meson_regmap_config = {
>> .max_register = 0x1000,
>> };
>>
>> +static void meson_vpu_init(struct meson_drm *priv)
>> +{
>> + writel_relaxed(0x210000, priv->io_base + _REG(VPU_RDARB_MODE_L1C1));
>> + writel_relaxed(0x10000, priv->io_base + _REG(VPU_RDARB_MODE_L1C2));
>> + writel_relaxed(0x900000, priv->io_base + _REG(VPU_RDARB_MODE_L2C1));
>> + writel_relaxed(0x20000, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
>> +}
>
>> diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h
>> index 2847381..bca8714 100644
>> --- a/drivers/gpu/drm/meson/meson_registers.h
>> +++ b/drivers/gpu/drm/meson/meson_registers.h
>> @@ -1363,6 +1363,10 @@
>> #define VPU_PROT3_STAT_1 0x277a
>> #define VPU_PROT3_STAT_2 0x277b
>> #define VPU_PROT3_REQ_ONOFF 0x277c
>> +#define VPU_RDARB_MODE_L1C1 0x2790
>> +#define VPU_RDARB_MODE_L1C2 0x2799
>
> Hmm, not naturally aligned for writel. Is the register width correct,
> address correct, or this really is an unaligned iowrite?
The registers are aligned with the documentation, then are used with the _REG() macro
to align them with the bus (on top of the file).
Neil
>
>> +#define VPU_RDARB_MODE_L2C1 0x279d
>> +#define VPU_WRARB_MODE_L2C1 0x27a2
>
> Similarly,
> -Chris
>
^ permalink raw reply
* [RESEND PATCH 4/4] drm/meson: Add missing VPU init
From: Chris Wilson @ 2017-12-06 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512561268-29806-5-git-send-email-narmstrong@baylibre.com>
Quoting Neil Armstrong (2017-12-06 11:54:28)
> The VPU init misses these configurations values.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/gpu/drm/meson/meson_drv.c | 9 +++++++++
> drivers/gpu/drm/meson/meson_registers.h | 4 ++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> index 3b804fd..f9ad0e9 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -151,6 +151,14 @@ static struct regmap_config meson_regmap_config = {
> .max_register = 0x1000,
> };
>
> +static void meson_vpu_init(struct meson_drm *priv)
> +{
> + writel_relaxed(0x210000, priv->io_base + _REG(VPU_RDARB_MODE_L1C1));
> + writel_relaxed(0x10000, priv->io_base + _REG(VPU_RDARB_MODE_L1C2));
> + writel_relaxed(0x900000, priv->io_base + _REG(VPU_RDARB_MODE_L2C1));
> + writel_relaxed(0x20000, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
> +}
> diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h
> index 2847381..bca8714 100644
> --- a/drivers/gpu/drm/meson/meson_registers.h
> +++ b/drivers/gpu/drm/meson/meson_registers.h
> @@ -1363,6 +1363,10 @@
> #define VPU_PROT3_STAT_1 0x277a
> #define VPU_PROT3_STAT_2 0x277b
> #define VPU_PROT3_REQ_ONOFF 0x277c
> +#define VPU_RDARB_MODE_L1C1 0x2790
> +#define VPU_RDARB_MODE_L1C2 0x2799
Hmm, not naturally aligned for writel. Is the register width correct,
address correct, or this really is an unaligned iowrite?
> +#define VPU_RDARB_MODE_L2C1 0x279d
> +#define VPU_WRARB_MODE_L2C1 0x27a2
Similarly,
-Chris
^ permalink raw reply
* [PATCH 1/8] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Fabrizio Castro @ 2017-12-06 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <TY1PR06MB089533C44E4B42D647C2CC25C0320@TY1PR06MB0895.apcprd06.prod.outlook.com>
Hello Geert, Simon,
the problems I am seeing are not related to APMU/SMP, I'll send a v2 shortly.
Thanks,
Fab
>
> Hello Geert, Simon,
>
> >
> > As the dependency is in v4.15-rc1, it can be applied now.
> >
>
> we thought exactly the same thing, therefore we rebased and we re-ran our tests, to discover that something broke in between
> versions.
> I'll be in touch once I have more information, but it's a no go for now.
>
> Thanks,
> Fab
>
>
> [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.
[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
* [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT
From: Ard Biesheuvel @ 2017-12-06 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206115134.GZ22781@e103592.cambridge.arm.com>
On 6 December 2017 at 11:51, Dave Martin <Dave.Martin@arm.com> wrote:
> On Tue, Dec 05, 2017 at 06:04:34PM +0000, Ard Biesheuvel wrote:
>> On 5 December 2017 at 12:45, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >
>> >
>> >> On 5 Dec 2017, at 12:28, Dave Martin <Dave.Martin@arm.com> wrote:
>> >>
>> >>> On Mon, Dec 04, 2017 at 12:26:37PM +0000, Ard Biesheuvel wrote:
>> >>> Add a support macro to conditionally yield the NEON (and thus the CPU)
>> >>> that may be called from the assembler code. Given that especially the
>> >>> instruction based accelerated crypto code may use very tight loops, add
>> >>> some parametrization so that the TIF_NEED_RESCHED flag test is only
>> >>> executed every so many loop iterations.
>> >>>
>> >>> In some cases, yielding the NEON involves saving and restoring a non
>> >>> trivial amount of context (especially in the CRC folding algorithms),
>> >>> and so the macro is split into two, and the code in between is only
>> >>> executed when the yield path is taken, allowing the contex to be preserved.
>> >>> The second macro takes a label argument that marks the resume-from-yield
>> >>> path, which should restore the preserved context again.
>> >>>
>> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> >>> ---
>> >>> arch/arm64/include/asm/assembler.h | 50 ++++++++++++++++++++
>> >>> 1 file changed, 50 insertions(+)
>> >>>
>> >>> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
>> >>> index aef72d886677..917b026d3e00 100644
>> >>> --- a/arch/arm64/include/asm/assembler.h
>> >>> +++ b/arch/arm64/include/asm/assembler.h
>> >>> @@ -512,4 +512,54 @@ alternative_else_nop_endif
>> >>> #endif
>> >>> .endm
>> >>>
>> >>> +/*
>> >>> + * yield_neon - check whether to yield to another runnable task from
>> >>> + * kernel mode NEON code (running with preemption disabled)
>> >>> + *
>> >>> + * - Check whether the preempt count is exactly 1, in which case disabling
>> >>> + * preemption once will make the task preemptible. If this is not the case,
>> >>> + * yielding is pointless.
>> >>> + * - Check whether TIF_NEED_RESCHED is set, and if so, disable and re-enable
>> >>> + * kernel mode NEON (which will trigger a reschedule), and branch to the
>> >>> + * yield fixup code at @lbl.
>> >>> + */
>> >>> + .macro yield_neon, lbl:req, ctr, order, stride, loop
>> >>> + yield_neon_pre \ctr, \order, \stride, \loop
>> >>> + yield_neon_post \lbl
>> >>> + .endm
>> >>> +
>> >>> + .macro yield_neon_pre, ctr, order=0, stride, loop=4444f
>> >>> +#ifdef CONFIG_PREEMPT
>> >>> + /*
>> >>> + * With some algorithms, it makes little sense to poll the
>> >>> + * TIF_NEED_RESCHED flag after every iteration, so only perform
>> >>> + * the check every 2^order strides.
>> >>> + */
>> >>> + .if \order > 1
>> >>> + .if (\stride & (\stride - 1)) != 0
>> >>> + .error "stride should be a power of 2"
>> >>> + .endif
>> >>> + tst \ctr, #((1 << \order) * \stride - 1) & ~(\stride - 1)
>> >>> + b.ne \loop
>> >>> + .endif
>> >>
>> >> I'm not sure what baking in this check gives us, and this seems to
>> >> conflate two rather different things: yielding and defining a
>> >> "heartbeat" frequency for the calling code.
>> >>
>> >> Can we separate out the crypto-loop-helper semantics from the yield-
>> >> neon stuff?
>> >>
>> >
>> > Fair enough. I incorporated the check here so it disappears from the code entirely when !CONFIG_PREEMPT, because otherwise, you end up with a sequence that is mispredicted every # iterations without any benefit.
>> > I guess i could macroise that separately though.
>> >
>> >> If we had
>> >>
>> >> if_cond_yield_neon
>> >> // patchup code
>> >> endif_yield_neon
>> >>
>>
>> I like this, but ...
>>
>> >> then the caller is free to conditionally branch over that as appropriate
>> >> like
>> >>
>> >> loop:
>> >> // crypto stuff
>> >> tst x0, #0xf
>> >> b.ne loop
>> >>
>> >> if_cond_yield_neon
>> >> // patchup code
>> >> endif_cond_yield_neon
>> >>
>>
>> I need to put the post patchup code somewhere too. Please refer to the
>> CRC patches for the best examples of this.
>
> I'm not sure I follow. If you need to do something different after
> patchup, can't you either pull that code into the if...endif too, or
> otherwise put a branch before the endif?
>
No, not really.
What I currently have is
> if_cond_yield_neon
> // patchup code
> endif_cond_yield_neon
which is being turned into
get_thread_info x0
ldr w1, [x0, #TSK_TI_PREEMPT]
ldr x0, [x0, #TSK_TI_FLAGS]
cmp w1, #1 // == PREEMPT_OFFSET
csel x0, x0, xzr, eq
tbnz x0, #TIF_NEED_RESCHED, 5555f // needs rescheduling?
4444:
.subsection 1
5555:
// patchup code
bl kernel_neon_end
bl kernel_neon_begin
// post patchup code goes here
b 4444b
.subsection
so what I basically need is a place to put the post patchup code,
unless I open code it and branch to a different label right after
kernel_neon_begin
^ permalink raw reply
* [PATCH 1/3] arm64: KVM: Move CPU ID reg trap setup off the world switch path
From: Dave Martin @ 2017-12-06 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206105300.GK32397@cbox>
On Wed, Dec 06, 2017 at 11:53:00AM +0100, Christoffer Dall wrote:
> On Tue, Dec 05, 2017 at 12:31:51PM +0000, Dave Martin wrote:
> > On Tue, Dec 05, 2017 at 10:09:15AM +0100, Christoffer Dall wrote:
> > > On Fri, Dec 01, 2017 at 03:19:40PM +0000, Dave Martin wrote:
> > > > The HCR_EL2.TID3 flag needs to be set when trapping guest access to
> > > > the CPU ID registers is required. However, the decision about
> > > > whether to set this bit does not need to be repeated at every
> > > > switch to the guest.
> > > >
> > > > Instead, it's sufficient to make this decision once and record the
> > > > outcome.
> > > >
> > > > This patch moves the decision to vcpu_reset_hcr() and records the
> > > > choice made in vcpu->arch.hcr_el2. The world switch code can then
> > > > load this directly when switching to the guest without the need for
> > > > conditional logic on the critical path.
> > > >
> > > > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > > > Suggested-by: Christoffer Dall <christoffer.dall@linaro.org>
> > > > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > >
> > > Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
> > >
> > > >
> > > > ---
> > > >
> > > > Note to maintainers: this was discussed on-list [1] prior to the merge
> > > > window, but this patch implementing the agreed decision hasn't been
> > > > posted previously.
> > > >
> > > > This should be considered a fix for v4.15.
> > >
> > > It's actually easier for me to apply this for v4.16 and base my VHE
> > > optimization patches on it.
> >
> > If you're happy for this optimisation to be missing for v4.15, I'm fine
> > with that.
> >
> > Can I leave it you to pick this up then?
>
> Yes, I applied it to our queue already.
OK, great, thanks
---Dave
^ permalink raw reply
* [RESEND PATCH 4/4] drm/meson: Add missing VPU init
From: Neil Armstrong @ 2017-12-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512561268-29806-1-git-send-email-narmstrong@baylibre.com>
The VPU init misses these configurations values.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/gpu/drm/meson/meson_drv.c | 9 +++++++++
drivers/gpu/drm/meson/meson_registers.h | 4 ++++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 3b804fd..f9ad0e9 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -151,6 +151,14 @@ static struct regmap_config meson_regmap_config = {
.max_register = 0x1000,
};
+static void meson_vpu_init(struct meson_drm *priv)
+{
+ writel_relaxed(0x210000, priv->io_base + _REG(VPU_RDARB_MODE_L1C1));
+ writel_relaxed(0x10000, priv->io_base + _REG(VPU_RDARB_MODE_L1C2));
+ writel_relaxed(0x900000, priv->io_base + _REG(VPU_RDARB_MODE_L2C1));
+ writel_relaxed(0x20000, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
+}
+
static int meson_drv_bind_master(struct device *dev, bool has_components)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -222,6 +230,7 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
/* Hardware Initialization */
+ meson_vpu_init(priv);
meson_venc_init(priv);
meson_vpp_init(priv);
meson_viu_init(priv);
diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h
index 2847381..bca8714 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -1363,6 +1363,10 @@
#define VPU_PROT3_STAT_1 0x277a
#define VPU_PROT3_STAT_2 0x277b
#define VPU_PROT3_REQ_ONOFF 0x277c
+#define VPU_RDARB_MODE_L1C1 0x2790
+#define VPU_RDARB_MODE_L1C2 0x2799
+#define VPU_RDARB_MODE_L2C1 0x279d
+#define VPU_WRARB_MODE_L2C1 0x27a2
/* osd super scale */
#define OSDSR_HV_SIZEIN 0x3130
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH 3/4] drm/meson: dw_hdmi: Add support for an optional external 5V regulator
From: Neil Armstrong @ 2017-12-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512561268-29806-1-git-send-email-narmstrong@baylibre.com>
On reference boards and derivatives, the HDMI Logic is powered by an external
5V regulator.
This regulator was set by the Vendor U-Boot, add optional support for it.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index cef4144..17de3af 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -23,6 +23,7 @@
#include <linux/of_graph.h>
#include <linux/reset.h>
#include <linux/clk.h>
+#include <linux/regulator/consumer.h>
#include <drm/drmP.h>
#include <drm/drm_edid.h>
@@ -137,6 +138,7 @@ struct meson_dw_hdmi {
struct reset_control *hdmitx_phy;
struct clk *hdmi_pclk;
struct clk *venci_clk;
+ struct regulator *hdmi_supply;
u32 irq_stat;
};
#define encoder_to_meson_dw_hdmi(x) \
@@ -751,6 +753,17 @@ static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
dw_plat_data = &meson_dw_hdmi->dw_plat_data;
encoder = &meson_dw_hdmi->encoder;
+ meson_dw_hdmi->hdmi_supply = devm_regulator_get_optional(dev, "hdmi");
+ if (IS_ERR(meson_dw_hdmi->hdmi_supply)) {
+ if (PTR_ERR(meson_dw_hdmi->hdmi_supply) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ meson_dw_hdmi->hdmi_supply = NULL;
+ } else {
+ ret = regulator_enable(meson_dw_hdmi->hdmi_supply);
+ if (ret)
+ return ret;
+ }
+
meson_dw_hdmi->hdmitx_apb = devm_reset_control_get_exclusive(dev,
"hdmitx_apb");
if (IS_ERR(meson_dw_hdmi->hdmitx_apb)) {
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH 2/4] dt-bindings: display: amlogic, meson-dw-hdmi: Add optional HDMI 5V regulator
From: Neil Armstrong @ 2017-12-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512561268-29806-1-git-send-email-narmstrong@baylibre.com>
On reference boards and derivatives, the HDMI Logic is powered by an external
5V regulator.
This regulator was set by the Vendor U-Boot, add optional support for it.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
index 7f040ed..bf4a180 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
@@ -48,6 +48,10 @@ Required properties:
Documentation/devicetree/bindings/reset/reset.txt,
the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
+Optional properties:
+- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI
+ logic, as described in the file ../regulator/regulator.txt
+
Required nodes:
The connections to the HDMI ports are modeled using the OF graph
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH 1/4] dt-bindings: display: amlogic, meson-vpu: Add optional power domain property
From: Neil Armstrong @ 2017-12-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512561268-29806-1-git-send-email-narmstrong@baylibre.com>
The Video Processing Unit power domain was setup by the Vendor U-Boot,
add support for an optional Power Domain phandle to setup it from the kernel.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
index 00f74ba..057b813 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
@@ -64,6 +64,10 @@ Required properties:
- reg-names: should contain the names of the previous memory regions
- interrupts: should contain the VENC Vsync interrupt number
+Optional properties:
+- power-domains: Optional phandle to associated power domain as described in
+ the file ../power/power_domain.txt
+
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph
--
2.7.4
^ permalink raw reply related
* [RESEND PATCH 0/4] drm/meson: power domain init related fixes
From: Neil Armstrong @ 2017-12-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
On the Amlogic Gx SoCs (GXBB, GXL & GXM), the VPU power domain is initialized
by the vendor U-Boot code, but running mainline U-boot has been possible
on these SoCs. But lacking such init made the system lock at kernel boot.
A PM Power Domain driver has been pushed at [1] to solve the main issue.
The following patches :
- updates the DT bindings accordingly
- adds support for missing regulators and registers init
Neil Armstrong (4):
dt-bindings: display: amlogic,meson-vpu: Add optional power domain
property
dt-bindings: display: amlogic,meson-dw-hdmi: Add optional HDMI 5V
regulator
drm/meson: dw_hdmi: Add support for an optional external 5V regulator
drm/meson: Add missing VPU init
.../devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 4 ++++
.../devicetree/bindings/display/amlogic,meson-vpu.txt | 4 ++++
drivers/gpu/drm/meson/meson_drv.c | 9 +++++++++
drivers/gpu/drm/meson/meson_dw_hdmi.c | 13 +++++++++++++
drivers/gpu/drm/meson/meson_registers.h | 4 ++++
5 files changed, 34 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH] arm64: fpsimd: Prevent registers leaking from dead tasks
From: Dave Martin @ 2017-12-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9i_XXxN08BMzV7LRFnMpsqA5TGdNTgwrihNGA3J2r7hQ@mail.gmail.com>
On Wed, Dec 06, 2017 at 09:57:15AM +0000, Ard Biesheuvel wrote:
> On 5 December 2017 at 14:56, Dave Martin <Dave.Martin@arm.com> wrote:
[...]
> > This patch fixes the problem by ensuring that the sched-in check
> > fails in (5): fpsimd_flush_task_state(T) is called when T is
> > forked, so that T->thread.fpsimd_state.cpu == C cannot be true.
> > This relies on the fact that T is not schedulable until after
> > copy_thread() completes.
> >
> > Once T's fpsimd state has been loaded on some CPU C there may still
> > be other cpus D for which per_cpu(fpsimd_last_state, D) ==
> > &X->thread.fpsimd_state. But D is necessarily != C in this case,
> > and the check in (5) must fail.
> >
> > An alternative fix would be to do refcounting on task_struct. This
> > would result in each CPU holding a reference to the last task whose
> > fpsimd state was loaded there. It's not clear whether this is
> > preferable, and it involves higher overhead than the fix proposed
> > in this patch. It would also moves all the task_struct freeing
>
> move
>
> > work into the context switch critical section, or otherwise some
> > deferred cleanup mechanism would need to be introduced, neither of
> > which seems obviously justified.
> >
> > Fixes: 005f78cd8849 ("arm64: defer reloading a task's FPSIMD state to userland resume")
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm64/kernel/process.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index b2adcce..5387d15 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -313,6 +313,7 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
> > */
> > clear_tsk_thread_flag(p, TIF_SVE);
> > p->thread.sve_state = NULL;
> > + fpsimd_flush_task_state(p);
> >
> > if (likely(!(p->flags & PF_KTHREAD))) {
> > *childregs = *current_pt_regs();
> > --
> > 2.1.4
> >
>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Thanks
---Dave
^ permalink raw reply
* [PATCH 2/6] cpufreq: ARM: sort the Kconfig menu
From: Gregory CLEMENT @ 2017-12-06 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204084124.mchpmw3kta5tddgh@vireshk-mac-ubuntu>
Hi Viresh,
On lun., d?c. 04 2017, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 01-12-17, 12:25, Gregory CLEMENT wrote:
>> +config ARM_VEXPRESS_SPC_CPUFREQ
>> + tristate "Versatile Express SPC based CPUfreq driver"
>> + depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
>> + help
>> + This add the CPUfreq driver support for Versatile Express
>> + big.LITTLE platforms using SPC for power management.
>> +
>> +config ARM_SCPI_CPUFREQ
>
> The order of above two must be reversed ?
Right, I will fix it.
Thanks,
Gregory
>
> --
> viresh
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT
From: Dave Martin @ 2017-12-06 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu88Ym4NxoLxVd07Z07PD454_ONV4D=pqvxezPvAPnd5og@mail.gmail.com>
On Tue, Dec 05, 2017 at 06:04:34PM +0000, Ard Biesheuvel wrote:
> On 5 December 2017 at 12:45, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> >
> >> On 5 Dec 2017, at 12:28, Dave Martin <Dave.Martin@arm.com> wrote:
> >>
> >>> On Mon, Dec 04, 2017 at 12:26:37PM +0000, Ard Biesheuvel wrote:
> >>> Add a support macro to conditionally yield the NEON (and thus the CPU)
> >>> that may be called from the assembler code. Given that especially the
> >>> instruction based accelerated crypto code may use very tight loops, add
> >>> some parametrization so that the TIF_NEED_RESCHED flag test is only
> >>> executed every so many loop iterations.
> >>>
> >>> In some cases, yielding the NEON involves saving and restoring a non
> >>> trivial amount of context (especially in the CRC folding algorithms),
> >>> and so the macro is split into two, and the code in between is only
> >>> executed when the yield path is taken, allowing the contex to be preserved.
> >>> The second macro takes a label argument that marks the resume-from-yield
> >>> path, which should restore the preserved context again.
> >>>
> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >>> ---
> >>> arch/arm64/include/asm/assembler.h | 50 ++++++++++++++++++++
> >>> 1 file changed, 50 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> >>> index aef72d886677..917b026d3e00 100644
> >>> --- a/arch/arm64/include/asm/assembler.h
> >>> +++ b/arch/arm64/include/asm/assembler.h
> >>> @@ -512,4 +512,54 @@ alternative_else_nop_endif
> >>> #endif
> >>> .endm
> >>>
> >>> +/*
> >>> + * yield_neon - check whether to yield to another runnable task from
> >>> + * kernel mode NEON code (running with preemption disabled)
> >>> + *
> >>> + * - Check whether the preempt count is exactly 1, in which case disabling
> >>> + * preemption once will make the task preemptible. If this is not the case,
> >>> + * yielding is pointless.
> >>> + * - Check whether TIF_NEED_RESCHED is set, and if so, disable and re-enable
> >>> + * kernel mode NEON (which will trigger a reschedule), and branch to the
> >>> + * yield fixup code at @lbl.
> >>> + */
> >>> + .macro yield_neon, lbl:req, ctr, order, stride, loop
> >>> + yield_neon_pre \ctr, \order, \stride, \loop
> >>> + yield_neon_post \lbl
> >>> + .endm
> >>> +
> >>> + .macro yield_neon_pre, ctr, order=0, stride, loop=4444f
> >>> +#ifdef CONFIG_PREEMPT
> >>> + /*
> >>> + * With some algorithms, it makes little sense to poll the
> >>> + * TIF_NEED_RESCHED flag after every iteration, so only perform
> >>> + * the check every 2^order strides.
> >>> + */
> >>> + .if \order > 1
> >>> + .if (\stride & (\stride - 1)) != 0
> >>> + .error "stride should be a power of 2"
> >>> + .endif
> >>> + tst \ctr, #((1 << \order) * \stride - 1) & ~(\stride - 1)
> >>> + b.ne \loop
> >>> + .endif
> >>
> >> I'm not sure what baking in this check gives us, and this seems to
> >> conflate two rather different things: yielding and defining a
> >> "heartbeat" frequency for the calling code.
> >>
> >> Can we separate out the crypto-loop-helper semantics from the yield-
> >> neon stuff?
> >>
> >
> > Fair enough. I incorporated the check here so it disappears from the code entirely when !CONFIG_PREEMPT, because otherwise, you end up with a sequence that is mispredicted every # iterations without any benefit.
> > I guess i could macroise that separately though.
> >
> >> If we had
> >>
> >> if_cond_yield_neon
> >> // patchup code
> >> endif_yield_neon
> >>
>
> I like this, but ...
>
> >> then the caller is free to conditionally branch over that as appropriate
> >> like
> >>
> >> loop:
> >> // crypto stuff
> >> tst x0, #0xf
> >> b.ne loop
> >>
> >> if_cond_yield_neon
> >> // patchup code
> >> endif_cond_yield_neon
> >>
>
> I need to put the post patchup code somewhere too. Please refer to the
> CRC patches for the best examples of this.
I'm not sure I follow. If you need to do something different after
patchup, can't you either pull that code into the if...endif too, or
otherwise put a branch before the endif?
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/6] dt-bindings: marvell: Add documentation for the North Bridge PM on Armada 37xx
From: Gregory CLEMENT @ 2017-12-06 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204214706.4sbjgxme3ftmf3l3@rob-hp-laptop>
Hi Rob,
On lun., d?c. 04 2017, Rob Herring <robh@kernel.org> wrote:
> On Fri, Dec 01, 2017 at 12:25:03PM +0100, Gregory CLEMENT wrote:
>> Extend the documentation of the Armada 37xx SoC with the the North
>> Bridge Power Management component.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> .../devicetree/bindings/arm/marvell/armada-37xx.txt | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> index 51336e5fc761..7ad9830d9177 100644
>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> @@ -14,3 +14,22 @@ following property before the previous one:
>> Example:
>>
>> compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
>> +
>> +
>> +Power management
>> +----------------
>> +
>> +For power management (particularly DVFS and AVS), the North Bridge
>> +Power Management component is needed:
>> +
>> +Required properties:
>> +- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
>> +- reg : the register start and length for the North Bridge
>> + Power Management
>> +
>> +Example:
>> +
>> +nb_pm: nb_pm at 14000 {
>
> Don't use underscore in node or property names. "syscon" is a better
> choice here.
OK I will change this.
Thanks,
Gregory
>
>> + compatible = "marvell,armada-3700-nb-pm", "syscon";
>> + reg = <0x14000 0x60>;
>> +}
>> --
>> 2.15.0
>>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/6] Add CPU Frequency scaling support on Armada 37xx
From: Gregory CLEMENT @ 2017-12-06 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f9ebd3e3-143a-b7e3-7b16-f09750b4c320@gmail.com>
Hi Andre,
On dim., d?c. 03 2017, Andre Heider <a.heider@gmail.com> wrote:
> Hi Gregory,
>
> I applied this and the dvfs patch set ([PATCH 0/3] Add DVFS support on
> CPU clock for Armada 37xx) on top of 4.14.3 and gave it a try on
> espressobin.
Thanks for testing.
>
> Upon modprobe I get:
> [ 66.231652] freq_table: Duplicate freq-table entries: 0
> [ 66.236967] cpu cpu0: cpufreq_init: invalid frequency table: -22
> [ 66.243534] freq_table: Duplicate freq-table entries: 0
> [ 66.248575] cpu cpu1: cpufreq_init: invalid frequency table: -22
>
> Is this supposed to work already? Do I miss something?
I did a last rebase before sending the series to remove the avs part not
working yet. And during this rebase I introduced an bug.
I will send a v2 soon if you are intersected by testing it right now,
here it is the fix:
iff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c
index 40c9a744cc6e..96c2600009b5 100644
--- a/drivers/cpufreq/armada-37xx-cpufreq.c
+++ b/drivers/cpufreq/armada-37xx-cpufreq.c
@@ -219,7 +219,8 @@ static int __init armada37xx_cpufreq_driver_init(void)
*/
for (load_level = ARMADA_37XX_DVFS_LOAD_0; load_level < LOAD_LEVEL_NR;
load_level++) {
- unsigned long freq = dvfs->divider[load_level];
+ unsigned long freq = cur_frequency /
+ dvfs->divider[load_level];
ret = dev_pm_opp_add(cpu_dev, freq, 0);
if (ret)
Gregory
>
> Oh, and on that scenario it's not possible to rmmod the driver again, EBUSY.
>
> Thanks,
> Andre
>
> On 01/12/17 12:25, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>> Hi,
>>
>> This series adds the CPU Frequency support on Armada 37xx using
>> DVFS. It is based on the initial work of Evan Wang and Victor Gu.
>>
>> DVFS control is done by a set of registers from the North Bridge Power
>> Management block. The binding for this block is documented in patch 1.
>>
>> While adding a new cpufreq driver I found that the Kconfig and
>> Makefile were no more in order, so it is fixed by patch 2 and 3.
>>
>> The 4th patch is just about updating the MAINTAINERS file with the new
>> driver.
>>
>> The next patch is the real purpose of the series. The main goal of
>> this driver is to setup the CPU load level in the hardware to
>> associate them to CPU frequencies and register a standard cpufreq
>> driver. Note that the hardware also capable of doing AVS (Adaptive
>> Voltage Scaling), by associating a voltage on each level beside the
>> CPU frequency. However, this support is not yet ready, so it is not
>> part of this series.
>>
>> Finally, the last patch is for arm-soc the arm-soc subsystem through
>> mvebu and update the device tree to support the CPU frequency scaling.
>>
>> An update on the CPU clock driver is needed in order to take into
>> account the DVFS setting. It's the purpose of an other series already
>> sent, but is no dependencies between the series (for building or at
>> runtime).
>>
>> Thanks,
>>
>> Gregory
>>
>> Gregory CLEMENT (6):
>> dt-bindings: marvell: Add documentation for the North Bridge PM on
>> Armada 37xx
>> cpufreq: ARM: sort the Kconfig menu
>> cpufreq: sort the drivers in ARM part
>> MAINTAINERS: add new entries for Armada 37xx cpufreq driver
>> cpufreq: Add DVFS support for Armada 37xx
>> arm64: dts: marvell: armada-37xx: add nodes allowing cpufreq support
>>
>> .../bindings/arm/marvell/armada-37xx.txt | 19 ++
>> MAINTAINERS | 1 +
>> arch/arm64/boot/dts/marvell/armada-372x.dtsi | 1 +
>> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 7 +
>> drivers/cpufreq/Kconfig.arm | 89 ++++----
>> drivers/cpufreq/Makefile | 9 +-
>> drivers/cpufreq/armada-37xx-cpufreq.c | 241 +++++++++++++++++++++
>> 7 files changed, 322 insertions(+), 45 deletions(-)
>> create mode 100644 drivers/cpufreq/armada-37xx-cpufreq.c
>>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply related
* [PATCH] ARM: dts: colibri/apalis: use correct compatible for RTC
From: Fabio Estevam @ 2017-12-06 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206102929.4755-1-stefan@agner.ch>
On Wed, Dec 6, 2017 at 8:29 AM, Stefan Agner <stefan@agner.ch> wrote:
> All Toradex Carrier Boards use a st,m41t0 compatible RTC. Compared
> to a st,m41t00 this RTC has also an oscillator fail bit which allows
> to detect when the RTC lost track of time.
>
> Cc: Sanchayan Maity <maitysanchayan@gmail.com>
> Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] media: platform: sti: Adopt SPDX identifier
From: Fabien DESSENNE @ 2017-12-06 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205145239.17908-1-benjamin.gaignard@st.com>
On 05/12/17 15:52, Benjamin Gaignard wrote:
> Add SPDX identifiers to files under sti directory
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
For the bdisp part:
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/media/platform/sti/bdisp/bdisp-debug.c | 2 +-
> drivers/media/platform/sti/bdisp/bdisp-filter.h | 2 +-
> drivers/media/platform/sti/bdisp/bdisp-hw.c | 2 +-
> drivers/media/platform/sti/bdisp/bdisp-reg.h | 2 +-
> drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 2 +-
> drivers/media/platform/sti/bdisp/bdisp.h | 2 +-
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.c | 5 +----
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.h | 5 +----
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 5 +----
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.h | 5 +----
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.c | 9 +--------
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.h | 9 +--------
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c | 11 +----------
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.h | 5 +----
> drivers/media/platform/sti/cec/stih-cec.c | 5 +----
> drivers/media/platform/sti/delta/delta-cfg.h | 2 +-
> drivers/media/platform/sti/delta/delta-debug.c | 2 +-
> drivers/media/platform/sti/delta/delta-debug.h | 2 +-
> drivers/media/platform/sti/delta/delta-ipc.c | 2 +-
> drivers/media/platform/sti/delta/delta-ipc.h | 2 +-
> drivers/media/platform/sti/delta/delta-mem.c | 2 +-
> drivers/media/platform/sti/delta/delta-mem.h | 2 +-
> drivers/media/platform/sti/delta/delta-mjpeg-dec.c | 2 +-
> drivers/media/platform/sti/delta/delta-mjpeg-fw.h | 2 +-
> drivers/media/platform/sti/delta/delta-mjpeg-hdr.c | 2 +-
> drivers/media/platform/sti/delta/delta-mjpeg.h | 2 +-
> drivers/media/platform/sti/delta/delta-v4l2.c | 2 +-
> drivers/media/platform/sti/delta/delta.h | 2 +-
> drivers/media/platform/sti/hva/hva-debugfs.c | 2 +-
> drivers/media/platform/sti/hva/hva-h264.c | 2 +-
> drivers/media/platform/sti/hva/hva-hw.c | 2 +-
> drivers/media/platform/sti/hva/hva-hw.h | 2 +-
> drivers/media/platform/sti/hva/hva-mem.c | 2 +-
> drivers/media/platform/sti/hva/hva-mem.h | 2 +-
> drivers/media/platform/sti/hva/hva-v4l2.c | 2 +-
> drivers/media/platform/sti/hva/hva.h | 2 +-
> 36 files changed, 36 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c b/drivers/media/platform/sti/bdisp/bdisp-debug.c
> index 2cc289e4dea1..c6a4e2de5c0c 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-debug.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2014
> * Authors: Fabien Dessenne <fabien.dessenne@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/debugfs.h>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-filter.h b/drivers/media/platform/sti/bdisp/bdisp-filter.h
> index 53e52fb4127f..d25adb57e3d0 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-filter.h
> +++ b/drivers/media/platform/sti/bdisp/bdisp-filter.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2014
> * Authors: Fabien Dessenne <fabien.dessenne@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #define BDISP_HF_NB 64
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c b/drivers/media/platform/sti/bdisp/bdisp-hw.c
> index b7892f3efd98..e7836b307d21 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-hw.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2014
> * Authors: Fabien Dessenne <fabien.dessenne@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/delay.h>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-reg.h b/drivers/media/platform/sti/bdisp/bdisp-reg.h
> index e7e1a425f65a..b07ecc903707 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-reg.h
> +++ b/drivers/media/platform/sti/bdisp/bdisp-reg.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2014
> * Authors: Fabien Dessenne <fabien.dessenne@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> struct bdisp_node {
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> index 7e9ed9c7b3e1..bf4ca16db440 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2014
> * Authors: Fabien Dessenne <fabien.dessenne@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/errno.h>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp.h b/drivers/media/platform/sti/bdisp/bdisp.h
> index b3fbf9902595..e309cde379ca 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp.h
> +++ b/drivers/media/platform/sti/bdisp/bdisp.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2014
> * Authors: Fabien Dessenne <fabien.dessenne@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/clk.h>
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.c b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.c
> index 2dfbe8ab5214..c64909e5ab64 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * c8sectpfe-common.c - C8SECTPFE STi DVB driver
> *
> @@ -5,10 +6,6 @@
> *
> * Author: Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
> */
> #include <linux/completion.h>
> #include <linux/delay.h>
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.h b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.h
> index da21c0ac0fc1..694f63832d3f 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.h
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-common.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * c8sectpfe-common.h - C8SECTPFE STi DVB driver
> *
> @@ -5,10 +6,6 @@
> *
> * Author: Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
> */
> #ifndef _C8SECTPFE_COMMON_H_
> #define _C8SECTPFE_COMMON_H_
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> index a0acee7671b1..d9a73d5c97fa 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * c8sectpfe-core.c - C8SECTPFE STi DVB driver
> *
> @@ -6,10 +7,6 @@
> * Author:Peter Bennett <peter.bennett@st.com>
> * Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
> */
> #include <linux/atomic.h>
> #include <linux/clk.h>
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.h b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.h
> index 39e7a221a941..3dbb3a287cc0 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.h
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * c8sectpfe-core.h - C8SECTPFE STi DVB driver
> *
> @@ -6,10 +7,6 @@
> * Author:Peter Bennett <peter.bennett@st.com>
> * Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
> */
> #ifndef _C8SECTPFE_CORE_H_
> #define _C8SECTPFE_CORE_H_
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.c b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.c
> index e9ba13db49cd..8f0ddcbeed9d 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * c8sectpfe-debugfs.c - C8SECTPFE STi DVB driver
> *
> @@ -5,14 +6,6 @@
> *
> * Author: Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software: you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 of
> - * the License as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> */
> #include <linux/debugfs.h>
> #include <linux/device.h>
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.h b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.h
> index 8af1ac1378c8..b8c30bcc8df9 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.h
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-debugfs.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /**
> * c8sectpfe-debugfs.h - C8SECTPFE STi DVB driver debugfs header
> *
> @@ -5,14 +6,6 @@
> *
> * Authors: Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software: you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 of
> - * the License as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> */
>
> #ifndef __C8SECTPFE_DEBUG_H
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c
> index 2c0015b1264d..075d4695ee4d 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * c8sectpfe-dvb.c - C8SECTPFE STi DVB driver
> *
> @@ -5,16 +6,6 @@
> *
> * Author Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - *
> - * GNU General Public License for more details.
> */
> #include <linux/completion.h>
> #include <linux/delay.h>
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.h b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.h
> index bd366dbc82b3..3d87a9ae8702 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.h
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * c8sectpfe-common.h - C8SECTPFE STi DVB driver
> *
> @@ -5,10 +6,6 @@
> *
> * Author: Peter Griffin <peter.griffin@linaro.org>
> *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
> */
> #ifndef _C8SECTPFE_DVB_H_
> #define _C8SECTPFE_DVB_H_
> diff --git a/drivers/media/platform/sti/cec/stih-cec.c b/drivers/media/platform/sti/cec/stih-cec.c
> index 70160df36de9..d34099f75990 100644
> --- a/drivers/media/platform/sti/cec/stih-cec.c
> +++ b/drivers/media/platform/sti/cec/stih-cec.c
> @@ -1,11 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * STIH4xx CEC driver
> * Copyright (C) STMicroelectronics SA 2016
> *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> */
> #include <linux/clk.h>
> #include <linux/interrupt.h>
> diff --git a/drivers/media/platform/sti/delta/delta-cfg.h b/drivers/media/platform/sti/delta/delta-cfg.h
> index c6388f575800..f47c6e6ff083 100644
> --- a/drivers/media/platform/sti/delta/delta-cfg.h
> +++ b/drivers/media/platform/sti/delta/delta-cfg.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef DELTA_CFG_H
> diff --git a/drivers/media/platform/sti/delta/delta-debug.c b/drivers/media/platform/sti/delta/delta-debug.c
> index a7ebf2cc7783..4b2eb6b63aa2 100644
> --- a/drivers/media/platform/sti/delta/delta-debug.c
> +++ b/drivers/media/platform/sti/delta/delta-debug.c
> @@ -1,9 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Hugues Fruchet <hugues.fruchet@st.com>
> * Fabrice Lecoultre <fabrice.lecoultre@st.com>
> * for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include "delta.h"
> diff --git a/drivers/media/platform/sti/delta/delta-debug.h b/drivers/media/platform/sti/delta/delta-debug.h
> index 955c1587ac2d..fa90252623e1 100644
> --- a/drivers/media/platform/sti/delta/delta-debug.h
> +++ b/drivers/media/platform/sti/delta/delta-debug.h
> @@ -1,9 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Hugues Fruchet <hugues.fruchet@st.com>
> * Fabrice Lecoultre <fabrice.lecoultre@st.com>
> * for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef DELTA_DEBUG_H
> diff --git a/drivers/media/platform/sti/delta/delta-ipc.c b/drivers/media/platform/sti/delta/delta-ipc.c
> index 41e4a4c259b3..a4603d573c34 100644
> --- a/drivers/media/platform/sti/delta/delta-ipc.c
> +++ b/drivers/media/platform/sti/delta/delta-ipc.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/rpmsg.h>
> diff --git a/drivers/media/platform/sti/delta/delta-ipc.h b/drivers/media/platform/sti/delta/delta-ipc.h
> index cef2019c72d4..9fba6b5d169a 100644
> --- a/drivers/media/platform/sti/delta/delta-ipc.h
> +++ b/drivers/media/platform/sti/delta/delta-ipc.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef DELTA_IPC_H
> diff --git a/drivers/media/platform/sti/delta/delta-mem.c b/drivers/media/platform/sti/delta/delta-mem.c
> index d7b53d31caa6..aeccd50583da 100644
> --- a/drivers/media/platform/sti/delta/delta-mem.c
> +++ b/drivers/media/platform/sti/delta/delta-mem.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include "delta.h"
> diff --git a/drivers/media/platform/sti/delta/delta-mem.h b/drivers/media/platform/sti/delta/delta-mem.h
> index f8ca109e1241..ff7d02f00b28 100644
> --- a/drivers/media/platform/sti/delta/delta-mem.h
> +++ b/drivers/media/platform/sti/delta/delta-mem.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef DELTA_MEM_H
> diff --git a/drivers/media/platform/sti/delta/delta-mjpeg-dec.c b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
> index 84ea43c0eb46..0533d4a083d2 100644
> --- a/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
> +++ b/drivers/media/platform/sti/delta/delta-mjpeg-dec.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2013
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/slab.h>
> diff --git a/drivers/media/platform/sti/delta/delta-mjpeg-fw.h b/drivers/media/platform/sti/delta/delta-mjpeg-fw.h
> index de803d0c2fe8..5a9404f4d055 100644
> --- a/drivers/media/platform/sti/delta/delta-mjpeg-fw.h
> +++ b/drivers/media/platform/sti/delta/delta-mjpeg-fw.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef DELTA_MJPEG_FW_H
> diff --git a/drivers/media/platform/sti/delta/delta-mjpeg-hdr.c b/drivers/media/platform/sti/delta/delta-mjpeg-hdr.c
> index a8fd8fa0ecb5..90e5b2f72c82 100644
> --- a/drivers/media/platform/sti/delta/delta-mjpeg-hdr.c
> +++ b/drivers/media/platform/sti/delta/delta-mjpeg-hdr.c
> @@ -1,7 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2013
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include "delta.h"
> diff --git a/drivers/media/platform/sti/delta/delta-mjpeg.h b/drivers/media/platform/sti/delta/delta-mjpeg.h
> index 18e6b37217ee..43f7a88b6e59 100644
> --- a/drivers/media/platform/sti/delta/delta-mjpeg.h
> +++ b/drivers/media/platform/sti/delta/delta-mjpeg.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2013
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef DELTA_MJPEG_H
> diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c b/drivers/media/platform/sti/delta/delta-v4l2.c
> index b2dc3d223a9c..232d508c5b66 100644
> --- a/drivers/media/platform/sti/delta/delta-v4l2.c
> +++ b/drivers/media/platform/sti/delta/delta-v4l2.c
> @@ -1,9 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Hugues Fruchet <hugues.fruchet@st.com>
> * Jean-Christophe Trotin <jean-christophe.trotin@st.com>
> * for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/clk.h>
> diff --git a/drivers/media/platform/sti/delta/delta.h b/drivers/media/platform/sti/delta/delta.h
> index 60c073246a01..2ba99922c05b 100644
> --- a/drivers/media/platform/sti/delta/delta.h
> +++ b/drivers/media/platform/sti/delta/delta.h
> @@ -1,7 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Author: Hugues Fruchet <hugues.fruchet@st.com> for STMicroelectronics.
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef DELTA_H
> diff --git a/drivers/media/platform/sti/hva/hva-debugfs.c b/drivers/media/platform/sti/hva/hva-debugfs.c
> index 83a6258a155b..9f7e8ac875d1 100644
> --- a/drivers/media/platform/sti/hva/hva-debugfs.c
> +++ b/drivers/media/platform/sti/hva/hva-debugfs.c
> @@ -1,8 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/debugfs.h>
> diff --git a/drivers/media/platform/sti/hva/hva-h264.c b/drivers/media/platform/sti/hva/hva-h264.c
> index a7e5eed17ada..6b0b321db8cc 100644
> --- a/drivers/media/platform/sti/hva/hva-h264.c
> +++ b/drivers/media/platform/sti/hva/hva-h264.c
> @@ -1,8 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include "hva.h"
> diff --git a/drivers/media/platform/sti/hva/hva-hw.c b/drivers/media/platform/sti/hva/hva-hw.c
> index ec25bdcfa3d1..7917fd2c4bd4 100644
> --- a/drivers/media/platform/sti/hva/hva-hw.c
> +++ b/drivers/media/platform/sti/hva/hva-hw.c
> @@ -1,8 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/clk.h>
> diff --git a/drivers/media/platform/sti/hva/hva-hw.h b/drivers/media/platform/sti/hva/hva-hw.h
> index b46017dcfae9..b298990264d5 100644
> --- a/drivers/media/platform/sti/hva/hva-hw.h
> +++ b/drivers/media/platform/sti/hva/hva-hw.h
> @@ -1,8 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef HVA_HW_H
> diff --git a/drivers/media/platform/sti/hva/hva-mem.c b/drivers/media/platform/sti/hva/hva-mem.c
> index 821c78ed208c..caf50cd4bb77 100644
> --- a/drivers/media/platform/sti/hva/hva-mem.c
> +++ b/drivers/media/platform/sti/hva/hva-mem.c
> @@ -1,8 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include "hva.h"
> diff --git a/drivers/media/platform/sti/hva/hva-mem.h b/drivers/media/platform/sti/hva/hva-mem.h
> index a95c728a45e6..fec549dff2b3 100644
> --- a/drivers/media/platform/sti/hva/hva-mem.h
> +++ b/drivers/media/platform/sti/hva/hva-mem.h
> @@ -1,8 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef HVA_MEM_H
> diff --git a/drivers/media/platform/sti/hva/hva-v4l2.c b/drivers/media/platform/sti/hva/hva-v4l2.c
> index 1c4fc33cbcb5..2ab0b5cc5c22 100644
> --- a/drivers/media/platform/sti/hva/hva-v4l2.c
> +++ b/drivers/media/platform/sti/hva/hva-v4l2.c
> @@ -1,8 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #include <linux/module.h>
> diff --git a/drivers/media/platform/sti/hva/hva.h b/drivers/media/platform/sti/hva/hva.h
> index 0d749b257a21..8882d901d119 100644
> --- a/drivers/media/platform/sti/hva/hva.h
> +++ b/drivers/media/platform/sti/hva/hva.h
> @@ -1,8 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> /*
> * Copyright (C) STMicroelectronics SA 2015
> * Authors: Yannick Fertre <yannick.fertre@st.com>
> * Hugues Fruchet <hugues.fruchet@st.com>
> - * License terms: GNU General Public License (GPL), version 2
> */
>
> #ifndef HVA_H
^ permalink raw reply
* [PATCH] arm64/mm: Do not write ASID generation to ttbr0
From: Julien Thierry @ 2017-12-06 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A27CCDF.1050305@arm.com>
On 06/12/17 10:56, James Morse wrote:
> Hi Julien,
>
> On 06/12/17 10:17, Julien Thierry wrote:
>> On 05/12/17 19:33, James Morse wrote:
>>> On 05/12/17 17:38, Julien Thierry wrote:
>>>> When writing the user ASID to ttbr0, 16bit get copied to ttbr0, potentially
>>>> including part of the ASID generation in the ttbr0.ASID. If the kernel is
>>>> using less than 16bits ASIDs and the other ttbr0 bits aren't RES0, two
>>>> tasks using the same mm context might end up running with different
>>>> ttbr0.ASID values.
>>>> This would be triggered by one of the threads being scheduled before a
>>>> roll-over and the second one scheduled after a roll-over.
>>>>
>>>> Pad the generation out of the 16bits of the mm id that are written to
>>>> ttbr0. Thus, what the hardware sees is what the kernel considers ASID.
>>>
>>> Is this to fix a system with a mix of 8/16 asid bits? Or someone being clever
>>> and reducing asid_bits to stress rollover?
>
>> So it was motivated by the later. But hopefully the fix, pushing the generation
>> always over 16bits is also suitable for hardware that mixes 8/16bits asids. If
>> it is not, do call it out.
>
> (okay, wasn't clear from the commit message!)
>
Fair point, I'll mention the mixed size hardware asids in the next version.
>
>>>> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
>>>> index 6f40170..a7c72d4 100644
>>>> --- a/arch/arm64/mm/context.c
>>>> +++ b/arch/arm64/mm/context.c
>>>> @@ -180,6 +190,13 @@ static u64 new_context(struct mm_struct *mm, unsigned
>>>> int cpu)
>>>> /* We're out of ASIDs, so increment the global generation count */
>>>> generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION,
>>>> &asid_generation);
>>>> +
>>>> + /*
>>>> + * It is unlikely the generation will ever overflow, but if this
>>>> + * happens, let it be known strange things can occur.
>>>> + */
>>>> + WARN_ON(generation == ASID_FIRST_VERSION);
>>>
>>> Won't generation wrap to zero, not '1<<16'?
>>
>> Yes it will! Silly me...
>>
>>>
>>> asid_generation-is-never-zero is one of the nasty things in this code.
>>>
>>> In check_and_switch_context() we switch to the 'fast path' where the current
>>> asid is usable if: the generation matches and the active_asid isn't 0 (which
>>> indicates a rollover has occurred).
>>>
>>> from mm/context.c::check_and_switch_context():
>>>> if (!((asid ^ atomic64_read(&asid_generation)) >> asid_bits)
>>>> && atomic64_xchg_relaxed(&per_cpu(active_asids, cpu), asid))
>>>> goto switch_mm_fastpath;
>>>
>>>
>>> If asid_generation is ever zero, (even briefly) multiple new tasks with
>>> different pages-tables will pass the generation test, and run with asid=0.
>>>
>>> Short of xchg(ASID_MAX_VERSION, ASID_FIRST_VERSION), every time, just in case, I
>>> don't think this is something we can handle.
>>>
>>> But, this thing is layers on layers of subtle behaviour, so I may have missed
>>> something...
>
>> I had not thought of that. However I believe we checked with 48bits and the case
>> of the generation overflowing would take a human life span (or something on that
>> scale) of a system running and spawning continuous processes before reaching
>
> This scales with the number of CPUs, and how quickly they can fork().
> (Not using all the counter bits makes me nervous.)
>
>
>> this. Which is why we decided on having a WARN_ON for now. So I don't know if we
>> want to change things for this corner case which really means "things are going
>> bad" more than anything else.
>
> But it fires the generation after the chaos started, so if we ever do see this
> it gives us false-confidence that generation-overflow wasn't the issue.
> WARN_ON(generation == ASID_MAX_VERSION) ?
>
Yes that seems fair.
>
>>> Instead, do you think we can duplicate just the asid bits (asid & ASID_MASK)
>>> into a new 16bit field in mm_context_t, which we then use instead of the ASID()
>>> and mmid macros? (We only set a new asid in one place as returned by
>>> new_context()).
>>>
>>
>> I'm not sure I understand why this prevents running with asid = 0 when
>> generation is 0.
>
> Sorry, I was talking about two things. It doesn't, I don't think we can do
> anything about that.
>
> This was a suggestion for an alternative way of stopping generation bits getting
> into the TTBR, which still lets use use all the counter bits. (and lets us mess
> with asid_bits to stress rollover without re-inventing this bug).
>
I see. Only thing that worries me is people being tempted to use this
duplicated field (only ASID) wrongfully.
I'm not very familiar with ASIDs and mem contexts so I'd like to know
how this suggestion sounds to others. If people agree, I'm happy to add
this for the next version.
>
>>> This would let context.c's asid_bits be arbitrary, as the hardware only uses the
>>> masked value it exposes in the new field.
>>>
>>> This doesn't solve the mixed 8/16 bit case. I think we should force those
>>> systems to use 8bit asids via cpufeature to preserve as much of the generation
>>> counter as possible.
>
>> Hmmm right, I see that today we just panic the kernel when we have a smaller
>> asid size than the boot cpu...
>> So if we boot on a 8bit asid cpu it should work but not the other way around...
>> I agree we probably should find a way to reduce the size of software asids
>> system wide when we find a cpu has less bits available.
>
> cpufeature has some stuff for 'LOWER_SAFE' that might help here..
>
I'll have a look.
Cheers,
--
Julien Thierry
^ permalink raw reply
* [PATCH 2/3] arm64: dts: rockchip: add usb3-phy phandle for dwc3.
From: Enric Balletbo i Serra @ 2017-12-06 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1756641.7q7fHBPi13@diego>
Hi Heiko,
On 06/12/17 12:20, Heiko St?bner wrote:
> Am Mittwoch, 6. Dezember 2017, 12:10:07 CET schrieb Enric Balletbo i Serra:
>> This patch adds the usb3-phy for both of the two dwc3 controllers on
>> rk3399.
>
> This patch adds quite a bit more than the phy phandles though.
>
> The powerdomain addition should definitly be a separate patch
> and the usb3-grf clock as well.
>
Ok, I'll split these parts and send in a separate patch in v2. Thanks for the
feedback.
Enric
>
> Heiko
>
>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 ++++++++++++++++++++--------
>> 1 file changed, 20 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 17e5e1a..c18ff88 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 {
>> @@ -407,14 +409,15 @@
>> 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;
>> 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";
>> };
>> };
>> @@ -425,9 +428,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 {
>> @@ -435,14 +440,15 @@
>> 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;
>> 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";
>> };
>> };
>> @@ -991,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>;
>
>
^ permalink raw reply
* [PATCH 1/8] ARM: dts: r8a7745: Add APMU node and second CPU core
From: Fabrizio Castro @ 2017-12-06 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUuF4kwUiUYCbSew3W0Pa2CfRdCijefbOO1ZYAbnyG3KA@mail.gmail.com>
Hello Geert, Simon,
>
> As the dependency is in v4.15-rc1, it can be applied now.
>
we thought exactly the same thing, therefore we rebased and we re-ran our tests, to discover that something broke in between versions.
I'll be in touch once I have more information, but it's a no go for now.
Thanks,
Fab
[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
* [PATCH 2/3] arm64: dts: rockchip: add usb3-phy phandle for dwc3.
From: Heiko Stübner @ 2017-12-06 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206111008.3079-2-enric.balletbo@collabora.com>
Am Mittwoch, 6. Dezember 2017, 12:10:07 CET schrieb Enric Balletbo i Serra:
> This patch adds the usb3-phy for both of the two dwc3 controllers on
> rk3399.
This patch adds quite a bit more than the phy phandles though.
The powerdomain addition should definitly be a separate patch
and the usb3-grf clock as well.
Heiko
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 17e5e1a..c18ff88 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 {
> @@ -407,14 +409,15 @@
> 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;
> 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";
> };
> };
> @@ -425,9 +428,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 {
> @@ -435,14 +440,15 @@
> 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;
> 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";
> };
> };
> @@ -991,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>;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox