* [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
* [GIT PULL] Allwinner clock changes for 4.18
From: Masahiro Yamada @ 2018-06-13 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613072649.dzbusalsfqlgymew@flea>
Hi.
2018-06-13 16:26 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.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 :/
>
Stephen offered to pick it up directly for -rc2.
Is that OK with you?
I am fine if it is well-organized between you and Stephen.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Paul Kocialkowski @ 2018-06-13 8:16 UTC (permalink / raw)
To: linux-arm-kernel
This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.
The offending commit triggers a run-time fault when accessing the panel
element of the sun4i_tcon structure when no such panel is attached.
It was apparently assumed in said commit that a panel is always used with
the TCON. Although it is often the case, this is not always true.
For instance a bridge might be used instead of a panel.
This issue was discovered using an A13-OLinuXino, that uses the TCON
in RGB mode for a simple DAC-based VGA bridge.
Cc: stable at vger.kernel.org
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -------------------------
1 file changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c3d92d537240..8045871335b5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -17,7 +17,6 @@
#include <drm/drm_encoder.h>
#include <drm/drm_modes.h>
#include <drm/drm_of.h>
-#include <drm/drm_panel.h>
#include <uapi/drm/drm_mode.h>
@@ -350,9 +349,6 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon,
static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
const struct drm_display_mode *mode)
{
- struct drm_panel *panel = tcon->panel;
- struct drm_connector *connector = panel->connector;
- struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -410,27 +406,6 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
- /*
- * On A20 and similar SoCs, the only way to achieve Positive Edge
- * (Rising Edge), is setting dclk clock phase to 2/3(240?).
- * By default TCON works in Negative Edge(Falling Edge),
- * this is why phase is set to 0 in that case.
- * Unfortunately there's no way to logically invert dclk through
- * IO_POL register.
- * The only acceptable way to work, triple checked with scope,
- * is using clock phase set to 0? for Negative Edge and set to 240?
- * for Positive Edge.
- * On A33 and similar SoCs there would be a 90? phase option,
- * but it divides also dclk by 2.
- * Following code is a way to avoid quirks all around TCON
- * and DOTCLOCK drivers.
- */
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
-
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
-
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
val);
--
2.17.0
^ permalink raw reply related
* [PATCH 14/28] drm/mediatek: add connection from RDMA1 to DPI1
From: CK Hu @ 2018-06-13 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528876574.11190.32.camel@mtksdccf07>
Hi, Stu:
On Wed, 2018-06-13 at 15:56 +0800, Stu Hsieh wrote:
> 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
It looks like that RDMA1 output is also SOUT, use the naming SOUT would
be better.
Regards,
CK
>
> 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] MAINTAINERS: Remove the AT91 clk driver entry
From: Boris Brezillon @ 2018-06-13 8:29 UTC (permalink / raw)
To: linux-arm-kernel
I've stopped actively maintaining this driver for quite some time
already, and at91 maintainers are doing a good job at maintaining it.
Remove the AT91 clk driver entry so that the driver automatically
falls under the "ARM/Microchip (AT91) SoC support" entry.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
---
MAINTAINERS | 5 -----
1 file changed, 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 634abf4569c4..491cc42ab65f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1242,11 +1242,6 @@ F: arch/arm/mach-aspeed/
F: arch/arm/boot/dts/aspeed-*
N: aspeed
-ARM/ATMEL AT91 Clock Support
-M: Boris Brezillon <boris.brezillon@bootlin.com>
-S: Maintained
-F: drivers/clk/at91
-
ARM/CALXEDA HIGHBANK ARCHITECTURE
M: Rob Herring <robh@kernel.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
--
2.14.1
^ permalink raw reply related
* [PATCH 13/28] drm/mediatek: add connection from RDMA0 to DSI3
From: Stu Hsieh @ 2018-06-13 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528877112.30263.24.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 16:05 +0800, CK Hu wrote:
> 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
>
OK, I would change the definition name from
DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN to DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN
> > 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 14/28] drm/mediatek: add connection from RDMA1 to DPI1
From: Stu Hsieh @ 2018-06-13 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528878446.30263.30.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 16:27 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Wed, 2018-06-13 at 15:56 +0800, Stu Hsieh wrote:
> > 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
>
> It looks like that RDMA1 output is also SOUT, use the naming SOUT would
> be better.
>
> Regards,
> CK
>
OK, I would change the definition name from
DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN to DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN
Regard,
STu
> >
> > 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 v4 6/6] dt-bindings: media: rcar-vin: Clarify optional props
From: jacopo mondi @ 2018-06-13 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612154553.kgqnqkwv3y6srivg@kekkonen.localdomain>
Hi Sakari,
On Tue, Jun 12, 2018 at 06:45:53PM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Tue, Jun 12, 2018 at 04:26:06PM +0200, Jacopo Mondi wrote:
> > Add a note to the R-Car VIN interface bindings to clarify that all
> > properties listed as generic properties in video-interfaces.txt can
> > be included in port at 0 endpoint, but if not explicitly listed in the
> > interface bindings documentation, they do not modify it behaviour.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > Documentation/devicetree/bindings/media/rcar_vin.txt | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index 8130849..03544c7 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -55,6 +55,12 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> > instances that are connected to external pins should have port 0.
> >
> > - Optional properties for endpoint nodes of port at 0:
> > +
> > + All properties described in [1] and which apply to the selected
> > + media bus type could be optionally listed here to better describe
> > + the current hardware configuration, but only the following ones do
> > + actually modify the VIN interface behaviour:
> > +
>
> I don't think this should be needed. You should only have properties that
> describe the hardware configuration in a given system.
>
There has been quite some debate on this, and please bear with me
here for re-proposing it: I started by removing properties in some DT
files for older Renesas board which listed endpoint properties not
documented in the VIN's bindings and not parsed by the VIN driver [1]
Niklas (but Simon and Geert seems to agree here) opposed to that
patch, as those properties where described in 'video-interfaces.txt' and
even if not parsed by the current driver implementation, they actually
describe hardware. I rebated that only properties listed in the device
bindings documentation should actually be used, and having properties
not parsed by the driver confuses users, which may expect changing
them modifies the interface configuration, which does not happens at
the moment.
This came out as a middle ground from a discussion with Niklas. As
stated in the cover letter if this patch makes someone uncomfortable, feel
free to drop it not to hold back the rest of the series which has been
well received instead.
Thanks
j
[1] https://www.spinics.net/lists/arm-kernel/msg656302.html
> > - hsync-active: see [1] for description. Default is active high.
> > - vsync-active: see [1] for description. Default is active high.
> > - data-enable-active: polarity of CLKENB signal, see [1] for
> > --
> > 2.7.4
> >
>
> --
> Sakari Ailus
> sakari.ailus at linux.intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/e8557938/attachment.sig>
^ permalink raw reply
* [PATCH 19/28] drm/mediatek: add connection from RDMA2 to DPI1
From: Stu Hsieh @ 2018-06-13 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528877675.30263.27.camel@mtksdaap41>
Hi, CK:
On Wed, 2018-06-13 at 16:14 +0800, CK Hu wrote:
> 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
>
The definition DISP_REG_CONFIG_DISP_RDMA2_SOUT is use term SOUT in this
patch.
Regard,
Stu
> >
> > 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] mm: cma: honor __GFP_ZERO flag in cma_alloc()
From: Marek Szyprowski @ 2018-06-13 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20180613085851eucas1p20337d050face8ff8ea87674e16a9ccd2@eucas1p2.samsung.com>
cma_alloc() function has gfp mask parameter, so users expect that it
honors typical memory allocation related flags. The most imporant from
the security point of view is handling of __GFP_ZERO flag, because memory
allocated by this function usually can be directly remapped to userspace
by device drivers as a part of multimedia processing and ignoring this
flag might lead to leaking some kernel structures to userspace.
Some callers of this function (for example arm64 dma-iommu glue code)
already assumed that the allocated buffers are cleared when this flag
is set. To avoid such issues, add simple code for clearing newly
allocated buffer when __GFP_ZERO flag is set. Callers will be then
updated to skip implicit clearing or adjust passed gfp flags.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
mm/cma.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 5809bbe360d7..1106d5aef2cc 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -464,6 +464,13 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
start = bitmap_no + mask + 1;
}
+ if (ret == 0 && gfp_mask & __GFP_ZERO) {
+ int i;
+
+ for (i = 0; i < count; i++)
+ clear_highpage(page + i);
+ }
+
trace_cma_alloc(pfn, page, count, align);
if (ret && !(gfp_mask & __GFP_NOWARN)) {
--
2.17.1
^ permalink raw reply related
* [PATCH 19/28] drm/mediatek: add connection from RDMA2 to DPI1
From: CK Hu @ 2018-06-13 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528880291.11190.45.camel@mtksdccf07>
Hi, Stu:
On Wed, 2018-06-13 at 16:58 +0800, Stu Hsieh wrote:
> Hi, CK:
>
> On Wed, 2018-06-13 at 16:14 +0800, CK Hu wrote:
> > 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
> >
>
> The definition DISP_REG_CONFIG_DISP_RDMA2_SOUT is use term SOUT in this
> patch.
>
I know, but RDMA2_MOUT_DPI1 should be changed to RDMA2_SOUT_DPI1.
Regards,
CK
> Regard,
> Stu
>
> > >
> > > 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 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: kbuild test robot @ 2018-06-13 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613161314.14894-3-yixun.lan@amlogic.com>
Hi Liang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mtd/nand/next]
[also build test ERROR on v4.17 next-20180613]
[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/Yixun-Lan/mtd-rawnand-meson-add-Amlogic-NAND-driver-support/20180613-161917
base: git://git.infradead.org/linux-mtd.git nand/next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-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=sparc64
All error/warnings (new ones prefixed by >>):
In file included from drivers/mtd/nand/raw/meson_nand.c:21:0:
>> drivers/clk/meson/clk-regmap.h:22:16: error: field 'hw' has incomplete type
struct clk_hw hw;
^~
>> drivers/mtd/nand/raw/meson_nand.c:951:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd/nand/raw/meson_nand.c:951:2: note: (near initialization for 'sd_emmc_c_ext_clk0_sel')
>> drivers/mtd/nand/raw/meson_nand.c:952:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_mux",
^~~~
>> drivers/mtd/nand/raw/meson_nand.c:952:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_mux",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:952:11: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:953:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_mux_ops,
^~~
drivers/mtd/nand/raw/meson_nand.c:953:10: warning: excess elements in struct initializer
.ops = &clk_regmap_mux_ops,
^
drivers/mtd/nand/raw/meson_nand.c:953:10: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:954:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:954:19: warning: excess elements in struct initializer
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:954:19: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:955:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~~
In file included from include/linux/list.h:9:0,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from include/linux/platform_device.h:14,
from drivers/mtd/nand/raw/meson_nand.c:9:
>> include/linux/kernel.h:71:25: warning: excess elements in struct initializer
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> drivers/mtd/nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
include/linux/kernel.h:71:25: note: (near initialization for '(anonymous)')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> drivers/mtd/nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
>> drivers/mtd/nand/raw/meson_nand.c:956:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
>> drivers/mtd/nand/raw/meson_nand.c:956:12: error: 'CLK_SET_RATE_PARENT' undeclared here (not in a function); did you mean 'DL_STATE_DORMANT'?
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
DL_STATE_DORMANT
drivers/mtd/nand/raw/meson_nand.c:956:12: warning: excess elements in struct initializer
drivers/mtd/nand/raw/meson_nand.c:956:12: note: (near initialization for '(anonymous)')
>> drivers/mtd/nand/raw/meson_nand.c:951:37: error: invalid use of undefined type 'struct clk_init_data'
.hw.init = &(struct clk_init_data) {
^
>> drivers/mtd/nand/raw/meson_nand.c:965:12: error: 'CLK_DIVIDER_ROUND_CLOSEST' undeclared here (not in a function); did you mean 'DIV_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~~~~~
DIV_ROUND_CLOSEST
>> drivers/mtd/nand/raw/meson_nand.c:965:40: error: 'CLK_DIVIDER_ONE_BASED' undeclared here (not in a function); did you mean 'CLK_DIVIDER_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~
CLK_DIVIDER_ROUND_CLOSEST
drivers/mtd/nand/raw/meson_nand.c:967:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd/nand/raw/meson_nand.c:967:2: note: (near initialization for 'sd_emmc_c_ext_clk0_div')
drivers/mtd/nand/raw/meson_nand.c:968:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_div",
^~~~
drivers/mtd/nand/raw/meson_nand.c:968:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_div",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:968:11: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:969:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_divider_ops,
^~~
drivers/mtd/nand/raw/meson_nand.c:969:10: warning: excess elements in struct initializer
.ops = &clk_regmap_divider_ops,
^
drivers/mtd/nand/raw/meson_nand.c:969:10: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:970:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:970:19: warning: excess elements in struct initializer
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^
drivers/mtd/nand/raw/meson_nand.c:970:19: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:971:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = 1,
^~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:971:18: warning: excess elements in struct initializer
.num_parents = 1,
^
drivers/mtd/nand/raw/meson_nand.c:971:18: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c:972:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
drivers/mtd/nand/raw/meson_nand.c:972:12: warning: excess elements in struct initializer
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
drivers/mtd/nand/raw/meson_nand.c:972:12: note: (near initialization for '(anonymous)')
drivers/mtd/nand/raw/meson_nand.c: In function 'meson_nfc_clk_init':
>> drivers/mtd/nand/raw/meson_nand.c:1007:38: error: implicit declaration of function '__clk_get_name'; did you mean 'clk_get_rate'? [-Werror=implicit-function-declaration]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^~~~~~~~~~~~~~
clk_get_rate
>> drivers/mtd/nand/raw/meson_nand.c:1007:36: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^
>> drivers/mtd/nand/raw/meson_nand.c:1011:8: error: implicit declaration of function 'devm_clk_register'; did you mean 'device_register'? [-Werror=implicit-function-declaration]
clk = devm_clk_register(nfc->dev, &mux->hw);
^~~~~~~~~~~~~~~~~
device_register
cc1: some warnings being treated as errors
--
In file included from drivers/mtd//nand/raw/meson_nand.c:21:0:
>> drivers/clk/meson/clk-regmap.h:22:16: error: field 'hw' has incomplete type
struct clk_hw hw;
^~
drivers/mtd//nand/raw/meson_nand.c:951:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd//nand/raw/meson_nand.c:951:2: note: (near initialization for 'sd_emmc_c_ext_clk0_sel')
drivers/mtd//nand/raw/meson_nand.c:952:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_mux",
^~~~
drivers/mtd//nand/raw/meson_nand.c:952:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_mux",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:952:11: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:953:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_mux_ops,
^~~
drivers/mtd//nand/raw/meson_nand.c:953:10: warning: excess elements in struct initializer
.ops = &clk_regmap_mux_ops,
^
drivers/mtd//nand/raw/meson_nand.c:953:10: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:954:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:954:19: warning: excess elements in struct initializer
.parent_names = sd_emmc_ext_clk0_parent_names,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:954:19: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:955:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~~
In file included from include/linux/list.h:9:0,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from include/linux/platform_device.h:14,
from drivers/mtd//nand/raw/meson_nand.c:9:
>> include/linux/kernel.h:71:25: warning: excess elements in struct initializer
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
drivers/mtd//nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
include/linux/kernel.h:71:25: note: (near initialization for '(anonymous)')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
drivers/mtd//nand/raw/meson_nand.c:955:18: note: in expansion of macro 'ARRAY_SIZE'
.num_parents = ARRAY_SIZE(sd_emmc_ext_clk0_parent_names),
^~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:956:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
drivers/mtd//nand/raw/meson_nand.c:956:12: error: 'CLK_SET_RATE_PARENT' undeclared here (not in a function); did you mean 'DL_STATE_DORMANT'?
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
DL_STATE_DORMANT
drivers/mtd//nand/raw/meson_nand.c:956:12: warning: excess elements in struct initializer
drivers/mtd//nand/raw/meson_nand.c:956:12: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:951:37: error: invalid use of undefined type 'struct clk_init_data'
.hw.init = &(struct clk_init_data) {
^
drivers/mtd//nand/raw/meson_nand.c:965:12: error: 'CLK_DIVIDER_ROUND_CLOSEST' undeclared here (not in a function); did you mean 'DIV_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~~~~~
DIV_ROUND_CLOSEST
drivers/mtd//nand/raw/meson_nand.c:965:40: error: 'CLK_DIVIDER_ONE_BASED' undeclared here (not in a function); did you mean 'CLK_DIVIDER_ROUND_CLOSEST'?
.flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
^~~~~~~~~~~~~~~~~~~~~
CLK_DIVIDER_ROUND_CLOSEST
drivers/mtd//nand/raw/meson_nand.c:967:2: error: field name not in record or union initializer
.hw.init = &(struct clk_init_data) {
^
drivers/mtd//nand/raw/meson_nand.c:967:2: note: (near initialization for 'sd_emmc_c_ext_clk0_div')
drivers/mtd//nand/raw/meson_nand.c:968:4: error: 'struct clk_init_data' has no member named 'name'
.name = "sd_emmc_c_nand_clk_div",
^~~~
drivers/mtd//nand/raw/meson_nand.c:968:11: warning: excess elements in struct initializer
.name = "sd_emmc_c_nand_clk_div",
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:968:11: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:969:4: error: 'struct clk_init_data' has no member named 'ops'
.ops = &clk_regmap_divider_ops,
^~~
drivers/mtd//nand/raw/meson_nand.c:969:10: warning: excess elements in struct initializer
.ops = &clk_regmap_divider_ops,
^
drivers/mtd//nand/raw/meson_nand.c:969:10: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:970:4: error: 'struct clk_init_data' has no member named 'parent_names'
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:970:19: warning: excess elements in struct initializer
.parent_names = (const char *[]){ "sd_emmc_c_nand_clk_mux" },
^
drivers/mtd//nand/raw/meson_nand.c:970:19: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:971:4: error: 'struct clk_init_data' has no member named 'num_parents'
.num_parents = 1,
^~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:971:18: warning: excess elements in struct initializer
.num_parents = 1,
^
drivers/mtd//nand/raw/meson_nand.c:971:18: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c:972:4: error: 'struct clk_init_data' has no member named 'flags'
.flags = CLK_SET_RATE_PARENT,
^~~~~
drivers/mtd//nand/raw/meson_nand.c:972:12: warning: excess elements in struct initializer
.flags = CLK_SET_RATE_PARENT,
^~~~~~~~~~~~~~~~~~~
drivers/mtd//nand/raw/meson_nand.c:972:12: note: (near initialization for '(anonymous)')
drivers/mtd//nand/raw/meson_nand.c: In function 'meson_nfc_clk_init':
drivers/mtd//nand/raw/meson_nand.c:1007:38: error: implicit declaration of function '__clk_get_name'; did you mean 'clk_get_rate'? [-Werror=implicit-function-declaration]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^~~~~~~~~~~~~~
clk_get_rate
drivers/mtd//nand/raw/meson_nand.c:1007:36: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
sd_emmc_ext_clk0_parent_names[i] = __clk_get_name(clk);
^
drivers/mtd//nand/raw/meson_nand.c:1011:8: error: implicit declaration of function 'devm_clk_register'; did you mean 'device_register'? [-Werror=implicit-function-declaration]
clk = devm_clk_register(nfc->dev, &mux->hw);
^~~~~~~~~~~~~~~~~
device_register
cc1: some warnings being treated as errors
vim +/hw +22 drivers/clk/meson/clk-regmap.h
ea11dda9 Jerome Brunet 2018-02-12 10
ea11dda9 Jerome Brunet 2018-02-12 11 /**
ea11dda9 Jerome Brunet 2018-02-12 12 * struct clk_regmap - regmap backed clock
ea11dda9 Jerome Brunet 2018-02-12 13 *
ea11dda9 Jerome Brunet 2018-02-12 14 * @hw: handle between common and hardware-specific interfaces
ea11dda9 Jerome Brunet 2018-02-12 15 * @map: pointer to the regmap structure controlling the clock
ea11dda9 Jerome Brunet 2018-02-12 16 * @data: data specific to the clock type
ea11dda9 Jerome Brunet 2018-02-12 17 *
ea11dda9 Jerome Brunet 2018-02-12 18 * Clock which is controlled by regmap backed registers. The actual type of
ea11dda9 Jerome Brunet 2018-02-12 19 * of the clock is controlled by the clock_ops and data.
ea11dda9 Jerome Brunet 2018-02-12 20 */
ea11dda9 Jerome Brunet 2018-02-12 21 struct clk_regmap {
ea11dda9 Jerome Brunet 2018-02-12 @22 struct clk_hw hw;
ea11dda9 Jerome Brunet 2018-02-12 23 struct regmap *map;
ea11dda9 Jerome Brunet 2018-02-12 24 void *data;
ea11dda9 Jerome Brunet 2018-02-12 25 };
ea11dda9 Jerome Brunet 2018-02-12 26
:::::: The code at line 22 was first introduced by commit
:::::: ea11dda9e091aba0fe6497108477699286a2d036 clk: meson: add regmap clocks
:::::: TO: Jerome Brunet <jbrunet@baylibre.com>
:::::: CC: Neil Armstrong <narmstrong@baylibre.com>
---
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: 53278 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/76026361/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/3] rtc: ftrtc010: switch to devm_rtc_allocate_device
From: Linus Walleij @ 2018-06-13 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-1-alexandre.belloni@bootlin.com>
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> Switch to devm_rtc_allocate_device/rtc_register_device. This allow or
> further improvement and simplifies ftrtc010_rtc_remove().
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/3] rtc: ftrtc010: handle dates after 2106
From: Linus Walleij @ 2018-06-13 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-2-alexandre.belloni@bootlin.com>
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> Use correct types for offset and time and use
> rtc_time64_to_tm/rtc_tm_to_time64 to handle dates after 2106 properly.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] rtc: ftrtc010: let the core handle range
From: Linus Walleij @ 2018-06-13 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141528.15635-3-alexandre.belloni@bootlin.com>
On Mon, Jun 4, 2018 at 4:15 PM, Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> The current range handling is highly suspicious. Anyway, let the core
> handle it.
Hmmm. I have datasheets, do you need some input about the hardware?
Something I should patch?
> The RTC has a 32 bit counter on top of days + hh:mm:ss registers.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Maxime Ripard @ 2018-06-13 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAR0TZEp9JfJAf3gmE1v6ig04TZ-NCiXm5_zYdpsQwhuRw@mail.gmail.com>
On Wed, Jun 13, 2018 at 05:16:30PM +0900, Masahiro Yamada wrote:
> Hi.
>
> 2018-06-13 16:26 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.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 :/
> >
>
> Stephen offered to pick it up directly for -rc2.
> Is that OK with you?
>
> I am fine if it is well-organized between you and Stephen.
Yep, that definitely works for me.
Sorry again,
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/206a5b4d/attachment.sig>
^ permalink raw reply
* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: Vadim Lomovtsev @ 2018-06-13 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612.152540.1304714747425091865.davem@davemloft.net>
Sorry for delay.
On Tue, Jun 12, 2018 at 03:25:40PM -0700, David Miller wrote:
> From: Dean Nelson <dnelson@redhat.com>
> Date: Mon, 11 Jun 2018 06:22:14 -0500
>
> > On 06/10/2018 02:35 PM, David Miller wrote:
> >> From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
> >> Date: Fri, 8 Jun 2018 02:27:59 -0700
> >>
> >>> + /* Save message data locally to prevent them from
> >>> + * being overwritten by next ndo_set_rx_mode call().
> >>> + */
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + mode = vf_work->mode;
> >>> + mc = vf_work->mc;
> >>> + vf_work->mc = NULL;
> >
> > If I'm reading this code correctly, I believe nic->rx_mode_work.mc
> > will
> > have been set to NULL before the lock is dropped by
> > nicvf_set_rx_mode_task() and acquired by nicvf_set_rx_mode().
> >
> >
> >>> + spin_unlock(&nic->rx_mode_wq_lock);
> >> At the moment you drop this lock, the memory behind 'mc' can be
> >> freed up by:
> >>
> >>> + spin_lock(&nic->rx_mode_wq_lock);
> >>> + kfree(nic->rx_mode_work.mc);
> >
> > So the kfree() will be called with a NULL pointer and quickly return.
> >
> >
> >> And you'll crash when you dereference it above via
> >> __nicvf_set_rx_mode_task().
> >>
> >
> > I believe the call to kfree() in nicvf_set_rx_mode() is there to free
> > up a mc_list that has been allocated by nicvf_set_rx_mode() during a
> > previous callback to the function, one that has not yet been processed
> > by nicvf_set_rx_mode_task().
> >
> > In this way only the last 'unprocessed' callback to
> > nicvf_set_rx_mode()
> > gets processed should there be multiple callbacks occurring between
> > the
> > times the nicvf_set_rx_mode_task() runs.
> >
> > In my testing with this patch, this is what I see happening.
>
> You're right, my bad.
>
> Patch applied.
Thank you for your time.
WBR,
Vadim
^ 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