* [PATCH v3 04/19] arm64: alternatives: Enforce alignment of struct alt_instr
From: Marc Zyngier @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218173926.16911-1-marc.zyngier@arm.com>
We're playing a dangerous game with struct alt_instr, as we produce
it using assembly tricks, but parse them using the C structure.
We just assume that the respective alignments of the two will
be the same.
But as we add more fields to this structure, the alignment requirements
of the structure may change, and lead to all kind of funky bugs.
TO solve this, let's move the definition of struct alt_instr to its
own file, and use this to generate the alignment constraint from
asm-offsets.c. The various macros are then patched to take the
alignment into account.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/alternative.h | 13 +++++--------
arch/arm64/include/asm/alternative_types.h | 13 +++++++++++++
arch/arm64/kernel/asm-offsets.c | 4 ++++
3 files changed, 22 insertions(+), 8 deletions(-)
create mode 100644 arch/arm64/include/asm/alternative_types.h
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 4a85c6952a22..395befde7595 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -2,28 +2,24 @@
#ifndef __ASM_ALTERNATIVE_H
#define __ASM_ALTERNATIVE_H
+#include <asm/asm-offsets.h>
#include <asm/cpucaps.h>
#include <asm/insn.h>
#ifndef __ASSEMBLY__
+#include <asm/alternative_types.h>
+
#include <linux/init.h>
#include <linux/types.h>
#include <linux/stddef.h>
#include <linux/stringify.h>
-struct alt_instr {
- s32 orig_offset; /* offset to original instruction */
- s32 alt_offset; /* offset to replacement instruction */
- u16 cpufeature; /* cpufeature bit set for replacement */
- u8 orig_len; /* size of original instruction(s) */
- u8 alt_len; /* size of new instruction(s), <= orig_len */
-};
-
void __init apply_alternatives_all(void);
void apply_alternatives(void *start, size_t length);
#define ALTINSTR_ENTRY(feature) \
+ " .align " __stringify(ALTINSTR_ALIGN) "\n" \
" .word 661b - .\n" /* label */ \
" .word 663f - .\n" /* new instruction */ \
" .hword " __stringify(feature) "\n" /* feature bit */ \
@@ -69,6 +65,7 @@ void apply_alternatives(void *start, size_t length);
#include <asm/assembler.h>
.macro altinstruction_entry orig_offset alt_offset feature orig_len alt_len
+ .align ALTINSTR_ALIGN
.word \orig_offset - .
.word \alt_offset - .
.hword \feature
diff --git a/arch/arm64/include/asm/alternative_types.h b/arch/arm64/include/asm/alternative_types.h
new file mode 100644
index 000000000000..26cf76167f2d
--- /dev/null
+++ b/arch/arm64/include/asm/alternative_types.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_ALTERNATIVE_TYPES_H
+#define __ASM_ALTERNATIVE_TYPES_H
+
+struct alt_instr {
+ s32 orig_offset; /* offset to original instruction */
+ s32 alt_offset; /* offset to replacement instruction */
+ u16 cpufeature; /* cpufeature bit set for replacement */
+ u8 orig_len; /* size of original instruction(s) */
+ u8 alt_len; /* size of new instruction(s), <= orig_len */
+};
+
+#endif
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 5ab8841af382..f00666341ae2 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -25,6 +25,7 @@
#include <linux/dma-mapping.h>
#include <linux/kvm_host.h>
#include <linux/suspend.h>
+#include <asm/alternative_types.h>
#include <asm/cpufeature.h>
#include <asm/thread_info.h>
#include <asm/memory.h>
@@ -151,5 +152,8 @@ int main(void)
DEFINE(HIBERN_PBE_ADDR, offsetof(struct pbe, address));
DEFINE(HIBERN_PBE_NEXT, offsetof(struct pbe, next));
DEFINE(ARM64_FTR_SYSVAL, offsetof(struct arm64_ftr_reg, sys_val));
+ BLANK();
+ DEFINE(ALTINSTR_ALIGN, (63 - __builtin_clzl(__alignof__(struct alt_instr))));
+
return 0;
}
--
2.14.2
^ permalink raw reply related
* [PATCH v3 03/19] arm64: asm-offsets: Remove potential circular dependency
From: Marc Zyngier @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218173926.16911-1-marc.zyngier@arm.com>
So far, we've been lucky enough that none of the include files
that asm-offsets.c requires include asm-offsets.h. This is
about to change, and would introduce a nasty circular dependency...
Let's now guard the inclusion of asm-offsets.h so that it never
gets pulled from asm-offsets.c. The same issue exists between
bounce.c and include/generated/bounds.h, and is worked around
by using the existing guard symbol.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/asm-offsets.h | 2 ++
arch/arm64/kernel/asm-offsets.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/asm-offsets.h b/arch/arm64/include/asm/asm-offsets.h
index d370ee36a182..7d6531a81eb3 100644
--- a/arch/arm64/include/asm/asm-offsets.h
+++ b/arch/arm64/include/asm/asm-offsets.h
@@ -1 +1,3 @@
+#if !defined(__GENERATING_ASM_OFFSETS_H) && !defined(__GENERATING_BOUNDS_H)
#include <generated/asm-offsets.h>
+#endif
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 742887330101..5ab8841af382 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -18,6 +18,8 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#define __GENERATING_ASM_OFFSETS_H 1
+
#include <linux/sched.h>
#include <linux/mm.h>
#include <linux/dma-mapping.h>
--
2.14.2
^ permalink raw reply related
* [PATCH v3 02/19] arm64: asm-offsets: Remove unused definitions
From: Marc Zyngier @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218173926.16911-1-marc.zyngier@arm.com>
asm-offsets.h contains a number of definitions that are not used
at all, and in some cases conflict with other definitions (such as
NSEC_PER_SEC).
Spring clean-up time.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/asm-offsets.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 7e8be0c22ce0..742887330101 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -83,10 +83,6 @@ int main(void)
DEFINE(VMA_VM_MM, offsetof(struct vm_area_struct, vm_mm));
DEFINE(VMA_VM_FLAGS, offsetof(struct vm_area_struct, vm_flags));
BLANK();
- DEFINE(VM_EXEC, VM_EXEC);
- BLANK();
- DEFINE(PAGE_SZ, PAGE_SIZE);
- BLANK();
DEFINE(__DMA_BIDIRECTIONAL, DMA_BIDIRECTIONAL);
DEFINE(__DMA_TO_DEVICE, DMA_TO_DEVICE);
DEFINE(__DMA_FROM_DEVICE, DMA_FROM_DEVICE);
@@ -98,7 +94,6 @@ int main(void)
DEFINE(CLOCK_REALTIME_COARSE, CLOCK_REALTIME_COARSE);
DEFINE(CLOCK_MONOTONIC_COARSE,CLOCK_MONOTONIC_COARSE);
DEFINE(CLOCK_COARSE_RES, LOW_RES_NSEC);
- DEFINE(NSEC_PER_SEC, NSEC_PER_SEC);
BLANK();
DEFINE(VDSO_CS_CYCLE_LAST, offsetof(struct vdso_data, cs_cycle_last));
DEFINE(VDSO_RAW_TIME_SEC, offsetof(struct vdso_data, raw_time_sec));
--
2.14.2
^ permalink raw reply related
* [PATCH v3 01/19] arm64: asm-offsets: Avoid clashing DMA definitions
From: Marc Zyngier @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218173926.16911-1-marc.zyngier@arm.com>
asm-offsets.h contains a few DMA related definitions that have
the exact same name than the enum members they are derived from.
While this is not a problem so far, it will become an issue if
both asm-offsets.h and include/linux/dma-direction.h: are pulled
by the same file.
Let's sidestep the issue by renaming the asm-offsets.h constants.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kernel/asm-offsets.c | 6 +++---
arch/arm64/mm/cache.S | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 71bf088f1e4b..7e8be0c22ce0 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -87,9 +87,9 @@ int main(void)
BLANK();
DEFINE(PAGE_SZ, PAGE_SIZE);
BLANK();
- DEFINE(DMA_BIDIRECTIONAL, DMA_BIDIRECTIONAL);
- DEFINE(DMA_TO_DEVICE, DMA_TO_DEVICE);
- DEFINE(DMA_FROM_DEVICE, DMA_FROM_DEVICE);
+ DEFINE(__DMA_BIDIRECTIONAL, DMA_BIDIRECTIONAL);
+ DEFINE(__DMA_TO_DEVICE, DMA_TO_DEVICE);
+ DEFINE(__DMA_FROM_DEVICE, DMA_FROM_DEVICE);
BLANK();
DEFINE(CLOCK_REALTIME, CLOCK_REALTIME);
DEFINE(CLOCK_MONOTONIC, CLOCK_MONOTONIC);
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index 7f1dbe962cf5..c1336be085eb 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -205,7 +205,7 @@ ENDPIPROC(__dma_flush_area)
* - dir - DMA direction
*/
ENTRY(__dma_map_area)
- cmp w2, #DMA_FROM_DEVICE
+ cmp w2, #__DMA_FROM_DEVICE
b.eq __dma_inv_area
b __dma_clean_area
ENDPIPROC(__dma_map_area)
@@ -217,7 +217,7 @@ ENDPIPROC(__dma_map_area)
* - dir - DMA direction
*/
ENTRY(__dma_unmap_area)
- cmp w2, #DMA_TO_DEVICE
+ cmp w2, #__DMA_TO_DEVICE
b.ne __dma_inv_area
ret
ENDPIPROC(__dma_unmap_area)
--
2.14.2
^ permalink raw reply related
* [PATCH v3 00/19] KVM/arm64: Randomise EL2 mappings
From: Marc Zyngier @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
Whilst KVM benefits from the kernel randomisation via KASLR, there is
no additional randomisation when the kernel is running at EL1, as we
directly use a fixed offset from the linear mapping. This is not
necessarily a problem, but we could do a bit better by independently
randomizing the HYP placement.
This series proposes to randomise the offset by inserting a few random
bits between the MSB of the RAM linear mapping and the top of the HYP
VA (VA_BITS - 2). That's not a lot of random bits (on my Mustang, I
get 13 bits), but that's better than nothing.
In order to achieve this, we need to be able to patch dynamic values
in the kernel text. This results in a bunch of changes to the
alternative framework, the insn library, and a few more hacks in KVM
itself (we get a new way to map the GIC at EL2). This series used to
depend on a number of cleanups in asm-offsets, which is not the case
anymore. I'm still including them as I think they are still pretty
useful.
This has been tested on the FVP model, Seattle (both 39 and 48bit VA),
Mustang and Thunder-X. I've also done a sanity check on 32bit (which
is only impacted by the HYP IO VA stuff).
Thanks,
M.
* From v2:
- Fixed a crapload of bugs in the immediate generation patch
I now have a test harness for it, making sure it generates the
same thing as GAS...
- Fixed a bug in the asm-offsets.h exclusion patch
- Reworked the alternative_cb code to be nicer and avoid generating
pointless nops
* From v1:
- Now works correctly with KASLR
- Dropped the callback field from alt_instr, and reuse one of the
existing fields to store an offset to the callback
- Fix HYP teardown path (depends on fixes previously posted)
- Dropped the VA offset macros
Marc Zyngier (19):
arm64: asm-offsets: Avoid clashing DMA definitions
arm64: asm-offsets: Remove unused definitions
arm64: asm-offsets: Remove potential circular dependency
arm64: alternatives: Enforce alignment of struct alt_instr
arm64: alternatives: Add dynamic patching feature
arm64: insn: Add N immediate encoding
arm64: insn: Add encoder for bitwise operations using literals
arm64: KVM: Dynamically patch the kernel/hyp VA mask
arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag
KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state
KVM: arm/arm64: Demote HYP VA range display to being a debug feature
KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings
KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state
KVM: arm/arm64: Move HYP IO VAs to the "idmap" range
arm64; insn: Add encoder for the EXTR instruction
arm64: insn: Allow ADD/SUB (immediate) with LSL #12
arm64: KVM: Dynamically compute the HYP VA mask
arm64: KVM: Introduce EL2 VA randomisation
arm64: Update the KVM memory map documentation
Documentation/arm64/memory.txt | 8 +-
arch/arm/include/asm/kvm_hyp.h | 6 +
arch/arm/include/asm/kvm_mmu.h | 4 +-
arch/arm64/include/asm/alternative.h | 49 ++++++--
arch/arm64/include/asm/alternative_types.h | 16 +++
arch/arm64/include/asm/asm-offsets.h | 2 +
arch/arm64/include/asm/cpucaps.h | 2 +-
arch/arm64/include/asm/insn.h | 16 +++
arch/arm64/include/asm/kvm_hyp.h | 9 ++
arch/arm64/include/asm/kvm_mmu.h | 56 ++++-----
arch/arm64/kernel/alternative.c | 21 +++-
arch/arm64/kernel/asm-offsets.c | 17 +--
arch/arm64/kernel/cpufeature.c | 19 ---
arch/arm64/kernel/insn.c | 190 ++++++++++++++++++++++++++++-
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/haslr.c | 135 ++++++++++++++++++++
arch/arm64/mm/cache.S | 4 +-
include/kvm/arm_vgic.h | 12 +-
virt/kvm/arm/hyp/vgic-v2-sr.c | 12 +-
virt/kvm/arm/mmu.c | 81 ++++++++----
virt/kvm/arm/vgic/vgic-init.c | 6 -
virt/kvm/arm/vgic/vgic-v2.c | 40 ++----
22 files changed, 549 insertions(+), 158 deletions(-)
create mode 100644 arch/arm64/include/asm/alternative_types.h
create mode 100644 arch/arm64/kvm/haslr.c
--
2.14.2
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: r8a7745: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513618743-4773-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
v1->v2:
* status "okay"->"disabled"
arch/arm/boot/dts/r8a7745.dtsi | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0fa7861..0b67ee5 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -235,6 +235,38 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer at ffca0000 {
+ compatible = "renesas,r8a7745-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ status = "disabled";
+ };
+
+ cmt1: timer at e6130000 {
+ compatible = "renesas,r8a7745-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ status = "disabled";
+ };
+
cpg: clock-controller at e6150000 {
compatible = "renesas,r8a7745-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513618743-4773-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
v1->v2:
* status "okay"->"disabled"
arch/arm/boot/dts/r8a7743.dtsi | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 59860c8..f250147 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -262,6 +262,38 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer at ffca0000 {
+ compatible = "renesas,r8a7743-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ status = "disabled";
+ };
+
+ cmt1: timer at e6130000 {
+ compatible = "renesas,r8a7743-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ status = "disabled";
+ };
+
cpg: clock-controller at e6150000 {
compatible = "renesas,r8a7743-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/3] Add CMT support to r8a774[35]
From: Fabrizio Castro @ 2017-12-18 17:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
this series adds CMT support for r8a7743 and r8a7745.
Thanks,
Fabrizio Castro (3):
dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
ARM: dts: r8a7743: Add CMT SoC specific support
ARM: dts: r8a7745: Add CMT SoC specific support
.../devicetree/bindings/timer/renesas,cmt.txt | 14 +++++++---
arch/arm/boot/dts/r8a7743.dtsi | 32 ++++++++++++++++++++++
arch/arm/boot/dts/r8a7745.dtsi | 32 ++++++++++++++++++++++
3 files changed, 74 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection
From: Tony Lindgren @ 2017-12-18 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8fe1dce0-3fd2-d740-8456-bf3b734e571a@ti.com>
* Grygorii Strashko <grygorii.strashko@ti.com> [171216 01:59]:
> On 12/13/2017 12:53 PM, Alexandre Belloni wrote:
> > +/ {
> > + chosen {
> > + linux,clocksource {
> > + timer = <&timer0>;
> > + };
> > +
> > + linux,clockevent {
> > + timer = <&timer1>;
> > + };
> > + };
> > +};
> >
>
> It'd be nice if smth. like this will actually happen, as on some OMAP
> platforms can be up to 3-4 alternatives for each clocksource/clockevent and
> different combination need to be selected depending on SoC and platform
> (and sometime - use case) which is pain in multi-platform environment now.
Yeah agreed.
> But more important note from my side is clocksource and clockevent selections seems
> not enough :( There are also sched clock (sched_clock_register()) and delay_timer
> (register_current_timer_delay() at least on ARM).
> Both above can't be unregistered (at least last time I've checked).
So maybe they should be also defined the sam way as above or is
there something more to it?
Regards,
Tony
^ permalink raw reply
* [PATCH 0/6] Add CPU Frequency scaling support on Armada 37xx
From: Gregory CLEMENT @ 2017-12-18 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <732df1c4-416b-8174-576b-c51db5a08c9c@gmail.com>
Hi Andre,
On mer., d?c. 06 2017, Andre Heider <a.heider@gmail.com> wrote:
> On 06/12/17 12:50, Gregory CLEMENT wrote:
>> 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)
>
> Much better, that seems to work so far, thanks!
>
> My espressobin now gets these frequencies: 200 MHz, 250 MHz, 500 MHz
> and 1000 MHz.
>
> With the schedutil governor and `watch -n 0.2 cpufreq-info -f -m` it
> jumps over all of those depending on the load, nice:
>
> Tested-by: Andre Heider <a.heider@gmail.com>
>
> The measured power usage doesn't drop though, I guess that requires
> the AVS part you mentioned? Looking forward to it ;)
Well I did some measurement and i saw some drop, according to my notes:
@ 250MHz: 222mA at 12V => 2.66W
@ 1000MHz: 238mA at 12CV => 2.87W
Not something huge, but only the CPUs which are concerned so it's not so
bad.
>
> On a related note: Do you know if power usage can be lowered by
> disabling eth phys? Is that possible on mainline?
For the test I have done just by removing an Ethernet cable we save a
lot of power, so it helps. I'm sure it is doable on mainline, but maybe
currently, there is something still missing.
Gregory
>
> Regards,
> Andre
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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: B15: fix unused label warnings
From: Arnd Bergmann @ 2017-12-18 16:52 UTC (permalink / raw)
To: linux-arm-kernel
The new conditionally compiled code leaves some labels and one
variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
are disabled:
arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
out_unmap:
^~~~~~~~~
arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
out_cpu_dead:
^~~~~~~~~~~~
At top level:
arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
This replaces the existing #ifdef conditionals with IS_ENABLED()
checks that let the compiler figure out for itself which code to
drop.
Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: use fewer #ifdef rather than adding more
---
arch/arm/mm/cache-b15-rac.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index f76988790011..d9586ba2e63c 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -50,6 +50,7 @@ extern void v7_flush_kern_cache_all(void);
static void __iomem *b15_rac_base;
static DEFINE_SPINLOCK(rac_lock);
+
static u32 rac_config0_reg;
/* Initialization flag to avoid checking for b15_rac_base, and to prevent
@@ -175,7 +176,6 @@ static struct notifier_block b15_rac_reboot_nb = {
.notifier_call = b15_rac_reboot_notifier,
};
-#ifdef CONFIG_HOTPLUG_CPU
/* The CPU hotplug case is the most interesting one, we basically need to make
* sure that the RAC is disabled for the entire system prior to having a CPU
* die, in particular prior to this dying CPU having exited the coherency
@@ -253,9 +253,7 @@ static int b15_rac_dead_cpu(unsigned int cpu)
return 0;
}
-#endif /* CONFIG_HOTPLUG_CPU */
-#ifdef CONFIG_PM_SLEEP
static int b15_rac_suspend(void)
{
/* Suspend the read-ahead cache oeprations, forcing our cache
@@ -286,7 +284,6 @@ static struct syscore_ops b15_rac_syscore_ops = {
.suspend = b15_rac_suspend,
.resume = b15_rac_resume,
};
-#endif
static int __init b15_rac_init(void)
{
@@ -315,23 +312,22 @@ static int __init b15_rac_init(void)
goto out;
}
-#ifdef CONFIG_HOTPLUG_CPU
- ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DEAD,
+ if (IS_ENABLED(CONFIG_HOTPLUG_CPU)) {
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DEAD,
"arm/cache-b15-rac:dead",
NULL, b15_rac_dead_cpu);
- if (ret)
- goto out_unmap;
+ if (ret)
+ goto out_unmap;
- ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
+ ret = cpuhp_setup_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
"arm/cache-b15-rac:dying",
NULL, b15_rac_dying_cpu);
- if (ret)
- goto out_cpu_dead;
-#endif
+ if (ret)
+ goto out_cpu_dead;
+ }
-#ifdef CONFIG_PM_SLEEP
- register_syscore_ops(&b15_rac_syscore_ops);
-#endif
+ if (IS_ENABLED(CONFIG_PM_SLEEP))
+ register_syscore_ops(&b15_rac_syscore_ops);
spin_lock(&rac_lock);
reg = __raw_readl(b15_rac_base + RAC_CONFIG0_REG);
--
2.9.0
^ permalink raw reply related
* [PATCH v2] arm: kirkwood: dts: Use lower case for bindings notation
From: Gregory CLEMENT @ 2017-12-18 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215214354.GA31157@lunn.ch>
Hi Mathieu,
On ven., d?c. 15 2017, Andrew Lunn <andrew@lunn.ch> wrote:
> On Fri, Dec 15, 2017 at 06:07:11PM +0100, Mathieu Malaterre wrote:
>> Improve the DTS files using lower case to fix the following dtc warnings:
>>
>> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>>
>> Converted using the following command:
>>
>> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>>
>> For simplicity, two sed expressions were used to solve each warnings separately.
>>
>> To make the regex expression more robust a few other issues were resolved,
>> namely setting unit-address to lower case, and adding a whitespace before the
>> the opening curly brace:
>>
>> https://elinux.org/Device_Tree_Linux#Linux_conventions
>>
>> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>>
>> Reported-by: David Daney <ddaney@caviumnetworks.com>
>> Suggested-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>
> Thanks for fixing up the commit message.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Applied on mvebu/dt
Thanks,
Gregory
>
> Andrew
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 06/10] arm64: handle 52-bit physical addresses in page table entries
From: Suzuki K Poulose @ 2017-12-18 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513184845-8711-7-git-send-email-kristina.martsenko@arm.com>
On 13/12/17 17:07, Kristina Martsenko wrote:
> The top 4 bits of a 52-bit physical address are positioned at bits
> 12..15 of a page table entry. Introduce macros to convert between a
> physical address and its placement in a table entry, and change all
> macros/functions that access PTEs to use them.
>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Kristina
Patch looks good, except for a couple of nits below
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> index c59c69e02036..60e0432df559 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -168,10 +168,12 @@
> #define PTE_UXN (_AT(pteval_t, 1) << 54) /* User XN */
> #define PTE_HYP_XN (_AT(pteval_t, 1) << 54) /* HYP XN */
>
> -#ifdef CONFIG_ARM64_PA_BITS_52
> #define PTE_ADDR_LOW (((_AT(pteval_t, 1) << (48 - PAGE_SHIFT)) - 1) << PAGE_SHIFT)
> +#ifdef CONFIG_ARM64_PA_BITS_52
> #define PTE_ADDR_HIGH (_AT(pteval_t, 0xf) << 12)
> -#define PTE_ADDR_MASK_52 (PTE_ADDR_LOW | PTE_ADDR_HIGH)
> +#define PTE_ADDR_MASK (PTE_ADDR_LOW | PTE_ADDR_HIGH)
> +#else
> +#define PTE_ADDR_MASK PTE_ADDR_LOW
> #endif
>
> /*
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 5d9554fb2692..65856a81e692 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -57,9 +57,20 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
>
> #define pte_ERROR(pte) __pte_error(__FILE__, __LINE__, pte_val(pte))
>
> -#define pte_pfn(pte) ((pte_val(pte) & PHYS_MASK) >> PAGE_SHIFT)
> +/*
> + * Macros to convert between a physical address and its placement in a
> + * page table entry, taking care of 52-bit addresses.
> + */
> +#ifdef CONFIG_ARM64_PA_BITS_52
> +#define __pte_to_phys(pte) ((pte_val(pte) & PTE_ADDR_LOW) | ((pte_val(pte) & PTE_ADDR_HIGH) << 36))
nit: The line is too long, 100+, it may be worth putting it in a separate line :
i.e,
+#define __pte_to_phys(pte) \
((pte_val(pte) & PTE_ADDR_LOW) | ((pte_val(pte) & PTE_ADDR_HIGH) << 36))
similarly below.
> +#define __phys_to_pte_val(phys) (((phys) | ((phys) >> 36)) & PTE_ADDR_MASK)
> +#else
> +#define __pte_to_phys(pte) (pte_val(pte) & PTE_ADDR_MASK)
> +#define __phys_to_pte_val(phys) (phys)
> +#endif
>
> -#define pfn_pte(pfn,prot) (__pte(((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)))
> +#define pte_pfn(pte) (__pte_to_phys(pte) >> PAGE_SHIFT)
> +#define pfn_pte(pfn,prot) __pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
>
> #define pte_none(pte) (!pte_val(pte))
> #define pte_clear(mm,addr,ptep) set_pte(ptep, __pte(0))
> @@ -284,6 +295,11 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
>
> #define __HAVE_ARCH_PTE_SPECIAL
>
> +static inline pte_t pgd_pte(pgd_t pgd)
> +{
> + return __pte(pgd_val(pgd));
> +}
> +
> static inline pte_t pud_pte(pud_t pud)
> {
> return __pte(pud_val(pud));
> @@ -349,16 +365,24 @@ static inline int pmd_protnone(pmd_t pmd)
>
> #define pmd_mkhuge(pmd) (__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
>
> -#define pmd_pfn(pmd) (((pmd_val(pmd) & PMD_MASK) & PHYS_MASK) >> PAGE_SHIFT)
> -#define pfn_pmd(pfn,prot) (__pmd(((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)))
> +#define __pmd_to_phys(pmd) __pte_to_phys(pmd_pte(pmd))
> +#define __phys_to_pmd_val(phys) __phys_to_pte_val(phys)
> +#define pmd_pfn(pmd) ((__pmd_to_phys(pmd) & PMD_MASK) >> PAGE_SHIFT)
> +#define pfn_pmd(pfn,prot) __pmd(__phys_to_pmd_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
> #define mk_pmd(page,prot) pfn_pmd(page_to_pfn(page),prot)
>
> #define pud_write(pud) pte_write(pud_pte(pud))
> -#define pud_pfn(pud) (((pud_val(pud) & PUD_MASK) & PHYS_MASK) >> PAGE_SHIFT)
> -#define pfn_pud(pfn,prot) (__pud(((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)))
> +
> +#define __pud_to_phys(pud) __pte_to_phys(pud_pte(pud))
> +#define __phys_to_pud_val(phys) __phys_to_pte_val(phys)
> +#define pud_pfn(pud) ((__pud_to_phys(pud) & PUD_MASK) >> PAGE_SHIFT)
> +#define pfn_pud(pfn,prot) __pud(__phys_to_pud_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
>
> #define set_pmd_at(mm, addr, pmdp, pmd) set_pte_at(mm, addr, (pte_t *)pmdp, pmd_pte(pmd))
>
> +#define __pgd_to_phys(pgd) __pte_to_phys(pgd_pte(pgd))
> +#define __phys_to_pgd_val(phys) __phys_to_pte_val(phys)
> +
> #define __pgprot_modify(prot,mask,bits) \
> __pgprot((pgprot_val(prot) & ~(mask)) | (bits))
>
> @@ -409,7 +433,7 @@ static inline void pmd_clear(pmd_t *pmdp)
>
> static inline phys_addr_t pmd_page_paddr(pmd_t pmd)
> {
> - return pmd_val(pmd) & PHYS_MASK & (s32)PAGE_MASK;
> + return __pmd_to_phys(pmd);
> }
>
> /* Find an entry in the third-level page table. */
> @@ -427,7 +451,7 @@ static inline phys_addr_t pmd_page_paddr(pmd_t pmd)
> #define pte_set_fixmap_offset(pmd, addr) pte_set_fixmap(pte_offset_phys(pmd, addr))
> #define pte_clear_fixmap() clear_fixmap(FIX_PTE)
>
> -#define pmd_page(pmd) pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
> +#define pmd_page(pmd) pfn_to_page(__phys_to_pfn(__pmd_to_phys(pmd)))
You could simplify the above to :
#define pmd_page(pmd) pfn_to_page(pmd_pfn(pmd))
? similarly for pud_page.
Other than the above nits:
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH v4 12/12] ARM64: dts: marvell: Add thermal support for A7K/A8K
From: Gregory CLEMENT @ 2017-12-18 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-13-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Add thermal DT nodes in AP806 and CP110 master/slave DTSI files.
>
> Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Applied on mvebu/dt64 (but not yet in linux-next)
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 6 ++++++
> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 6 ++++++
> arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 6 ++++++
> 3 files changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> index 1c4dd8ab9ad5..bbc5a4d3acac 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -285,6 +285,12 @@
> gpio-ranges = <&ap_pinctrl 0 0 20>;
> };
> };
> +
> + ap_thermal: thermal at 6f808C {
> + compatible = "marvell,armada-ap806-thermal";
> + reg = <0x6f808C 0x4>,
> + <0x6f8084 0x8>;
> + };
> };
> };
> };
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index e3b64d03fbd8..ecbc76d26dff 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -182,6 +182,12 @@
> interrupts = <ICU_GRP_NSR 77 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> + cpm_thermal: thermal at 400078 {
> + compatible = "marvell,armada-cp110-thermal";
> + reg = <0x400078 0x4>,
> + <0x400070 0x8>;
> + };
> +
> cpm_syscon0: system-controller at 440000 {
> compatible = "syscon", "simple-mfd";
> reg = <0x440000 0x2000>;
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index 0d51096c69f8..29ba32c68870 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -182,6 +182,12 @@
> interrupts = <ICU_GRP_NSR 77 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> + cps_thermal: thermal at 400078 {
> + compatible = "marvell,armada-cp110-thermal";
> + reg = <0x400078 0x4>,
> + <0x400070 0x8>;
> + };
> +
> cps_syscon0: system-controller at 440000 {
> compatible = "syscon", "simple-mfd";
> reg = <0x440000 0x2000>;
> --
> 2.11.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 v4 11/12] thermal: armada: Give meaningful names to the thermal zones
From: Gregory CLEMENT @ 2017-12-18 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-12-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> After registration to the thermal core, sysfs will make one entry
> per instance of the driver in /sys/class/thermal_zoneX and
> /sys/class/hwmon/hwmonX, X being the index of the instance, all of them
> having the type/name "armada_thermal".
>
> Until now there was only one thermal zone per SoC but SoCs like Armada
> A7K and Armada A8K have respectively two and three thermal zones (one
> per AP and one per CP) and this number is subject to grow in the future.
>
> Use dev_name() instead of the "armada_thermal" string to get a
> meaningful name and be able to identify the thermal zones from
> userspace.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
> ---
> drivers/thermal/armada_thermal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 4a5164ddffe7..42ef80b3b5f8 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -403,8 +403,8 @@ static int armada_thermal_probe(struct platform_device *pdev)
>
> priv->data->init_sensor(pdev, priv);
>
> - thermal = thermal_zone_device_register("armada_thermal", 0, 0,
> - priv, &ops, NULL, 0, 0);
> + thermal = thermal_zone_device_register(dev_name(&pdev->dev), 0, 0, priv,
> + &ops, NULL, 0, 0);
> if (IS_ERR(thermal)) {
> dev_err(&pdev->dev,
> "Failed to register thermal zone device\n");
> --
> 2.11.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 v4 10/12] thermal: armada: Wait sensors validity before exiting the init callback
From: Gregory CLEMENT @ 2017-12-18 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-11-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> The thermal core will check for sensors validity right after the
> initialization callback has returned. As the initialization routine make
> a reset, the sensors are not ready immediately and the core spawns an
> error in the dmesg. Avoid this annoying situation by polling on the
> validity bit before exiting from these routines. This also avoid the use
> of blind sleeps.
>
> Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 2eadd662591d..4a5164ddffe7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -23,6 +23,7 @@
> #include <linux/platform_device.h>
> #include <linux/of_device.h>
> #include <linux/thermal.h>
> +#include <linux/iopoll.h>
>
> /* Thermal Manager Control and Status Register */
> #define PMU_TDC0_SW_RST_MASK (0x1 << 1)
> @@ -59,6 +60,9 @@
> #define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
> #define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
>
> +#define STATUS_POLL_PERIOD_US 1000
> +#define STATUS_POLL_TIMEOUT_US 100000
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -155,6 +159,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
> msleep(50);
> }
>
> +static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
> +{
> + u32 reg;
> +
> + readl_relaxed_poll_timeout(priv->status, reg,
> + reg & priv->data->is_valid_bit,
> + STATUS_POLL_PERIOD_US,
> + STATUS_POLL_TIMEOUT_US);
> +}
> +
> static void armada380_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> @@ -164,7 +178,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
> reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> writel(reg, priv->control1);
> - msleep(10);
>
> /* Set Tsen Tc Trim to correct default value (errata #132698) */
> if (priv->control0) {
> @@ -172,8 +185,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
> reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
> reg |= CONTROL0_TSEN_TC_TRIM_VAL;
> writel(reg, priv->control0);
> - msleep(10);
> }
> +
> + /* Wait the sensors to be valid or the core will warn the user */
> + armada_wait_sensor_validity(priv);
> }
>
> static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -185,7 +200,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
> reg &= ~CONTROL0_TSEN_RESET;
> reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> writel(reg, priv->control0);
> - msleep(10);
> +
> + /* Wait the sensors to be valid or the core will warn the user
Just out of curiosity but how the core will warn the user?
Gregory
> */
> + armada_wait_sensor_validity(priv);
> }
>
> static bool armada_is_valid(struct armada_thermal_priv *priv)
> --
> 2.11.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 v4 09/12] thermal: armada: Change sensors trim default value
From: Gregory CLEMENT @ 2017-12-18 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-10-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Errata #132698 highlights an error in the default value of Tc trim.
> Set this parameter to b'011.
>
> Suggested-by: David Sniatkiwicz <davidsn@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
> ---
> drivers/thermal/armada_thermal.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index cef5c65c8f32..2eadd662591d 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -46,6 +46,10 @@
> #define CONTROL0_OFFSET 0x0
> #define CONTROL1_OFFSET 0x4
>
> +/* Errata fields */
> +#define CONTROL0_TSEN_TC_TRIM_MASK 0x7
> +#define CONTROL0_TSEN_TC_TRIM_VAL 0x3
> +
> /* TSEN refers to the temperature sensors within the AP */
> #define CONTROL0_TSEN_START BIT(0)
> #define CONTROL0_TSEN_RESET BIT(1)
> @@ -161,6 +165,15 @@ static void armada380_init_sensor(struct platform_device *pdev,
> reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> writel(reg, priv->control1);
> msleep(10);
> +
> + /* Set Tsen Tc Trim to correct default value (errata #132698) */
> + if (priv->control0) {
> + reg = readl_relaxed(priv->control0);
> + reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
> + reg |= CONTROL0_TSEN_TC_TRIM_VAL;
> + writel(reg, priv->control0);
> + msleep(10);
> + }
> }
>
> static void armada_ap806_init_sensor(struct platform_device *pdev,
> --
> 2.11.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 v4 08/12] thermal: armada: Update Kconfig and module description
From: Gregory CLEMENT @ 2017-12-18 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-9-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Update Armada thermal driver Kconfig entry as well as the driver's
> MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
> eg. Armada 7K and Armada 8K.
>
> Use the generic term "Marvell EBU Armada SoCs" instead of listing all
> the supported SoCs everywhere (excepted in the Kconfig description,
> where it is useful to have a list).
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
> ---
> drivers/thermal/Kconfig | 4 ++--
> drivers/thermal/armada_thermal.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 315ae2926e20..b6adc54b96f1 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -301,13 +301,13 @@ config DB8500_THERMAL
> thermal zone if trip points reached.
>
> config ARMADA_THERMAL
> - tristate "Armada 370/XP thermal management"
> + tristate "Marvell EBU Armada SoCs thermal management"
> depends on ARCH_MVEBU || COMPILE_TEST
> depends on HAS_IOMEM
> depends on OF
> help
> Enable this option if you want to have support for thermal management
> - controller present in Armada 370 and Armada XP SoC.
> + controller present in Marvell EBU Armada SoCs (370,375,XP,38x,7K,8K).
>
> config DA9062_THERMAL
> tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 11a94ad66c35..cef5c65c8f32 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -1,5 +1,5 @@
> /*
> - * Marvell Armada 370/XP thermal sensor driver
> + * Marvell EBU Armada SoCs thermal sensor driver
> *
> * Copyright (C) 2013 Marvell
> *
> @@ -408,5 +408,5 @@ static struct platform_driver armada_thermal_driver = {
> module_platform_driver(armada_thermal_driver);
>
> MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia@free-electrons.com>");
> -MODULE_DESCRIPTION("Armada 370/XP thermal driver");
> +MODULE_DESCRIPTION("Marvell EBU Armada SoCs thermal driver");
> MODULE_LICENSE("GPL v2");
> --
> 2.11.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 v4 07/12] thermal: armada: Add support for Armada CP110
From: Gregory CLEMENT @ 2017-12-18 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-8-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> From: Baruch Siach <baruch@tkos.co.il>
>
> The CP110 component is integrated in the Armada 8k and 7k lines of
> processors.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> [<miquel.raynal@free-electrons.com>: renamed the register pointers as
> well as some definitions related to the new register names and
> simplified the init sequence for Armada 380]
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
> ---
> drivers/thermal/armada_thermal.c | 33 ++++++++++++++++++++++++++-------
> 1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index ec29ea76b818..11a94ad66c35 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -37,7 +37,6 @@
> #define A375_UNIT_CONTROL_MASK 0x7
> #define A375_READOUT_INVERT BIT(15)
> #define A375_HW_RESETn BIT(8)
> -#define A380_HW_RESET BIT(8)
>
> /* Legacy bindings */
> #define LEGACY_CONTROL_MEM_LEN 0x4
> @@ -52,6 +51,10 @@
> #define CONTROL0_TSEN_RESET BIT(1)
> #define CONTROL0_TSEN_ENABLE BIT(2)
>
> +/* EXT_TSEN refers to the external temperature sensors, out of the AP */
> +#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
> +#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -153,12 +156,11 @@ static void armada380_init_sensor(struct platform_device *pdev,
> {
> u32 reg = readl_relaxed(priv->control1);
>
> - /* Reset hardware once */
> - if (!(reg & A380_HW_RESET)) {
> - reg |= A380_HW_RESET;
> - writel(reg, priv->control1);
> - msleep(10);
> - }
> + /* Disable the HW/SW reset */
> + reg |= CONTROL1_EXT_TSEN_HW_RESETn;
> + reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
> + writel(reg, priv->control1);
> + msleep(10);
> }
>
> static void armada_ap806_init_sensor(struct platform_device *pdev,
> @@ -278,6 +280,19 @@ static const struct armada_thermal_data armada_ap806_data = {
> .needs_control0 = true,
> };
>
> +static const struct armada_thermal_data armada_cp110_data = {
> + .is_valid = armada_is_valid,
> + .init_sensor = armada380_init_sensor,
> + .is_valid_bit = BIT(10),
> + .temp_shift = 0,
> + .temp_mask = 0x3ff,
> + .coef_b = 1172499100ULL,
> + .coef_m = 2000096ULL,
> + .coef_div = 4201,
> + .inverted = true,
> + .needs_control0 = true,
> +};
> +
> static const struct of_device_id armada_thermal_id_table[] = {
> {
> .compatible = "marvell,armadaxp-thermal",
> @@ -300,6 +315,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
> .data = &armada_ap806_data,
> },
> {
> + .compatible = "marvell,armada-cp110-thermal",
> + .data = &armada_cp110_data,
> + },
> + {
> /* sentinel */
> },
> };
> --
> 2.11.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 v4 06/12] thermal: armada: Add support for Armada AP806
From: Gregory CLEMENT @ 2017-12-18 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-7-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> From: Baruch Siach <baruch@tkos.co.il>
>
> The AP806 component is integrated in the Armada 8K and 7K lines of
> processors.
>
> The thermal sensor sample field on the status register is a signed
> value. Extend armada_get_temp() and the driver structure to handle
> signed values.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> [<miquel.raynal@free-electrons.com>: Changes when applying over the
> previous patches, including the register names changes, also switched
> the coefficients values to s64 instead of unsigned long to deal with
> negative values and used do_div instead of the traditionnal '/']
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
I am just a little concerned by the fac that the value pass though
get_temp() is an int and now the intermediate calculation are in
s64. But maybe I'm too picky for this,
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
> ---
> drivers/thermal/armada_thermal.c | 80 ++++++++++++++++++++++++++++++++--------
> 1 file changed, 65 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 198485fa77f2..ec29ea76b818 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -47,6 +47,11 @@
> #define CONTROL0_OFFSET 0x0
> #define CONTROL1_OFFSET 0x4
>
> +/* TSEN refers to the temperature sensors within the AP */
> +#define CONTROL0_TSEN_START BIT(0)
> +#define CONTROL0_TSEN_RESET BIT(1)
> +#define CONTROL0_TSEN_ENABLE BIT(2)
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> @@ -66,15 +71,17 @@ struct armada_thermal_data {
> bool (*is_valid)(struct armada_thermal_priv *);
>
> /* Formula coeficients: temp = (b - m * reg) / div */
> - unsigned long coef_b;
> - unsigned long coef_m;
> - unsigned long coef_div;
> + s64 coef_b;
> + s64 coef_m;
> + u32 coef_div;
> bool inverted;
> + bool signed_sample;
>
> /* Register shift and mask to access the sensor temperature */
> unsigned int temp_shift;
> unsigned int temp_mask;
> u32 is_valid_bit;
> + bool needs_control0;
> };
>
> static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -154,6 +161,18 @@ static void armada380_init_sensor(struct platform_device *pdev,
> }
> }
>
> +static void armada_ap806_init_sensor(struct platform_device *pdev,
> + struct armada_thermal_priv *priv)
> +{
> + u32 reg;
> +
> + reg = readl_relaxed(priv->control0);
> + reg &= ~CONTROL0_TSEN_RESET;
> + reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> + writel(reg, priv->control0);
> + msleep(10);
> +}
> +
> static bool armada_is_valid(struct armada_thermal_priv *priv)
> {
> u32 reg = readl_relaxed(priv->status);
> @@ -165,8 +184,8 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> int *temp)
> {
> struct armada_thermal_priv *priv = thermal->devdata;
> - unsigned long reg;
> - unsigned long m, b, div;
> + u32 reg, div;
> + s64 sample, b, m;
>
> /* Valid check */
> if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> @@ -177,6 +196,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
>
> reg = readl_relaxed(priv->status);
> reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
> + if (priv->data->signed_sample)
> + /* The most significant bit is the sign bit */
> + sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
> + else
> + sample = reg;
>
> /* Get formula coeficients */
> b = priv->data->coef_b;
> @@ -184,9 +208,12 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> div = priv->data->coef_div;
>
> if (priv->data->inverted)
> - *temp = ((m * reg) - b) / div;
> + *temp = (m * sample) - b;
> else
> - *temp = (b - (m * reg)) / div;
> + *temp = b - (m * sample);
> +
> + do_div(*temp, div);
> +
> return 0;
> }
>
> @@ -198,8 +225,8 @@ static const struct armada_thermal_data armadaxp_data = {
> .init_sensor = armadaxp_init_sensor,
> .temp_shift = 10,
> .temp_mask = 0x1ff,
> - .coef_b = 3153000000UL,
> - .coef_m = 10000000UL,
> + .coef_b = 3153000000ULL,
> + .coef_m = 10000000ULL,
> .coef_div = 13825,
> };
>
> @@ -209,8 +236,8 @@ static const struct armada_thermal_data armada370_data = {
> .is_valid_bit = BIT(9),
> .temp_shift = 10,
> .temp_mask = 0x1ff,
> - .coef_b = 3153000000UL,
> - .coef_m = 10000000UL,
> + .coef_b = 3153000000ULL,
> + .coef_m = 10000000ULL,
> .coef_div = 13825,
> };
>
> @@ -220,8 +247,8 @@ static const struct armada_thermal_data armada375_data = {
> .is_valid_bit = BIT(10),
> .temp_shift = 0,
> .temp_mask = 0x1ff,
> - .coef_b = 3171900000UL,
> - .coef_m = 10000000UL,
> + .coef_b = 3171900000ULL,
> + .coef_m = 10000000ULL,
> .coef_div = 13616,
> };
>
> @@ -231,12 +258,26 @@ static const struct armada_thermal_data armada380_data = {
> .is_valid_bit = BIT(10),
> .temp_shift = 0,
> .temp_mask = 0x3ff,
> - .coef_b = 1172499100UL,
> - .coef_m = 2000096UL,
> + .coef_b = 1172499100ULL,
> + .coef_m = 2000096ULL,
> .coef_div = 4201,
> .inverted = true,
> };
>
> +static const struct armada_thermal_data armada_ap806_data = {
> + .is_valid = armada_is_valid,
> + .init_sensor = armada_ap806_init_sensor,
> + .is_valid_bit = BIT(16),
> + .temp_shift = 0,
> + .temp_mask = 0x3ff,
> + .coef_b = -150000LL,
> + .coef_m = 423ULL,
> + .coef_div = 1,
> + .inverted = true,
> + .signed_sample = true,
> + .needs_control0 = true,
> +};
> +
> static const struct of_device_id armada_thermal_id_table[] = {
> {
> .compatible = "marvell,armadaxp-thermal",
> @@ -255,6 +296,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
> .data = &armada380_data,
> },
> {
> + .compatible = "marvell,armada-ap806-thermal",
> + .data = &armada_ap806_data,
> + },
> + {
> /* sentinel */
> },
> };
> @@ -296,6 +341,11 @@ static int armada_thermal_probe(struct platform_device *pdev)
> */
> if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> /* ->control0 unavailable in this configuration */
> + if (priv->data->needs_control0) {
> + dev_err(&pdev->dev, "No access to control0 register\n");
> + return -EINVAL;
> + }
> +
> priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> } else {
> priv->control0 = control + CONTROL0_OFFSET;
> --
> 2.11.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 v4 05/12] thermal: armada: Use real status register name
From: Gregory CLEMENT @ 2017-12-18 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218143643.7714-6-miquel.raynal@free-electrons.com>
Hi Miquel,
On lun., d?c. 18 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Three 32-bit registers are used to drive the thermal IP: control0,
> control1 and status. The two control registers share the same name both
> in the documentation and in the code, while the latter is referred as
> "sensor" in the code. Rename this pointer to be called "status" in order
> to be aligned with the documentation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
> ---
> drivers/thermal/armada_thermal.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index f422563e617c..198485fa77f2 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -51,7 +51,7 @@ struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> struct armada_thermal_priv {
> - void __iomem *sensor;
> + void __iomem *status;
> void __iomem *control0;
> void __iomem *control1;
> struct armada_thermal_data *data;
> @@ -98,9 +98,9 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
> writel(reg, priv->control1);
>
> /* Enable the sensor */
> - reg = readl_relaxed(priv->sensor);
> + reg = readl_relaxed(priv->status);
> reg &= ~PMU_TM_DISABLE_MASK;
> - writel(reg, priv->sensor);
> + writel(reg, priv->status);
> }
>
> static void armada370_init_sensor(struct platform_device *pdev,
> @@ -156,7 +156,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
>
> static bool armada_is_valid(struct armada_thermal_priv *priv)
> {
> - u32 reg = readl_relaxed(priv->sensor);
> + u32 reg = readl_relaxed(priv->status);
>
> return reg & priv->data->is_valid_bit;
> }
> @@ -175,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> return -EIO;
> }
>
> - reg = readl_relaxed(priv->sensor);
> + reg = readl_relaxed(priv->status);
> reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>
> /* Get formula coeficients */
> @@ -277,9 +277,9 @@ static int armada_thermal_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(priv->sensor))
> - return PTR_ERR(priv->sensor);
> + priv->status = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->status))
> + return PTR_ERR(priv->status);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> control = devm_ioremap_resource(&pdev->dev, res);
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2017-12-18 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8_6y3dU81ZS4WWCfpRZkfjGo_+_K--e3go_3_xXwBErQ@mail.gmail.com>
Hi Ard
2017-12-18 10:40 GMT+01:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
> 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.
>
Thanks. Tomasz Nowicki immediately pointed this to me off the lists.
> 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.
>
Already a lot of drivers use both DT + ACPI. Some have IMO very
fanciful bindings in both, mostly handled within the drivers with
custom functions. OF_ - only drivers can use of_mdio_ helper routines,
that assume a certain hierarchy:
MDIO device node with PHYs as children, which are referenced in the
ports node. I believe such approach could fit ACPI description too.
I'm aware however that my code is pretty much DT transposed into ACPI
environment and I'm of course open to discussion, how to do it in the
most proper way.
My main goal is to provide an fwnode-based glue code, that can be used
among the NIC/MDIO drivers (+ phylink) without multiple ifs
differentiating between ACPI/OF. What I sent has single calls in
mvpp2/mvmdio with a common bottom layers, but I don't see a problem,
that, e.g. when iterating over PHY subnodes, in case of OF
'reg'/'compatible' are used, whereas with ACPI some specific _ADR/_CID
objects.
I'd appreaciate any feedback.
Best regards,
Marcin
> 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
^ permalink raw reply
* [PATCH v5 7/9] arm64: Topology, rename cluster_id
From: Lorenzo Pieralisi @ 2017-12-18 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218124229.GG507@e105550-lin.cambridge.arm.com>
On Mon, Dec 18, 2017 at 12:42:29PM +0000, Morten Rasmussen wrote:
> On Fri, Dec 15, 2017 at 10:36:35AM -0600, Jeremy Linton wrote:
> > Hi,
> >
> > On 12/13/2017 12:02 PM, Lorenzo Pieralisi wrote:
> > >[+Morten, Dietmar]
> > >
> > >$SUBJECT should be:
> > >
> > >arm64: topology: rename cluster_id
> >
> > Sure..
> >
> > >
> > >On Fri, Dec 01, 2017 at 04:23:28PM -0600, Jeremy Linton wrote:
> > >>Lets match the name of the arm64 topology field
> > >>to the kernel macro that uses it.
> > >>
> > >>Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> > >>---
> > >> arch/arm64/include/asm/topology.h | 4 ++--
> > >> arch/arm64/kernel/topology.c | 27 ++++++++++++++-------------
> > >> 2 files changed, 16 insertions(+), 15 deletions(-)
> > >>
> > >>diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> > >>index c4f2d50491eb..118136268f66 100644
> > >>--- a/arch/arm64/include/asm/topology.h
> > >>+++ b/arch/arm64/include/asm/topology.h
> > >>@@ -7,14 +7,14 @@
> > >> struct cpu_topology {
> > >> int thread_id;
> > >> int core_id;
> > >>- int cluster_id;
> > >>+ int physical_id;
> > >
> > >package_id ?
> >
> > Given the macro is topology_physical_package_id, either makes sense to me.
> > <shrug> I will change it in the next set.
>
> I would vote for package_id too. arch/arm has 'socket_id' though.
>
> > >
> > >It has been debated before, I know. Should we keep the cluster_id too
> > >(even if it would be 1:1 mapped to package_id - for now) ?
> >
> > Well given that this patch replaces the patch that did that at your
> > request..
> >
> > I was hoping someone else would comment here, but my take at this point is
> > that it doesn't really matter in a functional sense at the moment.
> > Like the chiplet discussion it can be the subject of a future patch along
> > with the patches which tweak the scheduler to understand the split.
> >
> > BTW, given that i'm OoO next week, and the following that are the holidays,
> > I don't intend to repost this for a couple weeks. I don't think there are
> > any issues with this set.
> >
> > >
> > >There is also arch/arm to take into account, again, this patch is
> > >just renaming (as it should have named since the beginning) a
> > >topology level but we should consider everything from a legacy
> > >perspective.
>
> arch/arm has gone for thread/core/socket for the three topology levels
> it supports.
>
> I'm not sure what short term value keeping cluster_id has? Isn't it just
> about where we make the package = cluster assignment? Currently it is in
> the definition of topology_physical_package_id. If we keep cluster_id
> and add package_id, it gets moved into the MPIDR/DT parsing code.
>
> Keeping cluster_id and introducing a topology_cluster_id function could
> help cleaning up some of the users of topology_physical_package_id that
> currently assumes package_id == cluster_id though.
I think we should settle for a name (eg package_id), remove cluster_id
and convert arch/arm socket_id to the same naming used on arm64 (for
consistency - it is just a variable rename).
This leaves us with the naming "cluster" only in DT topology bindings,
which should be fine, given that "cluster" in that context is just a
"processor-container" - yes we could have chosen a better naming in
the first place but that's what it is.
We should nuke the existing users of topology_physical_package_id()
to identify clusters, I would not add another function for that purpose,
let's nip it in the bud.
Lorenzo
^ permalink raw reply
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-18 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218111819.nsu4dd6wacdud3lc@verge.net.au>
Hello Simon,
> > Hello Geert,
> >
> > thank you for your feedback.
> >
> > > Hi Fabrizio,
> > >
> > > On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
> > > <fabrizio.castro@bp.renesas.com> wrote:
> > > >> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
> > > >> > Add CMT[01] support to SoC DT.
> > > >> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > >> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > > >> > ---
> > > >> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
> > > >> > 1 file changed, 30 insertions(+)
> > > >>
> > > >> I was expecting the cmt nodes to be "disabled" in the SoC file
> > > >> and then enabled selectively in board files. Am I missing something?
> > > >
> > > > Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific
> DT.
> > > > The system will park it and leave its clock disabled until actually needed for something.
> > > > The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it
> > > disabled by default?
> > >
> > > It's debatable (thus up to Simon the maintainer ;-).
> > > For I/O devices, we disable them in the SoC .dtsi file.
> > > For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
> > > them enabled.
> > >
> > > Timers are core functionality, but who's actually using these timers?
> >
> > I don't have a use case in mind unfortunately, but it's still core
> > functionality and pretty harmless as far as I can tell. Let's see what
> > Simon thinks about this.
>
> On Renesas SoCs we have a bit more flexibility with timers than might
> be the case on other SoCs. Thus I'd like to keep with the scheme of
> disabling them in .dtsi and enabling them when they are needed.
>
> Please update the patches.
Ok, I'll send a v2.
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 0/2] arm64 SMMUv3 PMU driver with IORT support
From: Marc Zyngier @ 2017-12-18 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <999b7132-2de8-2872-1067-fc7e02cbc57a@arm.com>
Thanks for putting me in the loop Robin.
On 18/12/17 14:48, Robin Murphy wrote:
> On 10/12/17 02:35, Linu Cherian wrote:
>> Hi,
>>
>>
>> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
>>> This adds a driver for the SMMUv3 PMU into the perf framework.
>>> It includes an IORT update to support PM Counter Groups.
>>>
>>
>> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
>> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
>> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
>> are managed by two independent drivers.
>>
>> The problem arises when we want to alloc/free MSIs for these devices
>> using the APIs, platform_msi_domain_alloc/free_irqs.
>> Platform bus id being same for these two hardware blocks, they end up sharing the same
>> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
>> of this shared ITT becomes a problem when they are managed by two independent
>> drivers.
>
> What is the problem exactly? IIRC resizing a possibly-live ITT is a
> right pain in the bum to do - is it just that?
Understatement of the day! ;-) Yes, it is a massive headache, and will
either result in a temporary loss of interrupts (at some point you have
to unmap the ITT), or with spurious interrupts (you generate interrupts
for all the MSIs you've blackholed when unmapping the ITT).
>
>> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under
>> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors
>> required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs
>> function call for all devices that share the platform bus id.
>
> I'm not sure how scalable that approach would be, since it's not
> entirely obvious how to handle PMCGs associated with named components or
> root complexes (rather than directly with SMMU instances). We certainly
> don't want to end up spraying similar PMCG DevID logic around all manner
> of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs
> will be expected to have distinct IDs from their host devices, they
> could reasonably still overlap with other PMCGs/SMMUs).
>
>> Would like to know your expert opinion on what would be the right approach
>> to handle this case ?
>
> My gut feeling says the way to deal with this properly is in the ITS
> code, but I appreciate that that's a lot easier said than done :/
I can revive the hack I once wrote for that (and that was hoping to
forever forget), but that's pretty disgusting, and subject to the above
caveat.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ 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