* 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 v5, 24/32] drm/mediatek: add clock property check before get it
From: CK Hu @ 2019-08-30 6:11 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-25-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 clock property check before get it
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a5a6689..effc24a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -657,10 +657,12 @@ static int mtk_ddp_probe(struct platform_device *pdev)
> for (i = 0; i < 10; i++)
> ddp->mutex[i].id = i;
>
> - ddp->clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(ddp->clk)) {
> - dev_err(dev, "Failed to get clock\n");
> - return PTR_ERR(ddp->clk);
> + if (of_find_property(dev->of_node, "clocks", &i)) {
> + ddp->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(ddp->clk)) {
> + dev_err(dev, "Failed to get clock\n");
> + return PTR_ERR(ddp->clk);
> + }
Only "mediatek,mt8133-disp-mutex" has no clock property. For other SoC,
clock property is required. So I think this exception is just for
mt8183.
Regards,
CK
> }
>
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 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 01/11] dt-bindings: phy-mtk-tphy: add two optional properties for u2phy
From: Chunfeng Yun @ 2019-08-30 6:03 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: <20190829192341.GA26293@bogus>
On Thu, 2019-08-29 at 14:23 -0500, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:00:08PM +0800, Chunfeng Yun wrote:
> > Add two optional properties, one for J-K test, another for disconnect
> > threshold, both of them can be used to debug disconnection issues.
>
> Testing and debug properties aren't really things that belong in DT.
They are not only for test and debug, but also used to tune default
value for some platforms, I'll modify the description
>
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > index a5f7a4f0dbc1..d5b327f85fa2 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
> > @@ -52,6 +52,8 @@ Optional properties (PHY_TYPE_USB2 port (child) node):
> > - mediatek,eye-vrt : u32, the selection of VRT reference voltage
> > - mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
> > - mediatek,bc12 : bool, enable BC12 of u2phy if support it
> > +- mediatek,discth : u32, the voltage of disconnect threshold
> > +- mediatek,intr : u32, the value of internal R (resistance)
>
> These need units as defined in property-units.txt.
They are in fact the choice index of different level, will modify it
Thank you
>
> >
> > Example:
> >
> > --
> > 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 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Jassi Brar @ 2019-08-30 5:58 UTC (permalink / raw)
To: Peng Fan
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: <1567004515-3567-2-git-send-email-peng.fan@nxp.com>
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: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +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? That implies
there is only one physical channel in the platform. So if you need to
initiate different functions (tx, rx), you call them sequentially by
changing the func-id for each request. Why not?
-Jassi
_______________________________________________
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, 22/32] drm/mediatek: add ovl0/ovl_2l0 usecase
From: CK Hu @ 2019-08-30 5:58 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-23-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 ovl0/ovl_2l0 usecase
> in ovl->ovl_2l0 direct link usecase:
> 1. the crtc support layer number will 4+2
> 2. ovl_2l0 background color input select ovl0 when crtc init
> and disable it when crtc finish
> 3. config ovl_2l0 layer, if crtc config layer number is
> bigger than ovl0 support layers(max is 4)
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 38 +++++++++++++++++++++++++++++++--
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index c63ff2b..b55970a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -270,6 +270,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
>
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
> + enum mtk_ddp_comp_id prev;
> +
> + if (i > 0)
> + prev = mtk_crtc->ddp_comp[i - 1]->id;
> + else
> + prev = DDP_COMPONENT_ID_MAX;
> +
> + if (prev == DDP_COMPONENT_OVL0)
> + mtk_ddp_comp_bgclr_in_on(comp);
Even though both OVL and OVL_2L implement this function, I think we
could still call this function for OVL and OVL_2L, and in
mtk_ovl_bgclr_in_on(), to judge it's OVL or OVL_2L.
Regards,
CK
>
> mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
> mtk_ddp_comp_start(comp);
> @@ -279,9 +288,18 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> for (i = 0; i < mtk_crtc->layer_nr; i++) {
> struct drm_plane *plane = &mtk_crtc->planes[i];
> struct mtk_plane_state *plane_state;
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> + unsigned int local_layer;
>
> plane_state = to_mtk_plane_state(plane->state);
> - mtk_ddp_comp_layer_config(mtk_crtc->ddp_comp[0], i,
> +
> + if (i >= comp_layer_nr) {
> + comp = mtk_crtc->ddp_comp[1];
> + local_layer = i - comp_layer_nr;
> + } else
> + local_layer = i;
> + mtk_ddp_comp_layer_config(comp, local_layer,
> plane_state);
> }
>
> @@ -307,6 +325,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
> mtk_crtc->ddp_comp[i]->id);
> mtk_disp_mutex_disable(mtk_crtc->mutex);
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> + mtk_ddp_comp_bgclr_in_off(mtk_crtc->ddp_comp[i]);
> mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
> mtk_crtc->mmsys_reg_data,
> mtk_crtc->ddp_comp[i]->id,
> @@ -327,6 +346,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> unsigned int i;
> + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> + unsigned int local_layer;
>
> /*
> * TODO: instead of updating the registers here, we should prepare
> @@ -349,7 +370,14 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> plane_state = to_mtk_plane_state(plane->state);
>
> if (plane_state->pending.config) {
> - mtk_ddp_comp_layer_config(comp, i, plane_state);
> + if (i >= comp_layer_nr) {
> + comp = mtk_crtc->ddp_comp[1];
> + local_layer = i - comp_layer_nr;
> + } else
> + local_layer = i;
> +
> + mtk_ddp_comp_layer_config(comp, local_layer,
> + plane_state);
> plane_state->pending.config = false;
> }
> }
> @@ -572,6 +600,12 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> }
>
> mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
> + if (mtk_crtc->ddp_comp_nr > 1) {
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[1];
> +
> + if (comp->funcs->bgclr_in_on)
> + mtk_crtc->layer_nr += mtk_ddp_comp_layer_nr(comp);
> + }
> mtk_crtc->planes = devm_kcalloc(dev, mtk_crtc->layer_nr,
> sizeof(struct drm_plane),
> GFP_KERNEL);
_______________________________________________
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 5:55 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: <1567131991-189761-1-git-send-email-linyunsheng@huawei.com>
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?
> 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?
> 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: [PATCH 5/8] media: cedrus: Detect first slice of a frame
From: Boris Brezillon @ 2019-08-30 5:48 UTC (permalink / raw)
To: Jernej Škrabec
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
hverkuil-cisco, mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <3132748.mYbjOY1tKM@jernej-laptop>
On Thu, 29 Aug 2019 21:04:28 +0200
Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
> napisal(a):
> > Hi Jernej,
> >
> > On Thu, 22 Aug 2019 21:44:57 +0200
> >
> > Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > > When codec supports multiple slices in one frame, VPU has to know when
> > > first slice of each frame is being processed, presumably to correctly
> > > clear/set data in auxiliary buffers.
> > >
> > > Add first_slice field to cedrus_run structure and set it according to
> > > timestamps of capture and output buffers. If timestamps are different,
> > > it's first slice and viceversa.
> > >
> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > > ---
> > >
> > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > > 2 files changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > > 2f017a651848..32cb38e541c6 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> > >
> > > struct cedrus_run {
> > >
> > > struct vb2_v4l2_buffer *src;
> > > struct vb2_v4l2_buffer *dst;
> > >
> > > + bool first_slice;
> > >
> > > union {
> > >
> > > struct cedrus_h264_run h264;
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > > 56ca4c9ad01c..d7b54accfe83 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> > >
> > > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > >
> > > + run.first_slice =
> > > + run.src->vb2_buf.timestamp != run.dst-
> >vb2_buf.timestamp;
> >
> > Can't we use slice->first_mb_in_slice to determine if a slice is the
> > first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> > support ASO).
>
> I looked in all VPU documentation available to me (which isn't much) and there
> is no indication if ASO is supported or not. Do you have any sample video with
> out-of-order slices? It's my understanding that this is uncommon.
I'm not entirely sure, but my understanding was that it might be used
when streaming over network where some packets might be lost and
re-emitted later on.
> If it's
> supported, I would leave code as-is.
I remember seeing the ASO acronym mentioned in the hantro G1 spec, but
at the same time we're doing frame-based decoding, so I guess the HW
block expects slices to be ordered in that case. Honestly I don't know,
so let's keep the code as-is.
_______________________________________________
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, 13/32] drm/mediatek: move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
From: CK Hu @ 2019-08-30 5:41 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-14-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 move rdma sout from mtk_ddp_mout_en into mtk_ddp_sout_sel
> rdma only has single output, but no multi output,
> all these rdma->dsi/dpi usecase should move to mtk_ddp_sout_sel
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 | 90 +++++++++++++++++-----------------
> 1 file changed, 45 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 338cc2f..a5a6689 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -299,51 +299,6 @@ 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_RDMA0 && next == DDP_COMPONENT_DPI0) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DPI0;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DPI1;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DSI1;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DSI2;
> - } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> - value = RDMA0_SOUT_DSI3;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DSI1;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DSI2;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DSI3;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> - *addr = data->rdma1_sout_sel_in;
> - value = data->rdma1_sout_dpi0;
> - } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> - value = RDMA1_SOUT_DPI1;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DPI0;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DPI1;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DSI1;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DSI2;
> - } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> - value = RDMA2_SOUT_DSI3;
> } else {
> value = 0;
> }
> @@ -423,6 +378,51 @@ static unsigned int mtk_ddp_sout_sel(const struct mtk_mmsys_reg_data *data,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_OUT_SEL;
> value = BLS_TO_DPI_RDMA1_TO_DSI;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
> + value = RDMA0_SOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI3;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> + *addr = data->rdma1_sout_sel_in;
> + value = data->rdma1_sout_dpi0;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DPI0;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_SOUT_DSI3;
> } 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, 12/32] drm/mediatek: add mmsys private data for ddp path config
From: CK Hu @ 2019-08-30 5:40 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: <1567142858.5942.6.camel@mtksdaap41>
Hi, Yongqiang:
On Fri, 2019-08-30 at 13:27 +0800, CK Hu wrote:
> 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 mmsys private data for ddp path config
> > all these register offset and value will be different in future SOC
> > add these define into mmsys private data
> > u32 ovl0_mout_en;
> > u32 rdma1_sout_sel_in;
> > u32 rdma1_sout_dsi0;
> > u32 dpi0_sel_in;
> > u32 dpi0_sel_in_rdma1;
> > u32 dsi0_sel_in;
> > u32 dsi0_sel_in_rdma1;
> >
> > Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 86 +++++++++++++++++++++++----------
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 5 ++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 ++
> > 5 files changed, 76 insertions(+), 25 deletions(-)
> >
>
> [snip]
>
> >
> > void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> > + const struct mtk_mmsys_reg_data *reg_data,
> > enum mtk_ddp_comp_id cur,
> > enum mtk_ddp_comp_id next)
> > {
> > unsigned int addr, value, reg;
> >
> > - value = mtk_ddp_mout_en(cur, next, &addr);
> > + value = mtk_ddp_mout_en(reg_data, cur, next, &addr);
> > if (value) {
> > reg = readl_relaxed(config_regs + addr) | value;
> > writel_relaxed(reg, config_regs + addr);
> > }
> >
> > - mtk_ddp_sout_sel(config_regs, cur, next);
> > + value = mtk_ddp_sout_sel(reg_data, cur, next, &addr);
> > + if (value)
> > + writel_relaxed(value, config_regs + addr);
>
> I think the register could be written inside mtk_ddp_sout_sel(), why do
> you move out of that function?
OK, after review other patch, I understand what you do here.
You want to align the method of mtk_ddp_mout_en(), mtk_ddp_sout_sel(),
and mtk_ddp_sel_in(). so modification in these three function would be
the same style. So I think this alignment should be an independent patch
before this patch.
Regards,
CK
>
> Regards,
> CK
>
> >
> > - value = mtk_ddp_sel_in(cur, next, &addr);
> > + value = mtk_ddp_sel_in(reg_data, cur, next, &addr);
> > if (value) {
> > reg = readl_relaxed(config_regs + addr) | value;
> > writel_relaxed(reg, config_regs + addr);
> > @@ -420,18 +455,19 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> > }
> >
> >
> >
>
_______________________________________________
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 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
From: Peter Ujfalusi @ 2019-08-30 5:37 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-kernel, vkoul, dmaengine, dan.j.williams,
linux-omap, linux-arm-kernel
In-Reply-To: <20190829224728.GA1198@bogus>
Rob,
On 30/08/2019 1.47, Rob Herring wrote:
> On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote:
>> Similarly to paRAM slots, channels can be used by other cores.
>>
>> Add optional property to configure the reserved channel ranges.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>> ---
>> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> index 4bbc94d829c8..1198682ada99 100644
>> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>> @@ -42,6 +42,9 @@ Optional properties:
>> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>> the driver, they are allocated to be used by for example the
>> DSP. See example.
>> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by
>> + the driver, they are allocated to be used by for example the
>> + DSP. See example.
>
> Based on the other thread, I think extending dma-channel-mask to a
> uint32-array makes sense here.
Yes, that is the reason I have asked on that and I'm in progress of
converting the edma driver to use the dma-channel-mask.
Just need to do some shuffling in the driver to get the mask in a form
usable by the driver.
I'll send an updated series early next week.
- Péter
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
* Re: [PATCH v5, 12/32] drm/mediatek: add mmsys private data for ddp path config
From: CK Hu @ 2019-08-30 5:27 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-13-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 mmsys private data for ddp path config
> all these register offset and value will be different in future SOC
> add these define into mmsys private data
> u32 ovl0_mout_en;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dsi0;
> u32 dpi0_sel_in;
> u32 dpi0_sel_in_rdma1;
> u32 dsi0_sel_in;
> u32 dsi0_sel_in_rdma1;
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 86 +++++++++++++++++++++++----------
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 5 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 ++
> 5 files changed, 76 insertions(+), 25 deletions(-)
>
[snip]
>
> void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> + const struct mtk_mmsys_reg_data *reg_data,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next)
> {
> unsigned int addr, value, reg;
>
> - value = mtk_ddp_mout_en(cur, next, &addr);
> + value = mtk_ddp_mout_en(reg_data, cur, next, &addr);
> if (value) {
> reg = readl_relaxed(config_regs + addr) | value;
> writel_relaxed(reg, config_regs + addr);
> }
>
> - mtk_ddp_sout_sel(config_regs, cur, next);
> + value = mtk_ddp_sout_sel(reg_data, cur, next, &addr);
> + if (value)
> + writel_relaxed(value, config_regs + addr);
I think the register could be written inside mtk_ddp_sout_sel(), why do
you move out of that function?
Regards,
CK
>
> - value = mtk_ddp_sel_in(cur, next, &addr);
> + value = mtk_ddp_sel_in(reg_data, cur, next, &addr);
> if (value) {
> reg = readl_relaxed(config_regs + addr) | value;
> writel_relaxed(reg, config_regs + addr);
> @@ -420,18 +455,19 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> }
>
>
>
_______________________________________________
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 V3 01/10] dt-bindings: soc: Add dvfsrc driver bindings
From: Henry Chen @ 2019-08-30 5:26 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Boichat, Weiyi Lu, James Liao, Viresh Kumar, linux-kernel,
Stephen Boyd, Fan Chen, devicetree, Rob Herring, Ryan Case,
Matthias Brugger, linux-mediatek, Georgi Djakov, linux-arm-kernel
In-Reply-To: <20190829191631.GA15714@bogus>
On Thu, 2019-08-29 at 14:16 -0500, Rob Herring wrote:
> On Wed, 28 Aug 2019 20:28:39 +0800, Henry Chen wrote:
> > Document the binding for enabling dvfsrc on MediaTek SoC.
> >
> > Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
> > ---
> > .../devicetree/bindings/soc/mediatek/dvfsrc.txt | 23 ++++++++++++++++++++++
> > include/dt-bindings/soc/mtk,dvfsrc.h | 14 +++++++++++++
> > 2 files changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt
> > create mode 100644 include/dt-bindings/soc/mtk,dvfsrc.h
> >
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Hi Rob,
I'm sorry for the mistake. I stand corrected, and will add tags on next
version.
Henry
_______________________________________________
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, 11/32] drm/mediatek: split DISP_REG_CONFIG_DSI_SEL setting into another use case
From: CK Hu @ 2019-08-30 5:21 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-12-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>
>
> Here is two modifition in this patch:
> 1.bls->dpi0 and rdma1->dsi are differen usecase,
> Split DISP_REG_CONFIG_DSI_SEL setting into anther usecase
> 2.remove DISP_REG_CONFIG_DPI_SEL setting, DPI_SEL_IN_BLS is 0 and
> this is same with hardware defautl setting,
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 4866a9b..c93e1b7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -392,10 +392,9 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
> } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> config_regs + DISP_REG_CONFIG_OUT_SEL);
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> writel_relaxed(DSI_SEL_IN_RDMA,
> config_regs + DISP_REG_CONFIG_DSI_SEL);
> - writel_relaxed(DPI_SEL_IN_BLS,
> - config_regs + DISP_REG_CONFIG_DPI_SEL);
As internal discussion, please rewrite this to prevent breaking MT2701
connection. It's better to add comment to address the special usage for
MT2701.
Regards,
CK
> }
> }
>
_______________________________________________
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, 01/32] dt-bindings: mediatek: add binding for mt8183 display
From: CK Hu @ 2019-08-30 5:15 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-2-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>
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> .../bindings/display/mediatek/mediatek,display.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
> new file mode 100644
> index 0000000..951d2a8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,display.txt
> @@ -0,0 +1,21 @@
> +Mediatek Display Device
> +============================
> +
> +The Mediatek Display Device provides power control to the system.
> +
> +Required Properties:
> +
> +- compatible: Should be one of:
> + - "mediatek,mt8183-display"
I think this is "mediatek,mt8183-mmsys".
Regards,
CK
> +
> +The Display Device power name are defined in
> +include\dt-bindings\power\mt*-power.h
> +
> +
> +Example:
> +
> +display_components: dispsys@14000000 {
> + compatible = "mediatek,mt8183-display";
> + reg = <0 0x14000000 0 0x1000>;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> +};
> \ No newline at end of file
_______________________________________________
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 0/5] Add HDMI jack support on RK3288
From: Cheng-yi Chiang @ 2019-08-30 2:55 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: ALSA development, Douglas Anderson, Heiko Stuebner, Liam Girdwood,
David Airlie, dri-devel, Takashi Iwai, tzungbi,
Linux Kernel Mailing List, Hans Verkuil, Andrzej Hajda,
Russell King, Mark Brown, Laurent Pinchart, Daniel Vetter,
linux-rockchip, Dylan Reid, Jaroslav Kysela, linux-arm-kernel
In-Reply-To: <CA+Px+wX4gbntkd6y8NN8xwXpZLD4MH9rTeHcW9+Ndtw=3_mWBw@mail.gmail.com>
On Wed, Jul 17, 2019 at 6:28 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>
> On Wed, Jul 17, 2019 at 4:33 PM Cheng-Yi Chiang <cychiang@chromium.org> wrote:
> >
> > This patch series supports HDMI jack reporting on RK3288, which uses
> > DRM dw-hdmi driver and hdmi-codec codec driver.
> >
> > The previous discussion about reporting jack status using hdmi-notifier
> > and drm_audio_component is at
> >
> > https://lore.kernel.org/patchwork/patch/1083027/
> >
> > The new approach is to use a callback mechanism that is
> > specific to hdmi-codec.
> >
> > Changes from v4 to v5:
> > - synopsys/Kconfig: Remove the incorrect dependency change in v4.
> > - rockchip/Kconfig: Add dependency of hdmi-codec when it is really need
> > for jack support.
> >
> > Cheng-Yi Chiang (5):
> > ASoC: hdmi-codec: Add an op to set callback function for plug event
> > drm: bridge: dw-hdmi: Report connector status using callback
> > drm: dw-hdmi-i2s: Use fixed id for codec device
> > ASoC: rockchip_max98090: Add dai_link for HDMI
> > ASoC: rockchip_max98090: Add HDMI jack support
> >
> LGTM.
>
> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Hi Daniel,
Do you have further concern on this patch series related to hdmi-codec
and drm part ?
We would like to merge this patch series if possible.
They will be needed in many future chrome projects for HDMI audio jack
detection.
Thanks a lot!
_______________________________________________
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 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-08-30 2:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828140217.GC21614@e107155-lin>
> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, Aug 28, 2019 at 03:03:02AM +0000, Peng Fan wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2F&data=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Ca1e96c6b782d43b2cfb208d72bc05898%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637025977487779923&sdata=rzC%2B4Y1c
> q9Y3tSDFR
> > %2Fsvf5ktk7INP2rwXN%2BXdWCVjNs%3D&reserved=0
> >
> > Cc: Andre Przywara <andre.przywara@arm.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 215
> > ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 224 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
>
> [...]
>
> > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > + struct device *dev = &pdev->dev;
> > + struct mbox_controller *mbox;
> > + struct arm_smc_chan_data *chan_data;
> > + const char *method;
> > + bool mem_trans = false;
> > + int ret, i;
> > + u32 val;
> > +
> > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", &val)) {
> > + if (!val) {
> > + dev_err(dev, "invalid arm,num-chans value %u\n", val);
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "transports", &method)) {
> > + if (!strcmp("mem", method)) {
> > + mem_trans = true;
> > + } else if (!strcmp("reg", method)) {
> > + mem_trans = false;
> > + } else {
> > + dev_warn(dev, "invalid \"transports\" property: %s\n",
> > + method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "method", &method)) {
> > + if (!strcmp("hvc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > + } else if (!strcmp("smc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_smc;
> > + } else {
> > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > + method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > + if (!mbox)
> > + return -ENOMEM;
> > +
> > + mbox->num_chans = val;
> > + mbox->chans = devm_kcalloc(dev, mbox->num_chans,
> sizeof(*mbox->chans),
> > + GFP_KERNEL);
> > + if (!mbox->chans)
> > + return -ENOMEM;
> > +
> > + chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> > + GFP_KERNEL);
> > + if (!chan_data)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < mbox->num_chans; i++) {
> > + u32 function_id;
> > +
> > + ret = of_property_read_u32_index(dev->of_node,
> > + "arm,func-ids", i,
> > + &function_id);
>
> I missed it in binding but I thought we agreed to make this "arm,func-ids"
> a required property and not optional ?
Not sure Jassi is fine with it being a required property, but I could convert
it to a required property in V6.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
_______________________________________________
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 2:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828135802.GB21614@e107155-lin>
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM
> SMC/HVC mailbox
>
> On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan 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%7C37aa729c94944730868b08d72bbfc121%7C686ea1
> d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C1%7C637025974936865698&sdata=Inp
> %2FLs39m
> > +Gv1fe3dZMSaGmgmyWPT6awPh47s3mEtQ%2BQ%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%7C37aa729c94944730868b08d72bbfc121%7C686ea1d3bc2b4c
> 6fa92cd9
> >
> +9c5c301635%7C0%7C1%7C637025974936865698&sdata=jmoR1Qqm7
> 6N5NwDbgFE
> > +Fm8cpdW%2B%2FgqmG9mSGz9mXv58%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.
>
> What do you mean by that ? I would prefer to drop the above line unless I am
Ok. Dropped it in v6.
> missing something. IMO it contradicts the previous statement less you
> elaborate more on this.
>
> > 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.
>
> I assume you refer to asynchronous communication from OS to firmware in
> the above statement and "not asynchronous notification" from firmware to
> OS.
Since asynchronous notification dropped, so it should only be
synchronous communication could be established. So I'll
modify it as below:
r0/w0/x0 the firmware returns after the smc call is delivered as a received
message to the mailbox framework, so synchronous communication can be
established
>
> > + 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.
> > +
>
> Not sure if reference to SCMI is needed at all but I don't have any objections
> to it, just thought worth mentioning.
>
> > + 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.
> > +
>
>
> Other than the above points, I am fine with it. Once fixed,
>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Thanks,
Peng.
>
> Note I haven't reviewed the yaml scheme, but just binding in general.
>
> --
> Regards,
> Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: numa: check the node id before accessing node_to_cpumask_map
From: Yunsheng Lin @ 2019-08-30 2:26 UTC (permalink / raw)
To: will
Cc: mhocko, tglx, anshuman.khandual, linuxarm, linux-kernel, rppt,
cai, akpm, robin.murphy, adobriyan, linux-arm-kernel
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.
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.
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 related
* [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-08-30 2:28 UTC (permalink / raw)
To: sstabellini@kernel.org, linux@armlinux.org.uk,
catalin.marinas@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: xen-devel@lists.xenproject.org, Peng Fan, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
From: Peng Fan <peng.fan@nxp.com>
arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
So introduce xen_set_gfp_dma for arm32/arm64 and using __GFP_DMA
for the former and __GFP_DMA32 for the latter.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
V2:
Follow suggestion from Stefano,
introduce static inline void xen_set_gfp_dma(gfp_t *flags) for arm32/arm64, and
for arm64 using __GFP_DMA for the former and __GFP_DMA32 for the latter.
arch/arm/include/asm/xen/page.h | 5 +++++
arch/arm/xen/mm.c | 2 +-
arch/arm64/include/asm/xen/page.h | 5 +++++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 31bbc803cecb..d08309c45e6c 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1 +1,6 @@
#include <xen/arm/page.h>
+
+static inline void xen_set_gfp_dma(gfp_t *flags)
+{
+ *flags |= __GFP_DMA;
+}
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..828f49dc95f9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0xffffffff) {
- flags |= __GFP_DMA;
+ xen_set_gfp_dma(&flags);
break;
}
}
diff --git a/arch/arm64/include/asm/xen/page.h b/arch/arm64/include/asm/xen/page.h
index 31bbc803cecb..5eeabf2c6494 100644
--- a/arch/arm64/include/asm/xen/page.h
+++ b/arch/arm64/include/asm/xen/page.h
@@ -1 +1,6 @@
#include <xen/arm/page.h>
+
+static inline void xen_set_gfp_dma(gfp_t *flags)
+{
+ *flags |= __GFP_DMA32;
+}
--
2.16.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
* Re: [PATCH] ARM: dts: imx7: fix USB controller 'size' parameter
From: Peter Chen @ 2019-08-30 2:25 UTC (permalink / raw)
To: Thomas Schäfer
Cc: shawnguo@kernel.org, s.hauer@pengutronix.de, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190829154913.2049-1-thomas.schaefer@kontron.com>
On 19-08-29 17:49:13, Thomas Schaefer wrote:
> Currently the size parameter in the reg property of usbotg and
> usbh nodes in imx7s and imx7d dts includes is set to 0x200 which
> is wrong for the i.MX7 CPU. According to reference manual, spacing
> of USB controller registers is 0x10000 instead.
>
> This patch will fix this and set the 'size' to 0x10000.
>
> Signed-off-by: Thomas Schaefer <thomas.schaefer@kontron.com>
> ---
> arch/arm/boot/dts/imx7d.dtsi | 2 +-
> arch/arm/boot/dts/imx7s.dtsi | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 42528d2812a2..f1b098d28b6e 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -117,7 +117,7 @@
> &aips3 {
> usbotg2: usb@30b20000 {
> compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> - reg = <0x30b20000 0x200>;
> + reg = <0x30b20000 0x10000>;
> interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX7D_USB_CTRL_CLK>;
> fsl,usbphy = <&usbphynop2>;
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index c1a4fff5ceda..9e25fccf33f0 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -1088,7 +1088,7 @@
>
> usbotg1: usb@30b10000 {
> compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> - reg = <0x30b10000 0x200>;
> + reg = <0x30b10000 0x10000>;
> interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX7D_USB_CTRL_CLK>;
> fsl,usbphy = <&usbphynop1>;
> @@ -1099,7 +1099,7 @@
>
> usbh: usb@30b30000 {
> compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> - reg = <0x30b30000 0x200>;
> + reg = <0x30b30000 0x10000>;
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX7D_USB_CTRL_CLK>;
> fsl,usbphy = <&usbphynop3>;
Hi Thomos,
The core controller range is 0x200, from offset 0x200, it is
non-core register, which is used by usbmisc. Fabio said you
met problem at u-boot for this size, what's the problem about
it?
Thanks,
Peter
_______________________________________________
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 v14 07/10] soc: mediatek: cmdq: define the instruction struct
From: houlong wei @ 2019-08-30 2:23 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree@vger.kernel.org, Nicolas Boichat, srv_heupstream,
Jassi Brar, linux-kernel@vger.kernel.org, houlong.wei,
Dennis-YC Hsieh (謝宇哲),
CK Hu (胡俊光), Rob Herring,
linux-mediatek@lists.infradead.org, Matthias Brugger,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190829014817.25482-9-bibby.hsieh@mediatek.com>
On Thu, 2019-08-29 at 09:48 +0800, Bibby Hsieh wrote:
> Define an instruction structure for gce driver to append command.
> This structure can make the client's code more readability.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Reviewed-by: Houlong Wei <houlong.wei@mediatek.com>
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 77 ++++++++++++++++--------
> include/linux/mailbox/mtk-cmdq-mailbox.h | 10 +++
> 2 files changed, 61 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 7aa0517ff2f3..9472526ab076 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -9,12 +9,24 @@
> #include <linux/mailbox_controller.h>
> #include <linux/soc/mediatek/mtk-cmdq.h>
>
> -#define CMDQ_ARG_A_WRITE_MASK 0xffff
> #define CMDQ_WRITE_ENABLE_MASK BIT(0)
> #define CMDQ_EOC_IRQ_EN BIT(0)
> #define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
> << 32 | CMDQ_EOC_IRQ_EN)
>
> +struct cmdq_instruction {
> + union {
> + u32 value;
> + u32 mask;
> + };
> + union {
> + u16 offset;
> + u16 event;
> + };
> + u8 subsys;
> + u8 op;
> +};
> +
> static void cmdq_client_timeout(struct timer_list *t)
> {
> struct cmdq_client *client = from_timer(client, t, timer);
> @@ -110,10 +122,10 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> }
> EXPORT_SYMBOL(cmdq_pkt_destroy);
>
> -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> - u32 arg_a, u32 arg_b)
> +static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
> + struct cmdq_instruction inst)
Can we use 'struct cmdq_instruction *inst' instead of 'struct
cmdq_instruction inst' to reduce stack memory consumption a bit?
> {
> - u64 *cmd_ptr;
> + struct cmdq_instruction *cmd_ptr;
>
> if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> /*
> @@ -129,8 +141,9 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> __func__, (u32)pkt->buf_size);
> return -ENOMEM;
> }
> +
> cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> - (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> + *cmd_ptr = inst;
> pkt->cmd_buf_size += CMDQ_INST_SIZE;
>
> return 0;
> @@ -138,24 +151,31 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
>
> int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> {
> - u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> - (subsys << CMDQ_SUBSYS_SHIFT);
> + struct cmdq_instruction inst;
> +
> + inst.op = CMDQ_CODE_WRITE;
> + inst.value = value;
> + inst.offset = offset;
> + inst.subsys = subsys;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> + return cmdq_pkt_append_command(pkt, inst);
> }
> EXPORT_SYMBOL(cmdq_pkt_write);
>
> int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask)
> {
> - u32 offset_mask = offset;
> + struct cmdq_instruction inst = { {0} };
> + u16 offset_mask = offset;
> int err = 0;
>
> if (mask != 0xffffffff) {
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
> + inst.op = CMDQ_CODE_MASK;
> + inst.mask = ~mask;
> + err = cmdq_pkt_append_command(pkt, inst);
> offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> }
> - err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
> + err |= cmdq_pkt_write(pkt, subsys, offset_mask, value);
>
> return err;
> }
> @@ -163,43 +183,48 @@ EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> - u32 arg_b;
> + struct cmdq_instruction inst = { {0} };
>
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> - /*
> - * WFE arg_b
> - * bit 0-11: wait value
> - * bit 15: 1 - wait, 0 - no wait
> - * bit 16-27: update value
> - * bit 31: 1 - update, 0 - no update
> - */
> - arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
> + inst.op = CMDQ_CODE_WFE;
> + inst.value = CMDQ_WFE_OPTION;
> + inst.event = event;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
> + return cmdq_pkt_append_command(pkt, inst);
> }
> EXPORT_SYMBOL(cmdq_pkt_wfe);
>
> int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> {
> + struct cmdq_instruction inst = { {0} };
> +
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
> - CMDQ_WFE_UPDATE);
> + inst.op = CMDQ_CODE_WFE;
> + inst.value = CMDQ_WFE_UPDATE;
> + inst.event = event;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> }
> EXPORT_SYMBOL(cmdq_pkt_clear_event);
>
> static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> - int err;
> + struct cmdq_instruction inst = { {0} };
> + int err = 0;
>
> /* insert EOC and generate IRQ for each command iteration */
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
> + inst.op = CMDQ_CODE_EOC;
> + inst.value = CMDQ_EOC_IRQ_EN;
> + err = cmdq_pkt_append_command(pkt, inst);
>
> /* JUMP to end */
> - err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
> + inst.op = CMDQ_CODE_JUMP;
> + inst.value = CMDQ_JUMP_PASS;
> + err |= cmdq_pkt_append_command(pkt, inst);
>
> return err;
> }
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index e6f54ef6698b..678760548791 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -20,6 +20,16 @@
> #define CMDQ_WFE_WAIT BIT(15)
> #define CMDQ_WFE_WAIT_VALUE 0x1
>
> +/*
> + * WFE arg_b
> + * bit 0-11: wait value
> + * bit 15: 1 - wait, 0 - no wait
> + * bit 16-27: update value
> + * bit 31: 1 - update, 0 - no update
> + */
> +#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
> + CMDQ_WFE_WAIT_VALUE)
> +
> /** cmdq event maximum */
> #define CMDQ_MAX_EVENT 0x3ff
>
_______________________________________________
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 v3 00/39] put_user_pages(): miscellaneous call sites
From: John Hubbard @ 2019-08-30 2:21 UTC (permalink / raw)
To: Mike Marshall
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, Dan Williams, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, intel-gfx, john.hubbard,
linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, Linux NFS Mailing List, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <CAOg9mSQKGDywcMde2DE42diUS7J8m74Hdv+xp_PJhC39EXZQuw@mail.gmail.com>
On 8/29/2019 6:29 PM, Mike Marshall wrote:
> Hi John...
>
> I added this patch series on top of Linux 5.3rc6 and ran
> xfstests with no regressions...
>
> Acked-by: Mike Marshall <hubcap@omnibond.com>
>
Hi Mike (and I hope Ira and others are reading as well, because
I'm making a bunch of claims further down),
That's great news, thanks for running that test suite and for
the report and the ACK.
There is an interesting pause right now, due to the fact that
we've made some tentative decisions about gup pinning, that affect
the call sites. A key decision is that only pages that were
requested via FOLL_PIN, will require put_user_page*() to release
them. There are 4 main cases, which were first explained by Jan
Kara and Vlastimil Babka, and are now written up in my FOLL_PIN
patch [1].
So, what that means for this series is that:
1. Some call sites (mlock.c for example, and a lot of the mm/ files
in fact, and more) will not be converted: some of these patches will
get dropped, especially in mm/.
2. Call sites that do DirectIO or RDMA will need to set FOLL_PIN, and
will also need to call put_user_page().
3. Call sites that do RDMA will need to set FOLL_LONGTERM *and* FOLL_PIN,
3.a. ...and will at least in some cases need to provide a link to a
vaddr_pin object, and thus back to a struct file*...maybe. Still
under discussion.
4. It's desirable to keep FOLL_* flags (or at least FOLL_PIN) internal
to the gup() calls. That implies using a wrapper call such as Ira's
vaddr_pin_[user]_pages(), instead of gup(), and vaddr_unpin_[user]_pages()
instead of put_user_page*().
5. We don't want to churn the call sites unnecessarily.
With that in mind, I've taken another pass through all these patches
and narrowed it down to:
a) 12 call sites that I'd like to convert soon, but even those
really look cleaner with a full conversion to a wrapper call
similar to (identical to?) vaddr_pin_[user]_pages(), probably
just the FOLL_PIN only variant (not FOLL_LONGTERM). That
wrapper call is not ready yet, though.
b) Some more call sites that require both FOLL_PIN and FOLL_LONGTERM.
Definitely will wait to use the wrapper calls for these, because
they may also require hooking up to a struct file*.
c) A few more that were already applied, which is fine, because they
show where to convert, and simplify a few sites anyway. But they'll
need follow-on changes to, one way or another, set FOLL_PIN.
d) And of course a few sites whose patches get dropped, as mentioned
above.
[1] https://lore.kernel.org/r/20190821040727.19650-3-jhubbard@nvidia.com
thanks,
--
John Hubbard
NVIDIA
_______________________________________________
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 v3 00/39] put_user_pages(): miscellaneous call sites
From: Mike Marshall @ 2019-08-30 1:29 UTC (permalink / raw)
To: John Hubbard
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, Dan Williams, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, intel-gfx, john.hubbard,
linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, Linux NFS Mailing List, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <912eb2bd-4102-05c1-5571-c261617ad30b@nvidia.com>
Hi John...
I added this patch series on top of Linux 5.3rc6 and ran
xfstests with no regressions...
Acked-by: Mike Marshall <hubcap@omnibond.com>
-Mike
On Tue, Aug 6, 2019 at 9:50 PM John Hubbard <jhubbard@nvidia.com> wrote:
>
> On 8/6/19 6:32 PM, john.hubbard@gmail.com wrote:
> > From: John Hubbard <jhubbard@nvidia.com>
> > ...
> >
> > John Hubbard (38):
> > mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
> ...
> > 54 files changed, 191 insertions(+), 323 deletions(-)
> >
> ahem, yes, apparently this is what happens if I add a few patches while editing
> the cover letter... :)
>
> The subject line should read "00/41", and the list of files affected here is
> therefore under-reported in this cover letter. However, the patch series itself is
> intact and ready for submission.
>
> thanks,
> --
> John Hubbard
> NVIDIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RFC bpf-next 10/10] arm: include: asm: unified: mask .syntax unified for clang
From: Ivan Khoronzhuk @ 2019-08-30 0:50 UTC (permalink / raw)
To: linux, ast, daniel, yhs, davem, jakub.kicinski, hawk,
john.fastabend
Cc: Ivan Khoronzhuk, netdev, linux-kernel, clang-built-linux, bpf,
linux-arm-kernel
In-Reply-To: <20190830005037.24004-1-ivan.khoronzhuk@linaro.org>
The samples/bpf reuses linux headers, with clang -emit-llvm,
so this w/a is only for samples/bpf (samples/bpf/Makefile CLANG-bpf).
It allows to build samples/bpf for arm on target board.
In another way clang -emit-llvm generates errors like:
<inline asm>:1:1: error: unknown directive
.syntax unified
I have verified it on clang 5, 6 ,7, 8, 9, 10
as on native platform as for cross-compiling. This decision is
arguable, but it doesn't have impact on samples/bpf so it's easier
just ignore it for clang, at least for now...
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
arch/arm/include/asm/unified.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index 1e2c3eb04353..3cf8757b9a14 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -11,7 +11,11 @@
#if defined(__ASSEMBLY__)
.syntax unified
#else
-__asm__(".syntax unified");
+
+#ifndef __clang__
+ __asm__(".syntax unified");
+#endif
+
#endif
#ifdef CONFIG_CPU_V7M
--
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 RFC bpf-next 09/10] arm: include: asm: swab: mask rev16 instruction for clang
From: Ivan Khoronzhuk @ 2019-08-30 0:50 UTC (permalink / raw)
To: linux, ast, daniel, yhs, davem, jakub.kicinski, hawk,
john.fastabend
Cc: Ivan Khoronzhuk, netdev, linux-kernel, clang-built-linux, bpf,
linux-arm-kernel
In-Reply-To: <20190830005037.24004-1-ivan.khoronzhuk@linaro.org>
The samples/bpf with clang -emit-llvm reuses linux headers to build
bpf samples, and this w/a only for samples (samples/bpf/Makefile
CLANG-bpf).
It allows to build samples/bpf for arm bpf using clang.
In another way clang -emit-llvm generates errors like:
CLANG-bpf samples/bpf/tc_l2_redirect_kern.o
<inline asm>:1:2: error: invalid register/token name
rev16 r3, r0
This decision is arguable, probably there is another way, but
it doesn't have impact on samples/bpf, so it's easier just ignore
it for clang, at least for now.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
arch/arm/include/asm/swab.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/include/asm/swab.h b/arch/arm/include/asm/swab.h
index c6051823048b..a9fd9cd33d5e 100644
--- a/arch/arm/include/asm/swab.h
+++ b/arch/arm/include/asm/swab.h
@@ -25,8 +25,11 @@ static inline __attribute_const__ __u32 __arch_swahb32(__u32 x)
__asm__ ("rev16 %0, %1" : "=r" (x) : "r" (x));
return x;
}
+
+#ifndef __clang__
#define __arch_swahb32 __arch_swahb32
#define __arch_swab16(x) ((__u16)__arch_swahb32(x))
+#endif
static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
{
--
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
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