* [PATCH 1/2] phy: qcom-usb-hs: Replace the extcon API
From: Chanwoo Choi @ 2017-04-13 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1490675909-2533-1-git-send-email-cw00.choi@samsung.com>
Hi Kishon,
Could you please review these patches?
On 2017? 03? 28? 13:38, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - (deprecated) extcon_get_cable_state_() -> extcon_get_state()
>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> drivers/phy/phy-qcom-usb-hs.c | 14 +++-----------
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
> index 94dfbfd739c3..f630fa553b7d 100644
> --- a/drivers/phy/phy-qcom-usb-hs.c
> +++ b/drivers/phy/phy-qcom-usb-hs.c
> @@ -156,12 +156,12 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
> }
>
> if (uphy->vbus_edev) {
> - state = extcon_get_cable_state_(uphy->vbus_edev, EXTCON_USB);
> + state = extcon_get_state(uphy->vbus_edev, EXTCON_USB);
> /* setup initial state */
> qcom_usb_hs_phy_vbus_notifier(&uphy->vbus_notify, state,
> uphy->vbus_edev);
> - ret = extcon_register_notifier(uphy->vbus_edev, EXTCON_USB,
> - &uphy->vbus_notify);
> + ret = devm_extcon_register_notifier(&ulpi->dev, uphy->vbus_edev,
> + EXTCON_USB, &uphy->vbus_notify);
> if (ret)
> goto err_ulpi;
> }
> @@ -180,16 +180,8 @@ static int qcom_usb_hs_phy_power_on(struct phy *phy)
>
> static int qcom_usb_hs_phy_power_off(struct phy *phy)
> {
> - int ret;
> struct qcom_usb_hs_phy *uphy = phy_get_drvdata(phy);
>
> - if (uphy->vbus_edev) {
> - ret = extcon_unregister_notifier(uphy->vbus_edev, EXTCON_USB,
> - &uphy->vbus_notify);
> - if (ret)
> - return ret;
> - }
> -
> regulator_disable(uphy->v3p3);
> regulator_disable(uphy->v1p8);
> clk_disable_unprepare(uphy->sleep_clk);
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH 0/3] clk: sunxi-ng: gate/ungate PLL CPU clk after rate change
From: Chen-Yu Tsai @ 2017-04-13 2:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This series adds a clk notifier for use on the PLL CPU clks found in
Allwinner SoCs. Some people have observed issues with the design and
implementation of the CPU PLL clock, starting from the A31. Changes
to the PLL clock need a few cycles to stabilize. If the changes are
too drastic, the dividers in particular, there is a good chance that
the system will hang.
Previously we thought that reparenting the CPU clock away from the PLL
while changes were made, and then reparenting it back once it was stable,
should have been enough to mitigate the issue. Unfortunately it was
not. With cpufreq support for A33 recently introduced in commit
03749eb88e63 ("ARM: dts: sun8i: add opp-v2 table for A33"), system hangs
were observed one out of two to three boots, right after userspace
configured cpufreq to switch to the ondemand governor. Other experiments
done by Ondrej Jirman [1] show that it is not enough to just reparent
the CPU clock, but the PLL clock's dividers must not be used.
We suspect the divider changes make the PLL unstable to the point that
it can not recover, possibly not providing any output afterwards. We
lack any hard evidence (oscilloscope readings or hardware implementation
details) to fully explain the behavior. However, if the hardware is
stuck in some undesired state, it is possible to "reset" it, by gating
the PLL, then ungating it.
This series adds a new clk notifier that does exactly that. The clk
notifier is registered on the PLL clock. Whenever its rate is changed,
the notifier comes in and toggles the gate. The notifier should always
be the first one registered. And all consumers of the clock must also
have notifiers on it to temporarily reparent away during the change.
Patches 2 and 3 register this new notifier for the CPU PLL clocks on
the A33 and H3, respectively. With the first 2 patches applied, the
cpufreq related system hangs on the A33 go away.
Given that commit 03749eb88e63 ("ARM: dts: sun8i: add opp-v2 table for
A33") is already in v4.11-rc, I suggest we either try to merge the
first 2 patches for a very late -rc fix, or drop A33 cpufreq support
from v4.11, and add it later once this series is merged.
Regards
ChenYu
[1] http://www.spinics.net/lists/arm-kernel/msg552501.html
Chen-Yu Tsai (3):
clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks
clk: sunxi-ng: a33: gate then ungate PLL CPU clk after rate change
clk: sunxi-ng: h3: gate then ungate PLL CPU clk after rate change
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 11 ++++++++
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 11 ++++++++
drivers/clk/sunxi-ng/ccu_common.c | 49 ++++++++++++++++++++++++++++++++++++
drivers/clk/sunxi-ng/ccu_common.h | 12 +++++++++
4 files changed, 83 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH 1/3] clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks
From: Chen-Yu Tsai @ 2017-04-13 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413021354.3258-1-wens@csie.org>
In common PLL designs, changes to the dividers take effect almost
immediately, while changes to the multipliers (implemented as
dividers in the feedback loop) take a few cycles to work into
the feedback loop for the PLL to stablize.
Sometimes when the PLL clock rate is changed, the decrease in the
divider is too much for the decrease in the multiplier to catch up.
The PLL clock rate will spike, and in some cases, might lock up
completely. This is especially the case if the divider changed is
the pre-divider, which affects the reference frequency.
This patch introduces a clk notifier callback that will gate and
then ungate a clk after a rate change, effectively resetting it,
so it continues to work, despite any possible lockups. Care must
be taken to reparent any consumers to other temporary clocks during
the rate change, and that this notifier callback must be the first
to be registered.
This is intended to fix occasional lockups with cpufreq on newer
Allwinner SoCs, such as the A33 and the H3. Previously it was
thought that reparenting the cpu clock away from the PLL while
it stabilized was enough, as this worked quite well on the A31.
On the A33, hangs have been observed after cpufreq was recently
introduced. With the H3, a more thorough test [1] showed that
reparenting alone isn't enough. The system still locks up unless
the dividers are limited to 1.
A hunch was if the PLL was stuck in some unknown state, perhaps
gating then ungating it would bring it back to normal. Tests
done by Icenowy Zheng using Ondrej's test firmware shows this
to be a valid solution.
[1] http://www.spinics.net/lists/arm-kernel/msg552501.html
Reported-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Icenowy Zheng <icenowy@aosc.io>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/clk/sunxi-ng/ccu_common.c | 49 +++++++++++++++++++++++++++++++++++++++
drivers/clk/sunxi-ng/ccu_common.h | 12 ++++++++++
2 files changed, 61 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_common.c b/drivers/clk/sunxi-ng/ccu_common.c
index 188fa50d0380..40aac316128f 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -14,11 +14,13 @@
* GNU General Public License for more details.
*/
+#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/iopoll.h>
#include <linux/slab.h>
#include "ccu_common.h"
+#include "ccu_gate.h"
#include "ccu_reset.h"
static DEFINE_SPINLOCK(ccu_lock);
@@ -39,6 +41,53 @@ void ccu_helper_wait_for_lock(struct ccu_common *common, u32 lock)
WARN_ON(readl_relaxed_poll_timeout(addr, reg, reg & lock, 100, 70000));
}
+/*
+ * This clock notifier is called when the frequency of a PLL clock is
+ * changed. In common PLL designs, changes to the dividers take effect
+ * almost immediately, while changes to the multipliers (implemented
+ * as dividers in the feedback loop) take a few cycles to work into
+ * the feedback loop for the PLL to stablize.
+ *
+ * Sometimes when the PLL clock rate is changed, the decrease in the
+ * divider is too much for the decrease in the multiplier to catch up.
+ * The PLL clock rate will spike, and in some cases, might lock up
+ * completely.
+ *
+ * This notifier callback will gate and then ungate the clock,
+ * effectively resetting it, so it proceeds to work. Care must be
+ * taken to reparent consumers to other temporary clocks during the
+ * rate change, and that this notifier callback must be the first
+ * to be registered.
+ */
+static int ccu_pll_notifier_cb(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct ccu_pll_nb *pll = to_ccu_pll_nb(nb);
+ int ret = 0;
+
+ if (event != POST_RATE_CHANGE)
+ goto out;
+
+ ccu_gate_helper_disable(pll->common, pll->enable);
+
+ ret = ccu_gate_helper_enable(pll->common, pll->enable);
+ if (ret)
+ goto out;
+
+ ccu_helper_wait_for_lock(pll->common, pll->lock);
+
+out:
+ return notifier_from_errno(ret);
+}
+
+int ccu_pll_notifier_register(struct ccu_pll_nb *pll_nb)
+{
+ pll_nb->clk_nb.notifier_call = ccu_pll_notifier_cb;
+
+ return clk_notifier_register(pll_nb->common->hw.clk,
+ &pll_nb->clk_nb);
+}
+
int sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
const struct sunxi_ccu_desc *desc)
{
diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
index 73d81dc58fc5..d6fdd7a789aa 100644
--- a/drivers/clk/sunxi-ng/ccu_common.h
+++ b/drivers/clk/sunxi-ng/ccu_common.h
@@ -83,6 +83,18 @@ struct sunxi_ccu_desc {
void ccu_helper_wait_for_lock(struct ccu_common *common, u32 lock);
+struct ccu_pll_nb {
+ struct notifier_block clk_nb;
+ struct ccu_common *common;
+
+ u32 enable;
+ u32 lock;
+};
+
+#define to_ccu_pll_nb(_nb) container_of(_nb, struct ccu_pll_nb, clk_nb)
+
+int ccu_pll_notifier_register(struct ccu_pll_nb *pll_nb);
+
int sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
const struct sunxi_ccu_desc *desc);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] clk: sunxi-ng: a33: gate then ungate PLL CPU clk after rate change
From: Chen-Yu Tsai @ 2017-04-13 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413021354.3258-1-wens@csie.org>
This patch utilizes the new PLL clk notifier to gate then ungate the
PLL CPU clock after rate changes. This should mitigate the system
hangs observed after the introduction of cpufreq for the A33.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 56370c2c7f98..8d38e6510e29 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -756,6 +756,13 @@ static const struct sunxi_ccu_desc sun8i_a33_ccu_desc = {
.num_resets = ARRAY_SIZE(sun8i_a33_ccu_resets),
};
+static struct ccu_pll_nb sun8i_a33_pll_cpu_nb = {
+ .common = &pll_cpux_clk.common,
+ /* copy from pll_cpux_clk */
+ .enable = BIT(31),
+ .lock = BIT(28),
+};
+
static struct ccu_mux_nb sun8i_a33_cpu_nb = {
.common = &cpux_clk.common,
.cm = &cpux_clk.mux,
@@ -787,6 +794,10 @@ static void __init sun8i_a33_ccu_setup(struct device_node *node)
sunxi_ccu_probe(node, reg, &sun8i_a33_ccu_desc);
+ /* Gate then ungate PLL CPU after any rate changes */
+ ccu_pll_notifier_register(&sun8i_a33_pll_cpu_nb);
+
+ /* Reparent CPU during PLL CPU rate changes */
ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
&sun8i_a33_cpu_nb);
}
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] clk: sunxi-ng: h3: gate then ungate PLL CPU clk after rate change
From: Chen-Yu Tsai @ 2017-04-13 2:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413021354.3258-1-wens@csie.org>
This patch utilizes the new PLL clk notifier to gate then ungate the
PLL CPU clock after rate changes. This should prevent any system hangs
resulting from cpufreq changes to the clk.
Reported-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Icenowy Zheng <icenowy@aosc.io>
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 4cbc1b701b7c..fc04ef2af1ac 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -1103,6 +1103,13 @@ static const struct sunxi_ccu_desc sun50i_h5_ccu_desc = {
.num_resets = ARRAY_SIZE(sun50i_h5_ccu_resets),
};
+static struct ccu_pll_nb sun8i_h3_pll_cpu_nb = {
+ .common = &pll_cpux_clk.common,
+ /* copy from pll_cpux_clk */
+ .enable = BIT(31),
+ .lock = BIT(28),
+};
+
static struct ccu_mux_nb sun8i_h3_cpu_nb = {
.common = &cpux_clk.common,
.cm = &cpux_clk.mux,
@@ -1130,6 +1137,10 @@ static void __init sunxi_h3_h5_ccu_init(struct device_node *node,
sunxi_ccu_probe(node, reg, desc);
+ /* Gate then ungate PLL CPU after any rate changes */
+ ccu_pll_notifier_register(&sun8i_h3_pll_cpu_nb);
+
+ /* Reparent CPU during PLL CPU rate changes */
ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
&sun8i_h3_cpu_nb);
}
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] Add fault_major, fault_minor page fault trace events
From: Chris Redmon @ 2017-04-13 2:20 UTC (permalink / raw)
To: linux-arm-kernel
These changes add common trace events for major and minor page faults,
as well as adding these traces to the arm and arm64 architectures. These
traces offer useful information for determining the source of page faults
in realtime systems, as well as the time penalty for taking a major or
minor page fault.
I made an attempt to minimize the overhead when these tracepoints are not
enabled, but I'm willing to make more changes if desired.
Chris Redmon (3):
tracing: Introduce traces for major and minor page faults
arm: Utilize trace events for major and minor page faults
arm64: Utilize trace events for major and minor page faults
arch/arm/mm/fault.c | 14 +++++++
arch/arm64/mm/fault.c | 14 +++++++
include/trace/events/fault.h | 87 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 115 insertions(+)
create mode 100644 include/trace/events/fault.h
--
2.12.2.599.gcf11a67
^ permalink raw reply
* [PATCH 1/3] tracing: Introduce traces for major and minor page faults
From: Chris Redmon @ 2017-04-13 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413022040.10156-1-credmonster@gmail.com>
Tracing for major page faults is helpful especially for diagnosing
realtime latency issues (such as failure to mlock() something on a
realtime code path)
Signed-off-by: Chris Redmon <credmonster@gmail.com>
---
include/trace/events/fault.h | 87 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 87 insertions(+)
create mode 100644 include/trace/events/fault.h
diff --git a/include/trace/events/fault.h b/include/trace/events/fault.h
new file mode 100644
index 000000000000..c4803f859750
--- /dev/null
+++ b/include/trace/events/fault.h
@@ -0,0 +1,87 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM fault
+
+#if !defined(_TRACE_FAULT_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_FAULT_H
+
+#include <asm/ptrace.h>
+#include <linux/tracepoint.h>
+#include <linux/types.h>
+
+/*
+ * Event class for major/minor page faults:
+ */
+DECLARE_EVENT_CLASS(fault_major_minor_class,
+
+ TP_PROTO(
+ unsigned long address, struct pt_regs *regs,
+ unsigned long status, ktime_t start_time,
+ unsigned int flags, unsigned int fault),
+
+ TP_ARGS(address, regs, status, start_time, flags, fault),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, address)
+ __field(unsigned long, instruction_pointer)
+ __field(unsigned long, status)
+ __field(unsigned int, duration)
+ __field(unsigned int, flags)
+ __field(unsigned int, fault)
+ ),
+
+ TP_fast_assign(
+ __entry->address = address;
+ __entry->instruction_pointer = (regs ? instruction_pointer(regs) : 0);
+ __entry->status = (unsigned long) status;
+ __entry->duration = ktime_to_us(ktime_sub(ktime_get(), start_time));
+ __entry->flags = flags;
+ __entry->fault = fault;
+ ),
+
+ TP_printk("address=%pf ip=%pf status=0x%lx duration=%uus flags=%s fault=%s",
+ (void *)__entry->address, (void *)__entry->instruction_pointer,
+ __entry->status,
+ __entry->duration,
+ __print_flags(__entry->flags, "|",
+ {FAULT_FLAG_WRITE, "WRITE"},
+ {FAULT_FLAG_MKWRITE, "MKWRITE"},
+ {FAULT_FLAG_ALLOW_RETRY, "ALLOW_RETRY"},
+ {FAULT_FLAG_RETRY_NOWAIT, "RETRY_NOWAIT"},
+ {FAULT_FLAG_KILLABLE, "KILLABLE"},
+ {FAULT_FLAG_TRIED, "TRIED"},
+ {FAULT_FLAG_USER, "USER"}),
+ __print_flags(__entry->fault, "|",
+ {VM_FAULT_OOM, "OOM"},
+ {VM_FAULT_SIGBUS, "SIGBUS"},
+ {VM_FAULT_MAJOR, "MAJOR"},
+ {VM_FAULT_WRITE, "WRITE"},
+ {VM_FAULT_HWPOISON, "HWPOISON"},
+ {VM_FAULT_HWPOISON_LARGE, "HWPOISON_LARGE"},
+ {VM_FAULT_NOPAGE, "NOPAGE"},
+ {VM_FAULT_LOCKED, "LOCKED"},
+ {VM_FAULT_RETRY, "RETRY"},
+ {VM_FAULT_FALLBACK, "FALLBACK"})
+ )
+);
+
+#define DEFINE_PAGE_FAULT_MAJOR_MINOR_EVENT(name) \
+DEFINE_EVENT(fault_major_minor_class, name, \
+ TP_PROTO(unsigned long address, struct pt_regs *regs, \
+ unsigned long status, ktime_t start_time, \
+ unsigned int flags, unsigned int fault), \
+ TP_ARGS(address, regs, status, start_time, flags, fault));
+
+/*
+ * Tracepoint for major page faults:
+ */
+DEFINE_PAGE_FAULT_MAJOR_MINOR_EVENT(fault_major);
+
+/*
+ * Tracepoint for minor page faults:
+ */
+DEFINE_PAGE_FAULT_MAJOR_MINOR_EVENT(fault_minor);
+
+#endif /* _TRACE_FAULT_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.12.2.599.gcf11a67
^ permalink raw reply related
* [PATCH 2/3] arm: Utilize trace events for major and minor page faults
From: Chris Redmon @ 2017-04-13 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413022040.10156-1-credmonster@gmail.com>
Signed-off-by: Chris Redmon <credmonster@gmail.com>
---
arch/arm/mm/fault.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index ff8b0aa2dfde..e59514f85e01 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -29,6 +29,9 @@
#include "fault.h"
+#define CREATE_TRACE_POINTS
+#include <trace/events/fault.h>
+
#ifdef CONFIG_MMU
#ifdef CONFIG_KPROBES
@@ -262,6 +265,8 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
struct mm_struct *mm;
int fault, sig, code;
unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+ ktime_t start_time;
+ bool trace_fault_enabled = false;
if (notify_page_fault(regs, fsr))
return 0;
@@ -285,6 +290,11 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
if (fsr & FSR_WRITE)
flags |= FAULT_FLAG_WRITE;
+ if (trace_fault_major_enabled() || trace_fault_minor_enabled()) {
+ start_time = ktime_get();
+ trace_fault_enabled = true;
+ }
+
/*
* As per x86, we may deadlock here. However, since the kernel only
* validly references user space from well defined areas of the code,
@@ -330,10 +340,14 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
tsk->maj_flt++;
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1,
regs, addr);
+ if (trace_fault_enabled)
+ trace_fault_major(addr, regs, fsr, start_time, flags, fault);
} else {
tsk->min_flt++;
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1,
regs, addr);
+ if (trace_fault_enabled)
+ trace_fault_minor(addr, regs, fsr, start_time, flags, fault);
}
if (fault & VM_FAULT_RETRY) {
/* Clear FAULT_FLAG_ALLOW_RETRY to avoid any risk
--
2.12.2.599.gcf11a67
^ permalink raw reply related
* [PATCH 3/3] arm64: Utilize trace events for major and minor page faults
From: Chris Redmon @ 2017-04-13 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413022040.10156-1-credmonster@gmail.com>
Signed-off-by: Chris Redmon <credmonster@gmail.com>
---
arch/arm64/mm/fault.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 1b35b8bddbfb..d3097ff6fb8e 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -42,6 +42,9 @@
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/fault.h>
+
struct fault_info {
int (*fn)(unsigned long addr, unsigned int esr,
struct pt_regs *regs);
@@ -315,6 +318,8 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
int fault, sig, code;
unsigned long vm_flags = VM_READ | VM_WRITE;
unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+ ktime_t start_time;
+ bool trace_fault_enabled = false;
if (notify_page_fault(regs, esr))
return 0;
@@ -351,6 +356,11 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
die("Accessing user space memory outside uaccess.h routines", regs, esr);
}
+ if (trace_fault_major_enabled() || trace_fault_minor_enabled()) {
+ start_time = ktime_get();
+ trace_fault_enabled = true;
+ }
+
/*
* As per x86, we may deadlock here. However, since the kernel only
* validly references user space from well defined areas of the code,
@@ -395,10 +405,14 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
tsk->maj_flt++;
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, 1, regs,
addr);
+ if (trace_fault_enabled)
+ trace_fault_major(addr, regs, esr, start_time, mm_flags, fault);
} else {
tsk->min_flt++;
perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1, regs,
addr);
+ if (trace_fault_enabled)
+ trace_fault_minor(addr, regs, esr, start_time, mm_flags, fault);
}
if (fault & VM_FAULT_RETRY) {
/*
--
2.12.2.599.gcf11a67
^ permalink raw reply related
* [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash
From: Guochun Mao @ 2017-04-13 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e9eafca3-41a0-7e88-996b-9d1c51f0c132@wedev4u.fr>
Hi Cyrille,
On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote:
> Hi Guochun,
>
> Le 05/04/2017 ? 10:37, Guochun Mao a ?crit :
> > When nor's size larger than 16MByte, nor's address width maybe
> > set to 3 or 4, and controller should change address width according
> > to nor's setting.
> >
> > Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>st
> > ---
> > drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
> > index e661877..b637770 100644
> > --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > @@ -104,6 +104,8 @@
> > #define MTK_NOR_MAX_RX_TX_SHIFT 6
> > /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
> > #define MTK_NOR_MAX_SHIFT 7
> > +/* nor controller 4-byte address mode enable bit */
> > +#define MTK_NOR_4B_ADDR_EN BIT(4)
> >
> > /* Helpers for accessing the program data / shift data registers */
> > #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
> > @@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor)
> > 10000);
> > }
> >
> > +static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
> > +{
> > + u8 val;
> > + struct spi_nor *nor = &mt8173_nor->nor;
> > +
> > + val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
> > +
> > + switch (nor->addr_width) {
> > + case 3:
> > + val &= ~MTK_NOR_4B_ADDR_EN;
> > + break;
> > + case 4:
> > + val |= MTK_NOR_4B_ADDR_EN;
> > + break;
> > + default:
> > + dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
> > + nor->addr_width);
> > + break;
> > + }
> > +
> > + writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
> > +}
> > +
> > static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
> > {
> > int i;
> >
> > + mt8173_nor_set_addr_width(mt8173_nor);
> > +
> > for (i = 0; i < 3; i++) {
>
> Should it be 'i < nor->addr_width' instead of 'i < 3' ?
> Does it work when accessing data after 128Mbit ?
Yes, it can work.
Let's see the whole function,
static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
{
int i;
mt8173_nor_set_addr_width(mt8173_nor);
for (i = 0; i < 3; i++) {
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG
+ i * 4);
addr >>= 8;
}
/* Last register is non-contiguous */
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR3_REG);
}
The nor controller has 4 registers for address.
This '3' indicates the number of contiguous address' registers
base + MTK_NOR_RADR0_REG(0x10)
base + MTK_NOR_RADR1_REG(0x14)
base + MTK_NOR_RADR2_REG(0x18),
but the last address register is non-contiguous,
it's base + MTK_NOR_RADR3_REG(0xc8)
mt8173_nor_set_addr will set addr into these 4 registers by Byte.
The bit MTK_NOR_4B_ADDR_EN will decide whether 3-byte(0x10,0x14,0x18)
or 4-byte(0x10,0x14,x018,0xc8) been sent to nor device.
and, it can access data after 128Mbit when sent 4-byte address.
Best regards,
Guochun
>
> Best regards,
>
> Cyrille
>
> > writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4);
> > addr >>= 8;
> >
>
^ permalink raw reply
* [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
From: Michael Ellerman @ 2017-04-13 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491952528.7236.26.camel@kernel.crashing.org>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
>> Ok, point taken. BTW, may I ask you guys to have a look into this
>> please ?
>>
>> https://lkml.org/lkml/2017/4/6/743
>>
>> It is a side effect of this thread (v2), not sure why <asm/io.h>
>> on powerpc has to include <linux/io.h>.
>
> Not sure how we ended up with that... it's odd indeed.
>
> Michael ? Any reason we can't just remove it ?
No ... idea.
Looks like it was added in:
commit b41e5fffe8b81fc939067d8c1c195cc79115d5a3
Author: Emil Medve <Emilian.Medve@Freescale.com>
AuthorDate: Sat May 3 06:34:04 2008 +1000
Commit: Paul Mackerras <paulus@samba.org>
CommitDate: Mon May 5 16:47:14 2008 +1000
[POWERPC] devres: Add devm_ioremap_prot()
We provide an ioremap_flags, so this provides a corresponding
devm_ioremap_prot. The slight name difference is at Ben
Herrenschmidt's request as he plans on changing ioremap_flags to
ioremap_prot in the future.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Tejun Heo <htejun@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index afae0697e8ce..e0062d73db1c 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
#define _PNPWRP 0xa79
#define PNPBIOS_BASE 0xf000
+#include <linux/device.h>
+#include <linux/io.h>
+
#include <linux/compiler.h>
#include <asm/page.h>
#include <asm/byteorder.h>
@@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
I'll try removing it and see what breaks.
cheers
^ permalink raw reply related
* [PATCH v2] efi: Config options to assign versions in the PE-COFF header
From: Gary Lin @ 2017-04-13 3:58 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds the new config options to allow the user to modify the
following fields in the PE-COFF header.
UINT16 MajorOperatingSystemVersion
UINT16 MinorOperatingSystemVersion
UINT16 MajorImageVersion
UINT16 MinorImageVersion
Those fields are mainly for the executables or libraries in Windows NT
or higher to specify the minimum supported Windows version and the
version of the image itself.
Given the fact that those fields are ignored in UEFI, we can safely reuse
those fields for other purposes, e.g. Security Version(*).
(*) https://github.com/lcp/shim/wiki/Security-Version
v2 changes:
- Modify the header direct instead of using an external script as
suggested by Ard Biesheuvel
- Include arm and arm64
Cc: Russell King <linux@armlinux.org.uk>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Joey Lee <jlee@suse.com>
Cc: Vojtech Pavlik <vojtech@suse.cz>
Signed-off-by: Gary Lin <glin@suse.com>
---
arch/arm/Kconfig | 24 ++++++++++++++++++++++++
| 8 ++++----
arch/arm64/Kconfig | 24 ++++++++++++++++++++++++
arch/arm64/kernel/head.S | 8 ++++----
arch/x86/Kconfig | 24 ++++++++++++++++++++++++
| 8 ++++----
6 files changed, 84 insertions(+), 12 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0d4e71b42c77..4965ad2ccc23 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2090,6 +2090,30 @@ config EFI
is only useful for kernels that may run on systems that have
UEFI firmware.
+config EFI_MAJOR_OS
+ hex "EFI Major OS Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MINOR_OS
+ hex "EFI Minor OS Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MAJOR_IMAGE
+ hex "EFI Major Image Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MINOR_IMAGE
+ hex "EFI Minor Image Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
endmenu
menu "CPU Power Management"
--git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index 9d5dc4fda3c1..67715472a76f 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -69,10 +69,10 @@ extra_header_fields:
.long 0 @ ImageBase
.long 0x200 @ SectionAlignment
.long 0x200 @ FileAlignment
- .short 0 @ MajorOperatingSystemVersion
- .short 0 @ MinorOperatingSystemVersion
- .short 0 @ MajorImageVersion
- .short 0 @ MinorImageVersion
+ .short CONFIG_EFI_MAJOR_OS @ MajorOperatingSystemVersion
+ .short CONFIG_EFI_MINOR_OS @ MinorOperatingSystemVersion
+ .short CONFIG_EFI_MAJOR_IMAGE @ MajorImageVersion
+ .short CONFIG_EFI_MINOR_IMAGE @ MinorImageVersion
.short 0 @ MajorSubsystemVersion
.short 0 @ MinorSubsystemVersion
.long 0 @ Win32VersionValue
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3741859765cf..c782c422e58c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1033,6 +1033,30 @@ config EFI
allow the kernel to be booted as an EFI application. This
is only useful on systems that have UEFI firmware.
+config EFI_MAJOR_OS
+ hex "EFI Major OS Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MINOR_OS
+ hex "EFI Minor OS Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MAJOR_IMAGE
+ hex "EFI Major Image Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MINOR_IMAGE
+ hex "EFI Minor Image Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
config DMI
bool "Enable support for SMBIOS (DMI) tables"
depends on EFI
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 4fb6ccd886d1..9faa4b04d0ef 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -129,10 +129,10 @@ extra_header_fields:
.quad 0 // ImageBase
.long 0x1000 // SectionAlignment
.long PECOFF_FILE_ALIGNMENT // FileAlignment
- .short 0 // MajorOperatingSystemVersion
- .short 0 // MinorOperatingSystemVersion
- .short 0 // MajorImageVersion
- .short 0 // MinorImageVersion
+ .short CONFIG_EFI_MAJOR_OS // MajorOperatingSystemVersion
+ .short CONFIG_EFI_MINOR_OS // MinorOperatingSystemVersion
+ .short CONFIG_EFI_MAJOR_IMAGE // MajorImageVersion
+ .short CONFIG_EFI_MINOR_IMAGE // MinorImageVersion
.short 0 // MajorSubsystemVersion
.short 0 // MinorSubsystemVersion
.long 0 // Win32VersionValue
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5bbdef151805..233933fde7dd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1803,6 +1803,30 @@ config EFI_STUB
See Documentation/efi-stub.txt for more information.
+config EFI_MAJOR_OS
+ hex "EFI Major OS Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MINOR_OS
+ hex "EFI Minor OS Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MAJOR_IMAGE
+ hex "EFI Major Image Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
+config EFI_MINOR_IMAGE
+ hex "EFI Minor Image Version"
+ range 0x0 0xFFFF
+ default "0x0"
+ depends on EFI_STUB
+
config EFI_MIXED
bool "EFI mixed-mode support"
depends on EFI_STUB && X86_64
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 3dd5be33aaa7..863813007207 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -156,10 +156,10 @@ extra_header_fields:
#endif
.long 0x20 # SectionAlignment
.long 0x20 # FileAlignment
- .word 0 # MajorOperatingSystemVersion
- .word 0 # MinorOperatingSystemVersion
- .word 0 # MajorImageVersion
- .word 0 # MinorImageVersion
+ .word CONFIG_EFI_MAJOR_OS # MajorOperatingSystemVersion
+ .word CONFIG_EFI_MINOR_OS # MinorOperatingSystemVersion
+ .word CONFIG_EFI_MAJOR_IMAGE # MajorImageVersion
+ .word CONFIG_EFI_MINOR_IMAGE # MinorImageVersion
.word 0 # MajorSubsystemVersion
.word 0 # MinorSubsystemVersion
.long 0 # Win32VersionValue
--
2.12.0
^ permalink raw reply related
* [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board
From: Kever Yang @ 2017-04-13 4:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1642127.PiTFsmK4zh@phil>
Hi Heiko,
On 04/12/2017 09:29 PM, Heiko Stuebner wrote:
> Hi Kever,
>
> Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang:
>> Firefly-rk3399 is a bord from T-Firefly, you can find detail about
>> it here:
>> http://en.t-firefly.com/en/firenow/Firefly_RK3399/
>>
>> This patch add basic node for the board and make it able to bring
>> up.
>>
>> Peripheral works:
>> - usb hub which connect to ehci controller;
>> - UART2 debug
>> - eMMC
>> - PCIe
>>
>> Not work:
>> - USB 3.0 HOST, type-C port
>> - sdio, sd-card
>>
>> Not test for other peripheral:
>> - HDMI
>> - Ethernet
>> - OPTICAL
>> - WiFi/BT
>> - MIPI CSI/DSI
>> - IR
>> - EDP/DP
>>
>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> applied for 4.13, as we're a bit late for 4.12, with the following changes:
Thanks for your help, I'm not familiar with the devices status on upstream
because not working on kernel upstream for a long time.
> - commit subject
> - dropped status from backlight (as there is no disabled common node
> and it's specific to the firefly itself)
> - quite some reordering of properties
> - reordered regulator nodes per their addresses: 0x1b < 0x40
> - dropped obsolete regulator-compatible properties
> - fixed gpio-irq on the mpu6500
> - dropped out-of-tree orientation properties of mpu6500
> --> please provide the optional "mount-matrix" in a follow-up patch
> see bindings/iio/imu/inv_mpu6050.txt
Maybe we can drop this mpu6050 node first? I can't find binding file for it.
> - dropped rockchip,i2s-broken-burst-len;
> That change never made it into the mainline kernel
> - fixed pcie pinctrl indentation
> - dropped wireless-bluetooth uart-gpios pinctrl
> - dropped supports-emmc property
>
> Please try to be a bit more careful when porting stuff from device kernels
> with respect to properties not found in the mainline kernel and please
> also double-check in [0] that I didn't break anything.
I have test this patch on my firefly-rk3399, it works fine with pwm2
regulator
init in U-Boot.
Thanks,
- Kever
>
>
> Thanks
> Heiko
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=495a3c891a696b62465d71b1a125e3424352028b
>
>
^ permalink raw reply
* [PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
From: Minghsiu Tsai @ 2017-04-13 4:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Daniel Kurtz <djkurtz@chromium.org>
Experiments show that the:
(1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
(2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 13afe48..8ab7ca0 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file, void *fh,
struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
bool valid = false;
- if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (mtk_mdp_is_target_compose(s->target))
- valid = true;
- } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (mtk_mdp_is_target_crop(s->target))
valid = true;
+ } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (mtk_mdp_is_target_compose(s->target))
+ valid = true;
}
if (!valid) {
mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
@@ -907,12 +907,12 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
int ret;
bool valid = false;
- if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (s->target == V4L2_SEL_TGT_COMPOSE)
- valid = true;
- } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (s->target == V4L2_SEL_TGT_CROP)
valid = true;
+ } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (s->target == V4L2_SEL_TGT_COMPOSE)
+ valid = true;
}
if (!valid) {
mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
@@ -925,7 +925,7 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
if (ret)
return ret;
- if (mtk_mdp_is_target_crop(s->target))
+ if (mtk_mdp_is_target_compose(s->target))
frame = &ctx->s_frame;
else
frame = &ctx->d_frame;
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64
From: Ding Tianhong @ 2017-04-13 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E204FFD70@FRAEML521-MBX.china.huawei.com>
On 2017/4/7 23:57, Gabriele Paoloni wrote:
> Hi Robin and all
>
>> -----Original Message-----
>> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
>> owner at vger.kernel.org] On Behalf Of Robin Murphy
>> Sent: 20 March 2017 14:00
>> To: Dingtianhong; Catalin Marinas; Will Deacon; linux-arm-
>> kernel at lists.infradead.org; linux-kernel at vger.kernel.org
>> Cc: alexander.duyck at gmail.com; maowenan
>> Subject: Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64
>>
>> On 14/03/17 14:06, Ding Tianhong wrote:
>>> Hi Robin?
>>>
>>> On 2017/3/13 21:31, Robin Murphy wrote:
>>>> On 13/03/17 12:03, Ding Tianhong wrote:
>>>>> The ARCH_WANT_RELAX_ORDER will enable Relaxed Ordering (RO) which
>> allows
>>>>> transactions that do not have any order of completion requirements
>> to
>>>>> complete more efficiently compare to the Stricted Ordering (SO) for
>> ixbge
>>>>> nic card.
>>>>
>>>> Which ixgbe NIC? As far as I can see we have an arch-level config
>> option
>>>> here which applies to one single driver, and doesn't even cover all
>> the
>>>> hardware supported by that driver (82598, for example, still has the
>>>> #ifndef CONFIG_SPARC in the equivalent place). Looking at the
>> history,
>>>> I'd prefer to at least know what the "various issues with certain
>>>> chipsets" were, and why they wouldn't affect ARM systems, before
>> making
>>>> any judgement about whether this could be considered universally
>> safe
>>>> for arm64.
>>>>
>>>
>>> Indeed, in fact if the chipsets didn't support RO mode or has some
>> errata for RO mode, it may
>>> occur some issues, but it looks no such aarch64 chips, maybe I miss
>> something.
>>>
>>> There are several intel nic card could support enable relax order, so
>> need another patch to rename the SPARC
>>> to ARCH_WANT_RELAX_ORDER, the universal name looks more better.
>>
>> I'm sure I'm not alone in disagreeing outright that it looks better,
>> because ARCH_ is hardly the appropriate namespace for a driver option
>> unrelated to an architecture port's interaction with core kernel code;
>> plus it's further confounded by a name which both doesn't imply any
>> relationship with said driver, and does overlap with the kind of CPU
>> memory model terminology which *is* the purview of architecture ports.
>>
>> As an equivalent example, consider how equally misleading it would be
>> from the ARM maintainer perspective if CONFIG_IOMMU_IO_PGTABLE_LPAE was
>> just called CONFIG_ARCH_WANT_LPAE and implemented in this manner.
>>
>> Having looked into it, I see that "Relaxed Order" does actually turn
>> out
>> to be a specific PCIe term, but even in that context it doesn't apply
>> at
>> the arch level - that's going to be a matter for particular endpoints
>> and particular host controllers and all the quirks in between.
>
> I fully agree on this and to be honest I don't understand how
> <<commit 1a8b6d76dc5b "net:add one common config ARCH_WANT_RELAX_ORDER
> to support relax ordering">> has landed into mainline...
>
>
>>
>>>>> The system will see high write-to-memory performance when RO is
>>>>> enabled on the data transactions just like the SPARC did.
>>>>>
>>>>> The aarch64 pcie controller could both support Relaxed Ordering
>> (RO)
>>>>
>>>> What is "the AArch64 PCIe controller", exactly? Disregarding that
>>>> talking of PCIe in terms of the CPU ISA makes little sense, I can
>> barely
>>>> name two ARMv8-based systems which nominally use the same PCIe IP,
>> and
>>>> the amount of various quirks and incompatibilities I'm aware of
>> leaves
>>>> me with the default assumption that any such unqualified blanket
>>>> statement is probably wrong. I think we need some much more
>> considered
>>>> reasoning here.
>>>>
>>>
>>> Agree, till now I could only test on hip06/hip07 board and get the
>> better performance,
>>> maybe I could test on other aarch64 platform.
>>>
>>>>> and Stricted Ordering (SO), so enable ARCH_WANT_RELAX_ORDER for
>> ixgbe
>>>>> nic card to get much more better performance, and didn't see any
>>>>> adverse effects.
>>>>>
>>>>> Nic Card(Ixgbe) Disable RO | Enable RO
>>>>> Performance(Per thread) 8.4Gb/s | 9.4Gb/s
>>>>>
>>>>> Tested by Iperf on Hip06/Hip07 Soc Board.
>>>>>
>>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>>> ---
>>>>> arch/arm64/Kconfig | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>>>> index 8c7c244..36249a3 100644
>>>>> --- a/arch/arm64/Kconfig
>>>>> +++ b/arch/arm64/Kconfig
>>>>> @@ -115,6 +115,7 @@ config ARM64
>>>>> select SPARSE_IRQ
>>>>> select SYSCTL_EXCEPTION_TRACE
>>>>> select THREAD_INFO_IN_TASK
>>>>> + select ARCH_WANT_RELAX_ORDER
>>>>
>>>> I'd say the first order of business is to rename this config option
>> to
>>>> IXBGE_82599_WANT_RELAXED_ORDER so that it's not entirely misleading
>> and
>>>
>>> not only for 82599, including 82598, 82576....
>>
>> So why does ixgbe_start_hw_82598() still have the original #ifndef
>> CONFIG_SPARC from 887012e80aea?
>>
>> It was pretty clear from the outset that this is one of those patches
>> for making a particular card go faster in a particular system based on
>> what's available in the test lab - there's nothing inherently wrong
>> with
>> that, but if it were presented merely in those terms there would
>> probably be a lot less to object to.
>>
>>>> ambiguous. At first glance it looks far more like something scary to
>> do
>>>> with memory barriers than a network driver option. Howcome this
>> isn't
>>>> just in drivers/net/intel/Kconfig as a "default y if SPARC" bool
>> anyway?
>>>
>>> didn't see any essential differences, and I still need to get some
>> Acked by arm maintainer.
>>
>> The big difference is that had people done the sensible thing by
>> adding,
>> say, CONFIG_IXGBE_ALLOW_RELAXED_ORDER to drivers/net/intel/... and
>> sending a self-contained patch through the net tree, architecture
>> maintainers wouldn't even need to be aware, let alone ack anything.
>> Then
>> in future if someone sends another patch against the net tree changing
>> "y if (SPARC || ARM64)" back to "y if SPARC" because it happens to
>> break
>> on their system, the resulting discussion and resolution can happen on
>> netdev, and architecture maintainers who aren't necessarily familiar
>> with particular ixgbe/PCIe hardware details *still* don't need to care.
>
> Standard PCIe drivers uses bit 4 of the Device Control Register to
> enable/disable relaxed ordering: here it is not clear what Intel means
> by relaxed ordering and in which context (at least not to me) and why
> it should be disabled by default.
>
> From my perspective I would try to propose the following patch as RFC
> and see what the Intel maintainer comes up with and if any other ARM64
> host vendor would oppose to it.
> The RFC below reverts commit 1a8b6d76dc5b and enable relaxed ordering
> on SPARC and ARM64 machines...
>
> What do you think?
>
Hi Gab:
Till now I didn't get any useful feedback from the latest version patches,
it is really hard to unify everyone's opinion, I will follow your solution
and send a new version patch, thanks.
Ding
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index cd211a1..e03d354 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -844,7 +844,4 @@ config STRICT_MODULE_RWX
> and non-text memory will be made non-executable. This provides
> protection against certain security exploits (e.g. writing to text)
>
> -config ARCH_WANT_RELAX_ORDER
> - bool
> -
> source "kernel/gcov/Kconfig"
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 68ac5c7..cf4034c 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -44,7 +44,6 @@ config SPARC
> select CPU_NO_EFFICIENT_FFS
> select HAVE_ARCH_HARDENED_USERCOPY
> select PROVE_LOCKING_SMALL if PROVE_LOCKING
> - select ARCH_WANT_RELAX_ORDER
>
> config SPARC32
> def_bool !64BIT
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> index c38d50c..d55dcac 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> @@ -350,7 +350,8 @@ s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw)
> }
> IXGBE_WRITE_FLUSH(hw);
>
> -#ifndef CONFIG_ARCH_WANT_RELAX_ORDER
> +#if !defined(CONFIG_SPARC) && !defined(CONFIG_ARM64)
> +
> /* Disable relaxed ordering */
> for (i = 0; i < hw->mac.max_tx_queues; i++) {
> u32 regval;
>
>
>>
>> Robin.
^ permalink raw reply
* [PATCH v4 2/2] PCI: quirks: Fix ThunderX2 dma alias handling
From: Jon Masters @ 2017-04-13 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f6b5c29-c985-dbfc-8738-cbc9bd85e408@arm.com>
On 04/04/2017 10:28 AM, Robin Murphy wrote:
> So (at the risk of Jon mooing at me)
moooooooooooo
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
From: Wu-Cheng Li (李務誠) @ 2017-04-13 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492057130-1194-1-git-send-email-minghsiu.tsai@mediatek.com>
Reviewed-by: Wu-Cheng Li <wuchengli@chromium.org>
On Thu, Apr 13, 2017 at 12:18 PM, Minghsiu Tsai
<minghsiu.tsai@mediatek.com> wrote:
> From: Daniel Kurtz <djkurtz@chromium.org>
>
> Experiments show that the:
> (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
> (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
>
> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 13afe48..8ab7ca0 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file, void *fh,
> struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (mtk_mdp_is_target_compose(s->target))
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (mtk_mdp_is_target_crop(s->target))
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (mtk_mdp_is_target_compose(s->target))
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -907,12 +907,12 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
> int ret;
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (s->target == V4L2_SEL_TGT_COMPOSE)
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (s->target == V4L2_SEL_TGT_CROP)
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (s->target == V4L2_SEL_TGT_COMPOSE)
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -925,7 +925,7 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
> if (ret)
> return ret;
>
> - if (mtk_mdp_is_target_crop(s->target))
> + if (mtk_mdp_is_target_compose(s->target))
> frame = &ctx->s_frame;
> else
> frame = &ctx->d_frame;
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 1/3] clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks
From: Maxime Ripard @ 2017-04-13 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413021354.3258-2-wens@csie.org>
Hi Chen-Yu,
On Thu, Apr 13, 2017 at 10:13:52AM +0800, Chen-Yu Tsai wrote:
> In common PLL designs, changes to the dividers take effect almost
> immediately, while changes to the multipliers (implemented as
> dividers in the feedback loop) take a few cycles to work into
> the feedback loop for the PLL to stablize.
>
> Sometimes when the PLL clock rate is changed, the decrease in the
> divider is too much for the decrease in the multiplier to catch up.
> The PLL clock rate will spike, and in some cases, might lock up
> completely. This is especially the case if the divider changed is
> the pre-divider, which affects the reference frequency.
>
> This patch introduces a clk notifier callback that will gate and
> then ungate a clk after a rate change, effectively resetting it,
> so it continues to work, despite any possible lockups. Care must
> be taken to reparent any consumers to other temporary clocks during
> the rate change, and that this notifier callback must be the first
> to be registered.
>
> This is intended to fix occasional lockups with cpufreq on newer
> Allwinner SoCs, such as the A33 and the H3. Previously it was
> thought that reparenting the cpu clock away from the PLL while
> it stabilized was enough, as this worked quite well on the A31.
>
> On the A33, hangs have been observed after cpufreq was recently
> introduced. With the H3, a more thorough test [1] showed that
> reparenting alone isn't enough. The system still locks up unless
> the dividers are limited to 1.
>
> A hunch was if the PLL was stuck in some unknown state, perhaps
> gating then ungating it would bring it back to normal. Tests
> done by Icenowy Zheng using Ondrej's test firmware shows this
> to be a valid solution.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg552501.html
>
> Reported-by: Ondrej Jirman <megous@megous.com>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Tested-by: Icenowy Zheng <icenowy@aosc.io>
> Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Thanks for looking into this, and coming up with a clean solution, and
a great commit log.
However, I wondering, isn't that notifier just a re-implementation of
CLK_SET_RATE_GATE?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170413/076adcef/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] hwrng: mtk: add support for hardware random generator on MT7623 SoC
From: sean.wang at mediatek.com @ 2017-04-13 7:05 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
This patchset introduces support for Mediatek hardware random generator (RNG)
Currently, the driver is already tested successfully with rng-tools on MT7623
SoC. And it should also be workable on other similar Mediatek SoCs.
SoC that also works on other similar SoCs.
Sean Wang (2):
dt-bindings: hwrng: Add Mediatek hardware random generator bindings
hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 +++
drivers/char/hw_random/Kconfig | 16 +-
drivers/char/hw_random/Makefile | 2 +-
drivers/char/hw_random/mtk-rng.c | 174 ++++++++++++++++++++++
4 files changed, 208 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
create mode 100644 drivers/char/hw_random/mtk-rng.c
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: sean.wang at mediatek.com @ 2017-04-13 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492067108-14748-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Document the devicetree bindings for Mediatek random number
generator which could be found on MT7623 SoC or other similar
Mediatek SoCs.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt
new file mode 100644
index 0000000..a6d62a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for Mediatek random number generator
+found in Mediatek SoC family
+
+Required properties:
+- compatible : Should be "mediatek,mt7623-rng"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : Should contain "rng" entries;
+- reg : Specifies base physical address and size of the registers
+
+Example:
+
+rng: rng at 1020f000 {
+ compatible = "mediatek,mt7623-rng";
+ reg = <0 0x1020f000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_TRNG>;
+ clock-names = "rng";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: sean.wang at mediatek.com @ 2017-04-13 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492067108-14748-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds support for hardware random generator on MT7623 SoC
and should also work on other similar Mediatek SoCs. Currently,
the driver is already tested successfully with rng-tools.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/char/hw_random/Kconfig | 16 +++-
drivers/char/hw_random/Makefile | 2 +-
drivers/char/hw_random/mtk-rng.c | 174 +++++++++++++++++++++++++++++++++++++++
3 files changed, 190 insertions(+), 2 deletions(-)
create mode 100644 drivers/char/hw_random/mtk-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 0cafe08..af782ce 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
Generator hardware found on Cavium SoCs.
To compile this driver as a module, choose M here: the
- module will be called cavium_rng.
+ module will be called mtk-rng.
If unsure, say Y.
+config HW_RANDOM_MTK
+ tristate "Mediatek Random Number Generator support"
+ depends on HW_RANDOM
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ default y
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here. the
+ module will be called mtk-rng.
+
+ If unsure, say Y.
+
endif # HW_RANDOM
config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 5f52b1e..68be716 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -1,7 +1,6 @@
#
# Makefile for HW Random Number Generator (RNG) device drivers.
#
-
obj-$(CONFIG_HW_RANDOM) += rng-core.o
rng-core-y := core.o
obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
@@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
+obj-$(CONFIG_HW_RANDOM_MTK) += mtk-rng.o
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
new file mode 100644
index 0000000..6561ee0
--- /dev/null
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -0,0 +1,174 @@
+/*
+ * Driver for Mediatek Hardware Random Number Generator
+ *
+ * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#define MTK_RNG_DEV KBUILD_MODNAME
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define USEC_POLL 2
+#define TIMEOUT_POLL 20
+
+#define RNG_CTRL 0x00
+#define RNG_EN BIT(0)
+#define RNG_READY BIT(31)
+
+#define RNG_DATA 0x08
+
+#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
+
+struct mtk_rng {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *clk;
+ struct hwrng rng;
+};
+
+static int mtk_rng_init(struct hwrng *rng)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ u32 val;
+ int err;
+
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ return err;
+
+ val = readl(priv->base + RNG_CTRL);
+ val |= RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ return 0;
+}
+
+static void mtk_rng_cleanup(struct hwrng *rng)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ u32 val;
+
+ val = readl(priv->base + RNG_CTRL);
+ val &= ~RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ clk_disable_unprepare(priv->clk);
+}
+
+static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ int ready;
+
+ ready = readl(priv->base + RNG_CTRL) & RNG_READY;
+ if (!ready && wait)
+ readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
+ ready & RNG_READY, USEC_POLL,
+ TIMEOUT_POLL);
+ return !!ready;
+}
+
+static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ int retval = 0;
+
+ while (max >= sizeof(u32)) {
+ if (!mtk_rng_wait_ready(rng, wait))
+ break;
+
+ *(u32 *)buf = readl(priv->base + RNG_DATA);
+ retval += sizeof(u32);
+ buf += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ if (unlikely(wait && max))
+ dev_warn(priv->dev, "timeout might be not properly set\n");
+
+ return retval || !wait ? retval : -EIO;
+}
+
+static int mtk_rng_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret;
+ struct mtk_rng *priv;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "no iomem resource\n");
+ return -ENXIO;
+ }
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = &pdev->dev;
+ priv->rng.name = pdev->name;
+ priv->rng.init = mtk_rng_init;
+ priv->rng.cleanup = mtk_rng_cleanup;
+ priv->rng.read = mtk_rng_read;
+
+ priv->clk = devm_clk_get(&pdev->dev, "rng");
+ if (IS_ERR(priv->clk)) {
+ ret = PTR_ERR(priv->clk);
+ dev_err(&pdev->dev, "no clock for device: %d\n", ret);
+ return ret;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ ret = devm_hwrng_register(&pdev->dev, &priv->rng);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register rng device: %d\n",
+ ret);
+ return ret;
+ }
+
+ dev_info(&pdev->dev, "registered RNG driver\n");
+
+ return 0;
+}
+
+static const struct of_device_id mtk_rng_match[] = {
+ { .compatible = "mediatek,mt7623-rng" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mtk_rng_match);
+
+static struct platform_driver mtk_rng_driver = {
+ .probe = mtk_rng_probe,
+ .driver = {
+ .name = MTK_RNG_DEV,
+ .of_match_table = mtk_rng_match,
+ },
+};
+
+module_platform_driver(mtk_rng_driver);
+
+MODULE_DESCRIPTION("Mediatek Random Number Generator Driver");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH 2/6] regulator: anatop: only set supply regulator when it actually exists
From: Dong Aisheng @ 2017-04-13 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411203124.y7cwyttqfu4a2aov@sirena.org.uk>
Hi Mark,
On Tue, Apr 11, 2017 at 09:31:24PM +0100, Mark Brown wrote:
> On Wed, Apr 12, 2017 at 09:58:43AM +0800, Dong Aisheng wrote:
> > Mandatorily set the initdata->supply_regulator while it actually not
> > exist will cause regulator core to resolve supply each time whenever
> > a new regulator registered which is meaningless and waste CPU mips.
> >
> > We can observe more than one hundred times of iteration of resolving
> > during a MX6Q SDB board booting up.
> >
> > This patch adds the condition check for vin-supply to avoid the issue.
>
> This is an obvious abstraction failure - there is nothing magical about
> your driver which means that we need special casing in it to handle
> badly written DTs that don't specify supplies. Exactly the same
> argument applies to all other regulators so if this is worth fixing it's
> worth fixing in the core so we substitute in a dummy regulator if the
> supply is genuinely missing. Which is something we in fact have code to
> do already though for some reason I can't see we bypass it, I'll send a
> patch just now...
You're absolutely right!
I did this because there're some where else did the same thing.
e.g. drivers/regulator/fixed.c.
But it's obviously none of any platform specific and is perfectly
to be handled in regulator core.
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH] net: thunderx: Fix set_max_bgx_per_node for 81xx rgx
From: George Cherian @ 2017-04-13 7:25 UTC (permalink / raw)
To: linux-arm-kernel
Add the PCI_SUBSYS_DEVID_81XX_RGX and use the same to set
the max bgx per node count.
This fixes the issue intoduced by following commit
78aacb6f6 net: thunderx: Fix invalid mac addresses for node1 interfaces
With this commit the max_bgx_per_node for 81xx is set as 2 instead of 3
because of which num_vfs is always calculated as zero.
Signed-off-by: George Cherian <george.cherian@cavium.com>
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 1 +
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 64a1095..a0ca68c 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -134,6 +134,7 @@ static void set_max_bgx_per_node(struct pci_dev *pdev)
pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &sdevid);
switch (sdevid) {
case PCI_SUBSYS_DEVID_81XX_BGX:
+ case PCI_SUBSYS_DEVID_81XX_RGX:
max_bgx_per_node = MAX_BGX_PER_CN81XX;
break;
case PCI_SUBSYS_DEVID_83XX_BGX:
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
index c5080f2c..6b7fe6fd 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
@@ -16,6 +16,7 @@
/* Subsystem device IDs */
#define PCI_SUBSYS_DEVID_88XX_BGX 0xA126
#define PCI_SUBSYS_DEVID_81XX_BGX 0xA226
+#define PCI_SUBSYS_DEVID_81XX_RGX 0xA254
#define PCI_SUBSYS_DEVID_83XX_BGX 0xA326
#define MAX_BGX_THUNDER 8 /* Max 2 nodes, 4 per node */
--
2.1.4
^ permalink raw reply related
* [PATCH v2] efi: Config options to assign versions in the PE-COFF header
From: Ard Biesheuvel @ 2017-04-13 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413035827.9820-1-glin@suse.com>
On 13 April 2017 at 04:58, Gary Lin <glin@suse.com> wrote:
> This commit adds the new config options to allow the user to modify the
> following fields in the PE-COFF header.
>
> UINT16 MajorOperatingSystemVersion
> UINT16 MinorOperatingSystemVersion
> UINT16 MajorImageVersion
> UINT16 MinorImageVersion
>
> Those fields are mainly for the executables or libraries in Windows NT
> or higher to specify the minimum supported Windows version and the
> version of the image itself.
>
> Given the fact that those fields are ignored in UEFI, we can safely reuse
> those fields for other purposes, e.g. Security Version(*).
>
> (*) https://github.com/lcp/shim/wiki/Security-Version
>
> v2 changes:
> - Modify the header direct instead of using an external script as
> suggested by Ard Biesheuvel
> - Include arm and arm64
>
Thanks for the update. Could we put the Kconfig changes in
drivers/firmware/efi/Kconfig, rather than duplicating them 3 times?
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Joey Lee <jlee@suse.com>
> Cc: Vojtech Pavlik <vojtech@suse.cz>
> Signed-off-by: Gary Lin <glin@suse.com>
> ---
> arch/arm/Kconfig | 24 ++++++++++++++++++++++++
> arch/arm/boot/compressed/efi-header.S | 8 ++++----
> arch/arm64/Kconfig | 24 ++++++++++++++++++++++++
> arch/arm64/kernel/head.S | 8 ++++----
> arch/x86/Kconfig | 24 ++++++++++++++++++++++++
> arch/x86/boot/header.S | 8 ++++----
> 6 files changed, 84 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0d4e71b42c77..4965ad2ccc23 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2090,6 +2090,30 @@ config EFI
> is only useful for kernels that may run on systems that have
> UEFI firmware.
>
> +config EFI_MAJOR_OS
> + hex "EFI Major OS Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MINOR_OS
> + hex "EFI Minor OS Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MAJOR_IMAGE
> + hex "EFI Major Image Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MINOR_IMAGE
> + hex "EFI Minor Image Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> endmenu
>
> menu "CPU Power Management"
> diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
> index 9d5dc4fda3c1..67715472a76f 100644
> --- a/arch/arm/boot/compressed/efi-header.S
> +++ b/arch/arm/boot/compressed/efi-header.S
> @@ -69,10 +69,10 @@ extra_header_fields:
> .long 0 @ ImageBase
> .long 0x200 @ SectionAlignment
> .long 0x200 @ FileAlignment
> - .short 0 @ MajorOperatingSystemVersion
> - .short 0 @ MinorOperatingSystemVersion
> - .short 0 @ MajorImageVersion
> - .short 0 @ MinorImageVersion
> + .short CONFIG_EFI_MAJOR_OS @ MajorOperatingSystemVersion
> + .short CONFIG_EFI_MINOR_OS @ MinorOperatingSystemVersion
> + .short CONFIG_EFI_MAJOR_IMAGE @ MajorImageVersion
> + .short CONFIG_EFI_MINOR_IMAGE @ MinorImageVersion
> .short 0 @ MajorSubsystemVersion
> .short 0 @ MinorSubsystemVersion
> .long 0 @ Win32VersionValue
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3741859765cf..c782c422e58c 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1033,6 +1033,30 @@ config EFI
> allow the kernel to be booted as an EFI application. This
> is only useful on systems that have UEFI firmware.
>
> +config EFI_MAJOR_OS
> + hex "EFI Major OS Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MINOR_OS
> + hex "EFI Minor OS Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MAJOR_IMAGE
> + hex "EFI Major Image Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MINOR_IMAGE
> + hex "EFI Minor Image Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> config DMI
> bool "Enable support for SMBIOS (DMI) tables"
> depends on EFI
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 4fb6ccd886d1..9faa4b04d0ef 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -129,10 +129,10 @@ extra_header_fields:
> .quad 0 // ImageBase
> .long 0x1000 // SectionAlignment
> .long PECOFF_FILE_ALIGNMENT // FileAlignment
> - .short 0 // MajorOperatingSystemVersion
> - .short 0 // MinorOperatingSystemVersion
> - .short 0 // MajorImageVersion
> - .short 0 // MinorImageVersion
> + .short CONFIG_EFI_MAJOR_OS // MajorOperatingSystemVersion
> + .short CONFIG_EFI_MINOR_OS // MinorOperatingSystemVersion
> + .short CONFIG_EFI_MAJOR_IMAGE // MajorImageVersion
> + .short CONFIG_EFI_MINOR_IMAGE // MinorImageVersion
> .short 0 // MajorSubsystemVersion
> .short 0 // MinorSubsystemVersion
> .long 0 // Win32VersionValue
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5bbdef151805..233933fde7dd 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1803,6 +1803,30 @@ config EFI_STUB
>
> See Documentation/efi-stub.txt for more information.
>
> +config EFI_MAJOR_OS
> + hex "EFI Major OS Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MINOR_OS
> + hex "EFI Minor OS Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MAJOR_IMAGE
> + hex "EFI Major Image Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> +config EFI_MINOR_IMAGE
> + hex "EFI Minor Image Version"
> + range 0x0 0xFFFF
> + default "0x0"
> + depends on EFI_STUB
> +
> config EFI_MIXED
> bool "EFI mixed-mode support"
> depends on EFI_STUB && X86_64
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 3dd5be33aaa7..863813007207 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -156,10 +156,10 @@ extra_header_fields:
> #endif
> .long 0x20 # SectionAlignment
> .long 0x20 # FileAlignment
> - .word 0 # MajorOperatingSystemVersion
> - .word 0 # MinorOperatingSystemVersion
> - .word 0 # MajorImageVersion
> - .word 0 # MinorImageVersion
> + .word CONFIG_EFI_MAJOR_OS # MajorOperatingSystemVersion
> + .word CONFIG_EFI_MINOR_OS # MinorOperatingSystemVersion
> + .word CONFIG_EFI_MAJOR_IMAGE # MajorImageVersion
> + .word CONFIG_EFI_MINOR_IMAGE # MinorImageVersion
> .word 0 # MajorSubsystemVersion
> .word 0 # MinorSubsystemVersion
> .long 0 # Win32VersionValue
> --
> 2.12.0
>
^ permalink raw reply
* [PATCH 5/6] regulator: anatop-regulator: make regulator-name using optionally
From: Dong Aisheng @ 2017-04-13 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411203817.5f32em4v5xiwzchl@sirena.org.uk>
On Tue, Apr 11, 2017 at 09:38:18PM +0100, Mark Brown wrote:
> On Wed, Apr 12, 2017 at 09:58:46AM +0800, Dong Aisheng wrote:
> > rdesc->name/regulator-name is optional according to standard regulator
> > binding doc. Use it conditionally to avoid a kernel NULL point crash.
>
> It is optional in the standard binding because it is used to override
> the name statically provided in the driver for the device. Since the
> anatop regulator is completely dynamic (there's no static list of
> regulators in the device) it's mandatory for anatop regulators - you
> should improve the error handling instead to detect a missing name.
Got it. Will change in v2.
Thanks for the suggestion.
Regards
Dong Aisheng
^ 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