* [PATCH 23/28] drm/mediatek: add DPI1 support for mutex
From: CK Hu @ 2018-06-13 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-24-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the DPI1 support for mutex
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@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 5a8569fa6505..5916fc11693a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -76,6 +76,7 @@
> #define MUTEX_SOF_DSI0 1
> #define MUTEX_SOF_DSI1 2
> #define MUTEX_SOF_DPI0 3
> +#define MUTEX_SOF_DPI1 4
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> @@ -385,6 +386,9 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
> case DDP_COMPONENT_DPI0:
> reg = MUTEX_SOF_DPI0;
> break;
> + case DDP_COMPONENT_DPI1:
> + reg = MUTEX_SOF_DPI1;
> + break;
> default:
> if (ddp->mutex_mod[id] < 32) {
> offset = DISP_REG_MUTEX_MOD(mutex->id);
> @@ -417,6 +421,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
> case DDP_COMPONENT_DSI0:
> case DDP_COMPONENT_DSI1:
> case DDP_COMPONENT_DPI0:
> + case DDP_COMPONENT_DPI1:
> writel_relaxed(MUTEX_SOF_SINGLE_MODE,
> ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
> break;
^ permalink raw reply
* [PATCH 24/28] drm/mediatek: add DSI2 support for mutex
From: CK Hu @ 2018-06-13 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-25-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the DSI2 support for mutex
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@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 5916fc11693a..1e7e3872eccc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -77,6 +77,7 @@
> #define MUTEX_SOF_DSI1 2
> #define MUTEX_SOF_DPI0 3
> #define MUTEX_SOF_DPI1 4
> +#define MUTEX_SOF_DSI2 5
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> @@ -383,6 +384,9 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
> case DDP_COMPONENT_DSI1:
> reg = MUTEX_SOF_DSI0;
> break;
> + case DDP_COMPONENT_DSI2:
> + reg = MUTEX_SOF_DSI2;
> + break;
> case DDP_COMPONENT_DPI0:
> reg = MUTEX_SOF_DPI0;
> break;
> @@ -420,6 +424,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
> switch (id) {
> case DDP_COMPONENT_DSI0:
> case DDP_COMPONENT_DSI1:
> + case DDP_COMPONENT_DSI2:
> case DDP_COMPONENT_DPI0:
> case DDP_COMPONENT_DPI1:
> writel_relaxed(MUTEX_SOF_SINGLE_MODE,
^ permalink raw reply
* [PATCH 25/28] drm/mediatek: add DSI3 support for mutex
From: CK Hu @ 2018-06-13 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-26-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add the DSI3 support for mutex
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@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 1e7e3872eccc..28dd8531a7de 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -78,6 +78,7 @@
> #define MUTEX_SOF_DPI0 3
> #define MUTEX_SOF_DPI1 4
> #define MUTEX_SOF_DSI2 5
> +#define MUTEX_SOF_DSI3 6
>
> #define OVL0_MOUT_EN_COLOR0 0x1
> #define OD_MOUT_EN_RDMA0 0x1
> @@ -387,6 +388,9 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
> case DDP_COMPONENT_DSI2:
> reg = MUTEX_SOF_DSI2;
> break;
> + case DDP_COMPONENT_DSI3:
> + reg = MUTEX_SOF_DSI3;
> + break;
> case DDP_COMPONENT_DPI0:
> reg = MUTEX_SOF_DPI0;
> break;
> @@ -425,6 +429,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex,
> case DDP_COMPONENT_DSI0:
> case DDP_COMPONENT_DSI1:
> case DDP_COMPONENT_DSI2:
> + case DDP_COMPONENT_DSI3:
> case DDP_COMPONENT_DPI0:
> case DDP_COMPONENT_DPI1:
> writel_relaxed(MUTEX_SOF_SINGLE_MODE,
^ permalink raw reply
* [PATCH 2/4] net: emaclite: Fix MDIO bus unregister bug
From: Andrew Lunn @ 2018-06-13 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-3-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:17PM +0530, Radhey Shyam Pandey wrote:
> Since 'has_mdio' flag is not used,sequence insmod->rmmod-> insmod
> leads to failure as MDIO unregister doesn't happen in .remove().
> Fix it by checking MII bus pointer instead.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 3/4] net: emaclite: Remove unused 'has_mdio' flag.
From: Andrew Lunn @ 2018-06-13 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-4-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:18PM +0530, Radhey Shyam Pandey wrote:
> Remove unused 'has_mdio' flag.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Maxime Ripard @ 2018-06-13 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67DOgnW=gesPxgmxZJWieZkzjPJm5mt7eW15HgUP3_SZg@mail.gmail.com>
On Mon, Jun 11, 2018 at 03:53:41PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> > Hi Maxime,
> >
> >
> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> >> Hi Mike, Stephen,
> >>
> >> Please merge the following changes for the next merge window, thanks!
> >>
> >> Maxime
> >>
> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >>
> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >>
> >> are available in the Git repository at:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
> >>
> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
> >>
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
> >>
> >> ----------------------------------------------------------------
> >> Allwinner clock changes for 4.18
> >>
> >> Not a lot of changes for this release, but two quite important features
> >> were added: the H6 PRCM clock support, and the needed changes to the R40
> >> clock driver to allow for the EMAC to operate.
> >>
> >> ----------------------------------------------------------------
> >> Icenowy Zheng (3):
> >> clk: sunxi-ng: add support for H6 PRCM CCU
> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
> >>
> >
> >
> >
> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
> > not included in the pull request?
> >
> >
> > You said "I've picked it up"
> > https://patchwork.kernel.org/patch/10348031/
>
> It looks like it was accidentally dropped after a rebase.
> Not quite sure what happened there. Maxime?
I'm not quite sure what happened, sorry, but this should have
definitely been part of that PR :/
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/3b37b191/attachment.sig>
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2] arm: sun4i: Add support for Pengpod 1000 tablet
From: Hans de Goede @ 2018-06-13 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2787b2a-230d-ea3c-89b9-316ddcd20f67@settrans.net>
Hi,
On 05-06-18 20:18, Bob Ham wrote:
> On 05/06/18 15:50, Maxime Ripard wrote:
>> On Mon, Jun 04, 2018 at 06:33:02PM +0100, Bob Ham wrote:
>>> On 04/06/18 09:13, Maxime Ripard wrote:
>>>> On Sat, Jun 02, 2018 at 05:03:13PM +0100, Bob Ham wrote:
>>>
>>>>> + * This file is dual-licensed: you can use it either under the terms
>>>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>>>> + * licensing only applies to this file, and not this project as a
>>>>> + * whole.
>>>
>>>>> + * The above copyright notice and this permission notice shall be
>>>>> + * included in all copies or substantial portions of the Software.
>>>
>>>> And this is redundant with the SPDX header.
>>>
>>> The X11 license notice states explicitly that the notice has to be
>>> included in the file. Wouldn't removing it be a violation of the license?
>>
>> The SPDX header is explicitly here to remove the license text and
>> create a tag that is in a indirect reference to the license text in
>> LICENSES. It's not going away.
>
> Well, the top bit that I quoted above says that the licenses refer to
> only that one file in particular and not the project as a whole. Then
> the X11 license states that the notice can't be removed from 'this
> software and associated documentation files (the "Software")' which
> would seem to refer to the single file. Therefore, removing the notice
> from the single file and replacing it with an SPDX header would seem to
> violate the license.
>
> It's a fine point but it makes me nervous. I originally based my .dts
> on sun4i-a10-inet1.dts. I've CC'd the original copyright holder, Hans
> de Goede. Hans, are you willing to give permission for the license
> notice to be replaced with just an SPDX header indicating the dual
> licensing?
Yes that is fine by me and you've my permission to switch to using
just the SPDX header.
FWIW I do not believe the "can't be removed from 'this software and
associated documentation files (the "Software")'" language
applies to the software as a whole and not individual files.
> While we're at it, there are a number of other files with the same
> license text. Hans, are you prepared to give permission for your other
> license notices to be replaced with SPDX headers?
Yes you may make the same change to all files with my copyright.
Regards,
Hans
^ permalink raw reply
* [PATCH 4/4] net: emaclite: Remove xemaclite_mdio_setup return check
From: Andrew Lunn @ 2018-06-13 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-5-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:19PM +0530, Radhey Shyam Pandey wrote:
> Errors are already reported in xemaclite_mdio_setup so avoid
> reporting it again.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> index ec4608e..2a0c06e 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> @@ -1143,9 +1143,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
> xemaclite_update_address(lp, ndev->dev_addr);
>
> lp->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
> - rc = xemaclite_mdio_setup(lp, &ofdev->dev);
> - if (rc)
> - dev_warn(&ofdev->dev, "error registering MDIO bus\n");
> + xemaclite_mdio_setup(lp, &ofdev->dev);
>
> dev_info(dev, "MAC address is now %pM\n", ndev->dev_addr);
The patch itself is O.K.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
However, do you want to keep going if the MDIO bus fails? Maybe you
should failed the probe?
Andrew
^ permalink raw reply
* [PATCH 0/2] Enable VDMA S2MM vertical flip support
From: Radhey Shyam Pandey @ 2018-06-13 7:34 UTC (permalink / raw)
To: linux-arm-kernel
The AXI VDMA core supports Vertical Flip with S2MM as the path when
Enable Vertical Flip (Advanced tab) is selected. This patch series add
DT property for vertical flip and program its state in VDMA start_transfer.
Radhey Shyam Pandey (2):
dt-bindings: dmaengine: xilinx_dma: Add VDMA vertical flip property
dmaengine: xilinx_dma: Enable VDMA S2MM vertical flip support
.../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 +
drivers/dma/xilinx/xilinx_dma.c | 22 ++++++++++++++++++++
include/linux/dma/xilinx_dma.h | 2 +
3 files changed, 26 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 1/2] dt-bindings: dmaengine: xilinx_dma: Add VDMA vertical flip property
From: Radhey Shyam Pandey @ 2018-06-13 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528875288-9140-1-git-send-email-radhey.shyam.pandey@xilinx.com>
The AXI VDMA core supports Vertical flip in S2MM path when Enable
Vertical Flip (Advanced tab) is selected. To allow vertical flip
programming define an optional 'xlnx,enable-vert-flip' channel
child node property.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
.../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfa..174af2c 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -66,6 +66,8 @@ Optional child node properties:
Optional child node properties for VDMA:
- xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
+- xlnx,enable-vert-flip: Tells vertical flip is
+ enabled/disabled in hardware(S2MM path).
Optional child node properties for AXI DMA:
-dma-channels: Number of dma channels in child node.
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] dmaengine: xilinx_dma: Enable VDMA S2MM vertical flip support
From: Radhey Shyam Pandey @ 2018-06-13 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528875288-9140-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Vertical flip state is exported in xilinx_vdma_config and depending
on IP configuration(c_enable_vert_flip) vertical flip state is
programmed in hardware.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/dma/xilinx/xilinx_dma.c | 22 ++++++++++++++++++++++
include/linux/dma/xilinx_dma.h | 2 ++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 27b5235..c124423 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -115,6 +115,9 @@
#define XILINX_VDMA_REG_START_ADDRESS(n) (0x000c + 4 * (n))
#define XILINX_VDMA_REG_START_ADDRESS_64(n) (0x000c + 8 * (n))
+#define XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP 0x00ec
+#define XILINX_VDMA_ENABLE_VERTICAL_FLIP BIT(0)
+
/* HW specific definitions */
#define XILINX_DMA_MAX_CHANS_PER_DEVICE 0x20
@@ -340,6 +343,7 @@ struct xilinx_dma_tx_descriptor {
* @start_transfer: Differentiate b/w DMA IP's transfer
* @stop_transfer: Differentiate b/w DMA IP's quiesce
* @tdest: TDEST value for mcdma
+ * @has_vflip: S2MM vertical flip
*/
struct xilinx_dma_chan {
struct xilinx_dma_device *xdev;
@@ -376,6 +380,7 @@ struct xilinx_dma_chan {
void (*start_transfer)(struct xilinx_dma_chan *chan);
int (*stop_transfer)(struct xilinx_dma_chan *chan);
u16 tdest;
+ bool has_vflip;
};
/**
@@ -1092,6 +1097,14 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
desc->async_tx.phys);
/* Configure the hardware using info in the config structure */
+ if (chan->has_vflip) {
+ reg = dma_read(chan, XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP);
+ reg &= ~XILINX_VDMA_ENABLE_VERTICAL_FLIP;
+ reg |= config->vflip_en;
+ dma_write(chan, XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP,
+ reg);
+ }
+
reg = dma_ctrl_read(chan, XILINX_DMA_REG_DMACR);
if (config->frm_cnt_en)
@@ -2105,6 +2118,8 @@ int xilinx_vdma_channel_set_config(struct dma_chan *dchan,
}
chan->config.frm_cnt_en = cfg->frm_cnt_en;
+ chan->config.vflip_en = cfg->vflip_en;
+
if (cfg->park)
chan->config.park_frm = cfg->park_frm;
else
@@ -2428,6 +2443,13 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
+ chan->has_vflip = of_property_read_bool(node,
+ "xlnx,enable-vert-flip");
+ if (chan->has_vflip) {
+ chan->config.vflip_en = dma_read(chan,
+ XILINX_VDMA_REG_ENABLE_VERTICAL_FLIP) &
+ XILINX_VDMA_ENABLE_VERTICAL_FLIP;
+ }
chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
diff --git a/include/linux/dma/xilinx_dma.h b/include/linux/dma/xilinx_dma.h
index 34b98f2..5b6e61e 100644
--- a/include/linux/dma/xilinx_dma.h
+++ b/include/linux/dma/xilinx_dma.h
@@ -27,6 +27,7 @@
* @delay: Delay counter
* @reset: Reset Channel
* @ext_fsync: External Frame Sync source
+ * @vflip_en: Vertical Flip enable
*/
struct xilinx_vdma_config {
int frm_dly;
@@ -39,6 +40,7 @@ struct xilinx_vdma_config {
int delay;
int reset;
int ext_fsync;
+ bool vflip_en;
};
int xilinx_vdma_channel_set_config(struct dma_chan *dchan,
--
1.7.1
^ permalink raw reply related
* [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
From: Maxime Ripard @ 2018-06-13 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-5-jernej.skrabec@siol.net>
Hi,
Thanks for working on this!
On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> TCON TOP main purpose is to configure whole display pipeline. It
> determines relationships between mixers and TCONs, selects source TCON
> for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
> clock source and contains additional TV TCON and DSI gates.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
> include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
> 2 files changed, 56 insertions(+)
> create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 3346c1e2a7a0..ef64c589a4b3 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
> - 'lvds-alt': An alternative clock source, separate from the TCON channel 0
> clock, that can be used to drive the LVDS clock
>
> +TCON TOP
> +--------
> +
> +TCON TOPs main purpose is to configure whole display pipeline. It determines
> +relationships between mixers and TCONs, selects source TCON for HDMI, muxes
> +LCD and TV encoder GPIO output, selects TV encoder clock source and contains
> +additional TV TCON and DSI gates.
> +
> +It allows display pipeline to be configured in very different ways:
> +
> + / LCD0/LVDS0
> + / TCON-LCD0
> + | \ MIPI DSI
> + mixer0 |
> + \ / TCON-LCD1 - LCD1/LVDS1
> + TCON-TOP
> + / \ TCON-TV0 - TVE0/RGB
> + mixer1 | \
> + | TCON-TOP - HDMI
> + | /
> + \ TCON-TV1 - TVE1/RGB
> +
> +Note that both TCON TOP references same physical unit.
> +
> +Required properties:
> + - compatible: value must be one of:
> + * allwinner,sun8i-r40-tcon-top
> + - reg: base address and size of the memory-mapped region.
> + - clocks: phandle to the clocks feeding the TCON TOP
> + * bus: TCON TOP interface clock
> + - clock-names: clock name mentioned above
> + - resets: phandle to the reset line driving the DRC
s/DRC/TCON TOP/ ?
> + * rst: TCON TOP reset line
Remaining consistent with the clock name would be great
> + - reset-names: reset name mentioned above
> + - #clock-cells : must contain 1
An example would be nice here
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
> + should be the input for mixer0 mux. The second should be the output for that
> + mux. Third port should be input for mixer1 mux. Fourth port should be output
> + for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
> + be output for it. All output endpoints should have reg property with the id
> + of the target TCON. All ports should have only one enpoint connected to
^ endpoint
I guess it would me more readable if you were to make it a bullet
list, but this works for me otherwise.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/22350a8e/attachment.sig>
^ permalink raw reply
* [PATCH 26/28] drm/mediatek: add DPI1/DSI1/DSI2/DSI3 in comp_init
From: CK Hu @ 2018-06-13 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-27-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add components DPI1/DSI1/DSI2/DSI3 in comp_init.
> Because the some parameter for these components initialized
> in their driver.
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 22f4c72fa785..ff974d82a4a6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -278,7 +278,11 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
>
> if (comp_id == DDP_COMPONENT_BLS ||
> comp_id == DDP_COMPONENT_DPI0 ||
> + comp_id == DDP_COMPONENT_DPI1 ||
Why not move this modification to the patch 'add component DPI1'?
> comp_id == DDP_COMPONENT_DSI0 ||
> + comp_id == DDP_COMPONENT_DSI1 ||
> + comp_id == DDP_COMPONENT_DSI2 ||
Why not move this modification to the patch 'add component DSI2'?
> + comp_id == DDP_COMPONENT_DSI3 ||
Why not move this modification to the patch 'add component DSI3'?
Regards,
CK
> comp_id == DDP_COMPONENT_PWM0) {
> comp->regs = NULL;
> comp->clk = NULL;
^ permalink raw reply
* [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
From: Maxime Ripard @ 2018-06-13 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-25-jernej.skrabec@siol.net>
On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> Function is useful when drm_of_find_possible_crtcs() can't be used and
> custom parsing is needed. This can happen for example when there is a
> node with multiple muxes between crtc and encoder.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/drm_of.c | 4 ++--
> include/drm/drm_of.h | 8 ++++++++
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 1fe122461298..2e9cea3287b2 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
> * Given a port OF node, return the possible mask of the corresponding
> * CRTC within a device's list of CRTCs. Returns zero if not found.
> */
> -static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> - struct device_node *port)
> +uint32_t drm_crtc_port_mask(struct drm_device *dev,
> + struct device_node *port)
It should probably be exported too?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/60f38f14/attachment.sig>
^ permalink raw reply
* [PATCH 27/28] drm/mediatek: add third ddp path
From: CK Hu @ 2018-06-13 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-28-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch create third crtc by third ddp path
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 5 ++++-
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 658b8dd45b83..2d6aa150a9ff 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> int ret;
> int i;
>
> + if (!path)
> + return 0;
> +
> for (i = 0; i < path_len; i++) {
> enum mtk_ddp_comp_id comp_id = path[i];
> struct device_node *node;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 08d5d0b47bfe..3d279a299383 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -232,6 +232,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> if (ret < 0)
> goto err_component_unbind;
>
> + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> + private->data->third_len);
> + if (ret < 0)
> + goto err_component_unbind;
> +
> /* Use OVL device for all DMA memory allocations */
> np = private->comp_node[private->data->main_path[0]] ?:
> private->comp_node[private->data->ext_path[0]];
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index c3378c452c0a..ecc00ca3221d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -17,7 +17,7 @@
> #include <linux/io.h>
> #include "mtk_drm_ddp_comp.h"
>
> -#define MAX_CRTC 2
> +#define MAX_CRTC 3
> #define MAX_CONNECTOR 2
>
> struct device;
> @@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
> unsigned int main_len;
> const enum mtk_ddp_comp_id *ext_path;
> unsigned int ext_len;
> + const enum mtk_ddp_comp_id *third_path;
> + unsigned int third_len;
> +
> bool shadow_register;
> };
>
^ permalink raw reply
* [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
From: Maxime Ripard @ 2018-06-13 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-15-jernej.skrabec@siol.net>
On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> sense to check if panel or bridge is connected to them.
>
> Check if TCON has channel 0 and only then check for connected panel or
> bridges.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index b1205a7bc20f..c9ffa5381185 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
> static int sun4i_tcon_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> + const struct sun4i_tcon_quirks *quirks;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> int ret;
>
> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> - if (ret == -EPROBE_DEFER)
> - return ret;
> + quirks = of_device_get_match_data(&pdev->dev);
We should probably check ofr the pointer value before dereferencing it.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/86d5ae0a/attachment-0001.sig>
^ permalink raw reply
* [PATCH 13/28] drm/mediatek: add connection from RDMA0 to DSI3
From: Stu Hsieh @ 2018-06-13 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528868751.15127.10.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 13:45 +0800, CK Hu wrote:
> Hi, Stu:
>
> Two inline comment.
>
> On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > This patch add the connection from RDMA0 to DSI3
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index c08aed8dae44..fed1b5704355 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -83,6 +83,7 @@
> > #define GAMMA_MOUT_EN_RDMA1 0x1
> > #define RDMA0_MOUT_DPI0 0x2
> > #define RDMA0_MOUT_DSI2 0x4
> > +#define RDMA0_MOUT_DSI3 0x5
>
> Usually, each bit of a mout register represent a output enable. Is this
> value 0x5 is a correct value?
In hw CONFIG SPEC show as following:
Bit(s) Name Description
2:0 DISP_PATH0_SOUT_SEL_IN 0 : Output to DSI0
1: Ooutput to DSI1
2: Ooutput to DPI
3: Ooutput to DPI1
4: Ooutput to DSI2
5: Ooutput to DSI3
6 : reserved
7: Ooutput to DISP_UFOE
So, the value 0x5 is correct value.
Regard,
Stu
>
> > #define RDMA1_MOUT_DPI0 0x2
> > #define DPI0_SEL_IN_RDMA1 0x1
> > #define COLOR1_SEL_IN_OVL1 0x1
> > @@ -164,6 +165,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> > *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> > value = RDMA0_MOUT_DSI2;
> > + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> > + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> > + value = RDMA0_MOUT_DSI3;
> > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > value = RDMA1_MOUT_DPI0;
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index fe6fdc021fc7..22f4c72fa785 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -228,7 +228,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> > [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> > [DDP_COMPONENT_DSI2] = { MTK_DSI, 2, NULL },
> > - [DDP_COMPONENT_DSI2] = { MTK_DSI, 3, NULL },
> > + [DDP_COMPONENT_DSI3] = { MTK_DSI, 3, NULL },
>
> I think this is not related to this patch.
OK
>
> Regards,
> CK
>
> > [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> > [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> > [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
>
>
^ permalink raw reply
* [PATCH 28/28] drm/mediatek: Add support for mediatek SOC MT2712
From: CK Hu @ 2018-06-13 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-29-git-send-email-stu.hsieh@mediatek.com>
Hi, Stu:
On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> This patch add support for the Mediatek MT2712 DISP subsystem.
> There are two OVL engine and three disp output in MT2712.
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39 ++++++++++++++++++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +++++++++++++++++++++++++++++++++
> 2 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 28dd8531a7de..c3fa5591bfc8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -65,6 +65,24 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 24
> #define MT8173_MUTEX_MOD_DISP_OD 25
>
> +#define MT2712_MUTEX_MOD_DISP_PWM2 10
> +#define MT2712_MUTEX_MOD_DISP_OVL0 11
> +#define MT2712_MUTEX_MOD_DISP_OVL1 12
> +#define MT2712_MUTEX_MOD_DISP_RDMA0 13
> +#define MT2712_MUTEX_MOD_DISP_RDMA1 14
> +#define MT2712_MUTEX_MOD_DISP_RDMA2 15
> +#define MT2712_MUTEX_MOD_DISP_WDMA0 16
> +#define MT2712_MUTEX_MOD_DISP_WDMA1 17
> +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> +#define MT2712_MUTEX_MOD_DISP_AAL0 20
> +#define MT2712_MUTEX_MOD_DISP_UFOE 22
> +#define MT2712_MUTEX_MOD_DISP_PWM0 23
> +#define MT2712_MUTEX_MOD_DISP_PWM1 24
> +#define MT2712_MUTEX_MOD_DISP_OD0 25
> +#define MT2712_MUTEX_MOD2_DISP_AAL1 33
> +#define MT2712_MUTEX_MOD2_DISP_OD1 34
> +
> #define MT2701_MUTEX_MOD_DISP_OVL 3
> #define MT2701_MUTEX_MOD_DISP_WDMA 6
> #define MT2701_MUTEX_MOD_DISP_COLOR 7
> @@ -138,6 +156,26 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> };
>
> +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -533,6 +571,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
>
> static const struct of_device_id ddp_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> + { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
> { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> {},
> };
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 3d279a299383..3a866e1d6af4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> DDP_COMPONENT_DPI0,
> };
>
> +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_PWM0,
> +};
> +
> +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
> + DDP_COMPONENT_OVL1,
> + DDP_COMPONENT_COLOR1,
> + DDP_COMPONENT_AAL1,
> + DDP_COMPONENT_OD1,
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_DPI1,
> + DDP_COMPONENT_PWM1,
> +};
> +
> +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
> + DDP_COMPONENT_RDMA2,
> + DDP_COMPONENT_DSI3,
> + DDP_COMPONENT_PWM2,
> +};
> +
> static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> @@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .shadow_register = true,
> };
>
> +static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> + .main_path = mt2712_mtk_ddp_main,
> + .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
> + .ext_path = mt2712_mtk_ddp_ext,
> + .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
> + .third_path = mt2712_mtk_ddp_third,
> + .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
> +};
> +
> static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> .main_path = mt8173_mtk_ddp_main,
> .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> @@ -379,6 +414,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> + { .compatible = "mediatek,mt2712-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
> { .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
> @@ -557,6 +593,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
> static const struct of_device_id mtk_drm_of_ids[] = {
> { .compatible = "mediatek,mt2701-mmsys",
> .data = &mt2701_mmsys_driver_data},
> + { .compatible = "mediatek,mt2712-mmsys",
> + .data = &mt2712_mmsys_driver_data},
> { .compatible = "mediatek,mt8173-mmsys",
> .data = &mt8173_mmsys_driver_data},
> { }
^ permalink raw reply
* [PATCH 14/28] drm/mediatek: add connection from RDMA1 to DPI1
From: Stu Hsieh @ 2018-06-13 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528870410.15127.11.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 14:13 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > This patch add the connection from RDMA1 to DPI1
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index fed1b5704355..4abd5dabeccf 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -85,7 +85,9 @@
> > #define RDMA0_MOUT_DSI2 0x4
> > #define RDMA0_MOUT_DSI3 0x5
> > #define RDMA1_MOUT_DPI0 0x2
> > +#define RDMA1_MOUT_DPI1 0x3
>
> Usually, each bit of a mout register represent a output enable. Is this
> value 0x3 a correct value?
>
> Regards,
> CK
>
In HW CONFIG SPEC show as following
Bit(s) Name Description
2:0 DISP_PATH1_SOUT_SEL_IN 0 : Output to DSI0
1: Ooutput to DSI1
2: Ooutput to DPI
3: Ooutput to DPI1
4: Ooutput to DSI2
5: Ooutput to DSI3
6 : reserved
7: Ooutput to DISP_UFOE
So, 0x3 is correct value
Regard,
Stu
> > #define DPI0_SEL_IN_RDMA1 0x1
> > +#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > #define COLOR1_SEL_IN_OVL1 0x1
> >
> > #define OVL_MOUT_EN_RDMA 0x1
> > @@ -171,6 +173,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > value = RDMA1_MOUT_DPI0;
> > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > + value = RDMA1_MOUT_DPI1;
> > } else {
> > value = 0;
> > }
> > @@ -190,6 +195,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > value = DPI0_SEL_IN_RDMA1;
> > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > + value = DPI1_SEL_IN_RDMA1;
> > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > value = COLOR1_SEL_IN_OVL1;
>
>
^ permalink raw reply
* [PATCH 19/28] drm/mediatek: add connection from RDMA2 to DPI1
From: Stu Hsieh @ 2018-06-13 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528874037.30263.6.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 15:13 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > This patch add the connection from RDMA2 to DPI1
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 31a0832ef9ec..2d883815d79c 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -93,9 +93,11 @@
> > #define RDMA1_MOUT_DPI0 0x2
> > #define RDMA1_MOUT_DPI1 0x3
> > #define RDMA2_MOUT_DPI0 0x2
> > +#define RDMA2_MOUT_DPI1 0x3
>
> Usually, each bit of a mout register represent a output enable. Is this
> value 0x3 a correct value?
>
> Regards,
> CK
>
In HW CONFIG SPEC or MT2712_E2_MMSYS_Change_note show as following:
Bit(s) Name Description
2:0 DISP_RDMA2_SOUT_SEL_IN 0: output to dsi0
1: outptu to dsi1
2: output to dpi0
3: output to dpi1
4: output to dsi2
5: output to dsi3
So, 0x3 is correct value.
Regard,
Stu
> > #define DPI0_SEL_IN_RDMA1 0x1
> > #define DPI0_SEL_IN_RDMA2 0x3
> > #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
> > #define DSI1_SEL_IN_RDMA1 0x1
> > #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> > #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> > @@ -199,6 +201,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > value = RDMA2_MOUT_DPI0;
> > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > + value = RDMA2_MOUT_DPI1;
> > } else {
> > value = 0;
> > }
> > @@ -233,6 +238,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > value = DPI0_SEL_IN_RDMA2;
> > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > + value = DPI1_SEL_IN_RDMA2;
> > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > value = COLOR1_SEL_IN_OVL1;
>
>
^ permalink raw reply
* [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
From: Chen-Yu Tsai @ 2018-06-13 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613074621.5phumovcyymbkfbn@flea>
On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
>> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
>> sense to check if panel or bridge is connected to them.
>>
>> Check if TCON has channel 0 and only then check for connected panel or
>> bridges.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index b1205a7bc20f..c9ffa5381185 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
>> static int sun4i_tcon_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> + const struct sun4i_tcon_quirks *quirks;
>> struct drm_bridge *bridge;
>> struct drm_panel *panel;
>> int ret;
>>
>> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
>> - if (ret == -EPROBE_DEFER)
>> - return ret;
>> + quirks = of_device_get_match_data(&pdev->dev);
>
> We should probably check ofr the pointer value before dereferencing it.
I think we've discussed this before. If the driver has data structures
for all the supported compatible strings, and it is device tree only,
then we should just let it blow up in the user's face, since they are
obviously doing something they shouldn't be doing to get the driver
to probe without a compatible string match.
ChenYu
^ permalink raw reply
* [PATCH 13/28] drm/mediatek: add connection from RDMA0 to DSI3
From: CK Hu @ 2018-06-13 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528875983.11190.29.camel@mtksdccf07>
Hi, Stu:
On Wed, 2018-06-13 at 15:46 +0800, Stu Hsieh wrote:
> Hi, CK:
>
> On Wed, 2018-06-13 at 13:45 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > Two inline comment.
> >
> > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > This patch add the connection from RDMA0 to DSI3
> > >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> > > 2 files changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index c08aed8dae44..fed1b5704355 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -83,6 +83,7 @@
> > > #define GAMMA_MOUT_EN_RDMA1 0x1
> > > #define RDMA0_MOUT_DPI0 0x2
> > > #define RDMA0_MOUT_DSI2 0x4
> > > +#define RDMA0_MOUT_DSI3 0x5
> >
> > Usually, each bit of a mout register represent a output enable. Is this
> > value 0x5 is a correct value?
>
> In hw CONFIG SPEC show as following:
> Bit(s) Name Description
> 2:0 DISP_PATH0_SOUT_SEL_IN 0 : Output to DSI0
> 1: Ooutput to DSI1
> 2: Ooutput to DPI
> 3: Ooutput to DPI1
> 4: Ooutput to DSI2
> 5: Ooutput to DSI3
> 6 : reserved
> 7: Ooutput to DISP_UFOE
> So, the value 0x5 is correct value.
>
>From the definition, it looks like that RDMA0 could only single output
(output to only one destination at one moment). The register naming
'DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN' (MOUT means output to multiple
destination simultaneously) would confuse me. If the data sheet use the
confused naming, I think I could just accept it.
Regards,
CK
> Regard,
> Stu
>
> >
> > > #define RDMA1_MOUT_DPI0 0x2
> > > #define DPI0_SEL_IN_RDMA1 0x1
> > > #define COLOR1_SEL_IN_OVL1 0x1
> > > @@ -164,6 +165,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
> > > *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> > > value = RDMA0_MOUT_DSI2;
> > > + } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
> > > + *addr = DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN;
> > > + value = RDMA0_MOUT_DSI3;
> > > } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> > > value = RDMA1_MOUT_DPI0;
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index fe6fdc021fc7..22f4c72fa785 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -228,7 +228,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> > > [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> > > [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> > > [DDP_COMPONENT_DSI2] = { MTK_DSI, 2, NULL },
> > > - [DDP_COMPONENT_DSI2] = { MTK_DSI, 3, NULL },
> > > + [DDP_COMPONENT_DSI3] = { MTK_DSI, 3, NULL },
> >
> > I think this is not related to this patch.
> OK
>
> >
> > Regards,
> > CK
> >
> > > [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> > > [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> > > [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
> >
> >
>
>
^ permalink raw reply
* [PATCH 26/28] drm/mediatek: add DPI1/DSI1/DSI2/DSI3 in comp_init
From: Stu Hsieh @ 2018-06-13 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528875305.30263.14.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 15:35 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > This patch add components DPI1/DSI1/DSI2/DSI3 in comp_init.
> > Because the some parameter for these components initialized
> > in their driver.
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 22f4c72fa785..ff974d82a4a6 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -278,7 +278,11 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> >
> > if (comp_id == DDP_COMPONENT_BLS ||
> > comp_id == DDP_COMPONENT_DPI0 ||
> > + comp_id == DDP_COMPONENT_DPI1 ||
>
> Why not move this modification to the patch 'add component DPI1'?
>
> > comp_id == DDP_COMPONENT_DSI0 ||
> > + comp_id == DDP_COMPONENT_DSI1 ||
> > + comp_id == DDP_COMPONENT_DSI2 ||
>
> Why not move this modification to the patch 'add component DSI2'?
>
> > + comp_id == DDP_COMPONENT_DSI3 ||
>
> Why not move this modification to the patch 'add component DSI3'?
>
> Regards,
> CK
>
ok
Regard,
Stu
> > comp_id == DDP_COMPONENT_PWM0) {
> > comp->regs = NULL;
> > comp->clk = NULL;
>
>
^ permalink raw reply
* [PATCH v2 2/5] dt: qcom: 8996: thermal: Move to DT initialisation
From: Amit Kucheria @ 2018-06-13 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612193507.GO14924@minitux>
On Tue, Jun 12, 2018 at 10:35 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Tue 12 Jun 03:54 PDT 2018, Amit Kucheria wrote:
>
>> We also split up the regmap address space into two, one for the TM
>> registers, the other for the SROT registers. This was required to deal with
>> different address offsets for the TM and SROT registers across different
>> SoC families.
>>
>> Since tsens-common.c/init_common() currently only registers one address space, the order is important (TM before SROT).This is OK since the code doesn't really use the SROT functionality yet.
>
> Please line wrap this.
>
>>
>> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
>> ---
>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++++++++++-
>> drivers/thermal/qcom/tsens-8996.c | 1 -
>> 2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> index 410ae78..b4aab18 100644
>> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>> @@ -451,7 +451,17 @@
>>
>> tsens0: thermal-sensor at 4a8000 {
>> compatible = "qcom,msm8996-tsens";
>> - reg = <0x4a8000 0x2000>;
>> + reg = <0x4a9000 0x1000>, /* TM */
>> + <0x4a8000 0x1000>; /* SROT */
>> + #qcom,sensors = <13>;
>> + #thermal-sensor-cells = <1>;
>> + };
>> +
>> + tsens1: thermal-sensor at 4ac000 {
>> + compatible = "qcom,msm8996-tsens";
>> + reg = <0x4ad000 0x1000>, /* TM */
>> + <0x4ac000 0x1000>; /* SROT */
>> + #qcom,sensors = <8>;
>> #thermal-sensor-cells = <1>;
>> };
>>
>> diff --git a/drivers/thermal/qcom/tsens-8996.c b/drivers/thermal/qcom/tsens-8996.c
>> index e1f7781..6e59078 100644
>> --- a/drivers/thermal/qcom/tsens-8996.c
>> +++ b/drivers/thermal/qcom/tsens-8996.c
>> @@ -79,6 +79,5 @@ static const struct tsens_ops ops_8996 = {
>> };
>>
>> const struct tsens_data data_8996 = {
>> - .num_sensors = 13,
>
> This will cause the current 8996 dts to fail probing the tsens. I think
> you should just leave this as is, because specifying qcom,sensors in dts
> will overwrite this number regardless.
Ack, I didn't consider backword compatility of the code with the
current dts. Will fix.
> It also would make this change dts specific, which is convenient as it
> breaks the interdependency between the different subsystems.
>
>> .ops = &ops_8996,
>
> Regards,
> Bjorn
^ permalink raw reply
* [PATCH 19/28] drm/mediatek: add connection from RDMA2 to DPI1
From: CK Hu @ 2018-06-13 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528876862.11190.35.camel@mtksdccf07>
Hi, Stu:
On Wed, 2018-06-13 at 16:01 +0800, Stu Hsieh wrote:
> Hi, CK:
>
>
> On Wed, 2018-06-13 at 15:13 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Mon, 2018-06-11 at 11:26 +0800, Stu Hsieh wrote:
> > > This patch add the connection from RDMA2 to DPI1
> > >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index 31a0832ef9ec..2d883815d79c 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -93,9 +93,11 @@
> > > #define RDMA1_MOUT_DPI0 0x2
> > > #define RDMA1_MOUT_DPI1 0x3
> > > #define RDMA2_MOUT_DPI0 0x2
> > > +#define RDMA2_MOUT_DPI1 0x3
> >
> > Usually, each bit of a mout register represent a output enable. Is this
> > value 0x3 a correct value?
> >
> > Regards,
> > CK
> >
> In HW CONFIG SPEC or MT2712_E2_MMSYS_Change_note show as following:
>
> Bit(s) Name Description
> 2:0 DISP_RDMA2_SOUT_SEL_IN 0: output to dsi0
> 1: outptu to dsi1
> 2: output to dpi0
> 3: output to dpi1
> 4: output to dsi2
> 5: output to dsi3
>
> So, 0x3 is correct value.
The data sheet use the term SOUT match its function, so I think driver
have better change the naming to SOUT.
Regards,
CK
>
> Regard,
> Stu
>
> > > #define DPI0_SEL_IN_RDMA1 0x1
> > > #define DPI0_SEL_IN_RDMA2 0x3
> > > #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> > > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
> > > #define DSI1_SEL_IN_RDMA1 0x1
> > > #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> > > #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> > > @@ -199,6 +201,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > value = RDMA2_MOUT_DPI0;
> > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> > > + value = RDMA2_MOUT_DPI1;
> > > } else {
> > > value = 0;
> > > }
> > > @@ -233,6 +238,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> > > } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> > > *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > value = DPI0_SEL_IN_RDMA2;
> > > + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> > > + *addr = DISP_REG_CONFIG_DPI_SEL_IN;
> > > + value = DPI1_SEL_IN_RDMA2;
> > > } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
> > > *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
> > > value = COLOR1_SEL_IN_OVL1;
> >
> >
>
>
^ 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