* [PATCH 17/28] drm/mediatek: add connection from RDMA1 to DSI3
From: CK Hu @ 2018-06-13 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-18-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 connection from RDMA1 to DSI3
>
> 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 c3e647b04ffd..a5cee4b7f908 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -88,12 +88,14 @@
> #define RDMA0_MOUT_DSI3 0x5
> #define RDMA1_MOUT_DSI1 0x1
> #define RDMA1_MOUT_DSI2 0x4
> +#define RDMA1_MOUT_DSI3 0x5
Usually, each bit of a mout register represent a output enable. Is this
value 0x5 a correct value?
Regards,
CK
> #define RDMA1_MOUT_DPI0 0x2
> #define RDMA1_MOUT_DPI1 0x3
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> +#define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -182,6 +184,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> + value = RDMA1_MOUT_DSI3;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI0;
> @@ -216,6 +221,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> value = DSI2_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> + value = DSI3_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 v2 05/27] drm/sun4i: Add TCON TOP driver
From: kbuild test robot @ 2018-06-13 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-6-jernej.skrabec@siol.net>
Hi Jernej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17 next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jernej-Skrabec/clk-sunxi-ng-r40-Add-minimal-rate-for-video-PLLs/20180613-041046
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `init_module':
>> sun8i_tcon_top.c:(.init.text+0x0): multiple definition of `init_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.init.text+0x0): first defined here
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `cleanup_module':
>> sun8i_tcon_top.c:(.exit.text+0x0): multiple definition of `cleanup_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.exit.text+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43418 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/44b6eb84/attachment-0001.gz>
^ permalink raw reply
* [PATCH 18/28] drm/mediatek: add connection from RDMA2 to DPI0
From: CK Hu @ 2018-06-13 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-19-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 connection from RDMA2 to DPI0
>
> 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 | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index a5cee4b7f908..31a0832ef9ec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -31,6 +31,7 @@
> #define DISP_REG_CONFIG_DSIE_SEL_IN 0x0a4
> #define DISP_REG_CONFIG_DSIO_SEL_IN 0x0a8
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT 0x0b8
> #define DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN 0x0c4
> #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> #define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
> @@ -91,7 +92,9 @@
> #define RDMA1_MOUT_DSI3 0x5
> #define RDMA1_MOUT_DPI0 0x2
> #define RDMA1_MOUT_DPI1 0x3
> +#define RDMA2_MOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA1 0x1
> +#define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> @@ -193,6 +196,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_MOUT_DPI0;
> } else {
> value = 0;
> }
> @@ -224,6 +230,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
> *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
> value = DSI3_SEL_IN_RDMA1;
> + } 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_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: CK Hu @ 2018-06-13 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-20-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 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
> #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 20/28] drm/mediatek: add connection from RDMA2 to DSI1
From: CK Hu @ 2018-06-13 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-21-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 connection from RDMA2 to DSI1
>
> 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 | 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 2d883815d79c..ae10f8f1e140 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -94,11 +94,13 @@
> #define RDMA1_MOUT_DPI1 0x3
> #define RDMA2_MOUT_DPI0 0x2
> #define RDMA2_MOUT_DPI1 0x3
> +#define RDMA2_MOUT_DSI1 0x1
> #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 DSI1_SEL_IN_RDMA2 0x4
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
> @@ -198,6 +200,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> value = RDMA1_MOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_MOUT_DSI1;
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_MOUT_DPI0;
> @@ -241,6 +246,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } 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_RDMA2 && next == DDP_COMPONENT_DSI1) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI1_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 21/28] drm/mediatek: add connection from RDMA2 to DSI2
From: CK Hu @ 2018-06-13 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-22-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 connection from RDMA2 to DSI2
>
> 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 | 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 ae10f8f1e140..ce89a1d86b93 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -95,6 +95,7 @@
> #define RDMA2_MOUT_DPI0 0x2
> #define RDMA2_MOUT_DPI1 0x3
> #define RDMA2_MOUT_DSI1 0x1
> +#define RDMA2_MOUT_DSI2 0x4
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> @@ -102,6 +103,7 @@
> #define DSI1_SEL_IN_RDMA1 0x1
> #define DSI1_SEL_IN_RDMA2 0x4
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> +#define DSI2_SEL_IN_RDMA2 (0x4 << 16)
> #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> @@ -209,6 +211,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI1) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_MOUT_DPI1;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_MOUT_DSI2;
> } else {
> value = 0;
> }
> @@ -249,6 +254,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI1) {
> *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> value = DSI1_SEL_IN_RDMA2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI2_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 22/28] drm/mediatek: add connection from RDMA2 to DSI3
From: CK Hu @ 2018-06-13 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-23-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 connection from RDMA2 to DSI3
>
> 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 ce89a1d86b93..5a8569fa6505 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -96,6 +96,7 @@
> #define RDMA2_MOUT_DPI1 0x3
> #define RDMA2_MOUT_DSI1 0x1
> #define RDMA2_MOUT_DSI2 0x4
> +#define RDMA2_MOUT_DSI3 0x5
Usually, each bit of a mout register represent a output enable. Is this
value 0x5 a correct value?
Regards,
CK
> #define DPI0_SEL_IN_RDMA1 0x1
> #define DPI0_SEL_IN_RDMA2 0x3
> #define DPI1_SEL_IN_RDMA1 (0x1 << 8)
> @@ -105,6 +106,7 @@
> #define DSI2_SEL_IN_RDMA1 (0x1 << 16)
> #define DSI2_SEL_IN_RDMA2 (0x4 << 16)
> #define DSI3_SEL_IN_RDMA1 (0x1 << 16)
> +#define DSI3_SEL_IN_RDMA2 (0x4 << 16)
> #define COLOR1_SEL_IN_OVL1 0x1
>
> #define OVL_MOUT_EN_RDMA 0x1
> @@ -214,6 +216,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> value = RDMA2_MOUT_DSI2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
> + value = RDMA2_MOUT_DSI3;
> } else {
> value = 0;
> }
> @@ -257,6 +262,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI2) {
> *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> value = DSI2_SEL_IN_RDMA2;
> + } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI3_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 1/4] net: emaclite: Fix position of lp->mii_bus assignment
From: Andrew Lunn @ 2018-06-13 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528871719-1681-2-git-send-email-radhey.shyam.pandey@xilinx.com>
On Wed, Jun 13, 2018 at 12:05:16PM +0530, Radhey Shyam Pandey wrote:
> To ensure MDIO bus is not double freed in remove() path
> assign lp->mii_bus after MDIO bus registration.
>
> 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 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
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