* Re: [PATCH v5, 25/32] drm/mediatek: add connection from OVL0 to OVL_2L0
From: CK Hu @ 2019-08-30 6:20 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-26-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from OVL0 to OVL_2L0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index effc24a..42a130a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -137,6 +137,8 @@
> #define DPI_SEL_IN_BLS 0x0
> #define DSI_SEL_IN_RDMA 0x1
>
> +#define OVL0_MOUT_EN_OVL0_2L BIT(4)
> +
> struct mtk_disp_mutex {
> int id;
> bool claimed;
> @@ -299,6 +301,9 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD1_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
> + *addr = data->ovl0_mout_en;
> + value = OVL0_MOUT_EN_OVL0_2L;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 02/11] dt-bindings: phy-mtk-tphy: make the ref clock optional
From: Chunfeng Yun @ 2019-08-30 6:22 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, Kishon Vijay Abraham I,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20190829192550.GA29881@bogus>
On Thu, 2019-08-29 at 14:25 -0500, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:00:09PM +0800, Chunfeng Yun wrote:
> > Make the ref clock optional, then we no need refer to a fixed-clock
> > in DTS anymore when the clock of USB3 PHY comes from oscillator
> > directly
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > .../devicetree/bindings/phy/phy-mtk-tphy.txt | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index d5b327f85fa2..1c18bf10b2fe 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -34,12 +34,6 @@ Optional properties (controller (parent) node):
> >
> > Required properties (port (child) node):
> > - reg : address and length of the register set for the port.
> > -- clocks : a list of phandle + clock-specifier pairs, one for each
> > - entry in clock-names
> > -- clock-names : must contain
> > - "ref": 48M reference clock for HighSpeed analog phy; and 26M
> > - reference clock for SuperSpeed analog phy, sometimes is
> > - 24M, 25M or 27M, depended on platform.
> > - #phy-cells : should be 1 (See second example)
> > cell after port phandle is phy type from:
> > - PHY_TYPE_USB2
> > @@ -48,6 +42,13 @@ Required properties (port (child) node):
> > - PHY_TYPE_SATA
> >
> > Optional properties (PHY_TYPE_USB2 port (child) node):
> > +- clocks : a list of phandle + clock-specifier pairs, one for each
> > + entry in clock-names
> > +- clock-names : may contain
> > + "ref": 48M reference clock for HighSpeed anolog phy; and 26M
> > + reference clock for SuperSpeed anolog phy, sometimes is
> > + 24M, 25M or 27M, depended on platform.
>
> How do you know the frequency when it is not present?
It's always present, but sometimes it's always on by default (e.g. 48Mhz
of U2 PHY), or comes from oscillator directly (e.g. 26Mhz of U3 PHY),
so not controlled by CCF, of course we can use a fixed-clock in latter
case, it's useful to make it optional for these two cases.
Thanks
>
> > +
> > - mediatek,eye-src : u32, the value of slew rate calibrate
> > - mediatek,eye-vrt : u32, the selection of VRT reference voltage
> > - mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
> > --
> > 2.23.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 26/32] drm/mediatek: add connection from RDMA0 to COLOR0
From: CK Hu @ 2019-08-30 6:23 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-27-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from RDMA0 to COLOR0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 42a130a..03a46ec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -171,6 +171,8 @@ struct mtk_ddp {
>
> struct mtk_mmsys_reg_data {
> u32 ovl0_mout_en;
> + u32 rdma0_sout_sel_in;
> + u32 rdma0_sout_color0;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dpi0;
> u32 dpi0_sel_in;
> @@ -428,6 +430,9 @@ static unsigned int mtk_ddp_sout_sel(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_SOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
> + *addr = data->rdma0_sout_sel_in;
> + value = data->rdma0_sout_color0;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 04/11] dt-bindings: phy-mtk-tphy: add a new reference clock
From: Chunfeng Yun @ 2019-08-30 6:23 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, Kishon Vijay Abraham I,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <20190829200503.GA2542@bogus>
On Thu, 2019-08-29 at 15:05 -0500, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:00:11PM +0800, Chunfeng Yun wrote:
> > Usually the digital and anolog phys use the same reference clock,
> > but on some platforms, they are separated, so add another optional
> > clock to support it.
> > In order to keep the clock names consistent with PHY IP's, use
> > the da_ref for anolog phy and ref clock for digital phy.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index dbc143ed5999..ed9a2641f204 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -41,9 +41,12 @@ Optional properties (PHY_TYPE_USB2 port (child) node):
> > - clocks : a list of phandle + clock-specifier pairs, one for each
> > entry in clock-names
> > - clock-names : may contain
> > - "ref": 48M reference clock for HighSpeed anolog phy; and 26M
> > - reference clock for SuperSpeed anolog phy, sometimes is
> > + "ref": 48M reference clock for HighSpeed (digital) phy; and 26M
> > + reference clock for SuperSpeed (digital) phy, sometimes is
> > 24M, 25M or 27M, depended on platform.
> > + "da_ref": the reference clock of anolog phy, used if the clocks
> > + of anolog and digital phys are separated, otherwise uses
>
> s/amolog/analog/
will fix it
>
> > + "ref" clock only if need.
>
> needed.
also here
Thanks a lot
>
> >
> > - mediatek,eye-src : u32, the value of slew rate calibrate
> > - mediatek,eye-vrt : u32, the selection of VRT reference voltage
> > --
> > 2.23.0
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 0/3] perf cs-etm: Add support for callchain
From: Leo Yan @ 2019-08-30 6:24 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Suzuki K Poulose,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, linux-arm-kernel,
linux-kernel, Mike Leach, Robert Walker, Adrian Hunter
Cc: Leo Yan
This patch seris adds support for instruction sample's callchain.
Patch 01 is to refactor the instruction size calculation; patch 02
is to add thread stack and callchain support; patch 03 is a minor fixing
for instruction sample generation thus the instruction sample can be
alignment with the callchain generation.
Before:
# perf script --itrace=g16l64i100
main 1579 100 instructions: ffff0000102137f0 group_sched_in+0xb0 ([kernel.kallsyms])
main 1579 100 instructions: ffff000010213b78 flexible_sched_in+0xf0 ([kernel.kallsyms])
main 1579 100 instructions: ffff0000102135ac event_sched_in.isra.57+0x74 ([kernel.kallsyms])
main 1579 100 instructions: ffff000010219344 perf_swevent_add+0x6c ([kernel.kallsyms])
main 1579 100 instructions: ffff000010214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
[...]
After:
# perf script --itrace=g16l64i100
main 1579 100 instructions:
ffff0000102137f0 group_sched_in+0xb0 ([kernel.kallsyms])
main 1579 100 instructions:
ffff000010213b78 flexible_sched_in+0xf0 ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579 100 instructions:
ffff0000102135ac event_sched_in.isra.57+0x74 ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579 100 instructions:
ffff000010219344 perf_swevent_add+0x6c ([kernel.kallsyms])
ffff0000102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
main 1579 100 instructions:
ffff000010214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
ffff000010219360 perf_swevent_add+0x88 ([kernel.kallsyms])
ffff0000102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
[...]
Leo Yan (3):
perf cs-etm: Refactor instruction size handling
perf cs-etm: Add callchain to instruction sample
perf cs-etm: Correct the packet usage for instruction sample
tools/perf/util/cs-etm.c | 122 +++++++++++++++++++++++++++++++++------
1 file changed, 105 insertions(+), 17 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/3] perf cs-etm: Refactor instruction size handling
From: Leo Yan @ 2019-08-30 6:24 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Suzuki K Poulose,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, linux-arm-kernel,
linux-kernel, Mike Leach, Robert Walker, Adrian Hunter
Cc: Leo Yan
In-Reply-To: <20190830062421.31275-1-leo.yan@linaro.org>
There has several code pieces need to know the instruction size, but
now every place calculates the instruction size separately.
This patch refactors to create a new function cs_etm__instr_size() as
a central place to analyze the instruction length based on ISA type
and instruction value.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 44 +++++++++++++++++++++++++++-------------
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index b3a5daaf1a8f..882a0718033d 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -914,6 +914,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
}
+static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
+ u8 trace_chan_id,
+ enum cs_etm_isa isa,
+ u64 addr)
+{
+ int insn_len;
+
+ /*
+ * T32 instruction size might be 32-bit or 16-bit, decide by calling
+ * cs_etm__t32_instr_size().
+ */
+ if (isa == CS_ETM_ISA_T32)
+ insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
+ /* Otherwise, A64 and A32 instruction size are always 32-bit. */
+ else
+ insn_len = 4;
+
+ return insn_len;
+}
+
static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
{
/* Returns 0 for the CS_ETM_DISCONTINUITY packet */
@@ -938,19 +958,23 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
const struct cs_etm_packet *packet,
u64 offset)
{
+ int insn_len;
+
if (packet->isa == CS_ETM_ISA_T32) {
u64 addr = packet->start_addr;
while (offset > 0) {
- addr += cs_etm__t32_instr_size(etmq,
- trace_chan_id, addr);
+ addr += cs_etm__instr_size(etmq, trace_chan_id,
+ packet->isa, addr);
offset--;
}
return addr;
}
- /* Assume a 4 byte instruction size (A32/A64) */
- return packet->start_addr + offset * 4;
+ /* Return instruction size for A32/A64 */
+ insn_len = cs_etm__instr_size(etmq, trace_chan_id,
+ packet->isa, packet->start_addr);
+ return packet->start_addr + offset * insn_len;
}
static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq,
@@ -1090,16 +1114,8 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
return;
}
- /*
- * T32 instruction size might be 32-bit or 16-bit, decide by calling
- * cs_etm__t32_instr_size().
- */
- if (packet->isa == CS_ETM_ISA_T32)
- sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
- sample->ip);
- /* Otherwise, A64 and A32 instruction size are always 32-bit. */
- else
- sample->insn_len = 4;
+ sample->insn_len = cs_etm__instr_size(etmq, trace_chan_id,
+ packet->isa, sample->ip);
cs_etm__mem_access(etmq, trace_chan_id, sample->ip,
sample->insn_len, (void *)sample->insn);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 2/3] perf cs-etm: Add callchain to instruction sample
From: Leo Yan @ 2019-08-30 6:24 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Suzuki K Poulose,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, linux-arm-kernel,
linux-kernel, Mike Leach, Robert Walker, Adrian Hunter
Cc: Leo Yan
In-Reply-To: <20190830062421.31275-1-leo.yan@linaro.org>
Firstly, this patch adds support for the thread stack; when every branch
packet is coming we will push or pop the stack based on the sample
flags.
Secondly, based on the thread stack we can synthesize call chain for the
instruction sample, this can be used by itrace option '--itrace=g'.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 74 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 73 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 882a0718033d..ad573d3bd305 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -17,6 +17,7 @@
#include <stdlib.h>
#include "auxtrace.h"
+#include "callchain.h"
#include "color.h"
#include "cs-etm.h"
#include "cs-etm-decoder/cs-etm-decoder.h"
@@ -69,6 +70,7 @@ struct cs_etm_traceid_queue {
size_t last_branch_pos;
union perf_event *event_buf;
struct thread *thread;
+ struct ip_callchain *chain;
struct branch_stack *last_branch;
struct branch_stack *last_branch_rb;
struct cs_etm_packet *prev_packet;
@@ -246,6 +248,16 @@ static int cs_etm__init_traceid_queue(struct cs_etm_queue *etmq,
if (!tidq->prev_packet)
goto out_free;
+ if (etm->synth_opts.callchain) {
+ size_t sz = sizeof(struct ip_callchain);
+
+ /* Add 1 to callchain_sz for callchain context */
+ sz += (etm->synth_opts.callchain_sz + 1) * sizeof(u64);
+ tidq->chain = zalloc(sz);
+ if (!tidq->chain)
+ goto out_free;
+ }
+
if (etm->synth_opts.last_branch) {
size_t sz = sizeof(struct branch_stack);
@@ -270,6 +282,7 @@ static int cs_etm__init_traceid_queue(struct cs_etm_queue *etmq,
zfree(&tidq->last_branch);
zfree(&tidq->prev_packet);
zfree(&tidq->packet);
+ zfree(&tidq->chain);
out:
return rc;
}
@@ -541,6 +554,7 @@ static void cs_etm__free_traceid_queues(struct cs_etm_queue *etmq)
zfree(&tidq->last_branch_rb);
zfree(&tidq->prev_packet);
zfree(&tidq->packet);
+ zfree(&tidq->chain);
zfree(&tidq);
/*
@@ -1121,6 +1135,41 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
sample->insn_len, (void *)sample->insn);
}
+static void cs_etm__add_stack_event(struct cs_etm_queue *etmq,
+ struct cs_etm_traceid_queue *tidq)
+{
+ struct cs_etm_auxtrace *etm = etmq->etm;
+ u8 trace_chan_id = tidq->trace_chan_id;
+ int insn_len;
+ u64 from_ip, to_ip;
+
+ if (etm->synth_opts.callchain || etm->synth_opts.thread_stack) {
+
+ from_ip = cs_etm__last_executed_instr(tidq->prev_packet);
+ to_ip = cs_etm__first_executed_instr(tidq->packet);
+
+ /*
+ * T32 instruction size might be 32-bit or 16-bit, decide by
+ * calling cs_etm__t32_instr_size().
+ */
+ if (tidq->prev_packet->isa == CS_ETM_ISA_T32)
+ insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
+ from_ip);
+ /* Otherwise, A64 and A32 instruction size are always 32-bit. */
+ else
+ insn_len = 4;
+
+ thread_stack__event(tidq->thread, tidq->prev_packet->cpu,
+ tidq->prev_packet->flags,
+ from_ip, to_ip, insn_len,
+ etmq->buffer->buffer_nr);
+ } else {
+ thread_stack__set_trace_nr(tidq->thread,
+ tidq->prev_packet->cpu,
+ etmq->buffer->buffer_nr);
+ }
+}
+
static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
struct cs_etm_traceid_queue *tidq,
u64 addr, u64 period)
@@ -1146,6 +1195,14 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
+ if (etm->synth_opts.callchain) {
+ thread_stack__sample(tidq->thread, tidq->packet->cpu,
+ tidq->chain,
+ etm->synth_opts.callchain_sz + 1,
+ sample.ip, etm->kernel_start);
+ sample.callchain = tidq->chain;
+ }
+
if (etm->synth_opts.last_branch) {
cs_etm__copy_last_branch_rb(etmq, tidq);
sample.branch_stack = tidq->last_branch;
@@ -1329,6 +1386,8 @@ static int cs_etm__synth_events(struct cs_etm_auxtrace *etm,
attr.sample_type &= ~(u64)PERF_SAMPLE_ADDR;
}
+ if (etm->synth_opts.callchain)
+ attr.sample_type |= PERF_SAMPLE_CALLCHAIN;
if (etm->synth_opts.last_branch)
attr.sample_type |= PERF_SAMPLE_BRANCH_STACK;
@@ -1397,6 +1456,9 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
tidq->period_instructions = instrs_over;
}
+ if (tidq->prev_packet->last_instr_taken_branch)
+ cs_etm__add_stack_event(etmq, tidq);
+
if (etm->sample_branches) {
bool generate_sample = false;
@@ -2596,7 +2658,17 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
} else {
itrace_synth_opts__set_default(&etm->synth_opts,
session->itrace_synth_opts->default_no_sample);
- etm->synth_opts.callchain = false;
+
+ etm->synth_opts.thread_stack =
+ session->itrace_synth_opts->thread_stack;
+ }
+
+ if (etm->synth_opts.callchain && !symbol_conf.use_callchain) {
+ symbol_conf.use_callchain = true;
+ if (callchain_register_param(&callchain_param) < 0) {
+ symbol_conf.use_callchain = false;
+ etm->synth_opts.callchain = false;
+ }
}
err = cs_etm__synth_events(etm, session);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 3/3] perf cs-etm: Correct the packet usage for instruction sample
From: Leo Yan @ 2019-08-30 6:24 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Mathieu Poirier, Suzuki K Poulose,
Alexander Shishkin, Jiri Olsa, Namhyung Kim, linux-arm-kernel,
linux-kernel, Mike Leach, Robert Walker, Adrian Hunter
Cc: Leo Yan
In-Reply-To: <20190830062421.31275-1-leo.yan@linaro.org>
It uses 'tidq->packet' rather than 'tidq->prev_packet' to generate
instruction sample, comparing against the thread stack and the branch
samples which are using the 'tidp->prev_packet', thus this leads the
instruction sample to use one ahead packet than thread stack and branch
samples.
As result, the instruction's call chain can be wrongly displayed as
below:
main 1579 100 instructions:
ffff000010214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
ffff000010214850 perf_event_update_userpage+0x48 ([kernel.kallsyms])
ffff000010219360 perf_swevent_add+0x88 ([kernel.kallsyms])
ffff0000102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
In this log, the continuous two lines includes two functions, the up
line contains the child function info and the bottom line contains
its parent function, and so forth. But if review the first two lines:
perf_event_update_userpage+0x4c => the sampled instruction
perf_event_update_userpage+0x48 => the parent function's calling
The child function and parent function is the same function
perf_event_update_userpage(), but perf_event_update_userpage() isn't
a recursive function, thus this calling sequence shouldn't never happen.
This is caused by the instruction sample using the 'tidq->packet', but
this packet is not handled yet by thread stack, the thread stack is
delayed to handle one return packet for stack popping.
To fix this issue, we can simply to use 'tidq->prev_packet' to generate
the instruction sample, this allows the thread stack to push/pop
properly for instruction sample. Finally, we can get below result:
main 1579 100 instructions:
ffff000010214854 perf_event_update_userpage+0x4c ([kernel.kallsyms])
ffff000010219360 perf_swevent_add+0x88 ([kernel.kallsyms])
ffff0000102135f4 event_sched_in.isra.57+0xbc ([kernel.kallsyms])
ffff0000102137a0 group_sched_in+0x60 ([kernel.kallsyms])
ffff000010213b84 flexible_sched_in+0xfc ([kernel.kallsyms])
ffff00001020c0b4 visit_groups_merge+0x12c ([kernel.kallsyms])
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index ad573d3bd305..0bd2b3c48394 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1414,7 +1414,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
struct cs_etm_packet *tmp;
int ret;
u8 trace_chan_id = tidq->trace_chan_id;
- u64 instrs_executed = tidq->packet->instr_count;
+ u64 instrs_executed = tidq->prev_packet->instr_count;
tidq->period_instructions += instrs_executed;
@@ -1445,7 +1445,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
*/
u64 offset = (instrs_executed - instrs_over - 1);
u64 addr = cs_etm__instr_addr(etmq, trace_chan_id,
- tidq->packet, offset);
+ tidq->prev_packet, offset);
ret = cs_etm__synth_instruction_sample(
etmq, tidq, addr, etm->instructions_sample_period);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5, 27/32] drm/mediatek: add connection from RDMA1 to DSI0
From: CK Hu @ 2019-08-30 6:25 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-28-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from RDMA1 to DSI0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 03a46ec..aa6173b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -175,6 +175,7 @@ struct mtk_mmsys_reg_data {
> u32 rdma0_sout_color0;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dpi0;
> + u32 rdma1_sout_dsi0;
> u32 dpi0_sel_in;
> u32 dpi0_sel_in_rdma1;
> u32 dsi0_sel_in;
> @@ -433,6 +434,9 @@ static unsigned int mtk_ddp_sout_sel(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
> *addr = data->rdma0_sout_sel_in;
> value = data->rdma0_sout_color0;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> + *addr = data->rdma1_sout_sel_in;
> + value = data->rdma1_sout_dsi0;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-08-30 6:28 UTC (permalink / raw)
To: Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY2tRjazjaogpM7irqgTD+PdwsfqCxk5hP-_czrET3V5xQ@mail.gmail.com>
Hi Jassi,
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Tue, Aug 27, 2019 at 10:02 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to
> > trigger actions in software layers running in the EL2 or EL3 exception levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../devicetree/bindings/mailbox/arm-smc.yaml | 125
> +++++++++++++++++++++
> > 1 file changed, 125 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index 000000000000..f8eb28d5e307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23&data=02%7
> C01%7Cp
> >
> +eng.fan%40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d
> 3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C1%7C637027415448196145&sdata=xd
> nUObNqlRF
> > +lu8NiXSuc35fYrHIzR%2Fyak6IzW05Q3nA%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=02%7C01%7Cpe
> ng.fan%
> >
> +40nxp.com%7C8aa671dfa4d04ba003b508d72d0f297f%7C686ea1d3bc2b4c6
> fa92cd9
> >
> +9c5c301635%7C0%7C1%7C637027415448196145&sdata=wl%2Fdg09
> QMS%2FoHgI
> > +yD7ZBNpoIGXYxfFDRWhyYHogFd6A%3D&reserved=0
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +description: |
> > + This mailbox uses the ARM smc (secure monitor call) and hvc
> > +(hypervisor
> > + call) instruction to trigger a mailbox-connected activity in
> > +firmware,
> > + executing on the very same core as the caller. By nature this
> > +operation
> > + is synchronous and this mailbox provides no way for asynchronous
> > +messages
> > + to be delivered the other way round, from firmware to the OS, but
> > + asynchronous notification could also be supported. However the
> > +value of
> > + r0/w0/x0 the firmware returns after the smc call is delivered as a
> > +received
> > + message to the mailbox framework, so a synchronous communication
> > +can be
> > + established, for a asynchronous notification, no value will be returned.
> > + The exact meaning of both the action the mailbox triggers as well
> > +as the
> > + return value is defined by their users and is not subject to this binding.
> > +
> > + One use case of this mailbox is the SCMI interface, which uses
> > + shared memory to transfer commands and parameters, and a mailbox
> to
> > + trigger a function call. This allows SoCs without a separate
> > + management processor (or when such a processor is not available or
> > + used) to use this standardized interface anyway.
> > +
> > + This binding describes no hardware, but establishes a firmware
> interface.
> > + Upon receiving an SMC using one of the described SMC function
> > + identifiers, the firmware is expected to trigger some mailbox connected
> functionality.
> > + The communication follows the ARM SMC calling convention.
> > + Firmware expects an SMC function identifier in r0 or w0. The
> > + supported identifiers are passed from consumers, or listed in the
> > + the arm,func-ids properties as described below. The firmware can
> > + return one value in the first SMC result register, it is expected
> > + to be an error value, which shall be propagated to the mailbox client.
> > +
> > + Any core which supports the SMC or HVC instruction can be used, as
> > + long as a firmware component running in EL3 or EL2 is handling these
> calls.
> > +
> > +properties:
> > + compatible:
> > + const: arm,smc-mbox
> > +
> > + "#mbox-cells":
> > + const: 1
> > +
> > + arm,num-chans:
> > + description: The number of channels supported.
> > + items:
> > + minimum: 1
> > + maximum: 4096 # Should be enough?
> > +
> > + method:
> > + - enum:
> > + - smc
> > + - hvc
> > +
> > + transports:
> > + - enum:
> > + - mem
> > + - reg
> > +
> > + arm,func-ids:
> > + description: |
> > + An array of 32-bit values specifying the function IDs used by each
> > + mailbox channel. Those function IDs follow the ARM SMC calling
> > + convention standard [1].
> > +
> > + There is one identifier per channel and the number of supported
> > + channels is determined by the length of this array.
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > + minItems: 0
> > + maxItems: 4096 # Should be enough?
> > +
> > +required:
> > + - compatible
> > + - "#mbox-cells"
> > + - arm,num-chans
> > + - transports
> > + - method
> > +
> > +examples:
> > + - |
> > + sram@910000 {
> > + compatible = "mmio-sram";
> > + reg = <0x0 0x93f000 0x0 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x0 0x93f000 0x1000>;
> > +
> > + cpu_scp_lpri: scp-shmem@0 {
> > + compatible = "arm,scmi-shmem";
> > + reg = <0x0 0x200>;
> > + };
> > +
> > + cpu_scp_hpri: scp-shmem@200 {
> > + compatible = "arm,scmi-shmem";
> > + reg = <0x200 0x200>;
> > + };
> > + };
> > +
> > + firmware {
> > + smc_mbox: mailbox {
> > + #mbox-cells = <1>;
> > + compatible = "arm,smc-mbox";
> > + method = "smc";
> > + arm,num-chans = <0x2>;
> > + transports = "mem";
> > + /* Optional */
> > + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> >
> SMC/HVC is synchronously(block) running in "secure mode", i.e, there can
> only be one instance running platform wide. Right?
I think there could be channel for TEE, and channel for Linux.
For virtualization case, there could be dedicated channel for each VM.
That implies there is only
> one physical channel in the platform.
I don't think so, TEE/Linux should use different physical channels,
i.e, SRAM memory partitioned using TZASC.
So if you need to initiate different
> functions (tx, rx), you call them sequentially by changing the func-id for each
> request. Why not?
I could not follow you clearly. Could you please share more details?
Thanks,
Peng.
>
> -Jassi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* cleanup vmap usage in the dma-mapping layer
From: Christoph Hellwig @ 2019-08-30 6:29 UTC (permalink / raw)
To: iommu
Cc: linux-xtensa, linux-kernel, Russell King, linux-mm, Robin Murphy,
linux-arm-kernel
Hi all,
the common DMA remapping code uses the vmalloc/vmap code to create
page table entries for DMA mappings. This series lifts the currently
arm specific VM_* flag for that into common code, and also exposes
it to userspace in procfs to better understand the mappings.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] vmalloc: lift the arm flag for coherent mappings to common code
From: Christoph Hellwig @ 2019-08-30 6:29 UTC (permalink / raw)
To: iommu
Cc: linux-xtensa, linux-kernel, Russell King, linux-mm, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190830062924.21714-1-hch@lst.de>
The arm architecture had a VM_ARM_DMA_CONSISTENT flag to mark DMA
coherent remapping for a while. Lift this flag to common code so
that we can use it generically. We also check it in the only place
VM_USERMAP is directly check so that we can entirely replace that
flag as well (although I'm not even sure why we'd want to allow
remapping DMA appings, but I'd rather not change behavior).
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 22 +++++++---------------
arch/arm/mm/mm.h | 3 ---
include/linux/vmalloc.h | 2 ++
mm/vmalloc.c | 5 ++++-
4 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index d42557ee69c2..5c0af4a2faa7 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -340,19 +340,13 @@ static void *
__dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
{
- /*
- * DMA allocation can be mapped to user space, so lets
- * set VM_USERMAP flags too.
- */
- return dma_common_contiguous_remap(page, size,
- VM_ARM_DMA_CONSISTENT | VM_USERMAP,
+ return dma_common_contiguous_remap(page, size, VM_DMA_COHERENT,
prot, caller);
}
static void __dma_free_remap(void *cpu_addr, size_t size)
{
- dma_common_free_remap(cpu_addr, size,
- VM_ARM_DMA_CONSISTENT | VM_USERMAP);
+ dma_common_free_remap(cpu_addr, size, VM_DMA_COHERENT);
}
#define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
@@ -1379,8 +1373,8 @@ static void *
__iommu_alloc_remap(struct page **pages, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
{
- return dma_common_pages_remap(pages, size,
- VM_ARM_DMA_CONSISTENT | VM_USERMAP, prot, caller);
+ return dma_common_pages_remap(pages, size, VM_DMA_COHERENT, prot,
+ caller);
}
/*
@@ -1464,7 +1458,7 @@ static struct page **__iommu_get_pages(void *cpu_addr, unsigned long attrs)
return cpu_addr;
area = find_vm_area(cpu_addr);
- if (area && (area->flags & VM_ARM_DMA_CONSISTENT))
+ if (area && (area->flags & VM_DMA_COHERENT))
return area->pages;
return NULL;
}
@@ -1622,10 +1616,8 @@ void __arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
return;
}
- if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0) {
- dma_common_free_remap(cpu_addr, size,
- VM_ARM_DMA_CONSISTENT | VM_USERMAP);
- }
+ if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0)
+ dma_common_free_remap(cpu_addr, size, VM_DMA_COHERENT);
__iommu_remove_mapping(dev, handle, size);
__iommu_free_buffer(dev, pages, size, attrs);
diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
index 941356d95a67..88c121ac14b3 100644
--- a/arch/arm/mm/mm.h
+++ b/arch/arm/mm/mm.h
@@ -70,9 +70,6 @@ extern void __flush_dcache_page(struct address_space *mapping, struct page *page
#define VM_ARM_MTYPE(mt) ((mt) << 20)
#define VM_ARM_MTYPE_MASK (0x1f << 20)
-/* consistent regions used by dma_alloc_attrs() */
-#define VM_ARM_DMA_CONSISTENT 0x20000000
-
struct static_vm {
struct vm_struct vm;
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 9b21d0047710..dfa718ffdd4f 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -18,6 +18,7 @@ struct notifier_block; /* in notifier.h */
#define VM_ALLOC 0x00000002 /* vmalloc() */
#define VM_MAP 0x00000004 /* vmap()ed pages */
#define VM_USERMAP 0x00000008 /* suitable for remap_vmalloc_range */
+#define VM_DMA_COHERENT 0x00000010 /* dma_alloc_coherent */
#define VM_UNINITIALIZED 0x00000020 /* vm_struct is not fully initialized */
#define VM_NO_GUARD 0x00000040 /* don't add guard page */
#define VM_KASAN 0x00000080 /* has allocated kasan shadow memory */
@@ -26,6 +27,7 @@ struct notifier_block; /* in notifier.h */
* vfree_atomic().
*/
#define VM_FLUSH_RESET_PERMS 0x00000100 /* Reset direct map and flush TLB on unmap */
+
/* bits [20..32] reserved for arch specific ioremap internals */
/*
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 7ba11e12a11f..c1246d77cf75 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2993,7 +2993,7 @@ int remap_vmalloc_range_partial(struct vm_area_struct *vma, unsigned long uaddr,
if (!area)
return -EINVAL;
- if (!(area->flags & VM_USERMAP))
+ if (!(area->flags & (VM_USERMAP | VM_DMA_COHERENT)))
return -EINVAL;
if (kaddr + size > area->addr + get_vm_area_size(area))
@@ -3496,6 +3496,9 @@ static int s_show(struct seq_file *m, void *p)
if (v->flags & VM_USERMAP)
seq_puts(m, " user");
+ if (v->flags & VM_DMA_COHERENT)
+ seq_puts(m, " dma-coherent");
+
if (is_vmalloc_addr(v->pages))
seq_puts(m, " vpages");
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] dma-mapping: always use VM_DMA_COHERENT for generic DMA remap
From: Christoph Hellwig @ 2019-08-30 6:29 UTC (permalink / raw)
To: iommu
Cc: linux-xtensa, linux-kernel, Russell King, linux-mm, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190830062924.21714-1-hch@lst.de>
Currently the generic dma remap allocator gets a vm_flags passed by
the caller that is a little confusing. We just introduced a generic
vmalloc-level flag to identify the dma coherent allocations, so use
that everywhere and remove the now pointless argument.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 10 ++++------
arch/xtensa/kernel/pci-dma.c | 4 ++--
drivers/iommu/dma-iommu.c | 6 +++---
include/linux/dma-mapping.h | 6 ++----
kernel/dma/remap.c | 25 +++++++++++--------------
5 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 5c0af4a2faa7..054a66f725b3 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -340,13 +340,12 @@ static void *
__dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
{
- return dma_common_contiguous_remap(page, size, VM_DMA_COHERENT,
- prot, caller);
+ return dma_common_contiguous_remap(page, size, prot, caller);
}
static void __dma_free_remap(void *cpu_addr, size_t size)
{
- dma_common_free_remap(cpu_addr, size, VM_DMA_COHERENT);
+ dma_common_free_remap(cpu_addr, size);
}
#define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
@@ -1373,8 +1372,7 @@ static void *
__iommu_alloc_remap(struct page **pages, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
{
- return dma_common_pages_remap(pages, size, VM_DMA_COHERENT, prot,
- caller);
+ return dma_common_pages_remap(pages, size, prot, caller);
}
/*
@@ -1617,7 +1615,7 @@ void __arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
}
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0)
- dma_common_free_remap(cpu_addr, size, VM_DMA_COHERENT);
+ dma_common_free_remap(cpu_addr, size);
__iommu_remove_mapping(dev, handle, size);
__iommu_free_buffer(dev, pages, size, attrs);
diff --git a/arch/xtensa/kernel/pci-dma.c b/arch/xtensa/kernel/pci-dma.c
index 65f05776d827..154979d62b73 100644
--- a/arch/xtensa/kernel/pci-dma.c
+++ b/arch/xtensa/kernel/pci-dma.c
@@ -167,7 +167,7 @@ void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
if (PageHighMem(page)) {
void *p;
- p = dma_common_contiguous_remap(page, size, VM_MAP,
+ p = dma_common_contiguous_remap(page, size,
pgprot_noncached(PAGE_KERNEL),
__builtin_return_address(0));
if (!p) {
@@ -192,7 +192,7 @@ void arch_dma_free(struct device *dev, size_t size, void *vaddr,
page = virt_to_page(platform_vaddr_to_cached(vaddr));
} else {
#ifdef CONFIG_MMU
- dma_common_free_remap(vaddr, size, VM_MAP);
+ dma_common_free_remap(vaddr, size);
#endif
page = pfn_to_page(PHYS_PFN(dma_to_phys(dev, dma_handle)));
}
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index f68a62c3c32b..013416f5ad38 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -617,7 +617,7 @@ static void *iommu_dma_alloc_remap(struct device *dev, size_t size,
< size)
goto out_free_sg;
- vaddr = dma_common_pages_remap(pages, size, VM_USERMAP, prot,
+ vaddr = dma_common_pages_remap(pages, size, prot,
__builtin_return_address(0));
if (!vaddr)
goto out_unmap;
@@ -941,7 +941,7 @@ static void __iommu_dma_free(struct device *dev, size_t size, void *cpu_addr)
pages = __iommu_dma_get_pages(cpu_addr);
if (!pages)
page = vmalloc_to_page(cpu_addr);
- dma_common_free_remap(cpu_addr, alloc_size, VM_USERMAP);
+ dma_common_free_remap(cpu_addr, alloc_size);
} else {
/* Lowmem means a coherent atomic or CMA allocation */
page = virt_to_page(cpu_addr);
@@ -979,7 +979,7 @@ static void *iommu_dma_alloc_pages(struct device *dev, size_t size,
pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
cpu_addr = dma_common_contiguous_remap(page, alloc_size,
- VM_USERMAP, prot, __builtin_return_address(0));
+ prot, __builtin_return_address(0));
if (!cpu_addr)
goto out_free_pages;
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..c9725390fbbc 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -616,13 +616,11 @@ extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
unsigned long attrs);
void *dma_common_contiguous_remap(struct page *page, size_t size,
- unsigned long vm_flags,
pgprot_t prot, const void *caller);
void *dma_common_pages_remap(struct page **pages, size_t size,
- unsigned long vm_flags, pgprot_t prot,
- const void *caller);
-void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags);
+ pgprot_t prot, const void *caller);
+void dma_common_free_remap(void *cpu_addr, size_t size);
int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot);
bool dma_in_atomic_pool(void *start, size_t size);
diff --git a/kernel/dma/remap.c b/kernel/dma/remap.c
index ffe78f0b2fe4..01d4ef5685a4 100644
--- a/kernel/dma/remap.c
+++ b/kernel/dma/remap.c
@@ -12,12 +12,11 @@
#include <linux/vmalloc.h>
static struct vm_struct *__dma_common_pages_remap(struct page **pages,
- size_t size, unsigned long vm_flags, pgprot_t prot,
- const void *caller)
+ size_t size, pgprot_t prot, const void *caller)
{
struct vm_struct *area;
- area = get_vm_area_caller(size, vm_flags, caller);
+ area = get_vm_area_caller(size, VM_DMA_COHERENT, caller);
if (!area)
return NULL;
@@ -34,12 +33,11 @@ static struct vm_struct *__dma_common_pages_remap(struct page **pages,
* Cannot be used in non-sleeping contexts
*/
void *dma_common_pages_remap(struct page **pages, size_t size,
- unsigned long vm_flags, pgprot_t prot,
- const void *caller)
+ pgprot_t prot, const void *caller)
{
struct vm_struct *area;
- area = __dma_common_pages_remap(pages, size, vm_flags, prot, caller);
+ area = __dma_common_pages_remap(pages, size, prot, caller);
if (!area)
return NULL;
@@ -53,7 +51,6 @@ void *dma_common_pages_remap(struct page **pages, size_t size,
* Cannot be used in non-sleeping contexts
*/
void *dma_common_contiguous_remap(struct page *page, size_t size,
- unsigned long vm_flags,
pgprot_t prot, const void *caller)
{
int i;
@@ -67,7 +64,7 @@ void *dma_common_contiguous_remap(struct page *page, size_t size,
for (i = 0; i < (size >> PAGE_SHIFT); i++)
pages[i] = nth_page(page, i);
- area = __dma_common_pages_remap(pages, size, vm_flags, prot, caller);
+ area = __dma_common_pages_remap(pages, size, prot, caller);
kfree(pages);
@@ -79,11 +76,11 @@ void *dma_common_contiguous_remap(struct page *page, size_t size,
/*
* Unmaps a range previously mapped by dma_common_*_remap
*/
-void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
+void dma_common_free_remap(void *cpu_addr, size_t size)
{
struct vm_struct *area = find_vm_area(cpu_addr);
- if (!area || (area->flags & vm_flags) != vm_flags) {
+ if (!area || area->flags != VM_DMA_COHERENT) {
WARN(1, "trying to free invalid coherent area: %p\n", cpu_addr);
return;
}
@@ -127,8 +124,8 @@ int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
if (!atomic_pool)
goto free_page;
- addr = dma_common_contiguous_remap(page, atomic_pool_size, VM_USERMAP,
- prot, __builtin_return_address(0));
+ addr = dma_common_contiguous_remap(page, atomic_pool_size, prot,
+ __builtin_return_address(0));
if (!addr)
goto destroy_genpool;
@@ -143,7 +140,7 @@ int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
return 0;
remove_mapping:
- dma_common_free_remap(addr, atomic_pool_size, VM_USERMAP);
+ dma_common_free_remap(addr, atomic_pool_size);
destroy_genpool:
gen_pool_destroy(atomic_pool);
atomic_pool = NULL;
@@ -217,7 +214,7 @@ void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
arch_dma_prep_coherent(page, size);
/* create a coherent mapping */
- ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
+ ret = dma_common_contiguous_remap(page, size,
dma_pgprot(dev, PAGE_KERNEL, attrs),
__builtin_return_address(0));
if (!ret) {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] dma-mapping: introduce a dma_common_find_pages helper
From: Christoph Hellwig @ 2019-08-30 6:29 UTC (permalink / raw)
To: iommu
Cc: linux-xtensa, linux-kernel, Russell King, linux-mm, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190830062924.21714-1-hch@lst.de>
A helper to find the backing page array based on a virtual address.
This also ensures we do the same vm_flags check everywhere instead
of slightly different or missing ones in a few places.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 7 +------
drivers/iommu/dma-iommu.c | 15 +++------------
include/linux/dma-mapping.h | 1 +
kernel/dma/remap.c | 13 +++++++++++--
4 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 054a66f725b3..d07e5c865557 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1447,18 +1447,13 @@ static struct page **__atomic_get_pages(void *addr)
static struct page **__iommu_get_pages(void *cpu_addr, unsigned long attrs)
{
- struct vm_struct *area;
-
if (__in_atomic_pool(cpu_addr, PAGE_SIZE))
return __atomic_get_pages(cpu_addr);
if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
return cpu_addr;
- area = find_vm_area(cpu_addr);
- if (area && (area->flags & VM_DMA_COHERENT))
- return area->pages;
- return NULL;
+ return dma_common_find_pages(cpu_addr);
}
static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 013416f5ad38..eafc378da448 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -541,15 +541,6 @@ static struct page **__iommu_dma_alloc_pages(struct device *dev,
return pages;
}
-static struct page **__iommu_dma_get_pages(void *cpu_addr)
-{
- struct vm_struct *area = find_vm_area(cpu_addr);
-
- if (!area || !area->pages)
- return NULL;
- return area->pages;
-}
-
/**
* iommu_dma_alloc_remap - Allocate and map a buffer contiguous in IOVA space
* @dev: Device to allocate memory for. Must be a real device
@@ -938,7 +929,7 @@ static void __iommu_dma_free(struct device *dev, size_t size, void *cpu_addr)
* If it the address is remapped, then it's either non-coherent
* or highmem CMA, or an iommu_dma_alloc_remap() construction.
*/
- pages = __iommu_dma_get_pages(cpu_addr);
+ pages = dma_common_find_pages(cpu_addr);
if (!pages)
page = vmalloc_to_page(cpu_addr);
dma_common_free_remap(cpu_addr, alloc_size);
@@ -1045,7 +1036,7 @@ static int iommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
return -ENXIO;
if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) {
- struct page **pages = __iommu_dma_get_pages(cpu_addr);
+ struct page **pages = dma_common_find_pages(cpu_addr);
if (pages)
return __iommu_dma_mmap(pages, size, vma);
@@ -1067,7 +1058,7 @@ static int iommu_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
int ret;
if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) {
- struct page **pages = __iommu_dma_get_pages(cpu_addr);
+ struct page **pages = dma_common_find_pages(cpu_addr);
if (pages) {
return sg_alloc_table_from_pages(sgt, pages,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c9725390fbbc..e4840f40ae69 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -615,6 +615,7 @@ extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs);
+struct page **dma_common_find_pages(void *cpu_addr);
void *dma_common_contiguous_remap(struct page *page, size_t size,
pgprot_t prot, const void *caller);
diff --git a/kernel/dma/remap.c b/kernel/dma/remap.c
index 01d4ef5685a4..3482fc585c59 100644
--- a/kernel/dma/remap.c
+++ b/kernel/dma/remap.c
@@ -11,6 +11,15 @@
#include <linux/slab.h>
#include <linux/vmalloc.h>
+struct page **dma_common_find_pages(void *cpu_addr)
+{
+ struct vm_struct *area = find_vm_area(cpu_addr);
+
+ if (!area || area->flags != VM_DMA_COHERENT)
+ return NULL;
+ return area->pages;
+}
+
static struct vm_struct *__dma_common_pages_remap(struct page **pages,
size_t size, pgprot_t prot, const void *caller)
{
@@ -78,9 +87,9 @@ void *dma_common_contiguous_remap(struct page *page, size_t size,
*/
void dma_common_free_remap(void *cpu_addr, size_t size)
{
- struct vm_struct *area = find_vm_area(cpu_addr);
+ struct page **pages = dma_common_find_pages(cpu_addr);
- if (!area || area->flags != VM_DMA_COHERENT) {
+ if (!pages) {
WARN(1, "trying to free invalid coherent area: %p\n", cpu_addr);
return;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] arm: remove wrappers for the generic dma remap helpers
From: Christoph Hellwig @ 2019-08-30 6:29 UTC (permalink / raw)
To: iommu
Cc: linux-xtensa, linux-kernel, Russell King, linux-mm, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190830062924.21714-1-hch@lst.de>
Remove a few tiny wrappers around the generic dma remap code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 32 +++++---------------------------
1 file changed, 5 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index d07e5c865557..8cb57f1664b2 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -336,18 +336,6 @@ static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
pgprot_t prot, struct page **ret_page,
const void *caller, bool want_vaddr);
-static void *
-__dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
- const void *caller)
-{
- return dma_common_contiguous_remap(page, size, prot, caller);
-}
-
-static void __dma_free_remap(void *cpu_addr, size_t size)
-{
- dma_common_free_remap(cpu_addr, size);
-}
-
#define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
static struct gen_pool *atomic_pool __ro_after_init;
@@ -503,7 +491,7 @@ static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
if (!want_vaddr)
goto out;
- ptr = __dma_alloc_remap(page, size, gfp, prot, caller);
+ ptr = dma_common_contiguous_remap(page, size, prot, caller);
if (!ptr) {
__dma_free_buffer(page, size);
return NULL;
@@ -570,7 +558,7 @@ static void *__alloc_from_contiguous(struct device *dev, size_t size,
goto out;
if (PageHighMem(page)) {
- ptr = __dma_alloc_remap(page, size, GFP_KERNEL, prot, caller);
+ ptr = dma_common_contiguous_remap(page, size, prot, caller);
if (!ptr) {
dma_release_from_contiguous(dev, page, count);
return NULL;
@@ -590,7 +578,7 @@ static void __free_from_contiguous(struct device *dev, struct page *page,
{
if (want_vaddr) {
if (PageHighMem(page))
- __dma_free_remap(cpu_addr, size);
+ dma_common_free_remap(cpu_addr, size);
else
__dma_remap(page, size, PAGE_KERNEL);
}
@@ -682,7 +670,7 @@ static void *remap_allocator_alloc(struct arm_dma_alloc_args *args,
static void remap_allocator_free(struct arm_dma_free_args *args)
{
if (args->want_vaddr)
- __dma_free_remap(args->cpu_addr, args->size);
+ dma_common_free_remap(args->cpu_addr, args->size);
__dma_free_buffer(args->page, args->size);
}
@@ -1365,16 +1353,6 @@ static int __iommu_free_buffer(struct device *dev, struct page **pages,
return 0;
}
-/*
- * Create a CPU mapping for a specified pages
- */
-static void *
-__iommu_alloc_remap(struct page **pages, size_t size, gfp_t gfp, pgprot_t prot,
- const void *caller)
-{
- return dma_common_pages_remap(pages, size, prot, caller);
-}
-
/*
* Create a mapping in device IO address space for specified pages
*/
@@ -1526,7 +1504,7 @@ static void *__arm_iommu_alloc_attrs(struct device *dev, size_t size,
if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
return pages;
- addr = __iommu_alloc_remap(pages, size, gfp, prot,
+ addr = dma_common_pages_remap(pages, size, prot,
__builtin_return_address(0));
if (!addr)
goto err_mapping;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5, 28/32] drm/mediatek: add connection from OVL_2L0 to RDMA0
From: CK Hu @ 2019-08-30 6:30 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-29-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> this patch add add connection from OVL_2L0 to RDMA0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index aa6173b..943e114 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -33,6 +33,12 @@
> #define DISP_REG_CONFIG_DSI_SEL 0x050
> #define DISP_REG_CONFIG_DPI_SEL 0x064
>
> +#define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
> +#define MT8183_DISP_PATH0_SEL_IN 0xf24
> +
> +#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> +#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
> +
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> #define MT2701_DISP_MUTEX0_SOF0 0x30
>
> @@ -307,6 +313,10 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
> *addr = data->ovl0_mout_en;
> value = OVL0_MOUT_EN_OVL0_2L;
> + } else if (cur == DDP_COMPONENT_OVL_2L0 &&
> + next == DDP_COMPONENT_RDMA0) {
> + *addr = MT8183_DISP_OVL0_2L_MOUT_EN;
> + value = OVL0_2L_MOUT_EN_DISP_PATH0;
> } else {
> value = 0;
> }
> @@ -366,6 +376,10 @@ static unsigned int mtk_ddp_sel_in(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> *addr = DISP_REG_CONFIG_DSI_SEL;
> value = DSI_SEL_IN_BLS;
> + } else if (cur == DDP_COMPONENT_OVL_2L0 &&
> + next == DDP_COMPONENT_RDMA0) {
> + *addr = MT8183_DISP_PATH0_SEL_IN;
> + value = DISP_PATH0_SEL_IN_OVL0_2L;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 29/32] drm/mediatek: add connection from OVL_2L1 to RDMA1
From: CK Hu @ 2019-08-30 6:33 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-30-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from OVL_2L1 to RDMA1
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 943e114..237824f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -34,9 +34,11 @@
> #define DISP_REG_CONFIG_DPI_SEL 0x064
>
> #define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
> +#define MT8183_DISP_OVL1_2L_MOUT_EN 0xf08
> #define MT8183_DISP_PATH0_SEL_IN 0xf24
>
> #define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> +#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
> #define DISP_PATH0_SEL_IN_OVL0_2L 0x1
>
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> @@ -317,6 +319,10 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
> next == DDP_COMPONENT_RDMA0) {
> *addr = MT8183_DISP_OVL0_2L_MOUT_EN;
> value = OVL0_2L_MOUT_EN_DISP_PATH0;
> + } else if (cur == DDP_COMPONENT_OVL_2L1 &&
> + next == DDP_COMPONENT_RDMA1) {
> + *addr = MT8183_DISP_OVL1_2L_MOUT_EN;
> + value = OVL1_2L_MOUT_EN_RDMA1;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 30/32] drm/mediatek: add connection from DITHER0 to DSI0
From: CK Hu @ 2019-08-30 6:34 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-31-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from DITHER0 to DSI0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 237824f..fd38658 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -35,10 +35,12 @@
>
> #define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
> #define MT8183_DISP_OVL1_2L_MOUT_EN 0xf08
> +#define MT8183_DISP_DITHER0_MOUT_EN 0xf0c
> #define MT8183_DISP_PATH0_SEL_IN 0xf24
>
> #define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
> #define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
> +#define DITHER0_MOUT_IN_DSI0 BIT(0)
> #define DISP_PATH0_SEL_IN_OVL0_2L 0x1
>
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> @@ -323,6 +325,9 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
> next == DDP_COMPONENT_RDMA1) {
> *addr = MT8183_DISP_OVL1_2L_MOUT_EN;
> value = OVL1_2L_MOUT_EN_RDMA1;
> + } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
> + *addr = MT8183_DISP_DITHER0_MOUT_EN;
> + value = DITHER0_MOUT_IN_DSI0;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: numa: check the node id before accessing node_to_cpumask_map
From: Yunsheng Lin @ 2019-08-30 6:35 UTC (permalink / raw)
To: Michal Hocko
Cc: tglx, anshuman.khandual, robin.murphy, linuxarm, linux-kernel,
rppt, cai, akpm, will, adobriyan, linux-arm-kernel
In-Reply-To: <20190830055528.GO28313@dhcp22.suse.cz>
On 2019/8/30 13:55, Michal Hocko wrote:
> On Fri 30-08-19 10:26:31, Yunsheng Lin wrote:
>> Some buggy bios may not set the device' numa id, and dev_to_node
>> will return -1, which may cause global-out-of-bounds error
>> detected by KASAN.
>
> Why should we workaround a buggy bios like that? Is it so widespread and
> no BIOS update available? Also, why is this arm64 specific?
For our case, there is BIOS update available. I just thought it might
be better to protect from this case when BIOS has not implemented the
device' numa id setting feature or the feature from BIOS has some bug.
It is not arm64 specific, right now I only have arm64 board. If it is
ok to protect this from the buggy BIOS, maybe all other arch can be
changed too.
>
>> This patch changes cpumask_of_node to return cpu_none_mask if the
>> node is not valid, and sync the cpumask_of_node between the
>> cpumask_of_node function in numa.h and numa.c.
>
> Why?
When CONFIG_DEBUG_PER_CPU_MAPS is defined, the cpumask_of_node() in
numa.c is used, if not, the cpumask_of_node() in numa.h is used.
I am not sure why there is difference between them, and it is there
when since the below commit:
1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
I synced them to keep them consistent whether CONFIG_DEBUG_PER_CPU_MAPS
is defined.
>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>> ---
>> arch/arm64/include/asm/numa.h | 6 ++++++
>> arch/arm64/mm/numa.c | 2 +-
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
>> index 626ad01..da891ed 100644
>> --- a/arch/arm64/include/asm/numa.h
>> +++ b/arch/arm64/include/asm/numa.h
>> @@ -25,6 +25,12 @@ const struct cpumask *cpumask_of_node(int node);
>> /* Returns a pointer to the cpumask of CPUs on Node 'node'. */
>> static inline const struct cpumask *cpumask_of_node(int node)
>> {
>> + if (node >= nr_node_ids || node < 0)
>> + return cpu_none_mask;
>> +
>> + if (!node_to_cpumask_map[node])
>> + return cpu_online_mask;
>> +
>> return node_to_cpumask_map[node];
>> }
>> #endif
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 4f241cc..3846313 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -46,7 +46,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
>> */
>> const struct cpumask *cpumask_of_node(int node)
>> {
>> - if (WARN_ON(node >= nr_node_ids))
>> + if (WARN_ON(node >= nr_node_ids || node < 0))
>> return cpu_none_mask;
>>
>> if (WARN_ON(node_to_cpumask_map[node] == NULL))
>> --
>> 2.8.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 31/32] drm/mediatek: add connection from RDMA0 to DSI0
From: CK Hu @ 2019-08-30 6:36 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-32-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add connection from RDMA0 to DSI0
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index fd38658..6a7cb15 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -42,6 +42,7 @@
> #define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
> #define DITHER0_MOUT_IN_DSI0 BIT(0)
> #define DISP_PATH0_SEL_IN_OVL0_2L 0x1
> +#define DSI0_SEL_IN_RDMA0 0x1
>
> #define MT2701_DISP_MUTEX0_MOD0 0x2c
> #define MT2701_DISP_MUTEX0_SOF0 0x30
> @@ -391,6 +392,9 @@ static unsigned int mtk_ddp_sel_in(const struct mtk_mmsys_reg_data *data,
> next == DDP_COMPONENT_RDMA0) {
> *addr = MT8183_DISP_PATH0_SEL_IN;
> value = DISP_PATH0_SEL_IN_OVL0_2L;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI0) {
> + *addr = data->dsi0_sel_in;
> + value = DSI0_SEL_IN_RDMA0;
> } else {
> value = 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 32/32] drm/mediatek: add support for mediatek SOC MT8183
From: CK Hu @ 2019-08-30 6:38 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-33-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +++++++++
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 27 ++++++++++++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 69 ++++++++++++++++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 ++++++++++++++++++++++
> 5 files changed, 161 insertions(+), 1 deletion(-)
>
[snip]
> @@ -613,6 +658,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
> .data = &mt2712_mmsys_driver_data},
> { .compatible = "mediatek,mt8173-mmsys",
> .data = &mt8173_mmsys_driver_data},
> + { .compatible = "mediatek,mt8183-display",
This should be "mediatek,mt8183-mmsys".
Regards,
CK
> + .data = &mt8183_mmsys_driver_data},
> { }
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: numa: check the node id before accessing node_to_cpumask_map
From: Michal Hocko @ 2019-08-30 6:44 UTC (permalink / raw)
To: Yunsheng Lin
Cc: tglx, anshuman.khandual, robin.murphy, linuxarm, linux-kernel,
rppt, cai, akpm, will, adobriyan, linux-arm-kernel
In-Reply-To: <49b86da7-f114-27c2-463a-9bf5082ac197@huawei.com>
On Fri 30-08-19 14:35:26, Yunsheng Lin wrote:
> On 2019/8/30 13:55, Michal Hocko wrote:
> > On Fri 30-08-19 10:26:31, Yunsheng Lin wrote:
> >> Some buggy bios may not set the device' numa id, and dev_to_node
> >> will return -1, which may cause global-out-of-bounds error
> >> detected by KASAN.
> >
> > Why should we workaround a buggy bios like that? Is it so widespread and
> > no BIOS update available? Also, why is this arm64 specific?
>
> For our case, there is BIOS update available. I just thought it might
> be better to protect from this case when BIOS has not implemented the
> device' numa id setting feature or the feature from BIOS has some bug.
>
> It is not arm64 specific, right now I only have arm64 board. If it is
> ok to protect this from the buggy BIOS, maybe all other arch can be
> changed too.
If we are to really care then this should be consistent among
architectures IMHO. But I am not really sure this is really worth it.
The code is quite old and I do not really remember any reports.
> >> This patch changes cpumask_of_node to return cpu_none_mask if the
> >> node is not valid, and sync the cpumask_of_node between the
> >> cpumask_of_node function in numa.h and numa.c.
> >
> > Why?
>
> When CONFIG_DEBUG_PER_CPU_MAPS is defined, the cpumask_of_node() in
> numa.c is used, if not, the cpumask_of_node() in numa.h is used.
>
> I am not sure why there is difference between them, and it is there
> when since the below commit:
> 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
>
> I synced them to keep them consistent whether CONFIG_DEBUG_PER_CPU_MAPS
> is defined.
Such a change should be made in a separate patch with a full
clarification/justification. From the above it is still not clear why
this is needed though.
> >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> >> ---
> >> arch/arm64/include/asm/numa.h | 6 ++++++
> >> arch/arm64/mm/numa.c | 2 +-
> >> 2 files changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> >> index 626ad01..da891ed 100644
> >> --- a/arch/arm64/include/asm/numa.h
> >> +++ b/arch/arm64/include/asm/numa.h
> >> @@ -25,6 +25,12 @@ const struct cpumask *cpumask_of_node(int node);
> >> /* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> >> static inline const struct cpumask *cpumask_of_node(int node)
> >> {
> >> + if (node >= nr_node_ids || node < 0)
> >> + return cpu_none_mask;
> >> +
> >> + if (!node_to_cpumask_map[node])
> >> + return cpu_online_mask;
> >> +
> >> return node_to_cpumask_map[node];
> >> }
> >> #endif
> >> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> >> index 4f241cc..3846313 100644
> >> --- a/arch/arm64/mm/numa.c
> >> +++ b/arch/arm64/mm/numa.c
> >> @@ -46,7 +46,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
> >> */
> >> const struct cpumask *cpumask_of_node(int node)
> >> {
> >> - if (WARN_ON(node >= nr_node_ids))
> >> + if (WARN_ON(node >= nr_node_ids || node < 0))
> >> return cpu_none_mask;
> >>
> >> if (WARN_ON(node_to_cpumask_map[node] == NULL))
> >> --
> >> 2.8.1
> >
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 05/11] soc: ti: omap-prm: sync func clock status with resets
From: Tero Kristo @ 2019-08-30 7:03 UTC (permalink / raw)
To: Philipp Zabel, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1567085114.5345.12.camel@pengutronix.de>
On 29/08/2019 16:25, Philipp Zabel wrote:
> On Wed, 2019-08-28 at 10:19 +0300, Tero Kristo wrote:
>> Hardware reset signals are tightly coupled with associated clocks, and
>> basically de-asserting a reset won't succeed properly if the clock is
>> not enabled, and vice-versa. Also, disabling a clock won't fully succeed
>> if the associated hardware resets are not asserted. Add status sync
>> functionality between these two for TI drivers so that the situations
>> can be handled properly without generating any timeouts.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/soc/ti/omap_prm.c | 36 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>>
>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>> index 38998ce19c71..e876bad8f8d5 100644
>> --- a/drivers/soc/ti/omap_prm.c
>> +++ b/drivers/soc/ti/omap_prm.c
>> @@ -15,6 +15,8 @@
>> #include <linux/platform_device.h>
>> #include <linux/reset-controller.h>
>> #include <linux/delay.h>
>> +#include <linux/clk.h>
>> +#include <linux/clk/ti.h>
>>
>> #include <linux/platform_data/ti-prm.h>
>>
>> @@ -42,7 +44,9 @@ struct omap_reset_data {
>> struct reset_controller_dev rcdev;
>> struct omap_prm *prm;
>> struct clockdomain *clkdm;
>> + struct clk *clk;
>> struct device *dev;
>> + u32 mask;
>> };
>>
>> #define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
>> @@ -102,6 +106,8 @@ static int omap_reset_assert(struct reset_controller_dev *rcdev,
>> v |= 1 << id;
>> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
>>
>> + ti_clk_notify_resets(reset->clk, v == reset->mask);
>> +
>> return 0;
>> }
>>
>> @@ -163,9 +169,19 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>> v &= ~(1 << id);
>> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
>>
>> + ti_clk_notify_resets(reset->clk, v == reset->mask);
>> +
>> if (!has_rstst)
>> goto exit;
>>
>> + /* If associated clock is disabled, we can't poll completion status */
>> + if (reset->clk) {
>> + struct clk_hw *hw = __clk_get_hw(reset->clk);
>> +
>> + if (!clk_hw_is_enabled(hw))
>> + return ret;
>> + }
>> +
>> /* wait for the status to be set */
>> while (1) {
>> v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>> @@ -199,8 +215,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
>> struct omap_prm *prm)
>> {
>> struct omap_reset_data *reset;
>> + const struct omap_rst_map *map;
>> struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
>> char buf[32];
>> + u32 v;
>>
>> /*
>> * Check if we have controllable resets. If either rstctrl is non-zero
>> @@ -215,6 +233,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
>> !pdata->clkdm_allow_idle)
>> return -EINVAL;
>>
>> + map = prm->data->rstmap;
>> + if (!map)
>> + return -EINVAL;
>
> Can this actually happen?
It can, if user writes bad data to the omap_prm_data structs. Without
this check it would make the probe crash which is bad.
>
>> +
>> reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
>> if (!reset)
>> return -ENOMEM;
>> @@ -224,6 +246,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
>> reset->rcdev.of_node = pdev->dev.of_node;
>> reset->rcdev.nr_resets = OMAP_MAX_RESETS;
>> reset->dev = &pdev->dev;
>> + reset->clk = of_clk_get(pdev->dev.of_node, 0);
>> +
>> + if (IS_ERR(reset->clk))
>> + reset->clk = NULL;
>
> Maybe only ignore -ENOENT?
Yeah, I can modify this.
>
>> reset->prm = prm;
>>
>> @@ -234,6 +260,16 @@ static int omap_prm_reset_init(struct platform_device *pdev,
>> if (!reset->clkdm)
>> return -EINVAL;
>>
>> + while (map->rst >= 0) {
>> + reset->mask |= BIT(map->rst);
>> + map++;
>> + }
>
> With this, you could use reset->mask to simplify _is_valid_reset.
True, let me re-write it.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/4] x86: kdump: move reserve_crashkernel_low() into crash_core.c
From: Chen Zhou @ 2019-08-30 7:11 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, james.morse, dyoung, bhsharma
Cc: Chen Zhou, kexec, linux-kernel, horms, guohanjun,
linux-arm-kernel
In-Reply-To: <20190830071200.56169-1-chenzhou10@huawei.com>
In preparation for supporting reserve_crashkernel_low in arm64 as
x86_64 does, move reserve_crashkernel_low() into kernel/crash_core.c.
Note, in arm64, we reserve low memory if and only if crashkernel=X,low
is specified. Different with x86_64, don't set low memory automatically.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
---
arch/x86/include/asm/kexec.h | 3 ++
arch/x86/kernel/setup.c | 65 ++++----------------------------------------
include/linux/crash_core.h | 4 +++
include/linux/kexec.h | 1 -
kernel/crash_core.c | 65 ++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 78 insertions(+), 60 deletions(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 5e7d6b4..bf21d6c 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -18,6 +18,9 @@
# define KEXEC_CONTROL_CODE_MAX_SIZE 2048
+/* 16M alignment for crash kernel regions */
+#define CRASH_ALIGN SZ_16M
+
#ifndef __ASSEMBLY__
#include <linux/string.h>
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index bbe35bf..2b437c4 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -449,9 +449,6 @@ static void __init memblock_x86_reserve_range_setup_data(void)
#ifdef CONFIG_KEXEC_CORE
-/* 16M alignment for crash kernel regions */
-#define CRASH_ALIGN SZ_16M
-
/*
* Keep the crash kernel below this limit.
*
@@ -473,59 +470,6 @@ static void __init memblock_x86_reserve_range_setup_data(void)
# define CRASH_ADDR_HIGH_MAX SZ_64T
#endif
-static int __init reserve_crashkernel_low(void)
-{
-#ifdef CONFIG_X86_64
- unsigned long long base, low_base = 0, low_size = 0;
- unsigned long total_low_mem;
- int ret;
-
- total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
-
- /* crashkernel=Y,low */
- ret = parse_crashkernel_low(boot_command_line, total_low_mem, &low_size, &base);
- if (ret) {
- /*
- * two parts from lib/swiotlb.c:
- * -swiotlb size: user-specified with swiotlb= or default.
- *
- * -swiotlb overflow buffer: now hardcoded to 32k. We round it
- * to 8M for other buffers that may need to stay low too. Also
- * make sure we allocate enough extra low memory so that we
- * don't run out of DMA buffers for 32-bit devices.
- */
- low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20);
- } else {
- /* passed with crashkernel=0,low ? */
- if (!low_size)
- return 0;
- }
-
- low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
- if (!low_base) {
- pr_err("Cannot reserve %ldMB crashkernel low memory, please try smaller size.\n",
- (unsigned long)(low_size >> 20));
- return -ENOMEM;
- }
-
- ret = memblock_reserve(low_base, low_size);
- if (ret) {
- pr_err("%s: Error reserving crashkernel low memblock.\n", __func__);
- return ret;
- }
-
- pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System low RAM: %ldMB)\n",
- (unsigned long)(low_size >> 20),
- (unsigned long)(low_base >> 20),
- (unsigned long)(total_low_mem >> 20));
-
- crashk_low_res.start = low_base;
- crashk_low_res.end = low_base + low_size - 1;
- insert_resource(&iomem_resource, &crashk_low_res);
-#endif
- return 0;
-}
-
static void __init reserve_crashkernel(void)
{
unsigned long long crash_size, crash_base, total_mem;
@@ -589,9 +533,12 @@ static void __init reserve_crashkernel(void)
return;
}
- if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
- memblock_free(crash_base, crash_size);
- return;
+ if (crash_base >= (1ULL << 32)) {
+ if (reserve_crashkernel_low()) {
+ memblock_free(crash_base, crash_size);
+ return;
+ }
+ insert_resource(&iomem_resource, &crashk_low_res);
}
pr_info("Reserving %ldMB of memory at %ldMB for crashkernel (System RAM: %ldMB)\n",
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 525510a..9192e43 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -6,6 +6,8 @@
#include <linux/elfcore.h>
#include <linux/elf.h>
+#include <asm/kexec.h>
+
#define CRASH_CORE_NOTE_NAME "CORE"
#define CRASH_CORE_NOTE_HEAD_BYTES ALIGN(sizeof(struct elf_note), 4)
#define CRASH_CORE_NOTE_NAME_BYTES ALIGN(sizeof(CRASH_CORE_NOTE_NAME), 4)
@@ -63,6 +65,7 @@ phys_addr_t paddr_vmcoreinfo_note(void);
extern unsigned char *vmcoreinfo_data;
extern size_t vmcoreinfo_size;
extern u32 *vmcoreinfo_note;
+extern struct resource crashk_low_res;
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
@@ -74,5 +77,6 @@ int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
+int __init reserve_crashkernel_low(void);
#endif /* LINUX_CRASH_CORE_H */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index b9b1bc5..62330aa 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -306,7 +306,6 @@ extern int kexec_load_disabled;
/* Location of a reserved region to hold the crash kernel.
*/
extern struct resource crashk_res;
-extern struct resource crashk_low_res;
extern note_buf_t __percpu *crash_notes;
/* flag to track if kexec reboot is in progress */
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 9f1557b..13cdf35 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -7,6 +7,8 @@
#include <linux/crash_core.h>
#include <linux/utsname.h>
#include <linux/vmalloc.h>
+#include <linux/memblock.h>
+#include <linux/swiotlb.h>
#include <asm/page.h>
#include <asm/sections.h>
@@ -292,6 +294,69 @@ int __init parse_crashkernel_low(char *cmdline,
"crashkernel=", suffix_tbl[SUFFIX_LOW]);
}
+int __init reserve_crashkernel_low(void)
+{
+#if defined(CONFIG_X86_64) || defined(CONFIG_ARM64)
+ unsigned long long base, low_base = 0, low_size = 0;
+ unsigned long total_low_mem;
+ int ret;
+
+ total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
+
+ /* crashkernel=Y,low */
+ ret = parse_crashkernel_low(boot_command_line, total_low_mem, &low_size,
+ &base);
+ if (ret) {
+#ifdef CONFIG_X86_64
+ /*
+ * two parts from lib/swiotlb.c:
+ * -swiotlb size: user-specified with swiotlb= or default.
+ *
+ * -swiotlb overflow buffer: now hardcoded to 32k. We round it
+ * to 8M for other buffers that may need to stay low too. Also
+ * make sure we allocate enough extra low memory so that we
+ * don't run out of DMA buffers for 32-bit devices.
+ */
+ low_size = max(swiotlb_size_or_default() + (8UL << 20),
+ 256UL << 20);
+#else
+ /*
+ * in arm64, reserve low memory if and only if crashkernel=X,low
+ * specified.
+ */
+ return -EINVAL;
+#endif
+ } else {
+ /* passed with crashkernel=0,low ? */
+ if (!low_size)
+ return 0;
+ }
+
+ low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
+ if (!low_base) {
+ pr_err("Cannot reserve %ldMB crashkernel low memory, please try smaller size.\n",
+ (unsigned long)(low_size >> 20));
+ return -ENOMEM;
+ }
+
+ ret = memblock_reserve(low_base, low_size);
+ if (ret) {
+ pr_err("%s: Error reserving crashkernel low memblock.\n",
+ __func__);
+ return ret;
+ }
+
+ pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System low RAM: %ldMB)\n",
+ (unsigned long)(low_size >> 20),
+ (unsigned long)(low_base >> 20),
+ (unsigned long)(total_low_mem >> 20));
+
+ crashk_low_res.start = low_base;
+ crashk_low_res.end = low_base + low_size - 1;
+#endif
+ return 0;
+}
+
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len)
{
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 0/4] support reserving crashkernel above 4G on arm64 kdump
From: Chen Zhou @ 2019-08-30 7:11 UTC (permalink / raw)
To: tglx, mingo, catalin.marinas, will, james.morse, dyoung, bhsharma
Cc: Chen Zhou, kexec, linux-kernel, horms, guohanjun,
linux-arm-kernel
I am busy with other things, so it was a long time before this version was
released.
This patch series enable reserving crashkernel above 4G in arm64.
There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
will boot failure because there is no low memory available for allocation.
To solve these issues, introduce crashkernel=X,low to reserve specified
size low memory.
Crashkernel=X tries to reserve memory for the crash dump kernel under
4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
size low memory for crash kdump kernel devices firstly and then reserve
memory above 4G.
When crashkernel is reserved above 4G in memory, that is, crashkernel=X,low
is specified simultaneously, kernel should reserve specified size low memory
for crash dump kernel devices. So there may be two crash kernel regions, one
is below 4G, the other is above 4G.
In order to distinct from the high region and make no effect to the use of
kexec-tools, rename the low region as "Crash kernel (low)", and add DT property
"linux,low-memory-range" to crash dump kernel's dtb to pass the low region.
Besides, we need to modify kexec-tools:
arm64: kdump: add another DT property to crash dump kernel's dtb(see [1])
The previous changes and discussions can be retrieved from:
Changes since [v5]
- Move reserve_crashkernel_low() into kernel/crash_core.c.
- Delete crashkernel=X,high.
- Modify crashkernel=X,low.
If crashkernel=X,low is specified simultaneously, reserve spcified size low
memory for crash kdump kernel devices firstly and then reserve memory above 4G.
In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, and then
pass to crash dump kernel by DT property "linux,low-memory-range".
- Update Documentation/admin-guide/kdump/kdump.rst.
Changes since [v4]
- Reimplement memblock_cap_memory_ranges for multiple ranges by Mike.
Changes since [v3]
- Add memblock_cap_memory_ranges back for multiple ranges.
- Fix some compiling warnings.
Changes since [v2]
- Split patch "arm64: kdump: support reserving crashkernel above 4G" as
two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate
patch.
Changes since [v1]:
- Move common reserve_crashkernel_low() code into kernel/kexec_core.c.
- Remove memblock_cap_memory_ranges() i added in v1 and implement that
in fdt_enforce_memory_region().
There are at most two crash kernel regions, for two crash kernel regions
case, we cap the memory range [min(regs[*].start), max(regs[*].end)]
and then remove the memory range in the middle.
[1]: http://lists.infradead.org/pipermail/kexec/2019-August/023569.html
[v1]: https://lkml.org/lkml/2019/4/2/1174
[v2]: https://lkml.org/lkml/2019/4/9/86
[v3]: https://lkml.org/lkml/2019/4/9/306
[v4]: https://lkml.org/lkml/2019/4/15/273
[v5]: https://lkml.org/lkml/2019/5/6/1360
Chen Zhou (4):
x86: kdump: move reserve_crashkernel_low() into crash_core.c
arm64: kdump: reserve crashkenel above 4G for crash dump kernel
arm64: kdump: add memory for devices by DT property, low-memory-range
kdump: update Documentation about crashkernel on arm64
Documentation/admin-guide/kdump/kdump.rst | 13 ++++-
Documentation/admin-guide/kernel-parameters.txt | 12 ++++-
arch/arm64/include/asm/kexec.h | 3 ++
arch/arm64/kernel/setup.c | 8 ++-
arch/arm64/mm/init.c | 61 +++++++++++++++++++++--
arch/x86/include/asm/kexec.h | 3 ++
arch/x86/kernel/setup.c | 65 +++----------------------
include/linux/crash_core.h | 4 ++
include/linux/kexec.h | 1 -
kernel/crash_core.c | 65 +++++++++++++++++++++++++
10 files changed, 168 insertions(+), 67 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox