* Re: [PATCH v7 2/3] clk: at91: allow setting PCKx parent via DT
From: Stephen Boyd @ 2020-05-27 3:23 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches, Michael Turquette,
Michał Mirosław, Nicolas Ferre, Rob Herring
Cc: devicetree, linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <0054532c00163ddf405dad658b32f0d7d97fcc8e.1588630999.git.mirq-linux@rere.qmqm.pl>
Quoting Michał Mirosław (2020-05-04 15:37:56)
> This exposes PROGx clocks for use in assigned-clocks DeviceTree property
> for selecting PCKx parent clock.
>
> Signed-off-by: Micha\u0142 Miros\u0142aw <mirq-linux@rere.qmqm.pl>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] clk: at91: pmc: decrement node's refcount
From: Stephen Boyd @ 2020-05-27 3:22 UTC (permalink / raw)
To: Claudiu Beznea, alexandre.belloni, ludovic.desroches, mturquette,
nicolas.ferre
Cc: Claudiu Beznea, linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <1588508289-10140-2-git-send-email-claudiu.beznea@microchip.com>
Quoting Claudiu Beznea (2020-05-03 05:18:09)
> of_find_matching_node() increment node's refcount. Call
> of_node_put() to decrement it after it was used.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] clk: at91: pmc: do not continue if compatible not located
From: Stephen Boyd @ 2020-05-27 3:22 UTC (permalink / raw)
To: Claudiu Beznea, alexandre.belloni, ludovic.desroches, mturquette,
nicolas.ferre
Cc: Claudiu Beznea, linux-clk, linux-arm-kernel, linux-kernel
In-Reply-To: <1588508289-10140-1-git-send-email-claudiu.beznea@microchip.com>
Quoting Claudiu Beznea (2020-05-03 05:18:08)
> pmc_register_ops() is called for all AT91 devices. Return
> -ENODEV in case of_find_matching_node() returns NULL.
>
> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: at91: Add peripheral clock for PTC
From: Stephen Boyd @ 2020-05-27 3:21 UTC (permalink / raw)
To: Codrin Ciubotariu, linux-arm-kernel, linux-clk, linux-kernel
Cc: alexandre.belloni, mturquette, ludovic.desroches, eugen.hristev,
Codrin Ciubotariu
In-Reply-To: <20200515142720.290206-1-codrin.ciubotariu@microchip.com>
Quoting Codrin Ciubotariu (2020-05-15 07:27:20)
> PMC generates the peripheral clock for the PTC.
>
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: kdump: Getting "warn_alloc" warning during boot of kdump kernel
From: Prabhakar Kushwaha @ 2020-05-27 3:14 UTC (permalink / raw)
To: linux-arm-kernel, kexec mailing list
Cc: John Donnelly, Ganapatrao Prabhakerrao Kulkarni, Catalin Marinas,
Bhupesh Sharma, Kamlakant Patel, Prabhakar Kushwaha, Will Deacon
In-Reply-To: <CAJ2QiJJgw0Cm=XBeVvOJ8WnWB0Xfv3JEYKTQUovnwrrDw17w9g@mail.gmail.com>
Hi All,
On Fri, May 15, 2020 at 4:28 PM Prabhakar Kushwaha
<prabhakar.pkin@gmail.com> wrote:
>
> Hi All,
>
> We are getting "warn_alloc" warning during boot of kdump kernel. This
> warning is observed with latest upstream tag (v5.7-rc5).
>
> Primary/1st Kernel
> ----------------------------
> # dmesg | grep crash
> [ 0.000000] crashkernel reserved: 0x00000000d6000000 -
> 0x00000000f6000000 (512 MB)
> [ 0.000000] Kernel command line:
> BOOT_IMAGE=(hd8,gpt2)/vmlinuz-5.7.0-rc5
> root=UUID=c4050f17-526f-48a8-9804-c6b35cbb584c ro crashkernel=512M
> earlycon console=ttyAMA0
>
> # cat /proc/iomem | grep -i crash
> d6000000 - f6000000 : Crash kernel
>
> Logs from Kdump/crash kernel with warnings & dump_stack
> ------------------------------------------------------------------------
>
> [ 0.239360] swapper/0: page allocation failure: order:2,
> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> [ 0.249917] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc5 #44
> [ 0.256246] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS
> 0ACKL027 07/01/2019
> [ 0.264333] Call trace:
> [ 0.266797] dump_backtrace+0x0/0x1f8
> [ 0.270490] show_stack+0x20/0x30
> [ 0.273833] dump_stack+0xc0/0x10c
> [ 0.277263] warn_alloc+0x10c/0x178
> [ 0.280781] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
> [ 0.286584] __alloc_pages_nodemask+0x2b4/0x300
> [ 0.291156] alloc_page_interleave+0x24/0xa0
> [ 0.295464] alloc_pages_current+0xe4/0x108
> [ 0.299686] dma_atomic_pool_init+0x44/0x1a4
> [ 0.303995] do_one_initcall+0x54/0x228
> [ 0.307864] kernel_init_freeable+0x228/0x2cc
> [ 0.312263] kernel_init+0x1c/0x110
> [ 0.315781] ret_from_fork+0x10/0x18
>
> We did some debugging.
> As per commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32")
> . DMA zone has been re-defined.
> here, ZONE_DMA has a fixed range of 0x802f0000 - 0xbfffffff and
> ZONE_DMA32 has range from 0xc0000000-0xfffffffff.
>
> When bootargs is defined with "crashkernel= X" for 1st/primary kernel.
> Than X amount of memory is reserved in First kernel. This reserved
> memory is used to boot kdump/crash kernel and represented as "Crash
> kernel" in cat /prom/iomem.
>
> If some region of reserved memory(Crash kernel) **does not** fall in
> ZONE_DMA region i.e. 0x802f0000 - 0xbfffffff, this warning is
> observed.
> Other drivers like scsi_register_driver [1] also fail. We also see
> other kinds of error [2].
>
> Considering DMA_ZONE has requirement of 0x802f0000 - 0xbfffffff.
> Can we enforce "Crash kernel" to always reserved between 0x0000_0000
> to 0xc000_0000 in reserve_crashkernel() -->memblock_find_in_range()
> or
> what could be best possible solution.
>
I saw similar error https://lkml.org/lkml/2020/2/24/746 with no
solution mentioned or Luckily next time reserve fell in address range
of DMA_ZONE,
This error was mentioned in context of patch series "support
reserving crashkernel above 4G on arm64 kdump. Link
https://lkml.org/lkml/2019/12/23/411"
But this error is observable without the mentioned patch series.
As mentioned in previous mail, can we consider enforcing "Crash
kernel" to be always reserved between 0x0000_0000 - 0xc000_0000.
or any other best possible solution.
Please suggest..
--pk
>
> [1]
> ------------------------------------------------------------
> [ 21.509239] dump_backtrace+0x0/0x1f8
> [ 21.516592] show_stack+0x20/0x30
> [ 21.523248] dump_stack+0xc0/0x10c
> [ 21.530087] warn_alloc+0x10c/0x178
> [ 21.537090] __alloc_pages_slowpath.constprop.112+0xaec/0xb28
> [ 21.548644] __alloc_pages_nodemask+0x2b4/0x300
> [ 21.557750] alloc_pages_current+0x90/0x108
> [ 21.566155] alloc_slab_page+0x184/0x340
> [ 21.574030] new_slab+0x420/0x4c8
> [ 21.580681] ___slab_alloc+0x354/0x4e8
> [ 21.588207] __slab_alloc+0x28/0x58
> [ 21.595210] kmem_cache_alloc_trace+0x230/0x250
> [ 21.604316] sr_probe+0x250/0x618 [sr_mod]
> [ 21.612555] really_probe+0xe4/0x448
> [ 21.619733] driver_probe_device+0xe8/0x140
> [ 21.628136] device_driver_attach+0x7c/0x88
> [ 21.636536] __driver_attach+0xac/0x178
> [ 21.644239] bus_for_each_dev+0x7c/0xd0
> [ 21.651943] driver_attach+0x2c/0x38
> [ 21.659119] bus_add_driver+0x1a8/0x240
> [ 21.666823] driver_register+0x6c/0x128
> [ 21.674533] scsi_register_driver+0x28/0x38
> [ 21.682939] init_sr+0x40/0x10000 [sr_mod]
>
> [2]
> -------------------------------------------------------------------
> [ 21.450571] systemd-udevd: page allocation failure: order:0,
> mode:0xcc1(GFP_KERNEL|GFP_DMA),
> nodemask=(null),cpuset=/,mems_allowed=0^M
> [ 21.450571] systemd-udevd: page allocation failure: order:0,
> mode:0xcc1(GFP_KERNEL|GFP_DMA),
> nodemask=(null),cpuset=/,mems_allowed=0^M
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V5 4/4] arm64/cpufeature: Replace all open bits shift encodings with macros
From: Anshuman Khandual @ 2020-05-27 3:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, Anshuman Khandual, catalin.marinas, suzuki.poulose,
linux-kernel, James Morse, Marc Zyngier, will
In-Reply-To: <1590548619-3441-1-git-send-email-anshuman.khandual@arm.com>
There are many open bits shift encodings for various CPU ID registers that
are scattered across cpufeature. This replaces them with register specific
sensible macro definitions. This should not have any functional change.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/include/asm/sysreg.h | 28 +++++++++++++++++
arch/arm64/kernel/cpufeature.c | 53 +++++++++++++++++----------------
2 files changed, 55 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 9add104d4762..6a956b2cfb93 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -763,6 +763,7 @@
#define ID_AA64MMFR2_CNP_SHIFT 0
/* id_aa64dfr0 */
+#define ID_AA64DFR0_DOUBLELOCK_SHIFT 36
#define ID_AA64DFR0_PMSVER_SHIFT 32
#define ID_AA64DFR0_CTX_CMPS_SHIFT 28
#define ID_AA64DFR0_WRPS_SHIFT 20
@@ -815,18 +816,40 @@
#define ID_ISAR6_DP_SHIFT 4
#define ID_ISAR6_JSCVT_SHIFT 0
+#define ID_MMFR0_INNERSHR_SHIFT 28
+#define ID_MMFR0_FCSE_SHIFT 24
+#define ID_MMFR0_AUXREG_SHIFT 20
+#define ID_MMFR0_TCM_SHIFT 16
+#define ID_MMFR0_SHARELVL_SHIFT 12
+#define ID_MMFR0_OUTERSHR_SHIFT 8
+#define ID_MMFR0_PMSA_SHIFT 4
+#define ID_MMFR0_VMSA_SHIFT 0
+
#define ID_MMFR4_EVT_SHIFT 28
#define ID_MMFR4_CCIDX_SHIFT 24
#define ID_MMFR4_LSM_SHIFT 20
#define ID_MMFR4_HPDS_SHIFT 16
#define ID_MMFR4_CNP_SHIFT 12
#define ID_MMFR4_XNX_SHIFT 8
+#define ID_MMFR4_AC2_SHIFT 4
#define ID_MMFR4_SPECSEI_SHIFT 0
#define ID_MMFR5_ETS_SHIFT 0
#define ID_PFR0_DIT_SHIFT 24
#define ID_PFR0_CSV2_SHIFT 16
+#define ID_PFR0_STATE3_SHIFT 12
+#define ID_PFR0_STATE2_SHIFT 8
+#define ID_PFR0_STATE1_SHIFT 4
+#define ID_PFR0_STATE0_SHIFT 0
+
+#define ID_DFR0_PERFMON_SHIFT 24
+#define ID_DFR0_MPROFDBG_SHIFT 20
+#define ID_DFR0_MMAPTRC_SHIFT 16
+#define ID_DFR0_COPTRC_SHIFT 12
+#define ID_DFR0_MMAPDBG_SHIFT 8
+#define ID_DFR0_COPSDBG_SHIFT 4
+#define ID_DFR0_COPDBG_SHIFT 0
#define ID_PFR2_SSBS_SHIFT 4
#define ID_PFR2_CSV3_SHIFT 0
@@ -869,6 +892,11 @@
#define ID_AA64MMFR0_TGRAN_SUPPORTED ID_AA64MMFR0_TGRAN64_SUPPORTED
#endif
+#define MVFR2_FPMISC_SHIFT 4
+#define MVFR2_SIMDMISC_SHIFT 0
+
+#define DCZID_DZP_SHIFT 4
+#define DCZID_BS_SHIFT 0
/*
* The ZCR_ELx_LEN_* definitions intentionally include bits [8:4] which
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 45eb1fa57f2a..452f6265eda3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -339,7 +339,7 @@ static const struct arm64_ftr_bits ftr_ctr[] = {
* make use of *minLine.
* If we have differing I-cache policies, report it as the weakest - VIPT.
*/
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, 14, 2, ICACHE_POLICY_VIPT), /* L1Ip */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_EXACT, CTR_L1IP_SHIFT, 2, ICACHE_POLICY_VIPT), /* L1Ip */
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IMINLINE_SHIFT, 4, 0),
ARM64_FTR_END,
};
@@ -350,19 +350,19 @@ struct arm64_ftr_reg arm64_ftr_reg_ctrel0 = {
};
static const struct arm64_ftr_bits ftr_id_mmfr0[] = {
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 28, 4, 0xf), /* InnerShr */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0), /* FCSE */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, 20, 4, 0), /* AuxReg */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0), /* TCM */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0), /* ShareLvl */
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0xf), /* OuterShr */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0), /* PMSA */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* VMSA */
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR0_INNERSHR_SHIFT, 4, 0xf),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR0_FCSE_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_MMFR0_AUXREG_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR0_TCM_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR0_SHARELVL_SHIFT, 4, 0),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR0_OUTERSHR_SHIFT, 4, 0xf),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR0_PMSA_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR0_VMSA_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 36, 4, 0),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_DOUBLELOCK_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64DFR0_PMSVER_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_CTX_CMPS_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_WRPS_SHIFT, 4, 0),
@@ -378,14 +378,14 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
};
static const struct arm64_ftr_bits ftr_mvfr2[] = {
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0), /* FPMisc */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* SIMDMisc */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, MVFR2_FPMISC_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, MVFR2_SIMDMISC_SHIFT, 4, 0),
ARM64_FTR_END,
};
static const struct arm64_ftr_bits ftr_dczid[] = {
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 4, 1, 1), /* DZP */
- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* BS */
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, DCZID_DZP_SHIFT, 1, 1),
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, DCZID_BS_SHIFT, 4, 0),
ARM64_FTR_END,
};
@@ -417,7 +417,8 @@ static const struct arm64_ftr_bits ftr_id_mmfr4[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR4_HPDS_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR4_CNP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR4_XNX_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0), /* ac2 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_MMFR4_AC2_SHIFT, 4, 0),
+
/*
* SpecSEI = 1 indicates that the PE might generate an SError on an
* external abort on speculative read. It is safe to assume that an
@@ -459,10 +460,10 @@ static const struct arm64_ftr_bits ftr_id_isar6[] = {
static const struct arm64_ftr_bits ftr_id_pfr0[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_DIT_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_PFR0_CSV2_SHIFT, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0), /* State3 */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0), /* State2 */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0), /* State1 */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0), /* State0 */
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE3_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE2_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE1_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_PFR0_STATE0_SHIFT, 4, 0),
ARM64_FTR_END,
};
@@ -486,13 +487,13 @@ static const struct arm64_ftr_bits ftr_id_pfr2[] = {
static const struct arm64_ftr_bits ftr_id_dfr0[] = {
/* [31:28] TraceFilt */
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 24, 4, 0xf), /* PerfMon */
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 12, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 8, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 4, 4, 0),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, 0, 4, 0),
+ S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR0_PERFMON_SHIFT, 4, 0xf),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR0_MPROFDBG_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR0_MMAPTRC_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR0_COPTRC_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR0_MMAPDBG_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR0_COPSDBG_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR0_COPDBG_SHIFT, 4, 0),
ARM64_FTR_END,
};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 3/4] arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR2 register
From: Anshuman Khandual @ 2020-05-27 3:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, Anshuman Khandual, catalin.marinas, suzuki.poulose,
linux-kernel, will
In-Reply-To: <1590548619-3441-1-git-send-email-anshuman.khandual@arm.com>
Enable EVT, BBM, TTL, IDS, ST, NV and CCIDX features bits in ID_AA64MMFR2
register as per ARM DDI 0487F.a specification.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Will Deacon <will@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/include/asm/sysreg.h | 7 +++++++
arch/arm64/kernel/cpufeature.c | 7 +++++++
2 files changed, 14 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index a798bb9c0845..9add104d4762 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -747,8 +747,15 @@
/* id_aa64mmfr2 */
#define ID_AA64MMFR2_E0PD_SHIFT 60
+#define ID_AA64MMFR2_EVT_SHIFT 56
+#define ID_AA64MMFR2_BBM_SHIFT 52
+#define ID_AA64MMFR2_TTL_SHIFT 48
#define ID_AA64MMFR2_FWB_SHIFT 40
+#define ID_AA64MMFR2_IDS_SHIFT 36
#define ID_AA64MMFR2_AT_SHIFT 32
+#define ID_AA64MMFR2_ST_SHIFT 28
+#define ID_AA64MMFR2_NV_SHIFT 24
+#define ID_AA64MMFR2_CCIDX_SHIFT 20
#define ID_AA64MMFR2_LVA_SHIFT 16
#define ID_AA64MMFR2_IESB_SHIFT 12
#define ID_AA64MMFR2_LSM_SHIFT 8
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c2253fb3401e..45eb1fa57f2a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -310,8 +310,15 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_E0PD_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_EVT_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_BBM_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_TTL_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_FWB_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_IDS_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_AT_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_ST_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_NV_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_CCIDX_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LVA_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_IESB_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LSM_SHIFT, 4, 0),
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 2/4] arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR1 register
From: Anshuman Khandual @ 2020-05-27 3:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, Anshuman Khandual, catalin.marinas, suzuki.poulose,
linux-kernel, will
In-Reply-To: <1590548619-3441-1-git-send-email-anshuman.khandual@arm.com>
Enable ETS, TWED, XNX and SPECSEI features bits in ID_AA64MMFR1 register as
per ARM DDI 0487F.a specification.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/include/asm/sysreg.h | 4 ++++
arch/arm64/kernel/cpufeature.c | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index cf983d03aa4c..a798bb9c0845 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -731,6 +731,10 @@
#endif
/* id_aa64mmfr1 */
+#define ID_AA64MMFR1_ETS_SHIFT 36
+#define ID_AA64MMFR1_TWED_SHIFT 32
+#define ID_AA64MMFR1_XNX_SHIFT 28
+#define ID_AA64MMFR1_SPECSEI_SHIFT 24
#define ID_AA64MMFR1_PAN_SHIFT 20
#define ID_AA64MMFR1_LOR_SHIFT 16
#define ID_AA64MMFR1_HPD_SHIFT 12
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index feaa6dcd6f7b..c2253fb3401e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -295,6 +295,10 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_ETS_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_TWED_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_XNX_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, ID_AA64MMFR1_SPECSEI_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_PAN_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_LOR_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_HPD_SHIFT, 4, 0),
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 1/4] arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR0 register
From: Anshuman Khandual @ 2020-05-27 3:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, Anshuman Khandual, catalin.marinas, suzuki.poulose,
linux-kernel, will
In-Reply-To: <1590548619-3441-1-git-send-email-anshuman.khandual@arm.com>
Enable EVC, FGT, EXS features bits in ID_AA64MMFR0 register as per ARM DDI
0487F.a specification.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/include/asm/sysreg.h | 3 +++
arch/arm64/kernel/cpufeature.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index fa9d02ca4b25..cf983d03aa4c 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -703,6 +703,9 @@
#define ID_AA64ZFR0_SVEVER_SVE2 0x1
/* id_aa64mmfr0 */
+#define ID_AA64MMFR0_ECV_SHIFT 60
+#define ID_AA64MMFR0_FGT_SHIFT 56
+#define ID_AA64MMFR0_EXS_SHIFT 44
#define ID_AA64MMFR0_TGRAN4_SHIFT 28
#define ID_AA64MMFR0_TGRAN64_SHIFT 24
#define ID_AA64MMFR0_TGRAN16_SHIFT 20
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index ada9f6f9b0f6..feaa6dcd6f7b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -267,6 +267,9 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
};
static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_ECV_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_FGT_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_EXS_SHIFT, 4, 0),
/*
* We already refuse to boot CPUs that don't support our configured
* page size, so we can only detect mismatches for a page size other
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V5 0/4] arm64/cpufeature: Introduce ID_PFR2, ID_DFR1, ID_MMFR5 and other changes
From: Anshuman Khandual @ 2020-05-27 3:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: mark.rutland, Anshuman Khandual, catalin.marinas, suzuki.poulose,
linux-kernel, James Morse, Marc Zyngier, will, kvmarm
These are remaining patches from V4 series which had some pending reviews
from Suzuki (https://patchwork.kernel.org/cover/11557333/). Also dropped
[PATCH 15/17] as that will need some more investigation and rework.
This series applies on arm64/for-next/cpufeature.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Changes in V5:
- Dropped TGRAN features along with it's macros from ID_AA64MMFR0 per Suzuki
- Replaced with FTR_HIGHER_SAFE for SpecSEI feature in ID_AA64MMFR1 per Suzuki
- Dropped patch "arm64/cpufeature: Add remaining feature bits in ID_AA64DFR0 register"
Changes in V4: (https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=290085)
- Updated ftr_id_dfr0[] with a documentation for now missing [31:28] Tracfilt per Will
- Fixed erroneous bit width value from 28 to 4 for double lock feature per Will
- Replaced ID_SANITIZED() with ID_HIDDEN() for SYS_ID_DFR1_EL1 per Suzuki
- Fixed positions for register definitions as per new name based grouping per Will
- Replaced FTR_VISIBLE with FTR_HIDDEN for TLB feature in ID_AA64ISAR0 per Suzuki
- Replaced FTR_VISIBLE with FTR_HIDDEN for MPAM and SEL2 in ID_AA64PFR0 per Suzuki
- Replaced FTR_VISIBLE with FTR_HIDDEN for MPAMFRAC and RASFRAC in ID_AA64PFR1 per Suzuki
- Dropped both MTE and BT features from ftr_id_aa64pfr1[] to be added later per Suzuki
- Added ID_MMFR4_EL1 into the cpuinfo_arm64 context per Will
Changes in V3: (https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=281211)
- Rebased on git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git (for-next/cpufeature)
Changes in V2: (https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=270605)
- Added Suggested-by tag from Mark Rutland for all changes he had proposed
- Added comment for SpecSEI feature on why it is HIGHER_SAFE per Suzuki
- Added a patch which makes ID_AA64DFR0_DOUBLELOCK a signed feature per Suzuki
- Added ID_DFR1 and ID_MMFR5 system register definitions per Will
- Added remaining features bits for relevant 64 bit system registers per Will
- Changed commit message on [PATCH 5/7] regarding TraceFilt feature per Suzuki
- Changed ID_PFR2.CSV3 (FTR_STRICT -> FTR_NONSTRICT) as 64 bit registers per Will
- Changed ID_PFR0.CSV2 (FTR_STRICT -> FTR_NONSTRICT) as 64 bit registers per Will
- Changed some commit messages
Changes in V1: (https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=234093)
Anshuman Khandual (4):
arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR0 register
arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR1 register
arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR2 register
arm64/cpufeature: Replace all open bits shift encodings with macros
arch/arm64/include/asm/sysreg.h | 42 +++++++++++++++++++++
arch/arm64/kernel/cpufeature.c | 67 ++++++++++++++++++++-------------
2 files changed, 83 insertions(+), 26 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFCv2 6/9] kvm/arm64: Export kvm_handle_user_mem_abort() with prefault mode
From: Gavin Shan @ 2020-05-27 3:01 UTC (permalink / raw)
To: Mark Rutland
Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
linux-arm-kernel
In-Reply-To: <20200526105807.GE1363@C02TD0UTHF1T.local>
Hi Mark,
On 5/26/20 8:58 PM, Mark Rutland wrote:
> On Fri, May 08, 2020 at 01:29:16PM +1000, Gavin Shan wrote:
>> This renames user_mem_abort() to kvm_handle_user_mem_abort(), and
>> then export it. The function will be used in asynchronous page fault
>> to populate a page table entry once the corresponding page is populated
>> from the backup device (e.g. swap partition):
>>
>> * Parameter @fault_status is replace by @esr.
>> * The parameters are reorder based on their importance.
>
> It seems like multiple changes are going on here, and it would be
> clearer with separate patches.
>
> Passing the ESR rather than the extracted fault status seems fine, but
> for clarirty it's be nicer to do this in its own patch.
>
Ok. I'll have a separate patch to do this.
> Why is it necessary to re-order the function parameters? Does that align
> with other function prototypes?
>
There are no explicit reasons for it. I can restore the order to what we
had previously if you like.
> What exactly is the `prefault` parameter meant to do? It doesn't do
> anything currently, so it'd be better to introduce it later when logic
> using it is instroduced, or where callers will pass distinct values.
>
Yes, fair enough. I will merge the logic with PATCH[7] then.
> Thanks,
> Mark.
>
Thanks,
Gavin
>>
>> This shouldn't cause any functional changes.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>> ---
>> arch/arm64/include/asm/kvm_host.h | 4 ++++
>> virt/kvm/arm/mmu.c | 14 ++++++++------
>> 2 files changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 32c8a675e5a4..f77c706777ec 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -437,6 +437,10 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
>> struct kvm_vcpu_events *events);
>>
>> #define KVM_ARCH_WANT_MMU_NOTIFIER
>> +int kvm_handle_user_mem_abort(struct kvm_vcpu *vcpu, unsigned int esr,
>> + struct kvm_memory_slot *memslot,
>> + phys_addr_t fault_ipa, unsigned long hva,
>> + bool prefault);
>> int kvm_unmap_hva_range(struct kvm *kvm,
>> unsigned long start, unsigned long end);
>> int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index e462e0368fd9..95aaabb2b1fc 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -1656,12 +1656,12 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>> (hva & ~(map_size - 1)) + map_size <= uaddr_end;
>> }
>>
>> -static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> - struct kvm_memory_slot *memslot, unsigned long hva,
>> - unsigned long fault_status)
>> +int kvm_handle_user_mem_abort(struct kvm_vcpu *vcpu, unsigned int esr,
>> + struct kvm_memory_slot *memslot,
>> + phys_addr_t fault_ipa, unsigned long hva,
>> + bool prefault)
>> {
>> - int ret;
>> - u32 esr = kvm_vcpu_get_esr(vcpu);
>> + unsigned int fault_status = kvm_vcpu_trap_get_fault_type(esr);
>> bool write_fault, writable, force_pte = false;
>> bool exec_fault, needs_exec;
>> unsigned long mmu_seq;
>> @@ -1674,6 +1674,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>> pgprot_t mem_type = PAGE_S2;
>> bool logging_active = memslot_is_logging(memslot);
>> unsigned long vma_pagesize, flags = 0;
>> + int ret;
>>
>> write_fault = kvm_is_write_fault(esr);
>> exec_fault = kvm_vcpu_trap_is_iabt(esr);
>> @@ -1995,7 +1996,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> goto out_unlock;
>> }
>>
>> - ret = user_mem_abort(vcpu, fault_ipa, memslot, hva, fault_status);
>> + ret = kvm_handle_user_mem_abort(vcpu, esr, memslot,
>> + fault_ipa, hva, false);
>> if (ret == 0)
>> ret = 1;
>> out:
>> --
>> 2.23.0
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 18/24] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update
From: Xiang Zheng @ 2020-05-27 3:00 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, devicetree, linux-arm-kernel,
linux-pci, linux-mm
Cc: fenghua.yu, kevin.tian, jacob.jun.pan, will, catalin.marinas,
joro, christian.koenig, hch, jgg, Wang Haibin, Jonathan.Cameron,
zhangfei.gao, xuzaibo, robin.murphy, felix.kuehling, baolu.lu
In-Reply-To: <20200519175502.2504091-19-jean-philippe@linaro.org>
Hi Jean,
This patch only enables HTTU bits in CDs. Is it also neccessary to enable
HTTU bits in STEs in this patch?
On 2020/5/20 1:54, Jean-Philippe Brucker wrote:
> If the SMMU supports it and the kernel was built with HTTU support,
> enable hardware update of access and dirty flags. This is essential for
> shared page tables, to reduce the number of access faults on the fault
> queue. Normal DMA with io-pgtables doesn't currently use the access or
> dirty flags.
>
> We can enable HTTU even if CPUs don't support it, because the kernel
> always checks for HW dirty bit and updates the PTE flags atomically.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 1386d4d2bc60..6a368218f54c 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -58,6 +58,8 @@
> #define IDR0_ASID16 (1 << 12)
> #define IDR0_ATS (1 << 10)
> #define IDR0_HYP (1 << 9)
> +#define IDR0_HD (1 << 7)
> +#define IDR0_HA (1 << 6)
> #define IDR0_BTM (1 << 5)
> #define IDR0_COHACC (1 << 4)
> #define IDR0_TTF GENMASK(3, 2)
> @@ -311,6 +313,9 @@
> #define CTXDESC_CD_0_TCR_IPS GENMASK_ULL(34, 32)
> #define CTXDESC_CD_0_TCR_TBI0 (1ULL << 38)
>
> +#define CTXDESC_CD_0_TCR_HA (1UL << 43)
> +#define CTXDESC_CD_0_TCR_HD (1UL << 42)
> +
> #define CTXDESC_CD_0_AA64 (1UL << 41)
> #define CTXDESC_CD_0_S (1UL << 44)
> #define CTXDESC_CD_0_R (1UL << 45)
> @@ -663,6 +668,8 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_E2H (1 << 16)
> #define ARM_SMMU_FEAT_BTM (1 << 17)
> #define ARM_SMMU_FEAT_SVA (1 << 18)
> +#define ARM_SMMU_FEAT_HA (1 << 19)
> +#define ARM_SMMU_FEAT_HD (1 << 20)
> u32 features;
>
> #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
> @@ -1718,10 +1725,17 @@ static int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain,
> * this substream's traffic
> */
> } else { /* (1) and (2) */
> + u64 tcr = cd->tcr;
> +
> cdptr[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
> cdptr[2] = 0;
> cdptr[3] = cpu_to_le64(cd->mair);
>
> + if (!(smmu->features & ARM_SMMU_FEAT_HD))
> + tcr &= ~CTXDESC_CD_0_TCR_HD;
> + if (!(smmu->features & ARM_SMMU_FEAT_HA))
> + tcr &= ~CTXDESC_CD_0_TCR_HA;
> +
> /*
> * STE is live, and the SMMU might read dwords of this CD in any
> * order. Ensure that it observes valid values before reading
> @@ -1729,7 +1743,7 @@ static int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain,
> */
> arm_smmu_sync_cd(smmu_domain, ssid, true);
>
> - val = cd->tcr |
> + val = tcr |
> #ifdef __BIG_ENDIAN
> CTXDESC_CD_0_ENDI |
> #endif
> @@ -1958,10 +1972,12 @@ static struct arm_smmu_ctx_desc *arm_smmu_alloc_shared_cd(struct mm_struct *mm)
> return old_cd;
> }
>
> + /* HA and HD will be filtered out later if not supported by the SMMU */
> tcr = FIELD_PREP(CTXDESC_CD_0_TCR_T0SZ, 64ULL - VA_BITS) |
> FIELD_PREP(CTXDESC_CD_0_TCR_IRGN0, ARM_LPAE_TCR_RGN_WBWA) |
> FIELD_PREP(CTXDESC_CD_0_TCR_ORGN0, ARM_LPAE_TCR_RGN_WBWA) |
> FIELD_PREP(CTXDESC_CD_0_TCR_SH0, ARM_LPAE_TCR_SH_IS) |
> + CTXDESC_CD_0_TCR_HA | CTXDESC_CD_0_TCR_HD |
> CTXDESC_CD_0_TCR_EPD1 | CTXDESC_CD_0_AA64;
>
> switch (PAGE_SIZE) {
> @@ -4454,6 +4470,12 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
> smmu->features |= ARM_SMMU_FEAT_E2H;
> }
>
> + if (reg & (IDR0_HA | IDR0_HD)) {
> + smmu->features |= ARM_SMMU_FEAT_HA;
> + if (reg & IDR0_HD)
> + smmu->features |= ARM_SMMU_FEAT_HD;
> + }
> +
> /*
> * If the CPU is using VHE, but the SMMU doesn't support it, the SMMU
> * will create TLB entries for NH-EL1 world and will miss the
>
--
Thanks,
Xiang
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] ASoC: mmp-sspa: Fix return value check in asoc_mmp_sspa_probe()
From: Wei Yongjun @ 2020-05-27 3:02 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai
Cc: kernel-janitors, alsa-devel, Wei Yongjun, linux-kernel,
linux-arm-kernel
In case of error, the function devm_ioremap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
sound/soc/pxa/mmp-sspa.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/pxa/mmp-sspa.c b/sound/soc/pxa/mmp-sspa.c
index 3e37ab625f8d..4255851c71c1 100644
--- a/sound/soc/pxa/mmp-sspa.c
+++ b/sound/soc/pxa/mmp-sspa.c
@@ -493,13 +493,13 @@ static int asoc_mmp_sspa_probe(struct platform_device *pdev)
return -ENODEV;
sspa->rx_base = devm_ioremap(&pdev->dev, res->start, 0x30);
- if (IS_ERR(sspa->rx_base))
- return PTR_ERR(sspa->rx_base);
+ if (!sspa->rx_base)
+ return -ENOMEM;
sspa->tx_base = devm_ioremap(&pdev->dev,
res->start + 0x80, 0x30);
- if (IS_ERR(sspa->tx_base))
- return PTR_ERR(sspa->tx_base);
+ if (!sspa->tx_base)
+ return -ENOMEM;
sspa->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(sspa->clk))
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH RFCv2 5/9] kvm/arm64: Replace hsr with esr
From: Gavin Shan @ 2020-05-27 2:56 UTC (permalink / raw)
To: Mark Rutland
Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
linux-arm-kernel
In-Reply-To: <20200526104507.GC1363@C02TD0UTHF1T.local>
Hi Mark,
On 5/26/20 8:45 PM, Mark Rutland wrote:
> On Fri, May 08, 2020 at 01:29:15PM +1000, Gavin Shan wrote:
>> This replace the variable names to make them self-explaining. The
>> tracepoint isn't changed accordingly because they're part of ABI:
>>
>> * @hsr to @esr
>> * @hsr_ec to @ec
>> * Use kvm_vcpu_trap_get_class() helper if possible
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>
> As with patch 3, I think this cleanup makes sense independent from the
> rest of the series, and I think it'd make sense to bundle all the
> patches renaming hsr -> esr, and send those as a preparatory series.
>
Yes, PATCH[3/4/5] will be posted independently, as part of the
preparatory work, as you suggested.
Thanks,
Gavin
> Thanks,
> Mark.
>
>> ---
>> arch/arm64/kvm/handle_exit.c | 28 ++++++++++++++--------------
>> arch/arm64/kvm/hyp/switch.c | 9 ++++-----
>> arch/arm64/kvm/sys_regs.c | 30 +++++++++++++++---------------
>> 3 files changed, 33 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>> index 00858db82a64..e3b3dcd5b811 100644
>> --- a/arch/arm64/kvm/handle_exit.c
>> +++ b/arch/arm64/kvm/handle_exit.c
>> @@ -123,13 +123,13 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> */
>> static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> {
>> - u32 hsr = kvm_vcpu_get_esr(vcpu);
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>> int ret = 0;
>>
>> run->exit_reason = KVM_EXIT_DEBUG;
>> - run->debug.arch.hsr = hsr;
>> + run->debug.arch.hsr = esr;
>>
>> - switch (ESR_ELx_EC(hsr)) {
>> + switch (kvm_vcpu_trap_get_class(esr)) {
>> case ESR_ELx_EC_WATCHPT_LOW:
>> run->debug.arch.far = vcpu->arch.fault.far_el2;
>> /* fall through */
>> @@ -139,8 +139,8 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> case ESR_ELx_EC_BRK64:
>> break;
>> default:
>> - kvm_err("%s: un-handled case hsr: %#08x\n",
>> - __func__, (unsigned int) hsr);
>> + kvm_err("%s: un-handled case esr: %#08x\n",
>> + __func__, (unsigned int)esr);
>> ret = -1;
>> break;
>> }
>> @@ -150,10 +150,10 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>
>> static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> {
>> - u32 hsr = kvm_vcpu_get_esr(vcpu);
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>>
>> - kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
>> - hsr, esr_get_class_string(hsr));
>> + kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
>> + esr, esr_get_class_string(esr));
>>
>> kvm_inject_undefined(vcpu);
>> return 1;
>> @@ -230,10 +230,10 @@ static exit_handle_fn arm_exit_handlers[] = {
>>
>> static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
>> {
>> - u32 hsr = kvm_vcpu_get_esr(vcpu);
>> - u8 hsr_ec = ESR_ELx_EC(hsr);
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>> + u8 ec = kvm_vcpu_trap_get_class(esr);
>>
>> - return arm_exit_handlers[hsr_ec];
>> + return arm_exit_handlers[ec];
>> }
>>
>> /*
>> @@ -273,15 +273,15 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>> {
>> if (ARM_SERROR_PENDING(exception_index)) {
>> u32 esr = kvm_vcpu_get_esr(vcpu);
>> - u8 hsr_ec = ESR_ELx_EC(esr);
>> + u8 ec = kvm_vcpu_trap_get_class(esr);
>>
>> /*
>> * HVC/SMC already have an adjusted PC, which we need
>> * to correct in order to return to after having
>> * injected the SError.
>> */
>> - if (hsr_ec == ESR_ELx_EC_HVC32 || hsr_ec == ESR_ELx_EC_HVC64 ||
>> - hsr_ec == ESR_ELx_EC_SMC32 || hsr_ec == ESR_ELx_EC_SMC64) {
>> + if (ec == ESR_ELx_EC_HVC32 || ec == ESR_ELx_EC_HVC64 ||
>> + ec == ESR_ELx_EC_SMC32 || ec == ESR_ELx_EC_SMC64) {
>> u32 adj = kvm_vcpu_trap_il_is32bit(esr) ? 4 : 2;
>> *vcpu_pc(vcpu) -= adj;
>> }
>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> index 369f22f49f3d..7bf4840bf90e 100644
>> --- a/arch/arm64/kvm/hyp/switch.c
>> +++ b/arch/arm64/kvm/hyp/switch.c
>> @@ -356,8 +356,8 @@ static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
>> static bool __hyp_text __hyp_handle_fpsimd(struct kvm_vcpu *vcpu)
>> {
>> u32 esr = kvm_vcpu_get_esr(vcpu);
>> + u8 ec = kvm_vcpu_trap_get_class(esr);
>> bool vhe, sve_guest, sve_host;
>> - u8 hsr_ec;
>>
>> if (!system_supports_fpsimd())
>> return false;
>> @@ -372,14 +372,13 @@ static bool __hyp_text __hyp_handle_fpsimd(struct kvm_vcpu *vcpu)
>> vhe = has_vhe();
>> }
>>
>> - hsr_ec = kvm_vcpu_trap_get_class(esr);
>> - if (hsr_ec != ESR_ELx_EC_FP_ASIMD &&
>> - hsr_ec != ESR_ELx_EC_SVE)
>> + if (ec != ESR_ELx_EC_FP_ASIMD &&
>> + ec != ESR_ELx_EC_SVE)
>> return false;
>>
>> /* Don't handle SVE traps for non-SVE vcpus here: */
>> if (!sve_guest)
>> - if (hsr_ec != ESR_ELx_EC_FP_ASIMD)
>> + if (ec != ESR_ELx_EC_FP_ASIMD)
>> return false;
>>
>> /* Valid trap. Switch the context: */
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 012fff834a4b..58f81ab519af 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -2182,10 +2182,10 @@ static void unhandled_cp_access(struct kvm_vcpu *vcpu,
>> struct sys_reg_params *params)
>> {
>> u32 esr = kvm_vcpu_get_esr(vcpu);
>> - u8 hsr_ec = kvm_vcpu_trap_get_class(esr);
>> + u8 ec = kvm_vcpu_trap_get_class(esr);
>> int cp = -1;
>>
>> - switch(hsr_ec) {
>> + switch (ec) {
>> case ESR_ELx_EC_CP15_32:
>> case ESR_ELx_EC_CP15_64:
>> cp = 15;
>> @@ -2216,17 +2216,17 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu,
>> size_t nr_specific)
>> {
>> struct sys_reg_params params;
>> - u32 hsr = kvm_vcpu_get_esr(vcpu);
>> - int Rt = kvm_vcpu_sys_get_rt(hsr);
>> - int Rt2 = (hsr >> 10) & 0x1f;
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>> + int Rt = kvm_vcpu_sys_get_rt(esr);
>> + int Rt2 = (esr >> 10) & 0x1f;
>>
>> params.is_aarch32 = true;
>> params.is_32bit = false;
>> - params.CRm = (hsr >> 1) & 0xf;
>> - params.is_write = ((hsr & 1) == 0);
>> + params.CRm = (esr >> 1) & 0xf;
>> + params.is_write = ((esr & 1) == 0);
>>
>> params.Op0 = 0;
>> - params.Op1 = (hsr >> 16) & 0xf;
>> + params.Op1 = (esr >> 16) & 0xf;
>> params.Op2 = 0;
>> params.CRn = 0;
>>
>> @@ -2273,18 +2273,18 @@ static int kvm_handle_cp_32(struct kvm_vcpu *vcpu,
>> size_t nr_specific)
>> {
>> struct sys_reg_params params;
>> - u32 hsr = kvm_vcpu_get_esr(vcpu);
>> - int Rt = kvm_vcpu_sys_get_rt(hsr);
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>> + int Rt = kvm_vcpu_sys_get_rt(esr);
>>
>> params.is_aarch32 = true;
>> params.is_32bit = true;
>> - params.CRm = (hsr >> 1) & 0xf;
>> + params.CRm = (esr >> 1) & 0xf;
>> params.regval = vcpu_get_reg(vcpu, Rt);
>> - params.is_write = ((hsr & 1) == 0);
>> - params.CRn = (hsr >> 10) & 0xf;
>> + params.is_write = ((esr & 1) == 0);
>> + params.CRn = (esr >> 10) & 0xf;
>> params.Op0 = 0;
>> - params.Op1 = (hsr >> 14) & 0x7;
>> - params.Op2 = (hsr >> 17) & 0x7;
>> + params.Op1 = (esr >> 14) & 0x7;
>> + params.Op2 = (esr >> 17) & 0x7;
>>
>> if (!emulate_cp(vcpu, ¶ms, target_specific, nr_specific) ||
>> !emulate_cp(vcpu, ¶ms, global, nr_global)) {
>> --
>> 2.23.0
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 11/14] dt-bindings: clock: sparx5: Add bindings include file
From: Stephen Boyd @ 2020-05-27 2:56 UTC (permalink / raw)
To: Arnd Bergmann, Lars Povlsen, Linus Walleij, Rob Herring, SoC Team
Cc: devicetree, Alexandre Belloni, Steen Hegelund, linux-clk,
linux-kernel, Microchip Linux Driver Support, linux-gpio,
linux-arm-kernel, Olof Johansson, Michael Turquette, Lars Povlsen
In-Reply-To: <20200513125532.24585-12-lars.povlsen@microchip.com>
Quoting Lars Povlsen (2020-05-13 05:55:29)
> The Sparx5 support 9 different clock outputs. This include file has
> defines for each supported clock ordinal.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 12/14] clk: sparx5: Add Sparx5 SoC DPLL clock driver
From: Stephen Boyd @ 2020-05-27 2:56 UTC (permalink / raw)
To: Arnd Bergmann, Lars Povlsen, Linus Walleij, SoC Team
Cc: devicetree, Alexandre Belloni, Steen Hegelund, linux-clk,
linux-kernel, Microchip Linux Driver Support, linux-gpio,
linux-arm-kernel, Olof Johansson, Michael Turquette, Lars Povlsen
In-Reply-To: <20200513125532.24585-13-lars.povlsen@microchip.com>
Quoting Lars Povlsen (2020-05-13 05:55:30)
> diff --git a/drivers/clk/clk-sparx5.c b/drivers/clk/clk-sparx5.c
> new file mode 100644
> index 0000000000000..685b3028a7071
> --- /dev/null
> +++ b/drivers/clk/clk-sparx5.c
> @@ -0,0 +1,269 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Microchip Sparx5 SoC Clock driver.
> + *
> + * Copyright (c) 2019 Microchip Inc.
> + *
> + * Author: Lars Povlsen <lars.povlsen@microchip.com>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +#include <dt-bindings/clock/microchip,sparx5.h>
> +
> +#define PLL_DIV_MASK GENMASK(7, 0)
> +#define PLL_PRE_DIV_MASK GENMASK(10, 8)
> +#define PLL_PRE_DIV_SHIFT 8
> +#define PLL_ROT_DIR BIT(11)
> +#define PLL_ROT_SEL_MASK GENMASK(13, 12)
> +#define PLL_ROT_SEL_SHIFT 12
> +#define PLL_ROT_ENA BIT(14)
> +#define PLL_CLK_ENA BIT(15)
> +
> +#define MAX_SEL 4
> +#define MAX_PRE BIT(3)
> +
> +#define KHZ 1000
> +#define MHZ (KHZ*KHZ)
I suspect (1000 * KHZ) would make more sense.
> +
> +#define BASE_CLOCK (2500UL*MHZ)
> +
> +static u8 sel_rates[MAX_SEL] = { 0, 2*8, 2*4, 2*2 };
const?
> +
> +static const char *clk_names[N_CLOCKS] = {
> + "core", "ddr", "cpu2", "arm2",
> + "aux1", "aux2", "aux3", "aux4",
> + "synce",
> +};
> +
> +struct s5_hw_clk {
> + struct clk_hw hw;
> + void __iomem *reg;
> + int index;
> +};
> +
> +struct s5_clk_data {
> + void __iomem *base;
> + struct s5_hw_clk s5_hw[N_CLOCKS];
> +};
> +
> +struct pll_conf {
> + int freq;
> + u8 div;
> + bool rot_ena;
> + u8 rot_sel;
> + u8 rot_dir;
> + u8 pre_div;
> +};
> +
> +#define to_clk_pll(hw) container_of(hw, struct s5_hw_clk, hw)
> +
> +unsigned long calc_freq(const struct pll_conf *pdata)
> +{
> + unsigned long rate = BASE_CLOCK / pdata->div;
> +
> + if (pdata->rot_ena) {
> + unsigned long base = BASE_CLOCK / pdata->div;
> + int sign = pdata->rot_dir ? -1 : 1;
> + int divt = sel_rates[pdata->rot_sel] * (1 + pdata->pre_div);
> + int divb = divt + sign;
> +
> + rate = mult_frac(base, divt, divb);
> + rate = roundup(rate, 1000);
> + }
> +
> + return rate;
> +}
> +
> +static unsigned long clk_calc_params(unsigned long rate,
> + struct pll_conf *conf)
> +{
> + memset(conf, 0, sizeof(*conf));
> +
> + conf->div = DIV_ROUND_CLOSEST_ULL(BASE_CLOCK, rate);
> +
> + if (BASE_CLOCK % rate) {
> + struct pll_conf best;
> + ulong cur_offset, best_offset = rate;
> + int i, j;
> +
> + /* Enable fractional rotation */
> + conf->rot_ena = true;
> +
> + if ((BASE_CLOCK / rate) != conf->div) {
> + /* Overshoot, adjust other direction */
> + conf->rot_dir = 1;
> + }
> +
> + /* Brute force search over MAX_PRE * (MAX_SEL - 1) = 24 */
> + for (i = 0; i < MAX_PRE; i++) {
> + conf->pre_div = i;
> + for (j = 1; j < MAX_SEL; j++) {
> + conf->rot_sel = j;
> + conf->freq = calc_freq(conf);
> + cur_offset = abs(rate - conf->freq);
> + if (cur_offset == 0)
> + /* Perfect fit */
> + goto done;
Why not 'break' and drop the label?
> + if (cur_offset < best_offset) {
> + /* Better fit found */
> + best_offset = cur_offset;
> + best = *conf;
> + }
> + }
> + }
> + /* Best match */
> + *conf = best;
> + }
> +
> +done:
> + return conf->freq;
> +}
> +
> +static int clk_pll_enable(struct clk_hw *hw)
> +{
> + struct s5_hw_clk *pll = to_clk_pll(hw);
> + u32 val = readl(pll->reg);
> +
> + val |= PLL_CLK_ENA;
> + writel(val, pll->reg);
> + pr_debug("%s: Enable val %04x\n", clk_names[pll->index], val);
> + return 0;
> +}
> +
> +static void clk_pll_disable(struct clk_hw *hw)
> +{
> + struct s5_hw_clk *pll = to_clk_pll(hw);
> + u32 val = readl(pll->reg);
> +
> + val &= ~PLL_CLK_ENA;
> + writel(val, pll->reg);
> + pr_debug("%s: Disable val %04x\n", clk_names[pll->index], val);
Can we drop these pr_debug() prints? They're probably never going to be
used after developing this driver.
> +}
> +
> +static int clk_pll_set_rate(struct clk_hw *hw,
Please rename clk_pll to something less generic, like s5_pll or
something.
> + unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct s5_hw_clk *pll = to_clk_pll(hw);
> + struct pll_conf conf;
> + unsigned long eff_rate;
> + int ret = 0;
> +
> + eff_rate = clk_calc_params(rate, &conf);
> + if (eff_rate == rate) {
> + u32 val;
> +
> + val = readl(pll->reg) & PLL_CLK_ENA;
> + val |= PLL_DIV_MASK & conf.div;
> + if (conf.rot_ena) {
> + val |= (PLL_ROT_ENA |
> + (PLL_ROT_SEL_MASK &
> + (conf.rot_sel << PLL_ROT_SEL_SHIFT)) |
> + (PLL_PRE_DIV_MASK &
> + (conf.pre_div << PLL_PRE_DIV_SHIFT)));
This can use the FIELD_GET and helpers?
> + if (conf.rot_dir)
> + val |= PLL_ROT_DIR;
> + }
> + pr_debug("%s: Rate %ld >= 0x%04x\n",
> + clk_names[pll->index], rate, val);
> + writel(val, pll->reg);
> + } else {
> + pr_err("%s: freq unsupported: %ld paren %ld\n",
> + clk_names[pll->index], rate, parent_rate);
> + ret = -ENOTSUPP;
I'd prefer we short circuit the function
eff_rate = clk_calc_params(...);
if (eff_rate != rate)
return -ENOTSUPP;
do the other things...
This avoids lots of indentation.
> + }
> +
> + return ret;
> +}
> +
> +static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + /* Don't care */
What does this mean? recalc_rate is supposed to tell us what rate has
been achieved for this clk.
> + return 0;
> +}
> +
> +static long clk_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + struct pll_conf conf;
> + unsigned long eff_rate;
> +
> + eff_rate = clk_calc_params(rate, &conf);
> + pr_debug("%s: Rate %ld rounded to %ld\n", __func__, rate, eff_rate);
> +
> + return eff_rate;
> +}
> +
> +static const struct clk_ops s5_pll_ops = {
> + .enable = clk_pll_enable,
> + .disable = clk_pll_disable,
> + .set_rate = clk_pll_set_rate,
> + .round_rate = clk_pll_round_rate,
> + .recalc_rate = clk_pll_recalc_rate,
> +};
> +
> +static struct s5_clk_data *s5_clk_alloc(struct device_node *np)
> +{
> + struct s5_clk_data *clk_data;
> +
> + clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
> + if (WARN_ON(!clk_data))
Drop the WARN_ON(), kzalloc() already prints a big stacktrace when it
fails.
> + return NULL;
> +
> + clk_data->base = of_iomap(np, 0);
> + if (WARN_ON(!clk_data->base))
> + return NULL;
> +
> + return clk_data;
Just inline this function at the callsite please.
> +}
> +
> +static struct clk_hw *s5_clk_hw_get(struct of_phandle_args *clkspec, void *data)
> +{
> + struct s5_clk_data *pll_clk = data;
> + unsigned int idx = clkspec->args[0];
> +
> + if (idx >= N_CLOCKS) {
> + pr_err("%s: invalid index %u\n", __func__, idx);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + return &pll_clk->s5_hw[idx].hw;
> +}
> +
> +static void __init s5_pll_init(struct device_node *np)
> +{
> + int i, ret;
> + struct s5_clk_data *pll_clk;
> + struct clk_init_data init = { 0 };
Just do init = { } so that 0 doesn't trip up sparse.
> +
> + pll_clk = s5_clk_alloc(np);
> + if (!pll_clk)
> + return;
> +
> + init.ops = &s5_pll_ops;
> + init.parent_names = NULL;
> + init.num_parents = 0;
Drop these last two lines if there aren't any parents.
> +
> + for (i = 0; i < N_CLOCKS; i++) {
> + struct s5_hw_clk *s5_hw = &pll_clk->s5_hw[i];
> +
> + init.name = clk_names[i];
> + s5_hw->index = i;
> + s5_hw->reg = pll_clk->base + (i * sizeof(u32));
> + s5_hw->hw.init = &init;
> + ret = of_clk_hw_register(np, &s5_hw->hw);
> + if (ret) {
> + pr_err("failed to register %s clock\n", init.name);
> + return;
> + }
> + }
> +
> + of_clk_add_hw_provider(np, s5_clk_hw_get, pll_clk);
> +}
> +CLK_OF_DECLARE_DRIVER(microchip_s5, "microchip,sparx5-dpll", s5_pll_init);
Why DECLARE_DRIVER? Please add a comment indicating the other driver
that is supposed to probe against this node. And is there any reason
this can't be a platform driver? That is preferred over
CLK_OF_DECLARE*() usage.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFCv2 4/9] kvm/arm64: Detach ESR operator from vCPU struct
From: Gavin Shan @ 2020-05-27 2:55 UTC (permalink / raw)
To: Mark Rutland
Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
linux-arm-kernel
In-Reply-To: <20200526105154.GD1363@C02TD0UTHF1T.local>
Hi Mark,
On 5/26/20 8:51 PM, Mark Rutland wrote:
> On Fri, May 08, 2020 at 01:29:14PM +1000, Gavin Shan wrote:
>> There are a set of inline functions defined in kvm_emulate.h. Those
>> functions reads ESR from vCPU fault information struct and then operate
>> on it. So it's tied with vCPU fault information and vCPU struct. It
>> limits their usage scope.
>>
>> This detaches these functions from the vCPU struct. With this, the
>> caller has flexibility on where the ESR is read. It shouldn't cause
>> any functional changes.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>> ---
>> arch/arm64/include/asm/kvm_emulate.h | 83 +++++++++++-------------
>> arch/arm64/kvm/handle_exit.c | 20 ++++--
>> arch/arm64/kvm/hyp/switch.c | 24 ++++---
>> arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 7 +-
>> arch/arm64/kvm/inject_fault.c | 4 +-
>> arch/arm64/kvm/sys_regs.c | 12 ++--
>> virt/kvm/arm/arm.c | 4 +-
>> virt/kvm/arm/hyp/aarch32.c | 2 +-
>> virt/kvm/arm/hyp/vgic-v3-sr.c | 5 +-
>> virt/kvm/arm/mmio.c | 27 ++++----
>> virt/kvm/arm/mmu.c | 22 ++++---
>> 11 files changed, 112 insertions(+), 98 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>> index bd1a69e7c104..2873bf6dc85e 100644
>> --- a/arch/arm64/include/asm/kvm_emulate.h
>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>> @@ -270,10 +270,8 @@ static __always_inline u32 kvm_vcpu_get_esr(const struct kvm_vcpu *vcpu)
>> return vcpu->arch.fault.esr_el2;
>> }
>>
>> -static __always_inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
>> +static __always_inline int kvm_vcpu_get_condition(u32 esr)
>
> Given the `vcpu` argument has been removed, it's odd to keep `vcpu` in the
> name, rather than `esr`.
>
> e.g. this would make more sense as something like esr_get_condition().
>
> ... and if we did something like that, we could move most of the
> extraction functions into <asm/esr.h>, and share them with non-KVM code.
>
> Otherwise, do you need to extract all of these for your use-case, or do
> you only need a few of the helpers? If you only need a few, it might be
> better to only factor those out for now, and keep the existing API in
> place with wrappers, e.g. have:
>
> | esr_get_condition(u32 esr) {
> | ...
> | }
> |
> | kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
> | {
> | return esr_get_condition(kvm_vcpu_get_esr(vcpu));
> | }
>
Sure, I'll follow approach#1, to move these helper functions to asm/esr.h
and with "vcpu" dropped in their names. I don't think it makes sense to
maintain two sets of helper functions for the simple logic. So the helper
function will be called where they should be, as below:
esr_get_condition(u32 esr) { ... }
bool __hyp_text kvm_condition_valid32(const struct kvm_vcpu *vcpu)
{
int cond = esr_get_condition(kvm_vcpu_get_esr(vcpu));
:
}
Thanks,
Gavin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 10/14] dt-bindings: clock: sparx5: Add Sparx5 SoC DPLL clock
From: Stephen Boyd @ 2020-05-27 2:46 UTC (permalink / raw)
To: Arnd Bergmann, Lars Povlsen, Linus Walleij, Rob Herring, SoC Team
Cc: devicetree, Alexandre Belloni, Steen Hegelund, linux-clk,
linux-kernel, Microchip Linux Driver Support, linux-gpio,
linux-arm-kernel, Olof Johansson, Michael Turquette, Lars Povlsen
In-Reply-To: <20200513125532.24585-11-lars.povlsen@microchip.com>
Quoting Lars Povlsen (2020-05-13 05:55:28)
> diff --git a/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
> new file mode 100644
> index 0000000000000..594007d8fc59a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/microchip,sparx5-dpll.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip Sparx5 DPLL Clock
> +
> +maintainers:
> + - Lars Povlsen <lars.povlsen@microchip.com>
> +
> +description: |
> + The Sparx5 DPLL clock controller generates and supplies clock to
> + various peripherals within the SoC.
> +
> + This binding uses common clock bindings
> + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
I don't think we need this sentence. Please drop it.
> +
> +properties:
> + compatible:
> + const: microchip,sparx5-dpll
> +
> + reg:
> + items:
> + - description: dpll registers
> +
> + '#clock-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + # Clock provider for eMMC:
> + - |
> + clks: clks@61110000c {
Node name should be clock-controller@61110000c
> + compatible = "microchip,sparx5-dpll";
> + #clock-cells = <1>;
> + reg = <0x1110000c 0x24>;
Does it consume any clks itself? I'd expect to see some sort of 'clocks'
property in this node.
> + };
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFCv2 3/9] kvm/arm64: Rename kvm_vcpu_get_hsr() to kvm_vcpu_get_esr()
From: Gavin Shan @ 2020-05-27 2:43 UTC (permalink / raw)
To: Mark Rutland
Cc: aarcange, drjones, suzuki.poulose, catalin.marinas, linux-kernel,
eric.auger, james.morse, shan.gavin, maz, will, kvmarm,
linux-arm-kernel
In-Reply-To: <20200526104249.GB1363@C02TD0UTHF1T.local>
Hi Mark,
On 5/26/20 8:42 PM, Mark Rutland wrote:
> On Fri, May 08, 2020 at 01:29:13PM +1000, Gavin Shan wrote:
>> Since kvm/arm32 was removed, this renames kvm_vcpu_get_hsr() to
>> kvm_vcpu_get_esr() to it a bit more self-explaining because the
>> functions returns ESR instead of HSR on aarch64. This shouldn't
>> cause any functional changes.
>>
>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>
> I think that this would be a nice cleanup on its own, and could be taken
> independently of the rest of this series if it were rebased and sent as
> a single patch.
>
Yeah, I'll see how PATCH[3,4,5] can be posted independently
as part of the preparatory work, which is suggested by you
in another reply.
By the way, I assume the cleanup patches are good enough to
target 5.8.rc1/rc2 if you agree.
Thanks,
Gavin
>> ---
>> arch/arm64/include/asm/kvm_emulate.h | 36 +++++++++++++++-------------
>> arch/arm64/kvm/handle_exit.c | 12 +++++-----
>> arch/arm64/kvm/hyp/switch.c | 2 +-
>> arch/arm64/kvm/sys_regs.c | 6 ++---
>> virt/kvm/arm/hyp/aarch32.c | 2 +-
>> virt/kvm/arm/hyp/vgic-v3-sr.c | 4 ++--
>> virt/kvm/arm/mmu.c | 6 ++---
>> 7 files changed, 35 insertions(+), 33 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>> index a30b4eec7cb4..bd1a69e7c104 100644
>> --- a/arch/arm64/include/asm/kvm_emulate.h
>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>> @@ -265,14 +265,14 @@ static inline bool vcpu_mode_priv(const struct kvm_vcpu *vcpu)
>> return mode != PSR_MODE_EL0t;
>> }
>>
>> -static __always_inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
>> +static __always_inline u32 kvm_vcpu_get_esr(const struct kvm_vcpu *vcpu)
>> {
>> return vcpu->arch.fault.esr_el2;
>> }
>>
>> static __always_inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
>> {
>> - u32 esr = kvm_vcpu_get_hsr(vcpu);
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>>
>> if (esr & ESR_ELx_CV)
>> return (esr & ESR_ELx_COND_MASK) >> ESR_ELx_COND_SHIFT;
>> @@ -297,64 +297,66 @@ static inline u64 kvm_vcpu_get_disr(const struct kvm_vcpu *vcpu)
>>
>> static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
>> {
>> - return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
>> + return kvm_vcpu_get_esr(vcpu) & ESR_ELx_xVC_IMM_MASK;
>> }
>>
>> static __always_inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
>> {
>> - return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_ISV);
>> + return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_ISV);
>> }
>>
>> static inline unsigned long kvm_vcpu_dabt_iss_nisv_sanitized(const struct kvm_vcpu *vcpu)
>> {
>> - return kvm_vcpu_get_hsr(vcpu) & (ESR_ELx_CM | ESR_ELx_WNR | ESR_ELx_FSC);
>> + return kvm_vcpu_get_esr(vcpu) &
>> + (ESR_ELx_CM | ESR_ELx_WNR | ESR_ELx_FSC);
>> }
>>
>> static inline bool kvm_vcpu_dabt_issext(const struct kvm_vcpu *vcpu)
>> {
>> - return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SSE);
>> + return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_SSE);
>> }
>>
>> static inline bool kvm_vcpu_dabt_issf(const struct kvm_vcpu *vcpu)
>> {
>> - return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SF);
>> + return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_SF);
>> }
>>
>> static __always_inline int kvm_vcpu_dabt_get_rd(const struct kvm_vcpu *vcpu)
>> {
>> - return (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SRT_MASK) >> ESR_ELx_SRT_SHIFT;
>> + return (kvm_vcpu_get_esr(vcpu) & ESR_ELx_SRT_MASK) >> ESR_ELx_SRT_SHIFT;
>> }
>>
>> static __always_inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
>> {
>> - return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
>> + return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_S1PTW);
>> }
>>
>> static __always_inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
>> {
>> - return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WNR) ||
>> + return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_WNR) ||
>> kvm_vcpu_dabt_iss1tw(vcpu); /* AF/DBM update */
>> }
>>
>> static inline bool kvm_vcpu_dabt_is_cm(const struct kvm_vcpu *vcpu)
>> {
>> - return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
>> + return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_CM);
>> }
>>
>> static __always_inline unsigned int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
>> {
>> - return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
>> + return 1 << ((kvm_vcpu_get_esr(vcpu) & ESR_ELx_SAS) >>
>> + ESR_ELx_SAS_SHIFT);
>> }
>>
>> /* This one is not specific to Data Abort */
>> static __always_inline bool kvm_vcpu_trap_il_is32bit(const struct kvm_vcpu *vcpu)
>> {
>> - return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_IL);
>> + return !!(kvm_vcpu_get_esr(vcpu) & ESR_ELx_IL);
>> }
>>
>> static __always_inline u8 kvm_vcpu_trap_get_class(const struct kvm_vcpu *vcpu)
>> {
>> - return ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
>> + return ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
>> }
>>
>> static inline bool kvm_vcpu_trap_is_iabt(const struct kvm_vcpu *vcpu)
>> @@ -364,12 +366,12 @@ static inline bool kvm_vcpu_trap_is_iabt(const struct kvm_vcpu *vcpu)
>>
>> static __always_inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
>> {
>> - return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC;
>> + return kvm_vcpu_get_esr(vcpu) & ESR_ELx_FSC;
>> }
>>
>> static __always_inline u8 kvm_vcpu_trap_get_fault_type(const struct kvm_vcpu *vcpu)
>> {
>> - return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC_TYPE;
>> + return kvm_vcpu_get_esr(vcpu) & ESR_ELx_FSC_TYPE;
>> }
>>
>> static __always_inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
>> @@ -393,7 +395,7 @@ static __always_inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
>>
>> static __always_inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
>> {
>> - u32 esr = kvm_vcpu_get_hsr(vcpu);
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>> return ESR_ELx_SYS64_ISS_RT(esr);
>> }
>>
>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>> index aacfc55de44c..c5b75a4d5eda 100644
>> --- a/arch/arm64/kvm/handle_exit.c
>> +++ b/arch/arm64/kvm/handle_exit.c
>> @@ -89,7 +89,7 @@ static int handle_no_fpsimd(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> */
>> static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> {
>> - if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
>> + if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
>> trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
>> vcpu->stat.wfe_exit_stat++;
>> kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
>> @@ -119,7 +119,7 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> */
>> static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> {
>> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
>> + u32 hsr = kvm_vcpu_get_esr(vcpu);
>> int ret = 0;
>>
>> run->exit_reason = KVM_EXIT_DEBUG;
>> @@ -146,7 +146,7 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>
>> static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> {
>> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
>> + u32 hsr = kvm_vcpu_get_esr(vcpu);
>>
>> kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
>> hsr, esr_get_class_string(hsr));
>> @@ -226,7 +226,7 @@ static exit_handle_fn arm_exit_handlers[] = {
>>
>> static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
>> {
>> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
>> + u32 hsr = kvm_vcpu_get_esr(vcpu);
>> u8 hsr_ec = ESR_ELx_EC(hsr);
>>
>> return arm_exit_handlers[hsr_ec];
>> @@ -267,7 +267,7 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>> int exception_index)
>> {
>> if (ARM_SERROR_PENDING(exception_index)) {
>> - u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
>> + u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_esr(vcpu));
>>
>> /*
>> * HVC/SMC already have an adjusted PC, which we need
>> @@ -333,5 +333,5 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
>> exception_index = ARM_EXCEPTION_CODE(exception_index);
>>
>> if (exception_index == ARM_EXCEPTION_EL1_SERROR)
>> - kvm_handle_guest_serror(vcpu, kvm_vcpu_get_hsr(vcpu));
>> + kvm_handle_guest_serror(vcpu, kvm_vcpu_get_esr(vcpu));
>> }
>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> index 8a1e81a400e0..2c3242bcfed2 100644
>> --- a/arch/arm64/kvm/hyp/switch.c
>> +++ b/arch/arm64/kvm/hyp/switch.c
>> @@ -437,7 +437,7 @@ static bool __hyp_text __hyp_handle_fpsimd(struct kvm_vcpu *vcpu)
>>
>> static bool __hyp_text handle_tx2_tvm(struct kvm_vcpu *vcpu)
>> {
>> - u32 sysreg = esr_sys64_to_sysreg(kvm_vcpu_get_hsr(vcpu));
>> + u32 sysreg = esr_sys64_to_sysreg(kvm_vcpu_get_esr(vcpu));
>> int rt = kvm_vcpu_sys_get_rt(vcpu);
>> u64 val = vcpu_get_reg(vcpu, rt);
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 51db934702b6..5b61465927b7 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -2214,7 +2214,7 @@ static int kvm_handle_cp_64(struct kvm_vcpu *vcpu,
>> size_t nr_specific)
>> {
>> struct sys_reg_params params;
>> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
>> + u32 hsr = kvm_vcpu_get_esr(vcpu);
>> int Rt = kvm_vcpu_sys_get_rt(vcpu);
>> int Rt2 = (hsr >> 10) & 0x1f;
>>
>> @@ -2271,7 +2271,7 @@ static int kvm_handle_cp_32(struct kvm_vcpu *vcpu,
>> size_t nr_specific)
>> {
>> struct sys_reg_params params;
>> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
>> + u32 hsr = kvm_vcpu_get_esr(vcpu);
>> int Rt = kvm_vcpu_sys_get_rt(vcpu);
>>
>> params.is_aarch32 = true;
>> @@ -2387,7 +2387,7 @@ static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
>> int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> {
>> struct sys_reg_params params;
>> - unsigned long esr = kvm_vcpu_get_hsr(vcpu);
>> + unsigned long esr = kvm_vcpu_get_esr(vcpu);
>> int Rt = kvm_vcpu_sys_get_rt(vcpu);
>> int ret;
>>
>> diff --git a/virt/kvm/arm/hyp/aarch32.c b/virt/kvm/arm/hyp/aarch32.c
>> index d31f267961e7..864b477e660a 100644
>> --- a/virt/kvm/arm/hyp/aarch32.c
>> +++ b/virt/kvm/arm/hyp/aarch32.c
>> @@ -51,7 +51,7 @@ bool __hyp_text kvm_condition_valid32(const struct kvm_vcpu *vcpu)
>> int cond;
>>
>> /* Top two bits non-zero? Unconditional. */
>> - if (kvm_vcpu_get_hsr(vcpu) >> 30)
>> + if (kvm_vcpu_get_esr(vcpu) >> 30)
>> return true;
>>
>> /* Is condition field valid? */
>> diff --git a/virt/kvm/arm/hyp/vgic-v3-sr.c b/virt/kvm/arm/hyp/vgic-v3-sr.c
>> index ccf1fde9836c..8a7a14ec9120 100644
>> --- a/virt/kvm/arm/hyp/vgic-v3-sr.c
>> +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c
>> @@ -441,7 +441,7 @@ static int __hyp_text __vgic_v3_bpr_min(void)
>>
>> static int __hyp_text __vgic_v3_get_group(struct kvm_vcpu *vcpu)
>> {
>> - u32 esr = kvm_vcpu_get_hsr(vcpu);
>> + u32 esr = kvm_vcpu_get_esr(vcpu);
>> u8 crm = (esr & ESR_ELx_SYS64_ISS_CRM_MASK) >> ESR_ELx_SYS64_ISS_CRM_SHIFT;
>>
>> return crm != 8;
>> @@ -1007,7 +1007,7 @@ int __hyp_text __vgic_v3_perform_cpuif_access(struct kvm_vcpu *vcpu)
>> bool is_read;
>> u32 sysreg;
>>
>> - esr = kvm_vcpu_get_hsr(vcpu);
>> + esr = kvm_vcpu_get_esr(vcpu);
>> if (vcpu_mode_is_32bit(vcpu)) {
>> if (!kvm_condition_valid(vcpu)) {
>> __kvm_skip_instr(vcpu);
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index e3b9ee268823..5da0d0e7519b 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -1922,7 +1922,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> * For RAS the host kernel may handle this abort.
>> * There is no need to pass the error into the guest.
>> */
>> - if (!kvm_handle_guest_sea(fault_ipa, kvm_vcpu_get_hsr(vcpu)))
>> + if (!kvm_handle_guest_sea(fault_ipa, kvm_vcpu_get_esr(vcpu)))
>> return 1;
>>
>> if (unlikely(!is_iabt)) {
>> @@ -1931,7 +1931,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> }
>> }
>>
>> - trace_kvm_guest_fault(*vcpu_pc(vcpu), kvm_vcpu_get_hsr(vcpu),
>> + trace_kvm_guest_fault(*vcpu_pc(vcpu), kvm_vcpu_get_esr(vcpu),
>> kvm_vcpu_get_hfar(vcpu), fault_ipa);
>>
>> /* Check the stage-2 fault is trans. fault or write fault */
>> @@ -1940,7 +1940,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
>> kvm_vcpu_trap_get_class(vcpu),
>> (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
>> - (unsigned long)kvm_vcpu_get_hsr(vcpu));
>> + (unsigned long)kvm_vcpu_get_esr(vcpu));
>> return -EFAULT;
>> }
>>
>> --
>> 2.23.0
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RFCv2 0/9] kvm/arm64: Support Async Page Fault
From: Gavin Shan @ 2020-05-27 2:39 UTC (permalink / raw)
To: Mark Rutland
Cc: aarcange, drjones, suzuki.poulose, maz, linux-kernel, eric.auger,
james.morse, shan.gavin, catalin.marinas, pbonzini, will, kvmarm,
linux-arm-kernel
In-Reply-To: <20200526130927.GH1363@C02TD0UTHF1T.local>
Hi Mark,
On 5/26/20 11:09 PM, Mark Rutland wrote:
> At a high-level I'm rather fearful of this series. I can see many ways
> that this can break, and I can also see that even if/when we get things
> into a working state, constant vigilance will be requried for any
> changes to the entry code.
>
> I'm not keen on injecting non-architectural exceptions in this way, and
> I'm also not keen on how deep the PV hooks are injected currently (e.g.
> in the ret_to_user path).
>
First of all, thank you for your time and providing your comments continuously.
Since the series is tagged as RFC, it's not a surprise to see something is
obviously broken. However, Could you please provide more details? With more
details, I can figure out the solutions. If I'm correct, you're talking about
the added entry code and the injected PV hooks. Anyway, please provide more
details about your concerns so that I can figure out the solutions.
Let me briefly explain why we need the injected PV hooks in ret_to_user: There
are two fashions of wakeup and I would call them as direct wakeup and delayed
wakeup. The sleeping process is waked up directly when received PAGE_READY
notification from the host, which is the process of direct wakeup. However there
are some cases the direct wakeup can't be carried out. For example, the sleeper
and the waker are same process or the (CFS) runqueue has been locked by somebody
else. In these cases, the wakeup is delayed until the idle process is running or
in ret_to_user. It's how delayed wakeup works.
> I see a few patches have preparator cleanup that I think would be
> worthwhile regardless of this series; if you could factor those out and
> send them on their own it would get that out of the way and make it
> easier to review the series itself. Similarly, there's some duplication
> of code from arch/x86 which I think can be factored out to virt/kvm
> instead as preparatory work.
>
Yep, I agree there are several cleanup patches can be posted separately
and merged in advance. I will do that and thanks for the comments.
About the shared code between arm64/x86, I need some time to investigate.
Basically, I agree to do so. I also included Paolo here to check his opnion.
It's no doubt these are all preparatory work, to make the review a bit
easier as you said :)
> Generally, I also think that you need to spend some time on commit
> messages and/or documentation to better explain the concepts and
> expected usage. I had to reverse-engineer the series by reviewing it in
> entirety before I had an idea as to how basic parts of it strung
> together, and a more thorough conceptual explanation would make it much
> easier to critique the approach rather than the individual patches.
>
Yes, sure. I will do this in the future. Sorry about having taken you
too much to do the reverse-engineering. In next revision, I might put
more information in the cover letter and commit log to explain how things
are designed and working :)
> On Fri, May 08, 2020 at 01:29:10PM +1000, Gavin Shan wrote:
>> Testing
>> =======
>> The tests are carried on the following machine. A guest with single vCPU
>> and 4GB memory is started. Also, the QEMU process is put into memory cgroup
>> (v1) whose memory limit is set to 2GB. In the guest, there are two threads,
>> which are memory bound and CPU bound separately. The memory bound thread
>> allocates all available memory, accesses and them free them. The CPU bound
>> thread simply executes block of "nop".
>
> I appreciate this is a microbenchmark, but that sounds far from
> realistic.
>
> Is there a specitic real workload that's expected to be representative
> of?
>
> Can you run tests with a real workload? For example, a kernel build
> inside the VM?
>
Yeah, I agree it's far from a realistic workload. However, it's the test case
which was suggested when async page fault was proposed from day one, according
to the following document. On the page#34, you can see the benchmark, which is
similar to what we're doing.
https://www.linux-kvm.org/images/a/ac/2010-forum-Async-page-faults.pdf
Ok. I will test with the workload to build kernel or another better one to
represent the case.
>> The test is carried out for 5 time
>> continuously and the average number (per minute) of executed blocks in the
>> CPU bound thread is taken as indicator of improvement.
>>
>> Vendor: GIGABYTE CPU: 224 x Cavium ThunderX2(R) CPU CN9975 v2.2 @ 2.0GHz
>> Memory: 32GB Disk: Fusion-MPT SAS-3 (PCIe3.0 x8)
>>
>> Without-APF: 7029030180/minute = avg(7559625120 5962155840 7823208540
>> 7629633480 6170527920)
>> With-APF: 8286827472/minute = avg(8464584540 8177073360 8262723180
>> 8095084020 8434672260)
>> Outcome: +17.8%
>>
>> Another test case is to measure the time consumed by the application, but
>> with the CPU-bound thread disabled.
>>
>> Without-APF: 40.3s = avg(40.6 39.3 39.2 41.6 41.2)
>> With-APF: 40.8s = avg(40.6 41.1 40.9 41.0 40.7)
>> Outcome: +1.2%
>
> So this is pure overhead in that case?
>
Yes, It's the pure overhead, which is mainly contributed by the injected
PV code in ret_to_user.
> I think we need to see a real workload that this benefits. As it stands
> it seems that this is a lot of complexity to game a synthetic benchmark.
>
> Thanks,
> Mark.
>
>> I also have some code in the host to capture the number of async page faults,
>> time used to do swapin and its maximal/minimal values when async page fault
>> is enabled. During the test, the CPU-bound thread is disabled. There is about
>> 30% of the time used to do swapin.
>>
>> Number of async page fault: 7555 times
>> Total time used by application: 42.2 seconds
>> Total time used by swapin: 12.7 seconds (30%)
>> Minimal swapin time: 36.2 us
>> Maximal swapin time: 55.7 ms
>>
[...]
Thanks,
Gavin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2] arm64/cpufeature: Add get_arm64_ftr_reg_nowarn()
From: Anshuman Khandual @ 2020-05-27 2:26 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: mark.rutland, Mark Brown, linux-kernel, linux-arm-kernel,
Suzuki K Poulose
In-Reply-To: <20200526194648.GA2206@willie-the-truck>
On 05/27/2020 01:16 AM, Will Deacon wrote:
> On Tue, May 26, 2020 at 04:01:35PM +0100, Catalin Marinas wrote:
>> On Tue, May 26, 2020 at 07:09:13PM +0530, Anshuman Khandual wrote:
>>> @@ -632,8 +654,6 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
>>> const struct arm64_ftr_bits *ftrp;
>>> struct arm64_ftr_reg *reg = get_arm64_ftr_reg(sys_reg);
>>>
>>> - BUG_ON(!reg);
>>> -
>>> for (ftrp = reg->ftr_bits; ftrp->width; ftrp++) {
>>> u64 ftr_mask = arm64_ftr_mask(ftrp);
>>> s64 ftr_new = arm64_ftr_value(ftrp, new);
>>> @@ -762,7 +782,6 @@ static int check_update_ftr_reg(u32 sys_id, int cpu, u64 val, u64 boot)
>>> {
>>> struct arm64_ftr_reg *regp = get_arm64_ftr_reg(sys_id);
>>>
>>> - BUG_ON(!regp);
>>> update_cpu_ftr_reg(regp, val);
>>> if ((boot & regp->strict_mask) == (val & regp->strict_mask))
>>> return 0;
>>> @@ -776,9 +795,6 @@ static void relax_cpu_ftr_reg(u32 sys_id, int field)
>>> const struct arm64_ftr_bits *ftrp;
>>> struct arm64_ftr_reg *regp = get_arm64_ftr_reg(sys_id);
>>>
>>> - if (WARN_ON(!regp))
>>> - return;
>>
>> I think Will wanted an early return in all these functions not just
>> removing the BUG_ON(). I'll let him clarify.
>
> Yes, the callers need to check the pointer and return early.
Sure, will do. But for check_update_ftr_reg(), a feature register search
failure should be treated as a success (0) or a failure (1). What should
it return ? Seems bit tricky, as there are good reasons to go either way.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/4] scsi: ufs: Fix WriteBooster and cleanup UFS driver
From: Martin K. Petersen @ 2020-05-27 2:12 UTC (permalink / raw)
To: avri.altman, asutoshd, linux-scsi, alim.akhtar, jejb, Stanley Chu
Cc: Virtual_Global_UFS_Upstream, bvanassche, Martin K . Petersen,
linux-kernel, cang, linux-mediatek, matthias.bgg,
linux-arm-kernel, beanhuo
In-Reply-To: <20200522083212.4008-1-stanley.chu@mediatek.com>
On Fri, 22 May 2020 16:32:08 +0800, Stanley Chu wrote:
> This patch set fixes some WriteBooster issues and do small cleanup in UFS driver
>
> v3 -> v4
> - Squash patch [4] and [5] (Asutosh)
> - Fix commit message in patch [4]
>
> v2 -> v3
> - Introduce patch [5] to fix possible VCC power drain during runtime suspend (Asutosh)
>
> [...]
Applied to 5.8/scsi-queue, thanks!
[1/4] scsi: ufs: Remove unnecessary memset for dev_info
https://git.kernel.org/mkp/scsi/c/3a66ae512b09
[2/4] scsi: ufs: Allow WriteBooster on UFS 2.2 devices
https://git.kernel.org/mkp/scsi/c/c7cee3e746a5
[3/4] scsi: ufs: Fix index of attributes query for WriteBooster feature
https://git.kernel.org/mkp/scsi/c/e31011ab3709
[4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend
https://git.kernel.org/mkp/scsi/c/51dd905bd2f6
--
Martin K. Petersen Oracle Linux Engineering
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 24/26] arm64: mte: Introduce early param to disable MTE support
From: Patrick Daly @ 2020-05-27 2:11 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, Vladimir Murzin, Will Deacon, Szabolcs Nagy,
Andrey Konovalov, Kevin Brodsky, linux-mm, Vincenzo Frascino,
Peter Collingbourne, Dave P Martin, linux-arm-kernel
In-Reply-To: <20200522103714.GA26492@gaia>
On Fri, May 22, 2020 at 11:37:15AM +0100, Catalin Marinas wrote:
> Hi Patrick,
>
> On Thu, May 21, 2020 at 10:57:10PM -0700, Patrick Daly wrote:
> > On Mon, May 18, 2020 at 06:20:55PM +0100, Catalin Marinas wrote:
> > > On Mon, May 18, 2020 at 12:31:03PM +0100, Will Deacon wrote:
> > > > On Mon, May 18, 2020 at 12:26:30PM +0100, Vladimir Murzin wrote:
> > > > > On 5/15/20 6:16 PM, Catalin Marinas wrote:
> > > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > > > > index f2a93c8679e8..7436e7462b85 100644
> > > > > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > > > > @@ -373,6 +373,10 @@
> > > > > > arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
> > > > > > Format: <io>,<irq>,<nodeID>
> > > > > >
> > > > > > + arm64.mte_disable=
> > > > > > + [ARM64] Disable Linux support for the Memory
> > > > > > + Tagging Extension (both user and in-kernel).
> > > > > > +
> > > > >
> > > > > Should it really to take parameter (on/off/true/false)? It may lead to expectation
> > > > > that arm64.mte_disable=false should enable MT and, yes, double negatives make it
> > > > > look ugly, so if we do need parameter, can it be arm64.mte=on/off/true/false?
> > > >
> > > > I don't think "performance analysis" is a good justification for this
> > > > parameter tbh. We don't tend to add these options for other architectural
> > > > features, and I don't see why MTE is any different in this regard.
> > >
> > > There is an expectation of performance impact with MTE enabled,
> > > especially if it's running in synchronous mode. For the in-kernel MTE,
> > > we could add a parameter which sets sync vs async at boot time rather
> > > than a big disable knob. It won't affect user space however.
> > >
> > > The other 'justification' is if your hardware has weird unexpected
> > > behaviour but I'd like this handled via errata workarounds.
> > >
> > > I'll let the people who asked for this to chip in ;). I agree with you
> > > that we rarely add these (and I rejected a similar option a few weeks
> > > ago on the AMU patchset).
> >
> > We've been looking into other ways this on/off behavior could be achieved.
>
> The actual question here is what the on/off behaviour is needed for. We
> can figure out the best mechanism for this once we know what we want to
> achieve. My wild guess above was performance analysis but that can be
> toggled by either kernel boot parameter or run-time sysctl (or just the
> Kconfig option).
>
> If it is about forcing user space not to use MTE, we may look into some
> other sysctl controls (we already have one for the tagged address ABI).
We want to allow the end user to be able to easily "opt out" of MTE in favour
of better power, perf and battery life.
In terms of deciding policy, a sysctl is much more accessible than
reompiling with CONFIG_MTE=n, or replacing userspace libraries with
equivalents which don't use PROT_MTE.
--Patrick
>
> If it is for working around hardware not supporting MTE (i.e. no
> allocation tag storage), this should be handled differently, not by
> kernel parameter.
>
> > The "arm,armv8.5-memtag" DT flag already provides what we want - meaning
> > that this flag could be removed if the system did not support MTE.
> >
> > I did see your remark on "arm64: mte: Check the DT memory nodes for MTE support"
> > questioning whether it was the right approach - is this still the case?
>
> My plan is to remove the DT patch altogether _if_ I get confirmation
> from the CPU designers. The idea is that if ID_AA64PFR1_EL1.MTE > 1,
> Linux can assume system-wide MTE support. If an MTE-capable CPU is
> deployed in an SoC without tag storage, a tie-off should change the ID
> field to 1 (or 0). If we do find hardware with an ID field > 1 and no
> tag storage, it will be handled as an SoC erratum in the kernel,
> probably tied to the new SoC Id advertised by firmware (Sudeep had some
> patches recently).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 06/14] media: platform: Improve the implementation of the system PM ops
From: Xia Jiang @ 2020-05-27 1:52 UTC (permalink / raw)
To: Tomasz Figa
Cc: drinkcat, devicetree, mojahsu, srv_heupstream, Rick Chang,
senozhatsky, linux-kernel, maoguang.meng, Mauro Carvalho Chehab,
sj.huang, Rob Herring, Matthias Brugger, Hans Verkuil,
linux-mediatek, Marek Szyprowski, linux-arm-kernel, linux-media
In-Reply-To: <20200521153257.GF209565@chromium.org>
On Thu, 2020-05-21 at 15:32 +0000, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:25PM +0800, Xia Jiang wrote:
> > Cancel reset hw operation in suspend and resume function because this
> > will be done in device_run().
>
> This and...
>
> > Add spin_lock and unlock operation in irq and resume function to make
> > sure that the current frame is processed completely before suspend.
>
> ...this are two separate changes. Please split.
>
> >
> > Signed-off-by: Xia Jiang <xia.jiang@mediatek.com>
> > ---
> > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index dd5cadd101ef..2fa3711fdc9b 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -911,6 +911,8 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> > u32 dec_ret;
> > int i;
> >
> > + spin_lock(&jpeg->hw_lock);
> > +
>
> nit: For consistency, it is recommended to always use the same, i.e. the
> strongest, spin_(un)lock_ primitives when operating on the same spinlock.
> In this case it would be the irqsave(restore) variants.
>
> > dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
> > dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
> > ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
> > @@ -941,6 +943,7 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> > v4l2_m2m_buf_done(src_buf, buf_state);
> > v4l2_m2m_buf_done(dst_buf, buf_state);
> > v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> > + spin_unlock(&jpeg->hw_lock);
> > pm_runtime_put_sync(ctx->jpeg->dev);
> > return IRQ_HANDLED;
> > }
> > @@ -1191,7 +1194,6 @@ static __maybe_unused int mtk_jpeg_pm_suspend(struct device *dev)
> > {
> > struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
> >
> > - mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> > mtk_jpeg_clk_off(jpeg);
> >
> > return 0;
> > @@ -1202,19 +1204,24 @@ static __maybe_unused int mtk_jpeg_pm_resume(struct device *dev)
> > struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
> >
> > mtk_jpeg_clk_on(jpeg);
> > - mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> >
> > return 0;
> > }
> >
> > static __maybe_unused int mtk_jpeg_suspend(struct device *dev)
> > {
> > + struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
> > + unsigned long flags;
> > int ret;
> >
> > if (pm_runtime_suspended(dev))
> > return 0;
> >
> > + spin_lock_irqsave(&jpeg->hw_lock, flags);
>
> What does this spinlock protect us from? I can see that it would prevent
> the interrupt handler from being called, but is it okay to suspend the
> system without handling the interrupt?
Dear Tomasz,
I mean that if current image is processed in irq handler,suspend
function can not get the lock(it was locked in irq handler).Should I
move the spin_lock_irqsave(&jpeg->hw_lock, flags) to the start location
of suspend function or use wait_event_timeout() to handle the interrupt
before suspend?
Best Regards,
Xia Jiang
>
> > +
> > ret = mtk_jpeg_pm_suspend(dev);
> > +
>
> Looking at the implementation of mtk_jpeg_pm_suspend(), all it does is
> disabling the clock. How do we make sure that there is no frame currently
> being processed by the hardware?
>
> Best regards,
> Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9] mfd: mt6360: add pmic mt6360 driver
From: Gene Chen @ 2020-05-27 1:47 UTC (permalink / raw)
To: Lee Jones, matthias.bgg
Cc: Gene Chen, linux-kernel, cy_huang, linux-mediatek, Wilma.Wu,
linux-arm-kernel, shufan_lee
In-Reply-To: <1587641093-25441-1-git-send-email-gene.chen.richtek@gmail.com>
Gene Chen <gene.chen.richtek@gmail.com> 於 2020年4月23日 週四 下午7:25寫道：
>
> Add mfd driver for mt6360 pmic chip include
> Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck
>
> Signed-off-by: Gene Chen <gene_chen@richtek.com>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/mfd/Kconfig | 12 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/mt6360-core.c | 425 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++
> 4 files changed, 678 insertions(+)
> create mode 100644 drivers/mfd/mt6360-core.c
> create mode 100644 include/linux/mfd/mt6360.h
>
> changelogs between v1 & v2
> - include missing header file
>
> changelogs between v2 & v3
> - add changelogs
>
> changelogs between v3 & v4
> - fix Kconfig description
> - replace mt6360_pmu_info with mt6360_pmu_data
> - replace probe with probe_new
> - remove unnecessary irq_chip variable
> - remove annotation
> - replace MT6360_MFD_CELL with OF_MFD_CELL
>
> changelogs between v4 & v5
> - remove unnecessary parse dt function
> - use devm_i2c_new_dummy_device
> - add base-commit message
>
> changelogs between v5 & v6
> - review return value
> - remove i2c id_table
> - use GPL license v2
>
> changelogs between v6 & v7
> - add author description
> - replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE
> - remove mt6360-private.h
>
> changelogs between v7 & v8
> - fix kbuild auto reboot by include interrupt header
>
> changelogs between v8 & v9
> - fix GPL license out of date
> - add commit message about Acked-for-MFD-by
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 2b20329..0f8c341 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -857,6 +857,18 @@ config MFD_MAX8998
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_MT6360
> + tristate "Mediatek MT6360 SubPMIC"
> + select MFD_CORE
> + select REGMAP_I2C
> + select REGMAP_IRQ
> + depends on I2C
> + help
> + Say Y here to enable MT6360 PMU/PMIC/LDO functional support.
> + PMU part includes Charger, Flashlight, RGB LED
> + PMIC part includes 2-channel BUCKs and 2-channel LDOs
> + LDO part includes 4-channel LDOs
> +
> config MFD_MT6397
> tristate "MediaTek MT6397 PMIC Support"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b83f172..8c35816 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -238,6 +238,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o
> +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o
> mt6397-objs := mt6397-core.o mt6397-irq.o
> obj-$(CONFIG_MFD_MT6397) += mt6397.o
> obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o
> diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> new file mode 100644
> index 0000000..9bb63e0
> --- /dev/null
> +++ b/drivers/mfd/mt6360-core.c
> @@ -0,0 +1,425 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + *
> + * Author: Gene Chen <gene_chen@richtek.com>
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/version.h>
> +
> +#include <linux/mfd/mt6360.h>
> +
> +/* reg 0 -> 0 ~ 7 */
> +#define MT6360_CHG_TREG_EVT (4)
> +#define MT6360_CHG_AICR_EVT (5)
> +#define MT6360_CHG_MIVR_EVT (6)
> +#define MT6360_PWR_RDY_EVT (7)
> +/* REG 1 -> 8 ~ 15 */
> +#define MT6360_CHG_BATSYSUV_EVT (9)
> +#define MT6360_FLED_CHG_VINOVP_EVT (11)
> +#define MT6360_CHG_VSYSUV_EVT (12)
> +#define MT6360_CHG_VSYSOV_EVT (13)
> +#define MT6360_CHG_VBATOV_EVT (14)
> +#define MT6360_CHG_VBUSOV_EVT (15)
> +/* REG 2 -> 16 ~ 23 */
> +/* REG 3 -> 24 ~ 31 */
> +#define MT6360_WD_PMU_DET (25)
> +#define MT6360_WD_PMU_DONE (26)
> +#define MT6360_CHG_TMRI (27)
> +#define MT6360_CHG_ADPBADI (29)
> +#define MT6360_CHG_RVPI (30)
> +#define MT6360_OTPI (31)
> +/* REG 4 -> 32 ~ 39 */
> +#define MT6360_CHG_AICCMEASL (32)
> +#define MT6360_CHGDET_DONEI (34)
> +#define MT6360_WDTMRI (35)
> +#define MT6360_SSFINISHI (36)
> +#define MT6360_CHG_RECHGI (37)
> +#define MT6360_CHG_TERMI (38)
> +#define MT6360_CHG_IEOCI (39)
> +/* REG 5 -> 40 ~ 47 */
> +#define MT6360_PUMPX_DONEI (40)
> +#define MT6360_BAT_OVP_ADC_EVT (41)
> +#define MT6360_TYPEC_OTP_EVT (42)
> +#define MT6360_ADC_WAKEUP_EVT (43)
> +#define MT6360_ADC_DONEI (44)
> +#define MT6360_BST_BATUVI (45)
> +#define MT6360_BST_VBUSOVI (46)
> +#define MT6360_BST_OLPI (47)
> +/* REG 6 -> 48 ~ 55 */
> +#define MT6360_ATTACH_I (48)
> +#define MT6360_DETACH_I (49)
> +#define MT6360_QC30_STPDONE (51)
> +#define MT6360_QC_VBUSDET_DONE (52)
> +#define MT6360_HVDCP_DET (53)
> +#define MT6360_CHGDETI (54)
> +#define MT6360_DCDTI (55)
> +/* REG 7 -> 56 ~ 63 */
> +#define MT6360_FOD_DONE_EVT (56)
> +#define MT6360_FOD_OV_EVT (57)
> +#define MT6360_CHRDET_UVP_EVT (58)
> +#define MT6360_CHRDET_OVP_EVT (59)
> +#define MT6360_CHRDET_EXT_EVT (60)
> +#define MT6360_FOD_LR_EVT (61)
> +#define MT6360_FOD_HR_EVT (62)
> +#define MT6360_FOD_DISCHG_FAIL_EVT (63)
> +/* REG 8 -> 64 ~ 71 */
> +#define MT6360_USBID_EVT (64)
> +#define MT6360_APWDTRST_EVT (65)
> +#define MT6360_EN_EVT (66)
> +#define MT6360_QONB_RST_EVT (67)
> +#define MT6360_MRSTB_EVT (68)
> +#define MT6360_OTP_EVT (69)
> +#define MT6360_VDDAOV_EVT (70)
> +#define MT6360_SYSUV_EVT (71)
> +/* REG 9 -> 72 ~ 79 */
> +#define MT6360_FLED_STRBPIN_EVT (72)
> +#define MT6360_FLED_TORPIN_EVT (73)
> +#define MT6360_FLED_TX_EVT (74)
> +#define MT6360_FLED_LVF_EVT (75)
> +#define MT6360_FLED2_SHORT_EVT (78)
> +#define MT6360_FLED1_SHORT_EVT (79)
> +/* REG 10 -> 80 ~ 87 */
> +#define MT6360_FLED2_STRB_EVT (80)
> +#define MT6360_FLED1_STRB_EVT (81)
> +#define MT6360_FLED2_STRB_TO_EVT (82)
> +#define MT6360_FLED1_STRB_TO_EVT (83)
> +#define MT6360_FLED2_TOR_EVT (84)
> +#define MT6360_FLED1_TOR_EVT (85)
> +/* REG 11 -> 88 ~ 95 */
> +/* REG 12 -> 96 ~ 103 */
> +#define MT6360_BUCK1_PGB_EVT (96)
> +#define MT6360_BUCK1_OC_EVT (100)
> +#define MT6360_BUCK1_OV_EVT (101)
> +#define MT6360_BUCK1_UV_EVT (102)
> +/* REG 13 -> 104 ~ 111 */
> +#define MT6360_BUCK2_PGB_EVT (104)
> +#define MT6360_BUCK2_OC_EVT (108)
> +#define MT6360_BUCK2_OV_EVT (109)
> +#define MT6360_BUCK2_UV_EVT (110)
> +/* REG 14 -> 112 ~ 119 */
> +#define MT6360_LDO1_OC_EVT (113)
> +#define MT6360_LDO2_OC_EVT (114)
> +#define MT6360_LDO3_OC_EVT (115)
> +#define MT6360_LDO5_OC_EVT (117)
> +#define MT6360_LDO6_OC_EVT (118)
> +#define MT6360_LDO7_OC_EVT (119)
> +/* REG 15 -> 120 ~ 127 */
> +#define MT6360_LDO1_PGB_EVT (121)
> +#define MT6360_LDO2_PGB_EVT (122)
> +#define MT6360_LDO3_PGB_EVT (123)
> +#define MT6360_LDO5_PGB_EVT (125)
> +#define MT6360_LDO6_PGB_EVT (126)
> +#define MT6360_LDO7_PGB_EVT (127)
> +
> +static const struct regmap_irq mt6360_pmu_irqs[] = {
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_MIVR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_PWR_RDY_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_BATSYSUV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_CHG_VINOVP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSUV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VSYSOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBATOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_VBUSOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DET, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_WD_PMU_DONE, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TMRI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_ADPBADI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_RVPI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_OTPI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_AICCMEASL, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHGDET_DONEI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_WDTMRI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_SSFINISHI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_RECHGI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TERMI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_IEOCI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_PUMPX_DONEI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHG_TREG_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BAT_OVP_ADC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_TYPEC_OTP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_ADC_WAKEUP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_ADC_DONEI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BST_BATUVI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BST_VBUSOVI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BST_OLPI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_ATTACH_I, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_DETACH_I, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_QC30_STPDONE, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_QC_VBUSDET_DONE, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_HVDCP_DET, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHGDETI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_DCDTI, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_DONE_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_OV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_UVP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_OVP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_CHRDET_EXT_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_LR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_HR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FOD_DISCHG_FAIL_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_USBID_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_APWDTRST_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_EN_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_QONB_RST_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_MRSTB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_OTP_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_VDDAOV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_SYSUV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_STRBPIN_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_TORPIN_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_TX_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED_LVF_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_SHORT_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_SHORT_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_STRB_TO_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_STRB_TO_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED2_TOR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_FLED1_TOR_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_OV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK1_UV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_OV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_BUCK2_UV_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO1_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO2_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO3_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO5_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO6_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO7_OC_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO1_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO2_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO3_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO5_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO6_PGB_EVT, 8),
> + REGMAP_IRQ_REG_LINE(MT6360_LDO7_PGB_EVT, 8),
> +};
> +
> +static int mt6360_pmu_handle_post_irq(void *irq_drv_data)
> +{
> + struct mt6360_pmu_data *mpd = irq_drv_data;
> +
> + return regmap_update_bits(mpd->regmap,
> + MT6360_PMU_IRQ_SET, MT6360_IRQ_RETRIG, MT6360_IRQ_RETRIG);
> +}
> +
> +static struct regmap_irq_chip mt6360_pmu_irq_chip = {
> + .irqs = mt6360_pmu_irqs,
> + .num_irqs = ARRAY_SIZE(mt6360_pmu_irqs),
> + .num_regs = MT6360_PMU_IRQ_REGNUM,
> + .mask_base = MT6360_PMU_CHG_MASK1,
> + .status_base = MT6360_PMU_CHG_IRQ1,
> + .ack_base = MT6360_PMU_CHG_IRQ1,
> + .init_ack_masked = true,
> + .use_ack = true,
> + .handle_post_irq = mt6360_pmu_handle_post_irq,
> +};
> +
> +static const struct regmap_config mt6360_pmu_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MT6360_PMU_MAXREG,
> +};
> +
> +static const struct resource mt6360_adc_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_ADC_DONEI, "adc_donei"),
> +};
> +
> +static const struct resource mt6360_chg_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TREG_EVT, "chg_treg_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_PWR_RDY_EVT, "pwr_rdy_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_BATSYSUV_EVT, "chg_batsysuv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSUV_EVT, "chg_vsysuv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VSYSOV_EVT, "chg_vsysov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBATOV_EVT, "chg_vbatov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_VBUSOV_EVT, "chg_vbusov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_AICCMEASL, "chg_aiccmeasl"),
> + DEFINE_RES_IRQ_NAMED(MT6360_WDTMRI, "wdtmri"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_RECHGI, "chg_rechgi"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_TERMI, "chg_termi"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHG_IEOCI, "chg_ieoci"),
> + DEFINE_RES_IRQ_NAMED(MT6360_PUMPX_DONEI, "pumpx_donei"),
> + DEFINE_RES_IRQ_NAMED(MT6360_ATTACH_I, "attach_i"),
> + DEFINE_RES_IRQ_NAMED(MT6360_CHRDET_EXT_EVT, "chrdet_ext_evt"),
> +};
> +
> +static const struct resource mt6360_led_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED_CHG_VINOVP_EVT, "fled_chg_vinovp_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED_LVF_EVT, "fled_lvf_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_SHORT_EVT, "fled2_short_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_SHORT_EVT, "fled1_short_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED2_STRB_TO_EVT, "fled2_strb_to_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_FLED1_STRB_TO_EVT, "fled1_strb_to_evt"),
> +};
> +
> +static const struct resource mt6360_pmic_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_PGB_EVT, "buck1_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OC_EVT, "buck1_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_OV_EVT, "buck1_ov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK1_UV_EVT, "buck1_uv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_PGB_EVT, "buck2_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OC_EVT, "buck2_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_OV_EVT, "buck2_ov_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_BUCK2_UV_EVT, "buck2_uv_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_OC_EVT, "ldo6_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_OC_EVT, "ldo7_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO6_PGB_EVT, "ldo6_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO7_PGB_EVT, "ldo7_pgb_evt"),
> +};
> +
> +static const struct resource mt6360_ldo_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_OC_EVT, "ldo1_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_OC_EVT, "ldo2_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_OC_EVT, "ldo3_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_OC_EVT, "ldo5_oc_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO1_PGB_EVT, "ldo1_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO2_PGB_EVT, "ldo2_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO3_PGB_EVT, "ldo3_pgb_evt"),
> + DEFINE_RES_IRQ_NAMED(MT6360_LDO5_PGB_EVT, "ldo5_pgb_evt"),
> +};
> +
> +static const struct mfd_cell mt6360_devs[] = {
> + OF_MFD_CELL("mt6360_adc", mt6360_adc_resources,
> + NULL, 0, 0, "mediatek,mt6360_adc"),
> + OF_MFD_CELL("mt6360_chg", mt6360_chg_resources,
> + NULL, 0, 0, "mediatek,mt6360_chg"),
> + OF_MFD_CELL("mt6360_led", mt6360_led_resources,
> + NULL, 0, 0, "mediatek,mt6360_led"),
> + OF_MFD_CELL("mt6360_pmic", mt6360_pmic_resources,
> + NULL, 0, 0, "mediatek,mt6360_pmic"),
> + OF_MFD_CELL("mt6360_ldo", mt6360_ldo_resources,
> + NULL, 0, 0, "mediatek,mt6360_ldo"),
> + OF_MFD_CELL("mt6360_tcpc", NULL,
> + NULL, 0, 0, "mediatek,mt6360_tcpc"),
> +};
> +
> +static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] = {
> + MT6360_PMU_SLAVEID,
> + MT6360_PMIC_SLAVEID,
> + MT6360_LDO_SLAVEID,
> + MT6360_TCPC_SLAVEID,
> +};
> +
> +static int mt6360_pmu_probe(struct i2c_client *client)
> +{
> + struct mt6360_pmu_data *mpd;
> + unsigned int reg_data;
> + int i, ret;
> +
> + mpd = devm_kzalloc(&client->dev, sizeof(*mpd), GFP_KERNEL);
> + if (!mpd)
> + return -ENOMEM;
> +
> + mpd->dev = &client->dev;
> + i2c_set_clientdata(client, mpd);
> +
> + mpd->regmap = devm_regmap_init_i2c(client, &mt6360_pmu_regmap_config);
> + if (IS_ERR(mpd->regmap)) {
> + dev_err(&client->dev, "Failed to register regmap\n");
> + return PTR_ERR(mpd->regmap);
> + }
> +
> + ret = regmap_read(mpd->regmap, MT6360_PMU_DEV_INFO, ®_data);
> + if (ret) {
> + dev_err(&client->dev, "Device not found\n");
> + return ret;
> + }
> +
> + mpd->chip_rev = reg_data & CHIP_REV_MASK;
> + if (mpd->chip_rev != CHIP_VEN_MT6360) {
> + dev_err(&client->dev, "Device not supported\n");
> + return -ENODEV;
> + }
> +
> + mt6360_pmu_irq_chip.irq_drv_data = mpd;
> + ret = devm_regmap_add_irq_chip(&client->dev, mpd->regmap, client->irq,
> + IRQF_TRIGGER_FALLING, 0,
> + &mt6360_pmu_irq_chip, &mpd->irq_data);
> + if (ret) {
> + dev_err(&client->dev, "Failed to add Regmap IRQ Chip\n");
> + return ret;
> + }
> +
> + mpd->i2c[0] = client;
> + for (i = 1; i < MT6360_SLAVE_MAX; i++) {
> + mpd->i2c[i] = devm_i2c_new_dummy_device(&client->dev,
> + client->adapter,
> + mt6360_slave_addr[i]);
> + if (IS_ERR(mpd->i2c[i])) {
> + dev_err(&client->dev,
> + "Failed to get new dummy I2C device for address 0x%x",
> + mt6360_slave_addr[i]);
> + return PTR_ERR(mpd->i2c[i]);
> + }
> + i2c_set_clientdata(mpd->i2c[i], mpd);
> + }
> +
> + ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + mt6360_devs, ARRAY_SIZE(mt6360_devs), NULL,
> + 0, regmap_irq_get_domain(mpd->irq_data));
> + if (ret) {
> + dev_err(&client->dev,
> + "Failed to register subordinate devices\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __maybe_unused mt6360_pmu_suspend(struct device *dev)
> +{
> + struct i2c_client *i2c = to_i2c_client(dev);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(i2c->irq);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused mt6360_pmu_resume(struct device *dev)
> +{
> +
> + struct i2c_client *i2c = to_i2c_client(dev);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(i2c->irq);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(mt6360_pmu_pm_ops,
> + mt6360_pmu_suspend, mt6360_pmu_resume);
> +
> +static const struct of_device_id __maybe_unused mt6360_pmu_of_id[] = {
> + { .compatible = "mediatek,mt6360_pmu", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mt6360_pmu_of_id);
> +
> +static struct i2c_driver mt6360_pmu_driver = {
> + .driver = {
> + .pm = &mt6360_pmu_pm_ops,
> + .of_match_table = of_match_ptr(mt6360_pmu_of_id),
> + },
> + .probe_new = mt6360_pmu_probe,
> +};
> +module_i2c_driver(mt6360_pmu_driver);
> +
> +MODULE_AUTHOR("Gene Chen <gene_chen@richtek.com>");
> +MODULE_DESCRIPTION("MT6360 PMU I2C Driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
> new file mode 100644
> index 0000000..ea13040
> --- /dev/null
> +++ b/include/linux/mfd/mt6360.h
> @@ -0,0 +1,240 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#ifndef __MT6360_H__
> +#define __MT6360_H__
> +
> +#include <linux/regmap.h>
> +
> +enum {
> + MT6360_SLAVE_PMU = 0,
> + MT6360_SLAVE_PMIC,
> + MT6360_SLAVE_LDO,
> + MT6360_SLAVE_TCPC,
> + MT6360_SLAVE_MAX,
> +};
> +
> +#define MT6360_PMU_SLAVEID (0x34)
> +#define MT6360_PMIC_SLAVEID (0x1A)
> +#define MT6360_LDO_SLAVEID (0x64)
> +#define MT6360_TCPC_SLAVEID (0x4E)
> +
> +struct mt6360_pmu_data {
> + struct i2c_client *i2c[MT6360_SLAVE_MAX];
> + struct device *dev;
> + struct regmap *regmap;
> + struct regmap_irq_chip_data *irq_data;
> + unsigned int chip_rev;
> +};
> +
> +/* PMU register defininition */
> +#define MT6360_PMU_DEV_INFO (0x00)
> +#define MT6360_PMU_CORE_CTRL1 (0x01)
> +#define MT6360_PMU_RST1 (0x02)
> +#define MT6360_PMU_CRCEN (0x03)
> +#define MT6360_PMU_RST_PAS_CODE1 (0x04)
> +#define MT6360_PMU_RST_PAS_CODE2 (0x05)
> +#define MT6360_PMU_CORE_CTRL2 (0x06)
> +#define MT6360_PMU_TM_PAS_CODE1 (0x07)
> +#define MT6360_PMU_TM_PAS_CODE2 (0x08)
> +#define MT6360_PMU_TM_PAS_CODE3 (0x09)
> +#define MT6360_PMU_TM_PAS_CODE4 (0x0A)
> +#define MT6360_PMU_IRQ_IND (0x0B)
> +#define MT6360_PMU_IRQ_MASK (0x0C)
> +#define MT6360_PMU_IRQ_SET (0x0D)
> +#define MT6360_PMU_SHDN_CTRL (0x0E)
> +#define MT6360_PMU_TM_INF (0x0F)
> +#define MT6360_PMU_I2C_CTRL (0x10)
> +#define MT6360_PMU_CHG_CTRL1 (0x11)
> +#define MT6360_PMU_CHG_CTRL2 (0x12)
> +#define MT6360_PMU_CHG_CTRL3 (0x13)
> +#define MT6360_PMU_CHG_CTRL4 (0x14)
> +#define MT6360_PMU_CHG_CTRL5 (0x15)
> +#define MT6360_PMU_CHG_CTRL6 (0x16)
> +#define MT6360_PMU_CHG_CTRL7 (0x17)
> +#define MT6360_PMU_CHG_CTRL8 (0x18)
> +#define MT6360_PMU_CHG_CTRL9 (0x19)
> +#define MT6360_PMU_CHG_CTRL10 (0x1A)
> +#define MT6360_PMU_CHG_CTRL11 (0x1B)
> +#define MT6360_PMU_CHG_CTRL12 (0x1C)
> +#define MT6360_PMU_CHG_CTRL13 (0x1D)
> +#define MT6360_PMU_CHG_CTRL14 (0x1E)
> +#define MT6360_PMU_CHG_CTRL15 (0x1F)
> +#define MT6360_PMU_CHG_CTRL16 (0x20)
> +#define MT6360_PMU_CHG_AICC_RESULT (0x21)
> +#define MT6360_PMU_DEVICE_TYPE (0x22)
> +#define MT6360_PMU_QC_CONTROL1 (0x23)
> +#define MT6360_PMU_QC_CONTROL2 (0x24)
> +#define MT6360_PMU_QC30_CONTROL1 (0x25)
> +#define MT6360_PMU_QC30_CONTROL2 (0x26)
> +#define MT6360_PMU_USB_STATUS1 (0x27)
> +#define MT6360_PMU_QC_STATUS1 (0x28)
> +#define MT6360_PMU_QC_STATUS2 (0x29)
> +#define MT6360_PMU_CHG_PUMP (0x2A)
> +#define MT6360_PMU_CHG_CTRL17 (0x2B)
> +#define MT6360_PMU_CHG_CTRL18 (0x2C)
> +#define MT6360_PMU_CHRDET_CTRL1 (0x2D)
> +#define MT6360_PMU_CHRDET_CTRL2 (0x2E)
> +#define MT6360_PMU_DPDN_CTRL (0x2F)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL1 (0x30)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL2 (0x31)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL3 (0x32)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL4 (0x33)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL5 (0x34)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL6 (0x35)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL7 (0x36)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL8 (0x37)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL9 (0x38)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL10 (0x39)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL11 (0x3A)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL12 (0x3B)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL13 (0x3C)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL14 (0x3D)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL15 (0x3E)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL16 (0x3F)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL17 (0x40)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL18 (0x41)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL19 (0x42)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL20 (0x43)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL21 (0x44)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL22 (0x45)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL23 (0x46)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL24 (0x47)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL25 (0x48)
> +#define MT6360_PMU_BC12_CTRL (0x49)
> +#define MT6360_PMU_CHG_STAT (0x4A)
> +#define MT6360_PMU_RESV1 (0x4B)
> +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEH (0x4E)
> +#define MT6360_PMU_TYPEC_OTP_TH_SEL_CODEL (0x4F)
> +#define MT6360_PMU_TYPEC_OTP_HYST_TH (0x50)
> +#define MT6360_PMU_TYPEC_OTP_CTRL (0x51)
> +#define MT6360_PMU_ADC_BAT_DATA_H (0x52)
> +#define MT6360_PMU_ADC_BAT_DATA_L (0x53)
> +#define MT6360_PMU_IMID_BACKBST_ON (0x54)
> +#define MT6360_PMU_IMID_BACKBST_OFF (0x55)
> +#define MT6360_PMU_ADC_CONFIG (0x56)
> +#define MT6360_PMU_ADC_EN2 (0x57)
> +#define MT6360_PMU_ADC_IDLE_T (0x58)
> +#define MT6360_PMU_ADC_RPT_1 (0x5A)
> +#define MT6360_PMU_ADC_RPT_2 (0x5B)
> +#define MT6360_PMU_ADC_RPT_3 (0x5C)
> +#define MT6360_PMU_ADC_RPT_ORG1 (0x5D)
> +#define MT6360_PMU_ADC_RPT_ORG2 (0x5E)
> +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEH (0x5F)
> +#define MT6360_PMU_BAT_OVP_TH_SEL_CODEL (0x60)
> +#define MT6360_PMU_CHG_CTRL19 (0x61)
> +#define MT6360_PMU_VDDASUPPLY (0x62)
> +#define MT6360_PMU_BC12_MANUAL (0x63)
> +#define MT6360_PMU_CHGDET_FUNC (0x64)
> +#define MT6360_PMU_FOD_CTRL (0x65)
> +#define MT6360_PMU_CHG_CTRL20 (0x66)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL26 (0x67)
> +#define MT6360_PMU_CHG_HIDDEN_CTRL27 (0x68)
> +#define MT6360_PMU_RESV2 (0x69)
> +#define MT6360_PMU_USBID_CTRL1 (0x6D)
> +#define MT6360_PMU_USBID_CTRL2 (0x6E)
> +#define MT6360_PMU_USBID_CTRL3 (0x6F)
> +#define MT6360_PMU_FLED_CFG (0x70)
> +#define MT6360_PMU_RESV3 (0x71)
> +#define MT6360_PMU_FLED1_CTRL (0x72)
> +#define MT6360_PMU_FLED_STRB_CTRL (0x73)
> +#define MT6360_PMU_FLED1_STRB_CTRL2 (0x74)
> +#define MT6360_PMU_FLED1_TOR_CTRL (0x75)
> +#define MT6360_PMU_FLED2_CTRL (0x76)
> +#define MT6360_PMU_RESV4 (0x77)
> +#define MT6360_PMU_FLED2_STRB_CTRL2 (0x78)
> +#define MT6360_PMU_FLED2_TOR_CTRL (0x79)
> +#define MT6360_PMU_FLED_VMIDTRK_CTRL1 (0x7A)
> +#define MT6360_PMU_FLED_VMID_RTM (0x7B)
> +#define MT6360_PMU_FLED_VMIDTRK_CTRL2 (0x7C)
> +#define MT6360_PMU_FLED_PWSEL (0x7D)
> +#define MT6360_PMU_FLED_EN (0x7E)
> +#define MT6360_PMU_FLED_Hidden1 (0x7F)
> +#define MT6360_PMU_RGB_EN (0x80)
> +#define MT6360_PMU_RGB1_ISNK (0x81)
> +#define MT6360_PMU_RGB2_ISNK (0x82)
> +#define MT6360_PMU_RGB3_ISNK (0x83)
> +#define MT6360_PMU_RGB_ML_ISNK (0x84)
> +#define MT6360_PMU_RGB1_DIM (0x85)
> +#define MT6360_PMU_RGB2_DIM (0x86)
> +#define MT6360_PMU_RGB3_DIM (0x87)
> +#define MT6360_PMU_RESV5 (0x88)
> +#define MT6360_PMU_RGB12_Freq (0x89)
> +#define MT6360_PMU_RGB34_Freq (0x8A)
> +#define MT6360_PMU_RGB1_Tr (0x8B)
> +#define MT6360_PMU_RGB1_Tf (0x8C)
> +#define MT6360_PMU_RGB1_TON_TOFF (0x8D)
> +#define MT6360_PMU_RGB2_Tr (0x8E)
> +#define MT6360_PMU_RGB2_Tf (0x8F)
> +#define MT6360_PMU_RGB2_TON_TOFF (0x90)
> +#define MT6360_PMU_RGB3_Tr (0x91)
> +#define MT6360_PMU_RGB3_Tf (0x92)
> +#define MT6360_PMU_RGB3_TON_TOFF (0x93)
> +#define MT6360_PMU_RGB_Hidden_CTRL1 (0x94)
> +#define MT6360_PMU_RGB_Hidden_CTRL2 (0x95)
> +#define MT6360_PMU_RESV6 (0x97)
> +#define MT6360_PMU_SPARE1 (0x9A)
> +#define MT6360_PMU_SPARE2 (0xA0)
> +#define MT6360_PMU_SPARE3 (0xB0)
> +#define MT6360_PMU_SPARE4 (0xC0)
> +#define MT6360_PMU_CHG_IRQ1 (0xD0)
> +#define MT6360_PMU_CHG_IRQ2 (0xD1)
> +#define MT6360_PMU_CHG_IRQ3 (0xD2)
> +#define MT6360_PMU_CHG_IRQ4 (0xD3)
> +#define MT6360_PMU_CHG_IRQ5 (0xD4)
> +#define MT6360_PMU_CHG_IRQ6 (0xD5)
> +#define MT6360_PMU_QC_IRQ (0xD6)
> +#define MT6360_PMU_FOD_IRQ (0xD7)
> +#define MT6360_PMU_BASE_IRQ (0xD8)
> +#define MT6360_PMU_FLED_IRQ1 (0xD9)
> +#define MT6360_PMU_FLED_IRQ2 (0xDA)
> +#define MT6360_PMU_RGB_IRQ (0xDB)
> +#define MT6360_PMU_BUCK1_IRQ (0xDC)
> +#define MT6360_PMU_BUCK2_IRQ (0xDD)
> +#define MT6360_PMU_LDO_IRQ1 (0xDE)
> +#define MT6360_PMU_LDO_IRQ2 (0xDF)
> +#define MT6360_PMU_CHG_STAT1 (0xE0)
> +#define MT6360_PMU_CHG_STAT2 (0xE1)
> +#define MT6360_PMU_CHG_STAT3 (0xE2)
> +#define MT6360_PMU_CHG_STAT4 (0xE3)
> +#define MT6360_PMU_CHG_STAT5 (0xE4)
> +#define MT6360_PMU_CHG_STAT6 (0xE5)
> +#define MT6360_PMU_QC_STAT (0xE6)
> +#define MT6360_PMU_FOD_STAT (0xE7)
> +#define MT6360_PMU_BASE_STAT (0xE8)
> +#define MT6360_PMU_FLED_STAT1 (0xE9)
> +#define MT6360_PMU_FLED_STAT2 (0xEA)
> +#define MT6360_PMU_RGB_STAT (0xEB)
> +#define MT6360_PMU_BUCK1_STAT (0xEC)
> +#define MT6360_PMU_BUCK2_STAT (0xED)
> +#define MT6360_PMU_LDO_STAT1 (0xEE)
> +#define MT6360_PMU_LDO_STAT2 (0xEF)
> +#define MT6360_PMU_CHG_MASK1 (0xF0)
> +#define MT6360_PMU_CHG_MASK2 (0xF1)
> +#define MT6360_PMU_CHG_MASK3 (0xF2)
> +#define MT6360_PMU_CHG_MASK4 (0xF3)
> +#define MT6360_PMU_CHG_MASK5 (0xF4)
> +#define MT6360_PMU_CHG_MASK6 (0xF5)
> +#define MT6360_PMU_QC_MASK (0xF6)
> +#define MT6360_PMU_FOD_MASK (0xF7)
> +#define MT6360_PMU_BASE_MASK (0xF8)
> +#define MT6360_PMU_FLED_MASK1 (0xF9)
> +#define MT6360_PMU_FLED_MASK2 (0xFA)
> +#define MT6360_PMU_FAULTB_MASK (0xFB)
> +#define MT6360_PMU_BUCK1_MASK (0xFC)
> +#define MT6360_PMU_BUCK2_MASK (0xFD)
> +#define MT6360_PMU_LDO_MASK1 (0xFE)
> +#define MT6360_PMU_LDO_MASK2 (0xFF)
> +#define MT6360_PMU_MAXREG (MT6360_PMU_LDO_MASK2)
> +
> +/* MT6360_PMU_IRQ_SET */
> +#define MT6360_PMU_IRQ_REGNUM (MT6360_PMU_LDO_IRQ2 - MT6360_PMU_CHG_IRQ1 + 1)
> +#define MT6360_IRQ_RETRIG BIT(2)
> +
> +#define CHIP_VEN_MASK (0xF0)
> +#define CHIP_VEN_MT6360 (0x50)
> +#define CHIP_REV_MASK (0x0F)
> +
> +#endif /* __MT6360_H__ */
> --
> 2.7.4
>
Hi Lee,
i run checkpatch have 3 warning, but i think 1/2 can be ignored, i can
prepare devicetree binding document first.
does anything i can do when waiting review?
1. WARNING: Non-standard signature: Acked-for-mfd-by:
#10:
Acked-for-mfd-by: Lee Jones <lee.jones@linaro.org>
2. WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#92:
new file mode 100644.
3. WARNING: DT compatible string "mediatek,mt6360_pmu" appears
un-documented -- check ./Documentation/devicetree/bindings/
#505: FILE: drivers/mfd/mt6360-core.c:409:
+ { .compatible = "mediatek,mt6360_pmu", },
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox