* [PATCH 7/9] ARM: tegra: enable cache via TF
From: Dmitry Osipenko @ 2017-12-19 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a164b2270a3e996c083e94bf5b1e27028c1135e.1500510157.git.mirq-linux@rere.qmqm.pl>
On 20.07.2017 03:29, Micha? Miros?aw wrote:
> Cache enable needs to go via firmware call with TF running.
>
> Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> ---
Perhaps we can unify secure and non-secure modes. The code below works on both
secure-t30 and nonsecure-t20, all CPU's booted and working fine.
The "ARM: enable secure platform-only erratas" patch isn't needed in this case.
diff --git a/arch/arm/mach-tegra/reset-handler.S
b/arch/arm/mach-tegra/reset-handler.S
index 805f306fa6f7..9a92bbf8b5b0 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -80,6 +80,28 @@ ENTRY(tegra_resume)
#endif
#ifdef CONFIG_CACHE_L2X0
+#ifdef CONFIG_TRUSTED_FOUNDATIONS
+ adr r3, __tegra_cpu_reset_handler_data
+ ldr r0, [r3, #RESET_DATA(TF_PRESENT)]
+ cmp r0, #0
+ beq ca9_scu_l2_resume
+
+ adr r3, __tegra_smc_stack
+ stmia r3, {r4-r12, sp, lr}
+
+ mov r0, #3 // local wake
+ mov r3, #0
+ mov r4, #0
+ dsb
+ .arch_extension sec
+ smc #0
+
+ adr r3, __tegra_smc_stack
+ ldmia r3, {r4-r12, sp, pc}
+
+ b end_ca9_scu_l2_resume
+ca9_scu_l2_resume:
+#endif
/* L2 cache resume & re-enable */
bl l2c310_early_resume
#endif
@@ -92,6 +114,16 @@ end_ca9_scu_l2_resume:
ENDPROC(tegra_resume)
#endif
+#ifdef CONFIG_TRUSTED_FOUNDATIONS
+ .align L1_CACHE_SHIFT
+ .type __tegra_smc_stack, %object
+__tegra_smc_stack:
+ .rept 11
+ .long 0
+ .endr
+ .size __tegra_smc_stack, . - __tegra_smc_stack
+#endif /* CONFIG_TRUSTED_FOUNDATIONS */
+
.align L1_CACHE_SHIFT
ENTRY(__tegra_cpu_reset_handler_start)
@@ -121,6 +153,12 @@ ENTRY(__tegra_cpu_reset_handler)
cpsid aif, 0x13 @ SVC mode, interrupts disabled
tegra_get_soc_id TEGRA_APB_MISC_BASE, r6
+
+ adr r5, __tegra_cpu_reset_handler_data
+ ldr r0, [r5, #RESET_DATA(TF_PRESENT)]
+ cmp r0, #0
+ bne after_errata
+
#ifdef CONFIG_ARCH_TEGRA_2x_SOC
t20_check:
cmp r6, #TEGRA20
@@ -285,6 +323,10 @@ __tegra_cpu_reset_handler_data:
.equ __tegra20_cpu1_resettable_status_offset, \
. - __tegra_cpu_reset_handler_start
.byte 0
+ .align 4
+ .globl __tegra_tf_present
+ .equ __tegra_tf_present, . - __tegra_cpu_reset_handler_start
+ .long 0
.align L1_CACHE_SHIFT
ENTRY(__tegra_cpu_reset_handler_end)
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index dc558892753c..9b6558a69308 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -18,6 +18,7 @@
#include <linux/cpumask.h>
#include <linux/init.h>
#include <linux/io.h>
+#include <linux/of.h>
#include <soc/tegra/fuse.h>
@@ -89,6 +90,15 @@ static void __init tegra_cpu_reset_handler_enable(void)
void __init tegra_cpu_reset_handler_init(void)
{
+#ifdef CONFIG_TRUSTED_FOUNDATIONS
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "tlm,trusted-foundations");
+ if (np) {
+ __tegra_cpu_reset_handler_data[TEGRA_RESET_TF_PRESENT] = true;
+ of_node_put(np);
+ }
+#endif
#ifdef CONFIG_SMP
__tegra_cpu_reset_handler_data[TEGRA_RESET_MASK_PRESENT] =
diff --git a/arch/arm/mach-tegra/reset.h b/arch/arm/mach-tegra/reset.h
index 9c479c7925b8..0d9ddc022ece 100644
--- a/arch/arm/mach-tegra/reset.h
+++ b/arch/arm/mach-tegra/reset.h
@@ -25,7 +25,9 @@
#define TEGRA_RESET_STARTUP_SECONDARY 3
#define TEGRA_RESET_STARTUP_LP2 4
#define TEGRA_RESET_STARTUP_LP1 5
-#define TEGRA_RESET_DATA_SIZE 6
+#define TEGRA_RESET_RESETTABLE_STATUS 6
+#define TEGRA_RESET_TF_PRESENT 7
+#define TEGRA_RESET_DATA_SIZE 8
#ifndef __ASSEMBLY__
^ permalink raw reply related
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-19 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13bbaec1-31d9-f9fe-71b1-5b991f123108@codeaurora.org>
On 12/18, Timur Tabi wrote:
> On 12/18/17 8:39 PM, Stephen Boyd wrote:
> >Ah I missed that the u16 array can't be iterated through. Any
> >chance the ACPI tables can be changed to list pin ranges, like
> ><33 3>, <90 2>, to indicate that pins 33, 34, 35 and pins 90, 91
> >are available?
>
> It's too late. Firmware is already shipping with the current
> layout. Unfortunately, there's no good peer review process for DSDs
> that don't have a DT equivalent.
Alright!
>
> >That would allow us to put that into the core
> >pinctrl-msm.c file a little better and then only expose pins on
> >the gpiochip when call gpiochip_add_pin_range(). If we want to
> >support this in DT, I think we would have a DT property like
> >available-gpios = <33 3>, <90 2>, <100 34> that we can then
> >iterate through and add only these pins to the gpiochip. That's
> >better than a bitmap in DT and is still compressed somewhat.
>
> Keep in mind that all this ACPI junk is localized to
> pinctrl-qdf2xxx. pinctrl-msm does not define any new data
> structures, it just reuses the existing one. You can still define
> your DT properties any way you want in your client drivers.
> pinctrl-qdf2xxx is specific to the Centriq chips.
Of course.
>
> >Without going all the way down into that path, here's my patch to
> >make your patch smaller, but perhaps we can just look for the
> >ACPI property or the DT property in the pinctrl-msm.c core and
> >then add pin ranges directly. Then this ACPI driver doesn't
> >really need to change besides for the ID update. We can expose
> >all the pins and offsets, etc. from the hardware driver but cut
> >out gpios in the core layer in a generic way.
>
> Ok, let me review this. I don't think there's any gain in moving
> the ACPI processing to pinctrl-msm, however.
>
I will attempt to implement the DT part today. It may make the
get_direction() revert irrelevant if the gpios aren't even
exposed to gpiolib in the first place.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 0/9] soc: brcmstb: biuctrl updates for 64-bit chips
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patch series updates the Broadcom STB Bus Interface Unit controller to
support newer chips such as 7260, 7268, 7271 and 7278. These chips require
additional tuning in order to provide the expected bus throughput.
In the process, we need to re-organize the common.c file a little bit in order
to extract the family and product identifiers a little earlier.
Finally, by moving the biuctrl initialization an early_initcall level, we can
remove some code from the ARM-32bit machine descriptor file.
Provided that we are happy with these changes, I would route them through my
drivers/next branch and a subsequent Broadcom ARM SoC pull request.
Thank you
Changes in v2:
- collect Rob's acked-by on the first patch
- fixed the binding as suggested by Rob
Florian Fainelli (9):
dt-bindings: arm: Add entry for Broadcom Brahma-B53
dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
soc: brcmstb: Make CPU credit offset more parameterized
soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs
soc: brcmstb: biuctrl: Prepare for saving/restoring other registers
soc: brcmstb: biuctrl: Wire-up new registers
soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
soc: brcmstb: Split initialization
soc: brcmstb: biuctrl: Move to early_initcall
.../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 +--
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/mach-bcm/brcmstb.c | 2 -
drivers/soc/bcm/brcmstb/biuctrl.c | 176 +++++++++++++++++++--
drivers/soc/bcm/brcmstb/common.c | 27 ++--
include/linux/soc/brcmstb/brcmstb.h | 6 -
6 files changed, 186 insertions(+), 48 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/9] dt-bindings: arm: Add entry for Broadcom Brahma-B53
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
Broadcom's Brahma-B53 CPU is an ARMv8A processor used on a number of
DSL, Cable Modem and Set-top-box SoCs.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index a0009b72e9be..f4a777039f03 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -169,6 +169,7 @@ described below.
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
+ "brcm,brahma-b53"
"brcm,vulcan"
"cavium,thunder"
"cavium,thunder2"
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/9] dt-bindings: arm: brcmstb: Correct BIUCTRL node documentation
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
Correct the Device Tree bindings for the HIF_CPUBIUCTRL node whose
compatible string is actually brcm,bcm<chip-id>-cpu-biu-ctrl. Also
document in the binding the fallback property
("brcm,brcmstb-cpu-biu-ctrl") and update the example accordingly.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
index 790e6b0b8306..ed4bf3f388a3 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
@@ -17,21 +17,23 @@ Further, syscon nodes that map platform-specific registers used for general
system control is required:
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
- - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
+ - compatible: "brcm,bcm<chip_id>-cpu-biu-ctrl",
+ "brcm,brcmstb-cpu-biu-ctrl",
+ "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
-hif-cpubiuctrl node
+cpu-biu-ctrl node
-------------------
-SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit
-(BIU) block which controls and interfaces the CPU complex to the different
-Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block
-offers a feature called Write Pairing which consists in collapsing two adjacent
-cache lines into a single (bursted) write transaction towards the memory
-controller (MEMC) to maximize write bandwidth.
+SoCs with Broadcom Brahma15 ARM-based and Brahma53 ARM64-based CPUs have a
+specific Bus Interface Unit (BIU) block which controls and interfaces the CPU
+complex to the different Memory Controller Ports (MCP), one per memory
+controller (MEMC). This BIU block offers a feature called Write Pairing which
+consists in collapsing two adjacent cache lines into a single (bursted) write
+transaction towards the memory controller (MEMC) to maximize write bandwidth.
Required properties:
- - compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon"
+ - compatible: must be "brcm,bcm7445-cpu-biu-ctrl", ""brcm,brcmstb-cpu-biu-ctrl", "syscon"
Optional properties:
@@ -52,7 +54,7 @@ example:
};
hif_cpubiuctrl: syscon at 3e2400 {
- compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
+ compatible = "brcm,bcm7445-cpu-biu-ctrl", "brcm,brcmstb-cpu-biu-ctrl", "syscon";
reg = <0x3e2400 0x5b4>;
brcm,write-pairing;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/9] soc: brcmstb: Make CPU credit offset more parameterized
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
In preparation for fixing and changing values in the CPU_CREDIT_REG
register for B53-based systems, make the offset parameterized.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index 3c39415d484f..c3c548fcaa8c 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -26,6 +26,7 @@
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
+static unsigned int cpu_credit_reg_offset = CPU_CREDIT_REG_OFFSET;
static int __init mcp_write_pairing_set(void)
{
@@ -34,15 +35,15 @@ static int __init mcp_write_pairing_set(void)
if (!cpubiuctrl_base)
return -1;
- creds = readl_relaxed(cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ creds = readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
if (mcp_wr_pairing_en) {
pr_info("MCP: Enabling write pairing\n");
writel_relaxed(creds | CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ cpubiuctrl_base + cpu_credit_reg_offset);
} else if (creds & CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK) {
pr_info("MCP: Disabling write pairing\n");
writel_relaxed(creds & ~CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ cpubiuctrl_base + cpu_credit_reg_offset);
} else {
pr_info("MCP: Write pairing already disabled\n");
}
@@ -81,7 +82,7 @@ static int brcmstb_cpu_credit_reg_suspend(void)
{
if (cpubiuctrl_base)
cpu_credit_reg_dump =
- readl_relaxed(cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
return 0;
}
@@ -89,7 +90,7 @@ static void brcmstb_cpu_credit_reg_resume(void)
{
if (cpubiuctrl_base)
writel_relaxed(cpu_credit_reg_dump,
- cpubiuctrl_base + CPU_CREDIT_REG_OFFSET);
+ cpubiuctrl_base + cpu_credit_reg_offset);
}
static struct syscore_ops brcmstb_cpu_credit_syscore_ops = {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/9] soc: brcmstb: Correct CPU_CREDIT_REG offset for Brahma-B53 CPUs
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
On Broadcom Brahma-B53 CPUs, the CPU_CREDIT_REG offset got moved to
0x0b0 instead of 0x184, correct this such that we correcty
enable/disable write-pairing for these chips.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index c3c548fcaa8c..e8322e663831 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -21,12 +21,13 @@
#include <linux/syscore_ops.h>
#include <linux/soc/brcmstb/brcmstb.h>
-#define CPU_CREDIT_REG_OFFSET 0x184
+#define B15_CPU_CREDIT_REG_OFFSET 0x184
+#define B53_CPU_CREDIT_REG_OFFSET 0x0b0
#define CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK 0x70000000
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
-static unsigned int cpu_credit_reg_offset = CPU_CREDIT_REG_OFFSET;
+static unsigned int cpu_credit_reg_offset;
static int __init mcp_write_pairing_set(void)
{
@@ -53,7 +54,7 @@ static int __init mcp_write_pairing_set(void)
static int __init setup_hifcpubiuctrl_regs(void)
{
- struct device_node *np;
+ struct device_node *np, *cpu_dn;
int ret = 0;
np = of_find_compatible_node(NULL, NULL, "brcm,brcmstb-cpu-biu-ctrl");
@@ -70,6 +71,23 @@ static int __init setup_hifcpubiuctrl_regs(void)
}
mcp_wr_pairing_en = of_property_read_bool(np, "brcm,write-pairing");
+
+ cpu_dn = of_get_cpu_node(0, NULL);
+ if (!cpu_dn) {
+ pr_err("failed to obtain CPU device node\n");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (of_device_is_compatible(cpu_dn, "brcm,brahma-b15"))
+ cpu_credit_reg_offset = B15_CPU_CREDIT_REG_OFFSET;
+ else if (of_device_is_compatible(cpu_dn, "brcm,brahma-b53"))
+ cpu_credit_reg_offset = B53_CPU_CREDIT_REG_OFFSET;
+ else {
+ pr_err("unsupported CPU\n");
+ ret = -EINVAL;
+ }
+ of_node_put(cpu_dn);
out:
of_node_put(np);
return ret;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/9] soc: brcmstb: biuctrl: Prepare for saving/restoring other registers
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
In preparation for saving/restoring additional registers required on
some newer platforms (7268, 7271, 7278), migrate the code to use enums
and helper functions to access registers.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 75 ++++++++++++++++++++++++++++++---------
1 file changed, 58 insertions(+), 17 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index e8322e663831..16cbfc2e953a 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -21,13 +21,45 @@
#include <linux/syscore_ops.h>
#include <linux/soc/brcmstb/brcmstb.h>
-#define B15_CPU_CREDIT_REG_OFFSET 0x184
-#define B53_CPU_CREDIT_REG_OFFSET 0x0b0
#define CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK 0x70000000
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
-static unsigned int cpu_credit_reg_offset;
+static const int *cpubiuctrl_regs;
+
+static inline u32 cbc_readl(int reg)
+{
+ int offset = cpubiuctrl_regs[reg];
+
+ if (offset == -1)
+ return (u32)-1;
+
+ return readl_relaxed(cpubiuctrl_base + offset);
+}
+
+static inline void cbc_writel(u32 val, int reg)
+{
+ int offset = cpubiuctrl_regs[reg];
+
+ if (offset == -1)
+ return;
+
+ writel_relaxed(val, cpubiuctrl_base + offset);
+}
+
+enum cpubiuctrl_regs {
+ CPU_CREDIT_REG = 0,
+};
+
+static const int b15_cpubiuctrl_regs[] = {
+ [CPU_CREDIT_REG] = 0x184,
+};
+
+static const int b53_cpubiuctrl_regs[] = {
+ [CPU_CREDIT_REG] = 0x0b0,
+};
+
+#define NUM_CPU_BIUCTRL_REGS 1
static int __init mcp_write_pairing_set(void)
{
@@ -36,15 +68,15 @@ static int __init mcp_write_pairing_set(void)
if (!cpubiuctrl_base)
return -1;
- creds = readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
+ creds = cbc_readl(CPU_CREDIT_REG);
if (mcp_wr_pairing_en) {
pr_info("MCP: Enabling write pairing\n");
- writel_relaxed(creds | CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + cpu_credit_reg_offset);
+ cbc_writel(creds | CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
+ CPU_CREDIT_REG);
} else if (creds & CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK) {
pr_info("MCP: Disabling write pairing\n");
- writel_relaxed(creds & ~CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
- cpubiuctrl_base + cpu_credit_reg_offset);
+ cbc_writel(creds & ~CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK,
+ CPU_CREDIT_REG);
} else {
pr_info("MCP: Write pairing already disabled\n");
}
@@ -80,9 +112,9 @@ static int __init setup_hifcpubiuctrl_regs(void)
}
if (of_device_is_compatible(cpu_dn, "brcm,brahma-b15"))
- cpu_credit_reg_offset = B15_CPU_CREDIT_REG_OFFSET;
+ cpubiuctrl_regs = b15_cpubiuctrl_regs;
else if (of_device_is_compatible(cpu_dn, "brcm,brahma-b53"))
- cpu_credit_reg_offset = B53_CPU_CREDIT_REG_OFFSET;
+ cpubiuctrl_regs = b53_cpubiuctrl_regs;
else {
pr_err("unsupported CPU\n");
ret = -EINVAL;
@@ -94,21 +126,30 @@ static int __init setup_hifcpubiuctrl_regs(void)
}
#ifdef CONFIG_PM_SLEEP
-static u32 cpu_credit_reg_dump; /* for save/restore */
+static u32 cpubiuctrl_reg_save[NUM_CPU_BIUCTRL_REGS];
static int brcmstb_cpu_credit_reg_suspend(void)
{
- if (cpubiuctrl_base)
- cpu_credit_reg_dump =
- readl_relaxed(cpubiuctrl_base + cpu_credit_reg_offset);
+ unsigned int i;
+
+ if (!cpubiuctrl_base)
+ return 0;
+
+ for (i = 0; i < NUM_CPU_BIUCTRL_REGS; i++)
+ cpubiuctrl_reg_save[i] = cbc_readl(i);
+
return 0;
}
static void brcmstb_cpu_credit_reg_resume(void)
{
- if (cpubiuctrl_base)
- writel_relaxed(cpu_credit_reg_dump,
- cpubiuctrl_base + cpu_credit_reg_offset);
+ unsigned int i;
+
+ if (!cpubiuctrl_base)
+ return;
+
+ for (i = 0; i < NUM_CPU_BIUCTRL_REGS; i++)
+ cbc_writel(cpubiuctrl_reg_save[i], i);
}
static struct syscore_ops brcmstb_cpu_credit_syscore_ops = {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/9] soc: brcmstb: biuctrl: Wire-up new registers
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
Add definitions for B53 systems register: CPU_MCP_FLOW_REG and
CPU_WRITEBACK_CTRL_REG. These register will be saved and restored
accordingly.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index 16cbfc2e953a..d498f9db01ab 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -49,17 +49,23 @@ static inline void cbc_writel(u32 val, int reg)
enum cpubiuctrl_regs {
CPU_CREDIT_REG = 0,
+ CPU_MCP_FLOW_REG,
+ CPU_WRITEBACK_CTRL_REG
};
static const int b15_cpubiuctrl_regs[] = {
[CPU_CREDIT_REG] = 0x184,
+ [CPU_MCP_FLOW_REG] = -1,
+ [CPU_WRITEBACK_CTRL_REG] = -1,
};
static const int b53_cpubiuctrl_regs[] = {
[CPU_CREDIT_REG] = 0x0b0,
+ [CPU_MCP_FLOW_REG] = 0x0b4,
+ [CPU_WRITEBACK_CTRL_REG] = 0x22c,
};
-#define NUM_CPU_BIUCTRL_REGS 1
+#define NUM_CPU_BIUCTRL_REGS 3
static int __init mcp_write_pairing_set(void)
{
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/9] soc: brcmstb: biuctrl: Fine tune B53 MCP interface settings
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
In order to achieve expected MCP bus throughput on 3 particular chips:
7268, 7271 and 7278, do the appropriate programming of the MCP
interface: increase number of MCP write credits, turn on write-back
throttling when present.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/biuctrl.c | 76 +++++++++++++++++++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index d498f9db01ab..dd45bbfe64dd 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -22,6 +22,18 @@
#include <linux/soc/brcmstb/brcmstb.h>
#define CPU_CREDIT_REG_MCPx_WR_PAIRING_EN_MASK 0x70000000
+#define CPU_CREDIT_REG_MCPx_READ_CRED_MASK 0xf
+#define CPU_CREDIT_REG_MCPx_WRITE_CRED_MASK 0xf
+#define CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(x) ((x) * 8)
+#define CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(x) (((x) * 8) + 4)
+
+#define CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_SHIFT(x) ((x) * 8)
+#define CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_MASK 0xff
+
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_THRESHOLD_MASK 0xf
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_MASK 0xf
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT 4
+#define CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_ENABLE BIT(8)
static void __iomem *cpubiuctrl_base;
static bool mcp_wr_pairing_en;
@@ -59,6 +71,13 @@ static const int b15_cpubiuctrl_regs[] = {
[CPU_WRITEBACK_CTRL_REG] = -1,
};
+/* Odd cases, e.g: 7260 */
+static const int b53_cpubiuctrl_no_wb_regs[] = {
+ [CPU_CREDIT_REG] = 0x0b0,
+ [CPU_MCP_FLOW_REG] = 0x0b4,
+ [CPU_WRITEBACK_CTRL_REG] = -1,
+};
+
static const int b53_cpubiuctrl_regs[] = {
[CPU_CREDIT_REG] = 0x0b0,
[CPU_MCP_FLOW_REG] = 0x0b4,
@@ -90,6 +109,59 @@ static int __init mcp_write_pairing_set(void)
return 0;
}
+static const u32 b53_mach_compat[] = {
+ 0x7268,
+ 0x7271,
+ 0x7278,
+};
+
+static void __init mcp_b53_set(void)
+{
+ unsigned int i;
+ u32 reg;
+
+ reg = brcmstb_get_family_id();
+
+ for (i = 0; i < ARRAY_SIZE(b53_mach_compat); i++) {
+ if (BRCM_ID(reg) == b53_mach_compat[i])
+ break;
+ }
+
+ if (i == ARRAY_SIZE(b53_mach_compat))
+ return;
+
+ /* Set all 3 MCP interfaces to 8 credits */
+ reg = cbc_readl(CPU_CREDIT_REG);
+ for (i = 0; i < 3; i++) {
+ reg &= ~(CPU_CREDIT_REG_MCPx_WRITE_CRED_MASK <<
+ CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(i));
+ reg &= ~(CPU_CREDIT_REG_MCPx_READ_CRED_MASK <<
+ CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(i));
+ reg |= 8 << CPU_CREDIT_REG_MCPx_WRITE_CRED_SHIFT(i);
+ reg |= 8 << CPU_CREDIT_REG_MCPx_READ_CRED_SHIFT(i);
+ }
+ cbc_writel(reg, CPU_CREDIT_REG);
+
+ /* Max out the number of in-flight Jwords reads on the MCP interface */
+ reg = cbc_readl(CPU_MCP_FLOW_REG);
+ for (i = 0; i < 3; i++)
+ reg |= CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_MASK <<
+ CPU_MCP_FLOW_REG_MCPx_RDBUFF_CRED_SHIFT(i);
+ cbc_writel(reg, CPU_MCP_FLOW_REG);
+
+ /* Enable writeback throttling, set timeout to 128 cycles, 256 cycles
+ * threshold
+ */
+ reg = cbc_readl(CPU_WRITEBACK_CTRL_REG);
+ reg |= CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_ENABLE;
+ reg &= ~CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_THRESHOLD_MASK;
+ reg &= ~(CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_MASK <<
+ CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT);
+ reg |= 8;
+ reg |= 7 << CPU_WRITEBACK_CTRL_REG_WB_THROTTLE_TIMEOUT_SHIFT;
+ cbc_writel(reg, CPU_WRITEBACK_CTRL_REG);
+}
+
static int __init setup_hifcpubiuctrl_regs(void)
{
struct device_node *np, *cpu_dn;
@@ -126,6 +198,9 @@ static int __init setup_hifcpubiuctrl_regs(void)
ret = -EINVAL;
}
of_node_put(cpu_dn);
+
+ if (BRCM_ID(brcmstb_get_family_id()) == 0x7260)
+ cpubiuctrl_regs = b53_cpubiuctrl_no_wb_regs;
out:
of_node_put(np);
return ret;
@@ -177,6 +252,7 @@ void __init brcmstb_biuctrl_init(void)
return;
}
+ mcp_b53_set();
#ifdef CONFIG_PM_SLEEP
register_syscore_ops(&brcmstb_cpu_credit_syscore_ops);
#endif
--
2.9.3
^ permalink raw reply related
* [PATCH v2 8/9] soc: brcmstb: Split initialization
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
We may need access to family_id and product_id fairly early on boot for
other parts of the code (e.g: biuctrl.c), so split the initialization
between an early_init() and an arch_initcall() which allows us to do
that.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/soc/bcm/brcmstb/common.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
index a71730da6385..781ada62d0a3 100644
--- a/drivers/soc/bcm/brcmstb/common.c
+++ b/drivers/soc/bcm/brcmstb/common.c
@@ -66,13 +66,10 @@ static const struct of_device_id sun_top_ctrl_match[] = {
{ }
};
-static int __init brcmstb_soc_device_init(void)
+static int __init brcmstb_soc_device_early_init(void)
{
- struct soc_device_attribute *soc_dev_attr;
- struct soc_device *soc_dev;
struct device_node *sun_top_ctrl;
void __iomem *sun_top_ctrl_base;
- int ret = 0;
sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
if (!sun_top_ctrl)
@@ -84,12 +81,19 @@ static int __init brcmstb_soc_device_init(void)
family_id = readl(sun_top_ctrl_base);
product_id = readl(sun_top_ctrl_base + 0x4);
+ iounmap(sun_top_ctrl_base);
+ return 0;
+}
+early_initcall(brcmstb_soc_device_early_init);
+
+static int __init brcmstb_soc_device_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *soc_dev;
soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
- if (!soc_dev_attr) {
- ret = -ENOMEM;
- goto out;
- }
+ if (!soc_dev_attr)
+ return -ENOMEM;
soc_dev_attr->family = kasprintf(GFP_KERNEL, "%x",
family_id >> 28 ?
@@ -107,14 +111,9 @@ static int __init brcmstb_soc_device_init(void)
kfree(soc_dev_attr->soc_id);
kfree(soc_dev_attr->revision);
kfree(soc_dev_attr);
- ret = -ENODEV;
- goto out;
+ return -ENOMEM;
}
return 0;
-
-out:
- iounmap(sun_top_ctrl_base);
- return ret;
}
arch_initcall(brcmstb_soc_device_init);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 9/9] soc: brcmstb: biuctrl: Move to early_initcall
From: Florian Fainelli @ 2017-12-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219192247.29799-1-f.fainelli@gmail.com>
Being called during early_initcall() is early enough that it occurs
before SMP initialization, which is all we care about for the Bus
Interface Unit configuration.
This solves lack of BIU initialization on ARM64 platforms where we do
not have an anchor where to put the BIU initialization (since there are
no machine descriptors).
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mach-bcm/brcmstb.c | 2 --
drivers/soc/bcm/brcmstb/biuctrl.c | 6 ++++--
include/linux/soc/brcmstb/brcmstb.h | 6 ------
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
index 07e3a86c6466..5f127d5f1045 100644
--- a/arch/arm/mach-bcm/brcmstb.c
+++ b/arch/arm/mach-bcm/brcmstb.c
@@ -14,7 +14,6 @@
#include <linux/init.h>
#include <linux/irqchip.h>
#include <linux/of_platform.h>
-#include <linux/soc/brcmstb/brcmstb.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -38,7 +37,6 @@ u32 brcmstb_uart_config[3] = {
static void __init brcmstb_init_irq(void)
{
irqchip_init();
- brcmstb_biuctrl_init();
}
static const char *const brcmstb_match[] __initconst = {
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c b/drivers/soc/bcm/brcmstb/biuctrl.c
index dd45bbfe64dd..2b23ae7b5e9b 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -240,7 +240,7 @@ static struct syscore_ops brcmstb_cpu_credit_syscore_ops = {
#endif
-void __init brcmstb_biuctrl_init(void)
+static int __init brcmstb_biuctrl_init(void)
{
int ret;
@@ -249,11 +249,13 @@ void __init brcmstb_biuctrl_init(void)
ret = mcp_write_pairing_set();
if (ret) {
pr_err("MCP: Unable to disable write pairing!\n");
- return;
+ return ret;
}
mcp_b53_set();
#ifdef CONFIG_PM_SLEEP
register_syscore_ops(&brcmstb_cpu_credit_syscore_ops);
#endif
+ return 0;
}
+early_initcall(brcmstb_biuctrl_init);
diff --git a/include/linux/soc/brcmstb/brcmstb.h b/include/linux/soc/brcmstb/brcmstb.h
index 12e548938bbb..8e884e0dda0a 100644
--- a/include/linux/soc/brcmstb/brcmstb.h
+++ b/include/linux/soc/brcmstb/brcmstb.h
@@ -13,12 +13,6 @@ static inline u32 BRCM_REV(u32 reg)
}
/*
- * Bus Interface Unit control register setup, must happen early during boot,
- * before SMP is brought up, called by machine entry point.
- */
-void brcmstb_biuctrl_init(void);
-
-/*
* Helper functions for getting family or product id from the
* SoC driver.
*/
--
2.9.3
^ permalink raw reply related
* [-next PATCH 0/4] sysfs and DEVICE_ATTR_<foo>
From: Corey Minyard @ 2017-12-19 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513706701.git.joe@perches.com>
On 12/19/2017 12:15 PM, Joe Perches wrote:
> drivers/char/ipmi/ipmi_msghandler.c | 17 +++---
For ipmi:
Acked-by: Corey Minyard <cminyard@mvista.com>
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219023935.GA17456@codeaurora.org>
On 12/18/2017 08:39 PM, Stephen Boyd wrote:
> + for (i = 0, j = 0; i < num_gpios; i++) {
> pins[i].number = i;
> - pins[i].name = names[i];
> + groups[i].pins = &pins[i].number;
> +
> + /* Only expose GPIOs that are available */
> + if (gpios && gpios[j] != i)
> + continue;
I don't know if I would say this is an improvement. For one thing,
QCOM8001 systems are deprecated and don't really exist any more. At the
time I originally wrote this patch, they were still in the wild, but
they're all gone now. So it's no longer efficient to treat QCOM8001 as
the default case. This means that the for-loop will iterate over the
full range now, instead of the partial range that it does with my v10 patch.
If I post another version of this patch, I'm just going to remove
support for QCOM8001.
If you want to avoid kmalloc'ing the GPIOs array, we can put it on the
stack with a dynamic size, since it will be no more than MAX_GPIOS * 2
(i.e. 512) bytes in size.
u16 gpios[avail_gpios];
It would be a little hackish since it needs to be defined at the
beginning of a code block, so I would probably put into its own
function, but I still fail to see what's wrong with using kmalloc to
allocate that array for short-term use temporarily.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] arm64: Stop printing the virtual memory layout
From: Laura Abbott @ 2017-12-19 19:28 UTC (permalink / raw)
To: linux-arm-kernel
Printing kernel addresses should be done in limited circumstances, mostly
for debugging purposes. Printing out the virtual memory layout at every
kernel bootup doesn't really fall into this category so delete the prints.
There are other ways to get the same information.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
Follow up to my previous proposal to switch all these to %px
---
arch/arm64/mm/init.c | 43 -------------------------------------------
1 file changed, 43 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5960bef0170d..672094ed7e07 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -599,49 +599,6 @@ void __init mem_init(void)
mem_init_print_info(NULL);
-#define MLK(b, t) b, t, ((t) - (b)) >> 10
-#define MLM(b, t) b, t, ((t) - (b)) >> 20
-#define MLG(b, t) b, t, ((t) - (b)) >> 30
-#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
-
- pr_notice("Virtual kernel memory layout:\n");
-#ifdef CONFIG_KASAN
- pr_notice(" kasan : 0x%16lx - 0x%16lx (%6ld GB)\n",
- MLG(KASAN_SHADOW_START, KASAN_SHADOW_END));
-#endif
- pr_notice(" modules : 0x%16lx - 0x%16lx (%6ld MB)\n",
- MLM(MODULES_VADDR, MODULES_END));
- pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
- MLG(VMALLOC_START, VMALLOC_END));
- pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(_text, _etext));
- pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(__start_rodata, __init_begin));
- pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(__init_begin, __init_end));
- pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(_sdata, _edata));
- pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
- MLK_ROUNDUP(__bss_start, __bss_stop));
- pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
- MLK(FIXADDR_START, FIXADDR_TOP));
- pr_notice(" PCI I/O : 0x%16lx - 0x%16lx (%6ld MB)\n",
- MLM(PCI_IO_START, PCI_IO_END));
-#ifdef CONFIG_SPARSEMEM_VMEMMAP
- pr_notice(" vmemmap : 0x%16lx - 0x%16lx (%6ld GB maximum)\n",
- MLG(VMEMMAP_START, VMEMMAP_START + VMEMMAP_SIZE));
- pr_notice(" 0x%16lx - 0x%16lx (%6ld MB actual)\n",
- MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
- (unsigned long)virt_to_page(high_memory)));
-#endif
- pr_notice(" memory : 0x%16lx - 0x%16lx (%6ld MB)\n",
- MLM(__phys_to_virt(memblock_start_of_DRAM()),
- (unsigned long)high_memory));
-
-#undef MLK
-#undef MLM
-#undef MLK_ROUNDUP
-
/*
* Check boundaries twice: Some fundamental inconsistencies can be
* detected at build time already.
--
2.14.3
^ permalink raw reply related
* [PATCH 1/2] usb: musb: un-break davinci glue layer
From: Bin Liu @ 2017-12-19 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CF323D845261FD4F9B1E997381250334E344CBEB@maildb.hanover.local>
On Tue, Dec 19, 2017 at 05:33:14PM +0000, Alejandro Mery wrote:
> Hi Bin,
>
> On 19/12/17 17:22, Bin Liu wrote:
> > Hi Alejandro,
> >
> > On Fri, Dec 08, 2017 at 07:23:54PM +0000, Alejandro Mery wrote:
> >> MUSB's davinci glue was made to depend on BROKEN by Felipe Balbi back in
> >> 2013 because of lack of active development. needed changes were actually trivial
> >>
> >> Fixes: 787f5627bec8 (usb: musb: make davinci and da8xx glues depend on BROKEN)
> >> Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
> > Thanks for the effort to re-enable this driver. But due to lack of
> > development, other than the phy and fifo mode which you try to fix with
> > these two patches, the driver still doesn't fit in the current driver
> > framework, for example,
> >
> > - the driver depends on mach/ header for CPU and board type;
> > - clk control is not separated;
> > - gpio control vbus should use extcon driver;
> I'll try to fix these issues but it will take a while. I'm still
> struggling to get USB working at all on the DM365 EVM
Thanks for the effort.
>
> >
> > So I feel it is not ready to un-broken it yet, unless others have
> > different opinion.
> >
> > But I could take these two patches if not remove BROKEN from Kconfig.
>
> do you want a v2 for that?
That will be great!
Thanks,
-Bin.
^ permalink raw reply
* [PATCH] clk: sunxi: sun9i-mmc: Implement reset callback for reset controls
From: Michael Turquette @ 2017-12-19 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219083228.mima36idnmhmogdy@flea.lan>
Quoting Maxime Ripard (2017-12-19 00:32:28)
> On Mon, Dec 18, 2017 at 01:07:09PM -0800, Stephen Boyd wrote:
> > On 12/18, Chen-Yu Tsai wrote:
> > > Our MMC host driver now issues a reset, instead of just deasserting
> > > the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the
> > > device at probe time"). The sun9i-mmc clock driver does not support
> > > this, and will fail, which results in MMC not probing.
> > >
> > > This patch implements the reset callback by asserting the reset control,
> > > then deasserting it after a small delay.
> > >
> > > Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets")
> > > Cc: <stable@vger.kernel.org> # 4.14.x
> > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > > ---
> >
> > Did you want us to pick this up into clk-fixes? It seems to be
> > causing MMC to not work for some time? That sounds annoying
> > enough.
>
> That would be great, thanks!
Applied to clk-fixes.
Regards,
Mike
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Stephen Boyd @ 2017-12-19 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11a4d79d-73a5-5e98-c83f-f5e47bcfcdf2@samsung.com>
On 12/11, Marek Szyprowski wrote:
> Hi Stephen,
>
> On 2017-12-08 17:59, Stephen Boyd wrote:
> >On 12/08, Marek Szyprowski wrote:
> >>On 2017-12-08 13:33, Krzysztof Kozlowski wrote:
> >>>On Fri, Dec 8, 2017 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote:
> >>>>On Fri, Dec 08, 2017 at 12:20:07PM +0000, Mark Brown wrote:
> >>>>>On Thu, Dec 07, 2017 at 03:54:47PM -0800, kernelci.org bot wrote:
> >>>>>
> >>>>>Today's -next failed to boot on peach-pi:
> >>>>>
> >>>>>> exynos_defconfig:
> >>>>>> exynos5800-peach-pi:
> >>>>>> lab-collabora: new failure (last pass: next-20171205)
> >>>>>with details at https://kernelci.org/boot/id/5a2a2e7859b5141bc2afa17c/
> >>>>>(including logs and comparisons with other boots, the last good boot was
> >>>>>Wednesday). It looks like it hangs somewhere late on in boot, the last
> >>>>>output on the console is:
> >>>>>
> >>>>>[ 4.827139] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.3.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:03:c0
> >>>>>[ 5.781037] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
> >>>>>[ 5.786247] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
> >>>>>[ 5.819200] dma-pl330 3880000.adma: PM domain MAU will not be powered off
> >>>>>[ 64.529228] random: crng init done
> >>>>>
> >>>>>and there's failures earlier to instantiate the display.
> >>>>I just noticed that further up the log there's a lockdep splat with a
> >>>>conflict between the genpd and clock API locking - an ABBA issue with
> >>>>genpd->mlock and the clock API prepare_lock.
> >>>+Cc Marek Szyprowski,
> >>>
> >>>The lockdep issue and display failures (including regulator warning)
> >>>were present for some time. They also appear in boot log for
> >>>next-20171206 (https://storage.kernelci.org/next/master/next-20171206/arm/exynos_defconfig/lab-collabora/boot-exynos5800-peach-pi.html).
> >>>The difference is that 20171208 hangs on "random: crng init done"
> >>>which did not appear before at all.
> >I haven't looked at the lockdep splat yet, but is that happening
> >because of runtime PM usage by the clk framework?
>
> This is a false positive. The deplock doesn't distinguish each
> domain instance.
> Only some instances of exynos power domains use clocks (as an old
> workaround of
> the lack possibility to integrate proper clock rate/topology
> restoration after
> power off/on cycle in the clock provider driver).
>
> Those clock controllers, which implements runtime pm, are assigned to power
> domain, which doesn't touch clocks at all.
>
> I still have no idea how to fix the code to make deplock happy.
>
Right. Once lockdep complains lockdep turns itself off, so we
lose the ability to detect other problems. Even if it's a false
positive, it's a potential problem on some device so it's
concerning that runtime PM usage from clk framework has created
this potential problem.
Is it possible to remove the clk operations from the exynos power
domains? You say it's to deal with the lack of rate/topology
restoration so maybe it can be changed. That will at least allow
lockdep to continue working here and detect the "real" deadlock
here. Otherwise, do we need to revert runtime PM for clk
framework and back out all the Samsung changes on top of that? If
we need to do that, we need to do it soon.
We'll need to think about how to resolve the cross-subsystem
locking problem regardless. We definitely want to have genpd be
able to do CCF things, and CCF to use runtime PM and genpds too.
It seems that we have a classic AB-BA deadlock potential between
the clk prepare lock and the genpd domain mutex. Both frameworks
are holding a mutex across the operations of their providers
(either clk_ops or genpd power_on/off) so we can't have the CCF
call genpd things and genpd call CCF things or lockdep will
complain. I was worried about runtime PM usage by CCF causing
this problem, but I missed that genpd was behind runtime PM so I
didn't consider the locks in that part of the chain. Ugh.
Maybe we can have runtime PM things done outside of the prepare
lock in CCF, that way we aren't holding any locks that genpd may
need to use. That would fix the problem, but would expose us to
clk tree topology changes happening while we enable runtime PM
for clks. It would be great if we could drop all framework level
locks when we call into provider drivers. I'm not sure how to do
that yet, but that's probably the end goal.
Anyway, this needs some thought to figure out how to redesign the
CCF locking scheme so this problem doesn't exist.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add sid for a83t
From: kevans91 at ksu.edu @ 2017-12-19 20:11 UTC (permalink / raw)
To: linux-arm-kernel
From: Kyle Evans <kevans91@ksu.edu>
Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
thermal calibration data, add node to describe it.
a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
supported in an external driver for FreeBSD.
Signed-off-by: Kyle Evans <kevans91@ksu.edu>
---
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt | 1 +
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
index d69543701..e319fe5e2 100644
--- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Should be one of the following:
"allwinner,sun4i-a10-sid"
"allwinner,sun7i-a20-sid"
+ "allwinner,sun8i-a83t-sid"
"allwinner,sun8i-h3-sid"
"allwinner,sun50i-a64-sid"
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a..cced6e5fb 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -238,6 +238,11 @@
#size-cells = <0>;
};
+ sid: eeprom at 1c14000 {
+ compatible = "allwinner,sun8i-a83t-sid";
+ reg = <0x1c14000 0x400>;
+ };
+
usb_otg: usb at 1c19000 {
compatible = "allwinner,sun8i-a83t-musb",
"allwinner,sun8i-a33-musb";
--
2.15.1
^ permalink raw reply related
* [PATCH net 0/3] Few mvneta fixes
From: Arnd Bergmann @ 2017-12-19 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219165947.28516-1-gregory.clement@free-electrons.com>
On Tue, Dec 19, 2017 at 5:59 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hello,
>
> here it is a small series of fixes found on the mvneta driver. They
> had been already used in the vendor kernel and are now ported to
> mainline.
Does one of the patches look like it addresses the rare Oops we discussed on
#kernelci this morning?
https://storage.kernelci.org/stable/linux-4.9.y/v4.9.70/arm/mvebu_v7_defconfig/lab-free-electrons/boot-armada-375-db.html
Arnd
^ permalink raw reply
* [PATCH v8 9/9] KVM: arm/arm64: Update timer and forwarded irq documentation
From: Christoffer Dall @ 2017-12-19 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86efnywfjl.wl-marc.zyngier@arm.com>
On Wed, Dec 13, 2017 at 08:15:10PM +0000, Marc Zyngier wrote:
> On Wed, 13 Dec 2017 10:46:02 +0000,
> Christoffer Dall wrote:
> >
> > Now when we've reworked how mapped level-triggered interrupts are
> > processed for the timer interrupts, we update the documentation
> > correspondingly.
>
> Seems like the documentation is more out of date than we thought, see
> below.
>
Indeed. And I wondered if we should just nuke this file. The reason I
added it originally was that the concept of "never taking the interrupt"
was confusing to most, and we had to explain it several times over, but
perhaps it's really not needed anymore and we should let people read the
code instead?
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt | 50 ++++++++++------------
> > 1 file changed, 23 insertions(+), 27 deletions(-)
> >
> > diff --git a/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt b/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt
> > index 38bca2835278..f68c7d95a341 100644
> > --- a/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt
> > +++ b/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt
> > @@ -7,9 +7,10 @@ allowing software to inject virtual interrupts to a VM, which the guest
> > OS sees as regular interrupts. The code is famously known as the VGIC.
> >
> > Some of these virtual interrupts, however, correspond to physical
> > -interrupts from real physical devices. One example could be the
> > -architected timer, which itself supports virtualization, and therefore
> > -lets a guest OS program the hardware device directly to raise an
> > +interrupts from real physical devices. One example could be the ARM
> > +Generic Timers (also known as the "architected timers"), which are
> > +directly assigned to a VM while it's running, and therefore
> > +makes it possible for guest OSes to program the timers directly to raise an
> > interrupt at some point in time. When such an interrupt is raised, the
> > host OS initially handles the interrupt and must somehow signal this
> > event as a virtual interrupt to the guest. Another example could be a
> > @@ -37,7 +38,7 @@ inactive.
> >
> > The LRs include an extra bit, called the HW bit. When this bit is set,
> > KVM must also program an additional field in the LR, the physical IRQ
> > -number, to link the virtual with the physical IRQ.
> > +number, to link the virtual and physical IRQs together.
> >
> > When the HW bit is set, KVM must EITHER set the Pending OR the Active
> > bit, never both at the same time.
> > @@ -59,21 +60,21 @@ The state of forwarded physical interrupts is managed in the following way:
> > - LR.Pending will stay set as long as the guest has not acked the interrupt.
> > - LR.Pending transitions to LR.Active on the guest read of the IAR, as
> > expected.
> > - - On guest EOI, the *physical distributor* active bit gets cleared,
> > + - On guest deactivate, the *physical distributor* active bit gets cleared,
> > but the LR.Active is left untouched (set).
>
> Is this true? I seem to remember that we established it wasn't (back
> when we redesigned the vgic). Certainly, the current code relies on
> the Active bit being cleared in the LR as well as in the physical
> distributor.
>
No, you're right, it' crap.
> > - KVM clears the LR on VM exits when the physical distributor
> > active state has been cleared.
>
> And this isn't either, if my above assertion stands.
>
Right again.
> >
> > (*): The host handling is slightly more complicated. For some forwarded
> > -interrupts (shared), KVM directly sets the active state on the physical
> > -distributor before entering the guest, because the interrupt is never actually
> > -handled on the host (see details on the timer as an example below). For other
> > -forwarded interrupts (non-shared) the host does not deactivate the interrupt
> > -when the host ISR completes, but leaves the interrupt active until the guest
> > -deactivates it. Leaving the interrupt active is allowed, because Linux
> > -configures the physical GIC with EOIMode=1, which causes EOI operations to
> > -perform a priority drop allowing the GIC to receive other interrupts of the
> > -default priority.
> > +interrupts (shared), in some cases, KVM directly sets the active state
> > +on the physical distributor before entering the guest, because the
> > +interrupt is never actually handled on the host (see details on the
> > +timer as an example below). In other cases, the host does not
>
> This isn't true either. We now handle the timer interrupt on the host.
>
And again. I've rewritten this.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Stephen Boyd @ 2017-12-19 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f6b198f-d277-51dd-09ad-e1d751d5c1fa@codeaurora.org>
On 12/19, Timur Tabi wrote:
> On 12/18/2017 08:39 PM, Stephen Boyd wrote:
> >+ for (i = 0, j = 0; i < num_gpios; i++) {
> > pins[i].number = i;
> >- pins[i].name = names[i];
> >+ groups[i].pins = &pins[i].number;
> >+
> >+ /* Only expose GPIOs that are available */
> >+ if (gpios && gpios[j] != i)
> >+ continue;
>
> I don't know if I would say this is an improvement. For one thing,
> QCOM8001 systems are deprecated and don't really exist any more. At
> the time I originally wrote this patch, they were still in the wild,
> but they're all gone now. So it's no longer efficient to treat
> QCOM8001 as the default case. This means that the for-loop will
> iterate over the full range now, instead of the partial range that
> it does with my v10 patch.
>
> If I post another version of this patch, I'm just going to remove
> support for QCOM8001.
That sounds good too. The diff was really noisy because all the
foo[i] became foo[gpio] which causes the diff to increase for no
real purpose. My patch was rewriting that stuff so it doesn't
come into the diff and we can concentrate on what's actually
changing. We already iterate over the full range to fill in the
two fields anyway, so I'm not sure what you're getting at with
your for-loop comment. Seems like a micro-optimization on probe
that probably isn't going to be noticed.
>
> If you want to avoid kmalloc'ing the GPIOs array, we can put it on
> the stack with a dynamic size, since it will be no more than
> MAX_GPIOS * 2 (i.e. 512) bytes in size.
>
> u16 gpios[avail_gpios];
>
> It would be a little hackish since it needs to be defined at the
> beginning of a code block, so I would probably put into its own
> function, but I still fail to see what's wrong with using kmalloc to
> allocate that array for short-term use temporarily.
>
Yeah I wouldn't do that. I'm not trying to avoid allocating the
array anymore. Dynamically sized arrays on the stack are not a
great idea in the kernel where we have limited stack sizes.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-19 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219203055.GF7997@codeaurora.org>
On 12/19/2017 02:30 PM, Stephen Boyd wrote:
> Yeah I wouldn't do that. I'm not trying to avoid allocating the
> array anymore. Dynamically sized arrays on the stack are not a
> great idea in the kernel where we have limited stack sizes.
So do you just want to see a v11 that drops support for QCOM8001?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v8 9/9] KVM: arm/arm64: Update timer and forwarded irq documentation
From: Marc Zyngier @ 2017-12-19 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219202954.GC5380@cbox>
On Tue, 19 Dec 2017 21:29:54 +0100
Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Wed, Dec 13, 2017 at 08:15:10PM +0000, Marc Zyngier wrote:
> > On Wed, 13 Dec 2017 10:46:02 +0000,
> > Christoffer Dall wrote:
> > >
> > > Now when we've reworked how mapped level-triggered interrupts are
> > > processed for the timer interrupts, we update the documentation
> > > correspondingly.
> >
> > Seems like the documentation is more out of date than we thought, see
> > below.
> >
>
> Indeed. And I wondered if we should just nuke this file. The reason I
> added it originally was that the concept of "never taking the interrupt"
> was confusing to most, and we had to explain it several times over, but
> perhaps it's really not needed anymore and we should let people read the
> code instead?
Suits me (maintaining documentation is hard). I suggest we delete it
and write the perfect explanation once KVM is completely done...
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH v8 3/9] KVM: arm/arm64: Don't cache the timer IRQ level
From: Christoffer Dall @ 2017-12-19 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <517ead96-a689-d6f6-564f-67b1cd020daf@arm.com>
On Tue, Dec 19, 2017 at 02:17:38PM +0000, Julien Thierry wrote:
> Hi Christoffer,
>
> A few nits in the commit message.
>
> On 13/12/17 10:45, Christoffer Dall wrote:
> >The timer was modeled after a strict idea of modelling an interrupt line
>
> nit: modelling (also, modeled after a strict idea of modelling?)
>
Yes, I model the modelling of models of modeled timers. Is that not
clear? ;)
> >level in software, meaning that only transitions in the level needed to
>
> s/needed/need/ ?
>
ack
> >be reported to the VGIC. This works well for the timer, because the
> >arch timer code is in complete control of the device and can track the
> >transitions of the line.
> >
> >However, as we are about to support using the HW bit in the VGIC not
> >just for the timer, but also for VFIO which cannot track transitions of
> >the interrupt line, we have to decide on an interface for level
> >triggered mapped interrupts to the GIC, which both the timer and VFIO
>
> "level triggered interrupts mapped to the GIC" ?
>
an interface to the GIC for level ...
My writing here is really crap. Thanks for pointing that out.
> >can use.
> >
> >VFIO only sees an asserting transition of the physical interrupt line,
> >and tells the VGIC when that happens. That means that part of the
> >interrupt flow is offloaded to the hardware.
> >
> >To use the same interface for VFIO devices and the timer, we therefore
> >have to change the timer (we cannot change VFIO because it doesn't know
> >the details of the device it is assigning to a VM).
> >
> >Luckily, changing the timer is simple, we just need to stop 'caching'
> >the line level, but instead let the VGIC know the state of the timer
> >every time there is a potential change in the line level, and when the
> >line level should be asserted from the timer ISR. The VGIC can ignore
> >extra notifications using its validate mechanism.
> >
> >Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> >Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
>
Thanks,
-Christoffer
^ 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