[PATCH 07/26] drm/exynos: Use for_each_crtc_in_state
2016ë
05ì 30ì¼ 03:35ì Daniel Vetter ì´(ê°) ì´ ê¸:
> We want to hide drm_atomic_state internals better.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 2dd820e23b0c..cabc5fd0246d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -267,6 +267,8 @@ int exynos_atomic_commit(struct drm_device *dev, struct
> drm_atomic_state *state,
> {
> struct exynos_drm_private *priv = dev->dev_private;
> struct exynos_atomic_commit *commit;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> int i, ret;
>
> commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> @@ -288,10 +290,8 @@ int exynos_atomic_commit(struct drm_device *dev, struct
> drm_atomic_state *state,
> /* Wait until all affected CRTCs have completed previous commits and
>* mark them as pending.
>*/
> - for (i = 0; i < dev->mode_config.num_crtc; ++i) {
> - if (state->crtcs[i])
> - commit->crtcs |= 1 << drm_crtc_index(state->crtcs[i]);
> - }
> + for_each_crtc_in_state(state, crtc, crtc_state, i)
> + commit->crtcs |= 1 << drm_crtc_index(crtc);
>
> wait_event(priv->wait, !commit_is_pending(priv, commit->crtcs));
>
>
[PATCH] drm/exynos: use logical AND in exynos_drm_plane_check_size()
Picked it up.
Thanks,
Inki Dae
2016ë
06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Ping!
>
> - Tobias
>
> Tobias Jakobi wrote:
>> The current bitwise AND should result in the same assembler
>> but this is what the code is actually supposed to do.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> index b3f3c2c..e4a1a63 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> @@ -226,7 +226,7 @@ exynos_drm_plane_check_size(const struct
>> exynos_drm_plane_config *config,
>> state->v_ratio == (1 << 15))
>> height_ok = true;
>>
>> -if (width_ok & height_ok)
>> +if (width_ok && height_ok)
>> return 0;
>>
>> DRM_DEBUG_KMS("scaling mode is not supported");
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
[PATCH] drm/exynos: remove superfluous inclusions of fbdev header
Picked it up. Thanks, Inki Dae 2016ë 06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸: >> 3 files changed, 3 deletions(-)
[PATCH] drm/exynos: g2d: drop the _REG postfix from the stride defines
Picked it up.
Thanks,
Inki Dae
2016ë
06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Ping!
>
> - Tobias
>
> Tobias Jakobi wrote:
>> This makes the defines consistent with the rest.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> index 01b72b9..0934d38 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> @@ -48,13 +48,13 @@
>>
>> /* registers for base address */
>> #define G2D_SRC_BASE_ADDR 0x0304
>> -#define G2D_SRC_STRIDE_REG 0x0308
>> +#define G2D_SRC_STRIDE 0x0308
>> #define G2D_SRC_COLOR_MODE 0x030C
>> #define G2D_SRC_LEFT_TOP0x0310
>> #define G2D_SRC_RIGHT_BOTTOM0x0314
>> #define G2D_SRC_PLANE2_BASE_ADDR0x0318
>> #define G2D_DST_BASE_ADDR 0x0404
>> -#define G2D_DST_STRIDE_REG 0x0408
>> +#define G2D_DST_STRIDE 0x0408
>> #define G2D_DST_COLOR_MODE 0x040C
>> #define G2D_DST_LEFT_TOP0x0410
>> #define G2D_DST_RIGHT_BOTTOM0x0414
>> @@ -560,7 +560,7 @@ static enum g2d_reg_type g2d_get_reg_type(int reg_offset)
>>
>> switch (reg_offset) {
>> case G2D_SRC_BASE_ADDR:
>> -case G2D_SRC_STRIDE_REG:
>> +case G2D_SRC_STRIDE:
>> case G2D_SRC_COLOR_MODE:
>> case G2D_SRC_LEFT_TOP:
>> case G2D_SRC_RIGHT_BOTTOM:
>> @@ -570,7 +570,7 @@ static enum g2d_reg_type g2d_get_reg_type(int reg_offset)
>> reg_type = REG_TYPE_SRC_PLANE2;
>> break;
>> case G2D_DST_BASE_ADDR:
>> -case G2D_DST_STRIDE_REG:
>> +case G2D_DST_STRIDE:
>> case G2D_DST_COLOR_MODE:
>> case G2D_DST_LEFT_TOP:
>> case G2D_DST_RIGHT_BOTTOM:
>> @@ -961,8 +961,8 @@ static int g2d_check_reg_offset(struct device *dev,
>> } else
>> buf_info->types[reg_type] = BUF_TYPE_GEM;
>> break;
>> -case G2D_SRC_STRIDE_REG:
>> -case G2D_DST_STRIDE_REG:
>> +case G2D_SRC_STRIDE:
>> +case G2D_DST_STRIDE:
>> if (for_addr)
>> goto err;
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
[PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800
2016ë 06ì 10ì¼ 09:24ì Javier Martinez Canillas ì´(ê°) ì´ ê¸: > Hello Inki, > > On Thu, Jun 9, 2016 at 6:35 PM, Inki Dae wrote: > > [snip] > >>> I know that removing .trg_type is enough but I also removed those lines >>> because the fields are not used if .trg_type != I80_HW_TRG. So there is >>> no point to leave a set for unused fields. >>> >>> We can latter add those one HW trigger support is fixed for Exynos5420. >>> >> >> As of now, I can merge it but I think it would be not reasonable solution >> because potential problem still exists even we use SW trigger mode in >> default - ie., in case of using HW trigger mode at bootloader, same problem >> would happen as long as we don't support PSR mode support. >> > > Yes, I understand that the problem will show again if the bootloader > uses HW trigger mode and that we need proper Panel Self Refresh > support but I think that's a separate issue. That's why I said that > those can be addressed for v4.8 but revert to SW trigger for v4.7 as a > short term fix for the regression. > > In other words, enabling HW trigger mode breaks the display for the > Exynos5420 and Exynos5800 Peach Pi Chromebooks with the shipped > bootloaders (which are probably the most popular Exynos5 devices with > display and mainline support so is likely to affect users). I thought to add PSR support somehow but put me other things to trouble. Anyway, we could support it later so picked it up. Thanks, Inki Dae > > Best regards, > Javier > > >
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On 10.06.2016 23:43, Daniel Vetter wrote: > On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: >> From: Michel Dänzer >> >> If userspace wants a page flip to take effect during vblank sequence n, >> it has to wait for vblank seqno n-1 before calling the >> DRM_IOCTL_MODE_PAGE_FLIP ioctl. >> >> This change makes sure that we do not program the flip to the hardware >> before the end of vblank seqno n-1 in this case, to prevent the flip >> from taking effect too early. >> >> On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called >> during vblank, but userspace didn't wait for the current vblank seqno >> before, this change would still allow the flip to be programmed during >> the current vblank seqno. > > This just sounds like you're sending vblank events out a bit too early. > And watching vblank waits that userspace does works, but it's fragile, > add-hoc and I don't really jump in joy about adding that to the vblank > core. Is there no way you can adjust sending out the vblank events > similarly, to make sure userspace can never sneak in a pageflip too early? What you call "too early" is actually "during the vertical blank period waited for". IMHO only notifying userspace of a vertical blank period when it's already over would defeat the purpose. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 96360] [bisected: 3d02b7] VM fault with kernel 4.7-rc1 on Alien: Isolation
https://bugs.freedesktop.org/show_bug.cgi?id=96360 --- Comment #9 from Alexandre Demers --- (In reply to Nicolai Hähnle from comment #7) > Thanks! No VM faults here on Tonga, so this may be specific to SI. Do you > get VM faults in dmesg when you play the trace back on your system? Anything I can provide you with? Any specific test or steps? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/6d27ff2d/attachment.html>
[RFC v3 4/5] drm/mediatek: add support for Mediatek SoC MT2701
Hi, YT:
Some comments inline.
On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 42
> +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |8 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |2 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 31
> 6 files changed, 95 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index eb5c05e..1da0a71 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -286,11 +286,17 @@ static int mtk_disp_ovl_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_ddp_comp_driver_data mt2701_ovl_driver_data = {
> + .ovl = {0x0040, 1 << 12, 0}
> +};
> +
> static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
> .ovl = {0x0f40, 0, 1 << 12}
> };
>
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> + .data = &mt2701_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index fb0db50..506a353 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -225,11 +225,17 @@ static int mtk_disp_rdma_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_ddp_comp_driver_data mt2701_rdma_driver_data = {
> + .rdma_fifo_pseudo_size = SZ_4K,
> +};
> +
> static const struct mtk_ddp_comp_driver_data mt8173_rdma_driver_data = {
> .rdma_fifo_pseudo_size = SZ_8K,
> };
>
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> + .data = &mt2701_rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = &mt8173_rdma_driver_data},
> {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index fa53806..7ab6986 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -32,6 +32,10 @@
> #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> #define DISP_REG_CONFIG_MMSYS_CG_CON00x100
>
> +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
> +#define DISP_REG_CONFIG_OUT_SEL 0x04c
> +#define DISP_REG_CONFIG_DSI_SEL 0x050
Align the digital value.
> +
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
> #define DISP_REG_MUTEX_RST(n)(0x28 + 0x20 * (n))
> @@ -54,6 +58,13 @@
> #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
> #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>
> +#define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLSBIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0 BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1 BIT(12)
> +
> #define MUTEX_SOF_SINGLE_MODE0
> #define MUTEX_SOF_DSI0 1
> #define MUTEX_SOF_DSI1 2
> @@ -69,6 +80,10 @@
> #define DPI0_SEL_IN_RDMA10x1
> #define COLOR1_SEL_IN_OVL1 0x1
>
> +#define OVL_MOUT_EN_RDMA 0x1
> +#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
> +#define DSI_SEL_IN_BLS 0x0
> +
> struct mtk_disp_mutex {
> int id;
> bool claimed;
> @@ -82,6 +97,15 @@ struct mtk_ddp {
> const unsigned int *mutex_mod;
> };
>
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
> static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -109,6 +133,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
> *addr =
[PATCH] drm/exynos: use logical AND in exynos_drm_plane_check_size()
On Mon, Jun 13, 2016 at 3:34 AM, Inki Dae wrote:
> Picked it up.
Fyi it's already in drm-misc too.
-Daniel
>
> Thanks,
> Inki Dae
>
> 2016ë
06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Ping!
>>
>> - Tobias
>>
>> Tobias Jakobi wrote:
>>> The current bitwise AND should result in the same assembler
>>> but this is what the code is actually supposed to do.
>>>
>>> Signed-off-by: Tobias Jakobi
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> index b3f3c2c..e4a1a63 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> @@ -226,7 +226,7 @@ exynos_drm_plane_check_size(const struct
>>> exynos_drm_plane_config *config,
>>> state->v_ratio == (1 << 15))
>>> height_ok = true;
>>>
>>> -if (width_ok & height_ok)
>>> +if (width_ok && height_ok)
>>> return 0;
>>>
>>> DRM_DEBUG_KMS("scaling mode is not supported");
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC v3 3/5] drm/mediatek: add shadow register support
Hi, YT:
One comment inline.
On Thu, 2016-06-09 at 00:03 +0800, YT Shen wrote:
> We need to acquire mutex before using the resources,
> and need to release it after finished.
> So we don't need to write registers in the blanking period.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 75
> +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 22 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h |2 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c |1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.h |1 +
> 5 files changed, 72 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 24aa3ba..80d9641 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -315,6 +315,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> pm_runtime_put(drm->dev);
> }
>
> +static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> +{
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> + struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
> + unsigned int i;
> +
> + /*
> + * TODO: instead of updating the registers here, we should prepare
> + * working registers in atomic_commit and let the hardware command
> + * queue update module registers on vblank.
> + */
> + if (state->pending_config) {
> + mtk_ddp_comp_config(ovl, state->pending_width,
> + state->pending_height,
> + state->pending_vrefresh);
> +
> + state->pending_config = false;
> + }
> +
> + if (mtk_crtc->pending_planes) {
> + for (i = 0; i < OVL_LAYER_NR; i++) {
> + struct drm_plane *plane = &mtk_crtc->planes[i].base;
> + struct mtk_plane_state *plane_state;
> +
> + plane_state = to_mtk_plane_state(plane->state);
> +
> + if (plane_state->pending.config) {
> + mtk_ddp_comp_layer_config(ovl, i, plane_state);
> + plane_state->pending.config = false;
> + }
> + }
> + mtk_crtc->pending_planes = false;
> + }
> +}
> +
> static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> @@ -391,6 +427,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> *crtc,
> struct drm_crtc_state *old_crtc_state)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
> unsigned int pending_planes = 0;
> int i;
>
> @@ -409,6 +446,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> *crtc,
> }
> if (pending_planes)
> mtk_crtc->pending_planes = true;
> +
> + if (priv->data->shadow_register) {
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
> }
>
> static const struct drm_crtc_funcs mtk_crtc_funcs = {
> @@ -453,36 +496,10 @@ err_cleanup_crtc:
> void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> - struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> - unsigned int i;
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
>
> - /*
> - * TODO: instead of updating the registers here, we should prepare
> - * working registers in atomic_commit and let the hardware command
> - * queue update module registers on vblank.
> - */
> - if (state->pending_config) {
> - mtk_ddp_comp_config(ovl, state->pending_width,
> - state->pending_height,
> - state->pending_vrefresh);
> -
> - state->pending_config = false;
> - }
> -
> - if (mtk_crtc->pending_planes) {
> - for (i = 0; i < OVL_LAYER_NR; i++) {
> - struct drm_plane *plane = &mtk_crtc->planes[i].base;
> - struct mtk_plane_state *plane_state;
> -
> - plane_state = to_mtk_plane_state(plane->state);
> -
> - if (plane_state->pending.config) {
> - mtk_ddp_comp_layer_config(ovl, i, plane_state);
> - plane_state->pending.config = false;
> - }
> - }
> - mtk_crtc->pending_planes = false;
> - }
> + if (!priv->data->shadow_register)
> + mtk_crtc_ddp_config(crtc);
>
> mtk_drm_finish_page_flip(mtk_crtc);
> }
> diff --git a/drivers/gpu/
[patch] drm/i915/mocs: || vs | typo in get_mocs_settings()
It seems pretty clear that bitwise OR was intended here and not logical
OR.
Fixes: 6fc29133eafb ('drm/i915/gen9: Add WaDisableSkipCaching')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index 8f96c40..3c1482b 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -162,7 +162,7 @@ static bool get_mocs_settings(struct drm_i915_private
*dev_priv,
for (i = 0; i < table->size; i++)
if (WARN_ON(table->table[i].l3cc_value &
- (L3_ESC(1) || L3_SCC(0x7
+ (L3_ESC(1) | L3_SCC(0x7
return false;
}
[PATCH 1/3] drm/amdgpu/gfx8: fix CP jump table size
For the series:
Reviewed-by: Nicolai Hähnle
This patch is also:
Tested-by: Nicolai Hähnle
On 10.06.2016 16:13, Alex Deucher wrote:
> Align to the jump table offset. Fixes hangs on some
> systems with GFX PG enabled.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 4e34877..42dc5fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1299,7 +1299,7 @@ static int gfx_v8_0_rlc_init(struct amdgpu_device *adev)
>
> if ((adev->asic_type == CHIP_CARRIZO) ||
> (adev->asic_type == CHIP_STONEY)) {
> - adev->gfx.rlc.cp_table_size = (96 * 5 * 4) + (64 * 1024); /* JT
> + GDS */
> + adev->gfx.rlc.cp_table_size = ALIGN(96 * 5 * 4, 2048) + (64 *
> 1024); /* JT + GDS */
> if (adev->gfx.rlc.cp_table_obj == NULL) {
> r = amdgpu_bo_create(adev, adev->gfx.rlc.cp_table_size,
> PAGE_SIZE, true,
>AMDGPU_GEM_DOMAIN_VRAM,
>
[Bug 96445] [amdgpu][tonga] display freezes soon after X start
https://bugs.freedesktop.org/show_bug.cgi?id=96445 --- Comment #2 from Nicolai Hähnle --- Created attachment 124493 --> https://bugs.freedesktop.org/attachment.cgi?id=124493&action=edit avoid schedule() during spinlock Hi Csaba! The attached patch doesn't fix the problem for me, but it seems correct and at least changes the symptoms. Maybe it helps on your system? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/c0e4c943/attachment.html>
[Bug 96444] GRID Autosport crash on loading race
https://bugs.freedesktop.org/show_bug.cgi?id=96444 --- Comment #13 from Nicolai Hähnle --- Created attachment 124494 --> https://bugs.freedesktop.org/attachment.cgi?id=124494&action=edit crashing shader .ll file Thanks, Lorenzo. I've extracted the last shader, but unfortunately I cannot reproduce the crash with standalone llc on the latest LLVM. What GPU do you have / what does glxinfo say? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/58137000/attachment-0001.html>
[Bug 119991] Screen is corrupt upon resume from hybrid-sleep with Radeon HD5xxx cards
https://bugzilla.kernel.org/show_bug.cgi?id=119991 --- Comment #3 from Jani-Markus Maunus --- I did a bisect out of curiosity, and in my case the following commit fixes both issues. commit 274ad65c9d02bdcbee9bae045517864c3521d530 Author: Jérome Glisse Date: Fri Mar 18 16:58:39 2016 +0100 drm/radeon: hard reset r600 and newer GPU when hibernating. Some GPU block like UVD and VCE require hard reset to be properly resume if there is no real powerdown of the asic like during various hibernation step. This patch perform such hard reset. Reviewed-by: Christian König Signed-off-by: Jérôme Glisse Cc: Alex Deucher Cc: Christian König Signed-off-by: Alex Deucher Also, to clarify, reverting b9729b17a4 on master made no difference, but reverting it on the commit immediately preceding the above also fixed both issues. In any case, the bug appears fixed for me. I might be just rambling at this point, but 4.6.1 stable was definitely bugged for me, yet this commit is dated well before 4.6.1 release - any idea what's up with that? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 96444] GRID Autosport crash on loading race
https://bugs.freedesktop.org/show_bug.cgi?id=96444 --- Comment #14 from Lorenzo Bona --- Hi, my GPU is a R7-265. I haven't built LLVM since 08/06, so it's 5 day old. I can try to rebuild LLVM today. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/04a8c3ba/attachment.html>
[Bug 119861] Kernel BUG() when Xorg server is started using nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=119861 Lucas Stach changed: What|Removed |Added CC||dev at lynxeye.de --- Comment #4 from Lucas Stach --- Probably the same bug as seen on imx-drm by Philipp and fixed with the following 2 patches: https://patchwork.kernel.org/patch/9151037/ https://patchwork.kernel.org/patch/9151039/ Please test if those also fix this bug. Thanks. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: fb: cma: fix memory leak
On Sun, Jun 12, 2016 at 04:03:56PM +0100, Sudip Mukherjee wrote:
> We may have a situation that the memory allocation for fbdefio fails
> and then the allocation for fbops may succeed as some memory has been
> freed somewhere. Lets free fbops also to face these rare situtation.
> Since kfree can handle arguments as NULL, there should not be any
> problem in calling both the kfree().
>
> Signed-off-by: Sudip Mukherjee
Thanks for the patch, applied to drm-misc. For next time around please
figure out which patch created the broken using git blame. Then cite
that in your commit message and cc the author/reviewers of the broken
commit when submitting your fix.
-Daniel
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 2e7ef0b..c0b0c71 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -346,6 +346,7 @@ static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
> fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> if (!fbdefio || !fbops) {
> kfree(fbdefio);
> + kfree(fbops);
> return -ENOMEM;
> }
>
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 23/27] drm: Replace fb_helper->atomic with mode_config->atomic_commit
On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote:
> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter
> wrote:
> > Drivers transitioning to atomic might not yet want to enable full
> > DRIVER_ATOMIC support when it's not entirely working. But using atomic
> > internally makes a lot more sense earlier.
> >
> > Instead of spreading such flags to more places I figured it's simpler
> > to just check for mode_config->funcs->atomic_commit, and use atomic
> > paths if that is set. For the only driver currently transitioning
> > (i915) this does the right thing.
>
> Well, imx-drm is transitioning.
> Unfortunately, after applying this patch, legacy fbdev cannot enable
> displays when the imx-drm transitional patch set reaches phase 3 step 1[1].
>
> For those transitioning drivers with fine-grained steps, this patch
> is likely to expose the atomic function __drm_atomic_helper_set_config
> to legacy fbdev support too early. They could still be using
> drm_crtc_helper_set_config when adding ->atomic_commit.
>
> BTW, this patch and those for generic nonblocking commit are making
> the imx-drm transition a bit harder. Not good timing probably.
> But, I'll go on with the task anyway.
Hm, making transition harder wasn't really the intention. What exactly is
blowing up for you? At least how I planned the transition the first thing
you should be able to do is basic modesets (once you fill out
->atomic_commit), so I hoped that this wouldn't cause trouble.
Wrt nonblocking commit helpers breaking transitioning drivers: The most
likely cause is your driver isn't handling crtc_state->event yet. Before
you start using ->atomic_commit or one of the helpers to map legacy ioctl
to atomic, you need to fill out some code to handle that in ->atomic_begin
or ->atomic_flush. Then the transition should still work as before.
I'll be happy to help you out debug this, and then update my blog post
with the transition plan with the latest findings.
Thanks, Daniel
>
> [1] https://patchwork.kernel.org/patch/9144035/
>
> Regards,
> Liu Ying
>
> >
> > Cc: Maarten Lankhorst
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_helper.c| 6 ++
> > drivers/gpu/drm/i915/intel_fbdev.c | 2 --
> > include/drm/drm_fb_helper.h| 11 ---
> > 3 files changed, 2 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index c0e0a2e78d75..ba2fcb2a68ad 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -385,7 +385,7 @@ static int restore_fbdev_mode(struct drm_fb_helper
> > *fb_helper)
> >
> > drm_warn_on_modeset_not_all_locked(dev);
> >
> > - if (fb_helper->atomic)
> > + if (dev->mode_config.funcs->atomic_commit)
> > return restore_fbdev_mode_atomic(fb_helper);
> >
> > drm_for_each_plane(plane, dev) {
> > @@ -716,8 +716,6 @@ int drm_fb_helper_init(struct drm_device *dev,
> > i++;
> > }
> >
> > - fb_helper->atomic = !!drm_core_check_feature(dev, DRIVER_ATOMIC);
> > -
> > return 0;
> > out_free:
> > drm_fb_helper_crtc_free(fb_helper);
> > @@ -1344,7 +1342,7 @@ int drm_fb_helper_pan_display(struct
> > fb_var_screeninfo *var,
> > return -EBUSY;
> > }
> >
> > - if (fb_helper->atomic) {
> > + if (dev->mode_config.funcs->atomic_commit) {
> > ret = pan_display_atomic(var, info);
> > goto unlock;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index ef8e67690f3d..4c725ad6fb54 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -724,8 +724,6 @@ int intel_fbdev_init(struct drm_device *dev)
> > return ret;
> > }
> >
> > - ifbdev->helper.atomic = true;
> > -
> > dev_priv->fbdev = ifbdev;
> > INIT_WORK(&dev_priv->fbdev_suspend_work,
> > intel_fbdev_suspend_worker);
> >
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index 5b4aa35026a3..db8d4780eaa2 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -212,17 +212,6 @@ struct drm_fb_helper {
> > * needs to be reprobe when fbdev is in control again.
> > */
> > bool delayed_hotplug;
> > -
> > - /**
> > -* @atomic:
> > -*
> > -* Use atomic updates for restore_fbdev_mode(), etc. This defaults
> > to
> > -* true if driver has DRIVER_ATOMIC feature flag, but drivers can
> > -* override it to true after drm_fb_helper_init() if they support
> > atomic
> > -* modeset but do not yet advertise DRIVER_ATOMIC (note that
> > fb-helper
> > -* does not require ASYNC commits).
> > -*/
> > - bool atomic;
> > };
> >
> > #ifdef CONFIG_DRM_FBDEV_EMULATION
> > --
> > 2.8.1
> >
> >
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote: > On 10.06.2016 23:43, Daniel Vetter wrote: > > On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: > >> From: Michel Dänzer > >> > >> If userspace wants a page flip to take effect during vblank sequence n, > >> it has to wait for vblank seqno n-1 before calling the > >> DRM_IOCTL_MODE_PAGE_FLIP ioctl. > >> > >> This change makes sure that we do not program the flip to the hardware > >> before the end of vblank seqno n-1 in this case, to prevent the flip > >> from taking effect too early. > >> > >> On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called > >> during vblank, but userspace didn't wait for the current vblank seqno > >> before, this change would still allow the flip to be programmed during > >> the current vblank seqno. > > > > This just sounds like you're sending vblank events out a bit too early. > > And watching vblank waits that userspace does works, but it's fragile, > > add-hoc and I don't really jump in joy about adding that to the vblank > > core. Is there no way you can adjust sending out the vblank events > > similarly, to make sure userspace can never sneak in a pageflip too early? > > What you call "too early" is actually "during the vertical blank period > waited for". IMHO only notifying userspace of a vertical blank period > when it's already over would defeat the purpose. Afaiui the rules are: - The timestamp for vblank event needs to agree with whatever oml_sync requries. - The event delivery itself needs to be consistent with what page_flip takes, i.e. if userspace sees an event and immediately issues a page_flip then it should not be able to hit the same vblank with that pageflip. - The event needs to be after the old buffers are not longer used and can be reused for rendering. - There's no requirement at all that the event gets delivered at a specific point in the vblank, hardware is too different for that to work - that kind of precision is why we have a separate timestamp. I assume you're goal is to not delay page_flips unecessarily, without breaking requirement 2 here. Imo a simpler fix would be to delay the vblank handling to end of vblank. Fixes everything without hacks, no single-use driver oddity in the core, and you still can page_flip as late as you want without forcing a delay to the next vblank if your already past the start of vblank. And since you have high-precision timestamp support the vblank core will fudge the timestamp as needed. Ofc this assumes that amd hw has a vblank_end irq, but most desktop hw seems to have that (didn't check tbh whether amd has it). So all that's needed I think is to enable the vblank_end irq (in lockstep with the start one) and move drm_handle_vblank() from its current place to that new irq. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 96445] [amdgpu][tonga] display freezes soon after X start
https://bugs.freedesktop.org/show_bug.cgi?id=96445 Christian König changed: What|Removed |Added Attachment #124493|0 |1 is obsolete|| --- Comment #3 from Christian König --- Created attachment 124495 --> https://bugs.freedesktop.org/attachment.cgi?id=124495&action=edit Possible fix Complete fix for the issue, thanks to Nicolai for pointing me into the right direction. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/5b014ce7/attachment.html>
[PATCH] Exchange lable fail_encoder and fail_connector
The lable fail_connector should placed before fail_encoder since encoder was initialized before connector. which should also be called after connector initialization failed. Signed-off-by: Meng Yi --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c index c564ec6..759527e 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c @@ -51,9 +51,9 @@ int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev) drm_kms_helper_poll_init(fsl_dev->drm); return 0; -fail_encoder: - fsl_dev->crtc.funcs->destroy(&fsl_dev->crtc); fail_connector: fsl_dev->encoder.funcs->destroy(&fsl_dev->encoder); +fail_encoder: + fsl_dev->crtc.funcs->destroy(&fsl_dev->crtc); return ret; } -- 2.1.0.27.g96db324
drm/dp/mst: change MST detection scheme (v2) - reminder
On Sat, Jun 11, 2016 at 01:50:17PM +, Grodzovsky, Andrey wrote:
> Hi.
>
> Just a reminder with regard to this patch. Please comment if any changes are
> required.
> Thanks.
When resubmitting please gather all the r-b you've collected and resubmitt
he entire patch using git send-email. If you want to drive the point home,
add the above blurb to the commit message after a line with just --- (git
will cut away anything below that) and add a RESEND to the subject using
--subject-prefix="PATCH RESEND".
Or reply to the orginal patch directly. But this here doesn't work for the
usual flow.
Thanks, Daniel
>
> -Original Message-
> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
> Of dri-devel-request at lists.freedesktop.org
> Sent: Wednesday, May 18, 2016 7:10 PM
> To: dri-devel at lists.freedesktop.org
> Subject: dri-devel Digest, Vol 74, Issue 285
>
> Send dri-devel mailing list submissions to
> dri-devel at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-owner at lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of dri-devel digest..."
>
>
> Today's Topics:
>
>1. Re: [PATCH] drm: Nuke ->vblank_disable_allowed (Alex Deucher)
>2. Re: [PATCH 1/2] dma-buf/fence: add fence_collection fences
> (Chris Wilson)
>3. drm/dp/mst: change MST detection scheme (v2) (Andrey Grodzovsky)
>
>
> --
>
> Message: 1
> Date: Wed, 18 May 2016 17:54:50 -0400
> From: Alex Deucher
> To: Daniel Vetter
> Cc: Laurent Pinchart ,
> Intel Graphics Development , Liviu
> Dudau , DRI Development
> , Tomi Valkeinen
> , Russell King arm.linux.org.uk>,
> Alex Deucher , Daniel Vetter
>
> Subject: Re: [PATCH] drm: Nuke ->vblank_disable_allowed
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, May 18, 2016 at 4:29 PM, Daniel Vetter
> wrote:
> > This was added in
> >
> > commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241
> > Author: Jesse Barnes
> > Date: Tue Sep 30 12:14:26 2008 -0700
> >
> > drm: Rework vblank-wait handling to allow interrupt reduction.
> >
> > to stay backwards-compatible with old UMS code that didn't even tell
> > the kernel when it did a modeset, so that the kernel could
> > save/restore vblank counters. At worst this means vblanks will be
> > somewhat funky on a setup that very likely no one still runs.
> >
> > So let's just nuke it.
> >
> > Plan B would be to set it unconditionally in drm_vblank_init for kms
> > drivers, instead of in each driver separately. So if this patch breaks
> > anything please only restore the hunks in drmP.h and drm_irq.c, plus
> > add a check for DRIVER_MODESET in drm_vblank_init.
> >
> > Stumbled over this in a discussion on irc with Chris.
> >
> > v2: Remove leftover debug gunk from psr hacking (Alex).
> >
> > Cc: Chris Wilson
> > Cc: Alex Deucher
> > Cc: Liviu Dudau
> > Cc: Russell King
> > Cc: Thierry Reding
> > Cc: Eric Anholt
> > Cc: Laurent Pinchart
> > Cc: Inki Dae
> > Cc: Tomi Valkeinen
> > Cc: Mark Yao
> > Cc: Sascha Hauer
> > Cc: Philipp Zabel
> > Signed-off-by: Daniel Vetter
>
> Seems reasonable to me.
>
> Reviewed-by: Alex Deucher
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 1 -
> > drivers/gpu/drm/arm/hdlcd_drv.c | 1 -
> > drivers/gpu/drm/armada/armada_drv.c | 1 -
> > drivers/gpu/drm/drm_irq.c | 6 --
> > drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 ---
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 -
> > drivers/gpu/drm/gma500/psb_drv.c| 1 -
> > drivers/gpu/drm/i915/i915_dma.c | 3 ---
> > drivers/gpu/drm/imx/imx-drm-core.c | 7 ---
> > drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 -
> > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 7 ---
> > drivers/gpu/drm/tegra/drm.c | 1 -
> > drivers/gpu/drm/vc4/vc4_kms.c | 2 --
> > include/drm/drmP.h | 8
> > 14 files changed, 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> > index 9266c7b69808..835a3fa8d8df 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> > @@ -219,7 +219,6 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
> > if (r) {
> > return r;
> > }
> > - adev->ddev->vblank_disable_allowed = true;
> >
> > /* enable msi */
> > adev->irq.msi_enabled = false; diff --git
> > a/drivers/gpu
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #134 from Nicolai Hähnle --- Hi Daniel, curious, but I doubt the crash is related to the lockup. Most likely, buffer creation fails in radeon_cs_create_fence and then we get a NULL pointer dereference. If you could get a backtrace with line numbers to confirm that would be nice. In any case, GPU lockups can only be caused by actually submitting something to the GPU, which we obviously don't do once the game process crashes... so more likely, the GPU lockup happens first and then causes the subsequent failure somehow. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/7ae8c5b5/attachment.html>
[Bug 96495] [radeonsi] can't compile shaders with pow(10.0, x)
https://bugs.freedesktop.org/show_bug.cgi?id=96495 --- Comment #1 from Nicolai Hähnle --- Hi Vladislav, thanks for the report. I'm looking into it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/c5d62ced/attachment.html>
Looking for pointers on diagnosing ring test failure in amdgpu
Hi Matthew, sounds like the UVD block doesn't want to initialize. No idea off hand why, could be anything. I would need the hardware here for a closer inspection. For a workaround you can try to disable the UVD blokc using the ip_block_mask module parameter (it's a bitmask of enabled blocks e.g. 0x means all blocks enabled, UVD is bit 7 on Carrizo IIRC). Regards, Christian. Am 13.06.2016 um 03:35 schrieb Matthew Macy: > > I'm trying to bring up amdgpu an Carrizo A10 (Thinkpad e565 in case it > matters) on FreeBSD. The driver is essentially unmodified from what is found > in Linux 4.6 - relying on an extended version of FreeBSD's linuxkpi shims. > The shims work well enough that i915/drm from 4.6 works extremely well on > most hardware (I have yet to diagnose / fix the severe artifacts on Cherry > Trail and Atom). > > On my A10 ring 11 test is failing: >https://gist.github.com/mattmacy/8e4a85072648eceb2445ad227dcc447c > > On my friend's A12 based EliteBook ring initialization succeeds: > https://gist.github.com/mattmacy/d1fac64ab5190bb2568d6480dfbd7ee6 > > With minor timing perturbations ring tests will fail as early as ring 0. > > I'm hoping that one of the amdgpu developers might give me pointers on how to > diagnose further and or what bugs in the linuxkpi might be causing this. I > know that I can selectively disable the rings, but that doesn't help fix the > underlying problem. > > Thanks in advance. > > -M > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On 06/13/16 17:06, Daniel Vetter wrote: > On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote: >> On 10.06.2016 23:43, Daniel Vetter wrote: >>> On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: From: Michel Dänzer If userspace wants a page flip to take effect during vblank sequence n, it has to wait for vblank seqno n-1 before calling the DRM_IOCTL_MODE_PAGE_FLIP ioctl. This change makes sure that we do not program the flip to the hardware before the end of vblank seqno n-1 in this case, to prevent the flip from taking effect too early. On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called during vblank, but userspace didn't wait for the current vblank seqno before, this change would still allow the flip to be programmed during the current vblank seqno. >>> >>> This just sounds like you're sending vblank events out a bit too early. >>> And watching vblank waits that userspace does works, but it's fragile, >>> add-hoc and I don't really jump in joy about adding that to the vblank >>> core. Is there no way you can adjust sending out the vblank events >>> similarly, to make sure userspace can never sneak in a pageflip too early? >> >> What you call "too early" is actually "during the vertical blank period >> waited for". IMHO only notifying userspace of a vertical blank period >> when it's already over would defeat the purpose. > > Afaiui the rules are: > - The timestamp for vblank event needs to agree with whatever oml_sync > requries. > - The event delivery itself needs to be consistent with what page_flip > takes, i.e. if userspace sees an event and immediately issues a > page_flip then it should not be able to hit the same vblank with that > pageflip. > - The event needs to be after the old buffers are not longer used and can > be reused for rendering. That's only relevant for DRM_IOCTL_MODE_PAGE_FLIP, not DRM_IOCTL_WAIT_VBLANK. > - There's no requirement at all that the event gets delivered at a > specific point in the vblank, hardware is too different for that to work As the name implies, the purpose of DRM_IOCTL_WAIT_VBLANK is to wait for a vertical blank period. If that doesn't work as intended with some hardware, that's tough luck but not really my problem. :) > - that kind of precision is why we have a separate timestamp. I'm afraid this last item gives away that you're relatively new to this code. ;) The timestamp was originally literally just the current gettimeofday when the wait finished (the original DRM_IOCTL_WAIT_VBLANK ioctl didn't have any asynchronous notification functionality). It was relatively recently that Mario changed the timestamp to correspond to the end of the vertical blank period / start of scanout of the next frame, presumably due to your first rule above. > I assume you're goal is to not delay page_flips unecessarily, without > breaking requirement 2 here. Imo a simpler fix would be to delay the > vblank handling to end of vblank. Fixes everything without hacks, [...] Except it breaks the original purpose of the wait for vblank functionality, which is to wait for the beginning of a vertical blank period. [0] You're focusing too much on page flips and suggesting to throw out the vblank baby with the bathwater. I really don't see the big issue which would justify that. [0] As an analogy, how useful would e.g. calendar notifications be if they arrived at the end of the events they're about? "Hey, that meeting you were supposed to attend? It just finished!" -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 96495] [radeonsi] can't compile shaders with pow(10.0, x)
https://bugs.freedesktop.org/show_bug.cgi?id=96495 --- Comment #2 from Nicolai Hähnle --- The patch at http://reviews.llvm.org/D21282 fixes this for me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/183fd09d/attachment.html>
[PATCH] drm/virtio: Don't reinvent a flipping wheel
On Fr, 2016-06-10 at 17:20 +0200, Daniel Vetter wrote: > On Fri, Jun 10, 2016 at 12:07:53AM +0200, Daniel Vetter wrote: > > Now that the core helpers support nonblocking atomic commits there's > > no need to invent that wheel separately (instead of fixing the bug in > > the atomic implementation of virtio, as it should have been done!). > > > > v2: Rebased on top of > > > > commit e7cf0963f816fa44190caaf51aeffaa614c340c6 > > Author: Gerd Hoffmann > > Date: Tue May 31 08:50:47 2016 +0200 > > > > virtio-gpu: add atomic_commit function > > > > Cc: Gerd Hoffmann > > Tested-by: Gerd Hoffmann (v1) > > Reviewed-by: Gerd Hoffmann (v1) > > Signed-off-by: Daniel Vetter > > Gerd, can you pls retest? I think due to your change in the above > referenced commit to switch to active_only=true in commit_planes() this is > now broken. Yes, probably it'll break things. Any branch I can test? Your "stuff" branch seems to not yet have the commit above. I guess virtio-gpu should switch over to override .atomic_commit_tail instead of .atomic_commit? cheers, Gerd
[PATCH v4 0/4] Generic zpos property
version 4: make sure that normalized zpos value is stay in the defined property range and warn user if not. Fix NULL pointer bug in rcar-du while setting zpos value. No changes in the other drivers. version 3: use kmalloc_array instead of kmalloc. Correct normalize_zpos computation (comeback to Mareck original code) version 2: add a zpos property into drm_plane structure to simplify code. This allow to get/set zpos value in core and not in drivers code. Fix various remarks. version 1: refactor Marek's patches to have per plane zpos property instead of only one in core. Benjamin Gaignard (3): drm: add generic zpos property drm: sti: use generic zpos for plane drm: rcar: use generic code for managing zpos plane property Marek Szyprowski (1): drm/exynos: use generic code for managing zpos plane property Documentation/DocBook/gpu.tmpl| 10 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 4 + drivers/gpu/drm/drm_atomic_helper.c | 6 + drivers/gpu/drm/drm_blend.c | 230 ++ drivers/gpu/drm/drm_crtc_internal.h | 3 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 - drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 ++--- drivers/gpu/drm/exynos/exynos_mixer.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 - drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 +- drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 - drivers/gpu/drm/sti/sti_mixer.c | 9 +- drivers/gpu/drm/sti/sti_plane.c | 80 --- drivers/gpu/drm/sti/sti_plane.h | 2 - include/drm/drm_crtc.h| 30 18 files changed, 331 insertions(+), 139 deletions(-) create mode 100644 drivers/gpu/drm/drm_blend.c Cc: Inki Dae Cc: Daniel Vetter Cc: Ville Syrjala Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Andrzej Hajda Cc: Krzysztof Kozlowski Cc: Bartlomiej Zolnierkiewicz Cc: Tobias Jakobi Cc: Gustavo Padovan Cc: vincent.abriou at st.com Cc: fabien.dessenne at st.com Cc: Laurent Pinchart -- 1.9.1
[PATCH v4 4/4] drm: rcar: use generic code for managing zpos plane property
version 4:
fix null pointer issue while setting zpos in plane reset function
This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.
Signed-off-by: Benjamin Gaignard
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Laurent Pinchart
Cc: Marek Szyprowski
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 -
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
5 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda..28d2cb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,
static unsigned int plane_zpos(struct rcar_du_plane *plane)
{
- return to_rcar_plane_state(plane->plane.state)->zpos;
+ return plane->plane.state->normalized_zpos;
}
static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
- struct drm_property *zpos;
} props;
unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 86c109b..6a99959 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;
- rcdu->props.zpos =
- drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
- if (rcdu->props.zpos == NULL)
- return -ENOMEM;
-
return 0;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index bfe31ca..dc9bb96 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -652,7 +652,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
- state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+ state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
plane->state = &state->state;
plane->state->plane = plane;
@@ -670,8 +670,6 @@ static int rcar_du_plane_atomic_set_property(struct
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
- else if (property == rcdu->props.zpos)
- rstate->zpos = val;
else
return -EINVAL;
@@ -690,8 +688,6 @@ static int rcar_du_plane_atomic_get_property(struct
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
- else if (property == rcdu->props.zpos)
- *val = rstate->zpos;
else
return -EINVAL;
@@ -763,8 +759,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(&plane->plane.base,
rcdu->props.colorkey,
RCAR_DU_COLORKEY_NONE);
- drm_object_attach_property(&plane->plane.base,
- rcdu->props.zpos, 1);
+ drm_plane_create_zpos_property(&plane->plane, 1, 7);
}
return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
drm_plane *plane)
* @hwindex: 0-based hardware plane index, -1 means unused
* @alpha: value of the plane alpha property
* @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
*/
struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {
unsigned int alpha;
unsigned int colorkey;
- unsigned int zpos;
};
static inline struct rcar_du_plane_state *
--
1.9.1
[PATCH v4 3/4] drm/exynos: use generic code for managing zpos plane property
From: Marek Szyprowski
This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.
Signed-off-by: Marek Szyprowski
Signed-off-by: Benjamin Gaignard
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Andrzej Hajda
Cc: Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz
Cc: Tobias Jakobi
Cc: Gustavo Padovan
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 -
drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++-
3 files changed, 13 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cc33ec9..b34a7b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
- unsigned int zpos;
};
static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
* this array is used to be aware of which crtc did it request vblank.
*/
struct drm_crtc *crtc[MAX_CRTC];
- struct drm_property *plane_zpos_property;
struct device *dma_dev;
unsigned long da_start;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 55f1d37..1bd8ea7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)
exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
- exynos_state->zpos = exynos_plane->config->zpos;
plane->state = &exynos_state->base;
plane->state->plane = plane;
+ plane->state->zpos = exynos_plane->config->zpos;
}
}
@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;
__drm_atomic_helper_plane_duplicate_state(plane, ©->base);
- copy->zpos = exynos_state->zpos;
return ©->base;
}
@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct
drm_plane *plane,
kfree(old_exynos_state);
}
-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
- struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t val)
-{
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- struct exynos_drm_plane_state *exynos_state =
- to_exynos_plane_state(state);
- struct exynos_drm_private *dev_priv = plane->dev->dev_private;
- const struct exynos_drm_plane_config *config = exynos_plane->config;
-
- if (property == dev_priv->plane_zpos_property &&
- (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
- exynos_state->zpos = val;
- else
- return -EINVAL;
-
- return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
- const struct exynos_drm_plane_state *exynos_state =
- container_of(state, const struct exynos_drm_plane_state, base);
- struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
- if (property == dev_priv->plane_zpos_property)
- *val = exynos_state->zpos;
- else
- return -EINVAL;
-
- return 0;
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
- .atomic_set_property = exynos_drm_plane_atomic_set_property,
- .atomic_get_property = exynos_drm_plane_atomic_get_property,
};
static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs
plane_helper_funcs = {
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
{
- struct drm_device *dev = plane->dev;
- struct exynos_drm_private *dev_priv = dev->dev
[PATCH v4 1/4] drm: add generic zpos property
version 4:
- make sure that normalized zpos value is stay
in the defined property range and warn user if not
This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
id value if zpos equals
Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.
Signed-off-by: Marek Szyprowski
Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.
Signed-off-by: Benjamin Gaignard
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Andrzej Hajda
Cc: Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz
Cc: Tobias Jakobi
Cc: Gustavo Padovan
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart
---
Documentation/DocBook/gpu.tmpl | 10 ++
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_atomic.c| 4 +
drivers/gpu/drm/drm_atomic_helper.c | 6 +
drivers/gpu/drm/drm_blend.c | 230
drivers/gpu/drm/drm_crtc_internal.h | 3 +
include/drm/drm_crtc.h | 30 +
7 files changed, 284 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_blend.c
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index dac18b4..8baac27 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2146,6 +2146,16 @@ void intel_crt_init(struct drm_device *dev)
the underlying hardware).
+"zpos"
+ RANGE
+ Min= driver dependent, Max= driver dependent
+ Plane
+ Plane's 'z' position during blending operation (0 for
background, highest for frontmost).
+ If two planes assigned to same CRTC have equal zpos values, the
plane with higher plane
+ id is treated as closer to front. Can be IMMUTABLE if driver
doesn't support changing
+ planes' order. Exact value range is driver dependent.
+
+
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index be43afb..dbec0ea 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-drm-y := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5e4b820..812b0f0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -690,6 +690,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+ } else if (property == plane->zpos_property) {
+ state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -746,6 +748,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+ } else if (property == plane->zpos_property) {
+ *val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index bb98d74..9fbe08c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,8 @@
#include
#include
+#include "drm_crtc_internal.h"
+
/**
* DOC: overview
*
@@ -592,6 +594,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;
+ ret = drm_atomic_helper_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
diff --git a/drivers/gpu/drm/drm
[PATCH v4 2/4] drm: sti: use generic zpos for plane
remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.
Signed-off-by: Benjamin Gaignard
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Andrzej Hajda
Cc: Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz
Cc: Tobias Jakobi
Cc: Gustavo Padovan
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart
---
drivers/gpu/drm/sti/sti_mixer.c | 9 ++---
drivers/gpu/drm/sti/sti_plane.c | 80 +++--
drivers/gpu/drm/sti/sti_plane.h | 2 --
3 files changed, 31 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index 6f86f2b..1e4a9f0 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -239,13 +239,10 @@ static void sti_mixer_set_background_area(struct
sti_mixer *mixer,
int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
{
- int plane_id, depth = plane->zorder;
+ int plane_id, depth = plane->drm_plane.state->normalized_zpos;
unsigned int i;
u32 mask, val;
- if ((depth < 1) || (depth > GAM_MIXER_NB_DEPTH_LEVEL))
- return 1;
-
switch (plane->desc) {
case STI_GDP_0:
plane_id = GAM_DEPTH_GDP0_ID;
@@ -278,8 +275,8 @@ int sti_mixer_set_plane_depth(struct sti_mixer *mixer,
struct sti_plane *plane)
break;
}
- mask |= GAM_DEPTH_MASK_ID << (3 * (depth - 1));
- plane_id = plane_id << (3 * (depth - 1));
+ mask |= GAM_DEPTH_MASK_ID << (3 * depth);
+ plane_id = plane_id << (3 * depth);
DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
sti_plane_to_str(plane), depth);
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index f10c98d..0e447d9 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
#include "sti_drv.h"
#include "sti_plane.h"
-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
- STI_GDP_0,
- STI_GDP_1,
- STI_HQVDP_0,
- STI_GDP_2,
- STI_GDP_3,
-};
-
const char *sti_plane_to_str(struct sti_plane *plane)
{
switch (plane->desc) {
@@ -114,69 +105,54 @@ static void sti_plane_destroy(struct drm_plane *drm_plane)
drm_plane_cleanup(drm_plane);
}
-static int sti_plane_set_property(struct drm_plane *drm_plane,
- struct drm_property *property,
- uint64_t val)
+static int sti_plane_get_default_zpos(enum drm_plane_type type)
{
- struct drm_device *dev = drm_plane->dev;
- struct sti_private *private = dev->dev_private;
- struct sti_plane *plane = to_sti_plane(drm_plane);
-
- DRM_DEBUG_DRIVER("\n");
-
- if (property == private->plane_zorder_property) {
- plane->zorder = val;
+ switch (type) {
+ case DRM_PLANE_TYPE_PRIMARY:
return 0;
+ case DRM_PLANE_TYPE_OVERLAY:
+ return 1;
+ case DRM_PLANE_TYPE_CURSOR:
+ return 7;
}
+ return 0;
+}
- return -EINVAL;
+static void sti_plane_reset(struct drm_plane *plane)
+{
+ drm_atomic_helper_plane_reset(plane);
+ plane->state->zpos = sti_plane_get_default_zpos(plane->type);
}
-static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane)
+static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane,
+enum drm_plane_type type)
{
- struct drm_device *dev = drm_plane->dev;
- struct sti_private *private = dev->dev_private;
- struct sti_plane *plane = to_sti_plane(drm_plane);
- struct drm_property *prop;
-
- prop = private->plane_zorder_property;
- if (!prop) {
- prop = drm_property_create_range(dev, 0, "zpos", 1,
-GAM_MIXER_NB_DEPTH_LEVEL);
- if (!prop)
- return;
-
- private->plane_zorder_property = prop;
+ switch (type) {
+ case DRM_PLANE_TYPE_PRIMARY:
+ case DRM_PLANE_TYPE_OVERLAY:
+ drm_plane_create_zpos_property(drm_plane, 0, 6);
+ break;
+ case DRM_PLANE_TYPE_CURSOR:
+ drm_plane_create_zpos_immutable_property(drm_plane, 7, 7);
+ break;
}
-
- drm_object_attach_property(&drm_plane->base, prop, plane->zorder);
}
void sti_plane_init_property(struct sti_plane *plane,
enum drm_plane_type type)
{
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(sti_plane_default_zorder); i++)
- if (sti_plane_default_zorder[i] == plane->desc)
-
[PATCH 23/27] drm: Replace fb_helper->atomic with mode_config->atomic_commit
On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote:
> On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote:
>> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter
>> wrote:
>> > Drivers transitioning to atomic might not yet want to enable full
>> > DRIVER_ATOMIC support when it's not entirely working. But using atomic
>> > internally makes a lot more sense earlier.
>> >
>> > Instead of spreading such flags to more places I figured it's simpler
>> > to just check for mode_config->funcs->atomic_commit, and use atomic
>> > paths if that is set. For the only driver currently transitioning
>> > (i915) this does the right thing.
>>
>> Well, imx-drm is transitioning.
>> Unfortunately, after applying this patch, legacy fbdev cannot enable
>> displays when the imx-drm transitional patch set reaches phase 3 step 1[1].
>>
>> For those transitioning drivers with fine-grained steps, this patch
>> is likely to expose the atomic function __drm_atomic_helper_set_config
>> to legacy fbdev support too early. They could still be using
>> drm_crtc_helper_set_config when adding ->atomic_commit.
>>
>> BTW, this patch and those for generic nonblocking commit are making
>> the imx-drm transition a bit harder. Not good timing probably.
>> But, I'll go on with the task anyway.
>
> Hm, making transition harder wasn't really the intention. What exactly is
> blowing up for you? At least how I planned the transition the first thing
> you should be able to do is basic modesets (once you fill out
> ->atomic_commit), so I hoped that this wouldn't cause trouble.
At the imx-drm transition phase 1, ipu_plane_atomic_check checks
crtc->enabled and hopes it to be true. Till phase 3 step 1, this function
is not changed. This patch exposes restore_fbdev_mode_atomic and
pan_display_atomic to legacy fbdev too early. Both of them call
drm_atomic_commit which does plane check at atomic check stage.
Then, the plane check fails for the legacy fbdev, because
drm_atomic_commit sets crtc->enabled later than the legacy path
drm_crtc_helper_set_mode does. Actually, drm_atomic_commit
doesn't set crtc->enabled until the commit stage if you use the
atomic helper.
OTOH, we fill out ->atomic_commit with drm_atomic_helper_commit
at phase 3 step 1, then exposing drm_atomic_commit means that we
need to handle crtc_state->event no later than phase 3 step 1...
I haven't decided the right order/process to add the handling.
So, would it be an option to revert this patch...
>
> Wrt nonblocking commit helpers breaking transitioning drivers: The most
> likely cause is your driver isn't handling crtc_state->event yet. Before
> you start using ->atomic_commit or one of the helpers to map legacy ioctl
> to atomic, you need to fill out some code to handle that in ->atomic_begin
> or ->atomic_flush. Then the transition should still work as before.
I do have confusion on the event handling in some drivers' ->atomic_flush.
At least sun4i, kirin and fsl-dcu have the below snip:
==
if (event) {
crtc->state->event = NULL;
spin_lock_irq(&crtc->dev->event_lock);
if (drm_crtc_vblank_get(crtc) == 0)
drm_crtc_arm_vblank_event(crtc, event);
else
drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irq(&crtc->dev->event_lock);
}
==
It looks drm_crtc_vblank_get seldom fails?
And why do we send vblank event when it fails?
Regards,
Liu Ying
>
> I'll be happy to help you out debug this, and then update my blog post
> with the transition plan with the latest findings.
>
> Thanks, Daniel
>
>>
>> [1] https://patchwork.kernel.org/patch/9144035/
>>
>> Regards,
>> Liu Ying
>>
>> >
>> > Cc: Maarten Lankhorst
>> > Signed-off-by: Daniel Vetter
>> > ---
>> > drivers/gpu/drm/drm_fb_helper.c| 6 ++
>> > drivers/gpu/drm/i915/intel_fbdev.c | 2 --
>> > include/drm/drm_fb_helper.h| 11 ---
>> > 3 files changed, 2 insertions(+), 17 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> > b/drivers/gpu/drm/drm_fb_helper.c
>> > index c0e0a2e78d75..ba2fcb2a68ad 100644
>> > --- a/drivers/gpu/drm/drm_fb_helper.c
>> > +++ b/drivers/gpu/drm/drm_fb_helper.c
>> > @@ -385,7 +385,7 @@ static int restore_fbdev_mode(struct drm_fb_helper
>> > *fb_helper)
>> >
>> > drm_warn_on_modeset_not_all_locked(dev);
>> >
>> > - if (fb_helper->atomic)
>> > + if (dev->mode_config.funcs->atomic_commit)
>> > return restore_fbdev_mode_atomic(fb_helper);
>> >
>> > drm_for_each_plane(plane, dev) {
>> > @@ -716,8 +716,6 @@ int drm_fb_helper_init(struct drm_device *dev,
>> > i++;
>> > }
>> >
>> > - fb_helper->atomic = !!drm_core_check_feature(dev, DRIVER_ATOMIC);
>> > -
>> > return 0;
>> > out_free:
>> > drm_fb_helper_crtc_free(fb_helper);
>> > @@ -1344,7 +1342,7 @@ int drm
[v2 PATCH 3/4] Documentation: bindings: add dt documentation for cdn DP controller
This patch adds a binding that describes the cdn DP controller for
rk3399.
Signed-off-by: Chris Zhong
---
Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description
.../bindings/display/rockchip/cdn-dp-rockchip.txt | 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
new file mode 100644
index 000..4a66fc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
@@ -0,0 +1,62 @@
+Rockchip RK3399 specific extensions to the cdn Display Port
+
+
+Required properties:
+- compatible: must be "rockchip,cdn-dp"
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+
+- clock-names: from common clock binding:
+ Required elements: "core_clk" "pclk" "spdif"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port nodes with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+contained 2 endpoints, connecting to the output of vop.
+
+- phys: from general PHY binding: the phandle for the PHY device.
+
+- extcon: extcon specifier for the Power Delivery
+
+- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
+
+---
+
+Example:
+ cdn_dp: dp at fec0 {
+ compatible = "rockchip,cdn-dp";
+ reg = <0x0 0xfec0 0x0 0x10>;
+ interrupts = ;
+ clocks = <&cru SCLK_DP_CORE>, <&cru PCLK_DP_CTRL>,
+<&cru SCLK_SPDIF_REC_DPTX>;
+ clock-names = "core_clk", "pclk", "spdif";
+ phys = <&tcphy0>;
+ extcon = <&fusb1>;
+ rockchip,grf = <&grf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ dp_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dp_in_vopb: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_dp>;
+ };
+
+ dp_in_vopl: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_dp>;
+ };
+ };
+ };
+ };
--
2.6.3
[v2 PATCH 4/4] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/cdn/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.
Signed-off-by: Chris Zhong
---
Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()
Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/cdn-dp-core.c | 694 +++
drivers/gpu/drm/rockchip/cdn-dp-core.h | 108 +
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 717
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 404
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
9 files changed, 1942 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20da9a8 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
for the Analogix Core DP driver. If you want to enable DP
on RK3288 based SoC, you should selet this option.
+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn Dp driver. If you want to enable Dp on
+ RK3399 based SoC, you should selet this
+ option.
+
config ROCKCHIP_DW_HDMI
tristate "Rockchip specific extensions for Synopsys DW HDMI"
depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..abdecd5 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..4e7f036
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,694 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include "cdn-dp-reg.h"
+#include "cdn-dp-core.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_dp(c) \
+ container_of(c, struct cdn_dp_device, connector)
+
+#define encoder_to_dp(c) \
+ container_of(c, struct cdn_dp_device, encoder)
+
+/* dp grf register offset */
+#define DP_VOP_SEL 0x6224
+#define DP_SEL_VOP_LIT BIT(12)
+#define DP_CLK_RATE2
+#define WAIT_HPD_STABLE1000
+
+static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
+{
+ int ret;
+
+ ret = clk_prepare_enable(dp->pclk);
+ if (ret < 0) {
+ dev_err(dp->dev, "cannot enable dp pclk %d\n", ret);
+ goto err_pclk;
+ }
+
+ ret = clk_prepare_enable(dp->core_clk);
+ if (ret < 0) {
+ dev_err(dp->dev,
[v2 PATCH 0/4] Rockchip Type-C and DispplayPort driver
Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. The Type-C cable orientation detection and Power Delivery (PD) is accomplished using a PD PHY or a exernal PD chip. The DP controller is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to /lib/firmware/cdn/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The PHY driver has register a notification with extcon API, to get the alt mode from PD, the PD driver need call the devm_extcon_dev_allocate to create a extcon device and use extcon_set_state to notify PHY and DP controller. About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF. We can reference them in simple-card. This series is based on Mark Yao's branch: https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23 I test this patches on the rk3399-evb board, with a fusb302 driver, this branch has no rk3399.dtsi, so the patch about dts is not included in this series. Changes in v2: - add some registers description - select RESET_CONTROLLER - alphabetic order - modify some spelling mistakes - make mode cleaner - use bool for enable/disable - check all of the return value - return a better err number - use more readx_poll_timeout() - clk_disable_unprepare(tcphy->clk_ref); - remove unuse functions, rockchip_typec_phy_power_on/off - remove unnecessary typecast from void * - use dts node to distinguish between phys. - Alphabetic order - remove excess error message - use define clk_rate - check all return value - remove dev_set_name(dp->dev, "cdn-dp"); - use schedule_delayed_work - remove never-called functions - remove some unnecessary () Changes in v1: - add extcon node description - move the registers in phy driver - remove the suffix of reset - update the licence note - init core clock to 50MHz - use extcon API - remove unused global - add some comments for magic num - change usleep_range(1000, 2000) tousleep_range(1000, 1050) - remove __func__ from dev_err - return err number when get clk failed - remove ADDR_ADJ define - use devm_clk_get(&pdev->dev, "tcpdcore") - add extcon node description - add #sound-dai-cells description - use extcon API - use hdmi-codec for the DP Asoc - do not initialize the "ret" - printk a err log when drm_of_encoder_active_endpoint_id - modify the dclk pin_pol to a single line Chris Zhong (4): Documentation: bindings: add dt doc for Rockchip USB Type-C PHY phy: Add USB Type-C PHY driver for rk3399 Documentation: bindings: add dt documentation for cdn DP controller drm/rockchip: cdn-dp: add cdn DP support for rk3399 .../bindings/display/rockchip/cdn-dp-rockchip.txt | 62 ++ .../devicetree/bindings/phy/phy-rockchip-typec.txt | 77 ++ drivers/gpu/drm/rockchip/Kconfig | 9 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 694 +++ drivers/gpu/drm/rockchip/cdn-dp-core.h | 108 +++ drivers/gpu/drm/rockchip/cdn-dp-reg.c | 717 drivers/gpu/drm/rockchip/cdn-dp-reg.h | 404 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 6 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 2 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 2 + drivers/phy/Kconfig| 8 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-typec.c | 952 + include/linux/phy/phy-rockchip-typec.h | 20 + 15 files changed, 3062 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt create mode 100644 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h create mode 100644 drivers/phy/phy-rockchip-typec.c create mode 100644 include/linux/phy/phy-rockchip-typec.h -- 2.6.3
[GIT PULL] drm/mediatek: MT8173 HDMI support
Hi Dave, please consider merging this tag, which contains the v16 MT8173 HDMI patches I sent on 2016-05-26, rebased onto v4.7-rc2. There have been no further comments. regards Philipp The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b: Linux 4.7-rc2 (2016-06-05 14:31:26 -0700) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-2016-06-13 for you to fetch changes up to 21ff16b77e779f9f9dd56522613f3835b0a3a386: dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation (2016-06-13 11:08:27 +0200) MT8173 HDMI support - device tree binding documentation for MT8173 HDMI encoder, CEC, DDC, and PHY - drivers for MT8173 HDMI encoder, CEC (HPD only for now), DDC, and PHY - enable HDMI output via a custom SMCCC call - add ddc-i2c-bus property to HDMI connector device tree binding Jie Qiu (2): drm/mediatek: Add HDMI support drm/mediatek: enable hdmi output control bit Philipp Zabel (2): dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation .../bindings/display/connector/hdmi-connector.txt |1 + .../bindings/display/mediatek/mediatek,hdmi.txt| 148 ++ drivers/gpu/drm/mediatek/Kconfig |8 + drivers/gpu/drm/mediatek/Makefile |7 + drivers/gpu/drm/mediatek/mtk_cec.c | 265 +++ drivers/gpu/drm/mediatek/mtk_cec.h | 26 + drivers/gpu/drm/mediatek/mtk_hdmi.c| 1828 drivers/gpu/drm/mediatek/mtk_hdmi.h| 23 + drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c| 358 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 238 +++ drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 515 ++ 11 files changed, 3417 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.c create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
Bad flicker on skylake HQD due to code in the 4.7 merge window
On Tue, 31 May 2016, James Bottomley wrote: > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote: >> On Mon, 30 May 2016, James Bottomley < >> James.Bottomley at HansenPartnership.com> wrote: >> > I've tested a pristine 4.6.0 system, so it's definitely something >> > that >> > went in during the merge window. The flicker isn't continuous, >> > it's >> > periodic, with an interval of something like 2-5 seconds. It looks >> > like an old analogue TV going out of sync and then resyncing. I've >> > attached the dmesg and X.org log below just in case they can help. >> > I >> > might be able to bisect this next week, but, unfortunately, this is >> > my >> > current laptop and I'm travelling this week. >> >> Please try i915.enable_psr=0 module parameter. > > Makes no discernable difference. Current parameter settings are: Sorry for the silence. Would you mind trying out drm-intel-nightly branch of [1]? BR, Jani. [1] http://cgit.freedesktop.org/drm-intel -- Jani Nikula, Intel Open Source Technology Center
[v1,4/4] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Hi Guenter
Thanks for your comments
On 06/09/2016 06:13 AM, Guenter Roeck wrote:
>> +if (ret < 0) {
>> >+ dev_err(dp->dev, "failed to request firmware %d\n", ret);
>> >+ return ret;
>> >+ }
>> >+
>> >+ hdr = (struct cdn_firmware_header *)fw->data;
>> >+ if (fw->size != le32_to_cpu(hdr->size_bytes))
>> >+ return -EINVAL;
>> >+
>> >+ ret = cdn_dp_clk_enable(dp);
>> >+ if (ret < 0) {
>> >+ dev_err(dp->dev, "cannot enable dp clk %d\n", ret);
>> >+ return ret;
>> >+ }
>> >+
>> >+ dp_clock_reset_seq(dp);
>> >+
>> >+ iram_data = (const u32 *)(fw->data + hdr->header_size);
>> >+ dram_data = (const u32 *)(fw->data + hdr->header_size + hdr->iram_size);
> No need for endianness conversion here ?
>
The firmware does need for endianness conversio.
And for the other comments, I have done them, v2 has been posted.
[PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache
On 13/06/16 10:56, Shunqian Zheng wrote:
> Hi
>
> On 2016å¹´06æ10æ¥ 17:10, Tomasz Figa wrote:
>> Hi,
>>
>> On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng
>> wrote:
>>> Use DMA API instead of architecture internal functions like
>>> __cpuc_flush_dcache_area() etc.
>>>
>>> To support the virtual device like DRM the virtual slave iommu
>>> added in the previous patch, attaching to which the DRM can use
>>> it own domain->dev for dma_map_*(), dma_sync_*() even VOP is disabled.
>>>
>>> With this patch, this driver is available for ARM64 like RK3399.
>>>
>> Could we instead simply allocate coherent memory for page tables using
>> dma_alloc_coherent() and skip any flushing on CPU side completely? If
>> I'm looking correctly, the driver only reads back the page directory
>> when checking if there is a need to allocate new page table, so there
>> shouldn't be any significant penalty for disabling the cache.
> I try to use dma_alloc_coherent() to replace the dma_map_single(),
> but it doesn't work for me properly.
> Because the DRM uses the iommu_dma_ops instead the swiotlb_dma_ops after
> attaching
> to iommu, so when the iommu domain need to alloc a new page in
> rk_iommu_map(),
> it would call:
> rk_iommu_map() --> dma_alloc_coherent() --> ops->alloc() -->
> iommu_map() --> rk_iommu_map()
That sounds more like you're passing the wrong device around somewhere,
since this approach is working fine for other IOMMUs; specifically, the
flow goes:
dma_alloc_coherent(DRM dev) // for buffer
--> ops->alloc(DRM dev)
--> iommu_dma_alloc(DRM dev)
--> iommu_map()
--> dma_alloc_coherent(IOMMU dev) // for pagetable
--> ops->alloc(IOMMU dev)
--> swiotlb_alloc(IOMMU dev)
There shouldn't be any need for this "virtual IOMMU" at all. I think the
Exynos DRM driver is in a similar situation of having multiple devices
(involving multiple IOMMUs) backing the virtual DRM device, and that
doesn't seem to be doing anything this crazy so it's probably worth
taking a look at.
Robin.
> Then I try to reserve memory for coherent so that, dma_alloc_coherent()
> calls dma_alloc_from_coherent()
> but not ops->alloc(). But it doesn't work too because when DRM request
> buffer it never uses iommu.
>>
>> Other than that, please see some comments inline.
>>
>>> Signed-off-by: Shunqian Zheng
>>> ---
>>> drivers/iommu/rockchip-iommu.c | 113
>>> ++---
>>> 1 file changed, 71 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/drivers/iommu/rockchip-iommu.c
>>> b/drivers/iommu/rockchip-iommu.c
>>> index d6c3051..aafea6e 100644
>>> --- a/drivers/iommu/rockchip-iommu.c
>>> +++ b/drivers/iommu/rockchip-iommu.c
>>> @@ -4,8 +4,6 @@
>>>* published by the Free Software Foundation.
>>>*/
>>>
>>> -#include
>>> -#include
>>> #include
>>> #include
>>> #include
>>> @@ -61,8 +59,7 @@
>>> #define RK_MMU_IRQ_BUS_ERROR 0x02 /* bus read error */
>>> #define RK_MMU_IRQ_MASK (RK_MMU_IRQ_PAGE_FAULT |
>>> RK_MMU_IRQ_BUS_ERROR)
>>>
>>> -#define NUM_DT_ENTRIES 1024
>>> -#define NUM_PT_ENTRIES 1024
>>> +#define NUM_TLB_ENTRIES 1024 /* for both DT and PT */
>> Is it necessary to change this in this patch? In general, it's not a
>> good idea to mix multiple logical changes together.
> Sure, will restore changes in v3.
>>
>>> #define SPAGE_ORDER 12
>>> #define SPAGE_SIZE (1 << SPAGE_ORDER)
>>> @@ -82,7 +79,9 @@
>>>
>>> struct rk_iommu_domain {
>>> struct list_head iommus;
>>> + struct device *dev;
>>> u32 *dt; /* page directory table */
>>> + dma_addr_t dt_dma;
>>> spinlock_t iommus_lock; /* lock for iommus list */
>>> spinlock_t dt_lock; /* lock for modifying page directory
>>> table */
>>>
>>> @@ -98,14 +97,12 @@ struct rk_iommu {
>>> struct iommu_domain *domain; /* domain to which iommu is
>>> attached */
>>> };
>>>
>>> -static inline void rk_table_flush(u32 *va, unsigned int count)
>>> +static inline void rk_table_flush(struct device *dev, dma_addr_t dma,
>>> + unsigned int count)
>>> {
>>> - phys_addr_t pa_start = virt_to_phys(va);
>>> - phys_addr_t pa_end = virt_to_phys(va + count);
>>> - size_t size = pa_end - pa_start;
>>> + size_t size = count * 4;
>> It would be a good idea to specify what "count" is. I'm a bit confused
>> that before it meant bytes and now some multiple of 4?
> "count" means PT/DT entry count to flush here. I would add some more
> comment on it.
>
> Thank you very much,
> Shunqian
>>
>> Best regards,
>> Tomasz
>>
>> ___
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
> ___
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] drm: hdlcd: Unwind the DRM setup on error conditions in the right order.
On 08/06/16 13:56, Liviu Dudau wrote: > In hdlcd_drm_bind()/hdlcd_drm_unbind() we unwind the DRM setup in the > wrong order (drm_mode_config_cleanup() before connector and encoder > had a chance to cleanup their memory or before drm_dev_unregister()). > The correct order should match in both functions. > > Reported-by: Robin Murphy > Signed-off-by: Liviu Dudau > --- > > Robin, > > I believe this should fix your problems with HDLCD failing to allocate CMA > memory and then crashing. Heh, I'm not sure I'd even clocked that there was yet another propblem beyond the original gem_free_object() crash. I've just tried 4.7-rc3 with the relevant fixes for that, and indeed drm_connector_cleanup() does go bang, and this patch makes it happy again. Tested-by: Robin Murphy Thanks, Robin. > > Best regards, > Liviu > > drivers/gpu/drm/arm/hdlcd_drv.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > index 3422ca2..2c6eddb 100644 > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > @@ -382,7 +382,6 @@ static int hdlcd_drm_bind(struct device *dev) > > err_fbdev: > drm_kms_helper_poll_fini(drm); > - drm_mode_config_cleanup(drm); > drm_vblank_cleanup(drm); > err_vblank: > pm_runtime_disable(drm->dev); > @@ -390,6 +389,7 @@ err_pm_active: > component_unbind_all(dev, drm); > err_unregister: > drm_dev_unregister(drm); > + drm_mode_config_cleanup(drm); > err_unload: > drm_irq_uninstall(drm); > of_reserved_mem_device_release(drm->dev); > @@ -410,15 +410,15 @@ static void hdlcd_drm_unbind(struct device *dev) > hdlcd->fbdev = NULL; > } > drm_kms_helper_poll_fini(drm); > - component_unbind_all(dev, drm); > drm_vblank_cleanup(drm); > + component_unbind_all(dev, drm); > pm_runtime_get_sync(drm->dev); > drm_irq_uninstall(drm); > pm_runtime_put_sync(drm->dev); > pm_runtime_disable(drm->dev); > - of_reserved_mem_device_release(drm->dev); > - drm_mode_config_cleanup(drm); > drm_dev_unregister(drm); > + drm_mode_config_cleanup(drm); > + of_reserved_mem_device_release(drm->dev); > drm_dev_unref(drm); > drm->dev_private = NULL; > dev_set_drvdata(dev, NULL); >
[Bug 96360] [bisected: 3d02b7] VM fault with kernel 4.7-rc1 on Alien: Isolation
https://bugs.freedesktop.org/show_bug.cgi?id=96360 --- Comment #10 from Nicolai Hähnle --- No, thank you. I can reproduce this on a Verde, so it does seem to be SI-specific (perhaps also CI) or perhaps a radeon vs. amdgpu issue. I've seen a VM fault even with GALLIUM_DDEBUG=800 (i.e. frequent flushes) happen at 901138 @3 glDispatchCompute(num_groups_x = 128, num_groups_y = 2, num_groups_z = 1) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/be2ccb34/attachment.html>
[PATCH] drm/dsi: Add uevent callback
On Wed, Jun 08, 2016 at 10:10:29AM +0530, Archit Taneja wrote: > > > On 06/03/2016 08:58 PM, Thierry Reding wrote: > > From: Thierry Reding > > > > Implement a uevent callback for devices on the MIPI DSI bus. This > > callback will append MODALIAS information to the uevent and allow > > modules to be loaded when devices are added to the bus. > > Reviewed-by: Archit Taneja Applied to topic/drm-misc. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/8b823497/attachment.sig>
[PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding
On Fri, Jun 10, 2016 at 12:52:41PM -0700, Doug Anderson wrote: > Rob, > > On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark wrote: > > On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson > chromium.org> wrote: > >> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > >> using eDP interfaces. > > > > so drive-by comment... but shouldn't eDP be probe-able? Not sure why > > we need panel drivers or DT bindings? > > I was wondering about that too. As far as I can tell: > > 1. We need a panel driver because that appears to be what owns a > reference to the backlight / panel power regulator and that part is > not auto-probable. Yes, that's one of the reasons why we still need DT nodes for panels, even on a probe-able bus. eDP has a mechanism to allow brightness control via DPCD, but I've never actually seen it implemented. Even if we had that, we'd likely need to represent supplies and GPIOs for the backlight, and we'd be back to square one. DSI also provides a means to control backlight brightness, but in the same way that eDP doesn't go all the way, we'd require external resources to be hooked up via DT again. > 2. As far as I could tell, there is no way to declare a generic > (unspecified) panel in the device tree. Everyone seems to include > "simple-panel" in their compatible string but as far as I can tell > nothing in the kernel looks at it. The ones that do are wrong and should eventually be updated. This was originally done, and the driver used to match on simple-panel as well, but in retrospect that didn't make any sense at all so it was removed from the driver again. One of the reasons why it doesn't make any sense is because even if you have an EDID that's reachable, the EDID itself doesn't fully specify the panel. Power sequences are one example of data that's not represented in EDID. > 3. In theory, all the info specified here should match the EDID > exactly and thus (as you said) be probable. However, it sounds like > (for power sequencing reasons) there might be reasons why you'd want > to know exactly what panel was present beforehand. You might need to > power the panel and backlight in very specific sequences, for > instance. I'm not sure it's always 100% possible in all embedded > designs to read the EDID before you know how the sequencing should > work (but, of course, I'm a NOOB). It doesn't really matter whether you can access EDID or not, because EDID contains absolutely nothing on the power sequences for the panel. Even if it did, there'd be no way to relate that information to the device tree binding phandles. > 4. Reading the EDID can be slow. If you happen to know all the info > on the panel beforehand you can significantly speed up boot speed, > notably how fast you can get something on the screen. The motivation for potentially duplicating this information was not that it's slow to read EDID, but that occasionally you might not be able to access EDID. There could be a number of reasons why this might happen: a device might end up with an erased or invalid EDID or the DDC used to get at the EDID might be broken (I've been told that it's fairly common for OEMs to not wire through the DDC wires in cables to reduce costs). Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/9e49e0f3/attachment.sig>
[Bug 114711] ubsan: "shift exponent 32 is too large" in drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c:167:16
https://bugzilla.kernel.org/show_bug.cgi?id=114711 --- Comment #2 from Peter Gerber --- Yes, this fixes the issue. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 1/2] dt-bindings: add Starry KR122EA0SRA panel binding
On Fri, Jun 10, 2016 at 03:08:50PM -0700, Stéphane Marchesin wrote: > On Fri, Jun 10, 2016 at 3:03 PM, Rob Clark wrote: > > On Fri, Jun 10, 2016 at 3:52 PM, Doug Anderson > > wrote: > >> Rob, > >> > >> On Fri, Jun 10, 2016 at 11:43 AM, Rob Clark wrote: > >>> On Fri, Jun 10, 2016 at 1:02 PM, Douglas Anderson >>> chromium.org> wrote: > >>>> The Starry KR122EA0SRA is a 12.2", 1920x1200 TFT-LCD panel connected > >>>> using eDP interfaces. > >>> > >>> so drive-by comment... but shouldn't eDP be probe-able? Not sure why > >>> we need panel drivers or DT bindings? > >> > >> I was wondering about that too. As far as I can tell: > >> > >> 1. We need a panel driver because that appears to be what owns a > >> reference to the backlight / panel power regulator and that part is > >> not auto-probable. > > > > oh, hmm.. sad.. I was hoping that eDP would save us from dsi per-panel > > driver hell.. I guess being able to use panel-simple is at least an > > improvement. But panel specific sequences is sounds like panel-simple > > won't save us all the time :-( > > Yes, although you can probably make things mostly work with improper > sequencing and enough retries, a lot of ARM hw either requires > interesting sequencing, or has broken/unreliable DDC, which translates > into the use of panel simple on the sw side. panel-simple has support for very simple sequencing. You can specify delays after the prepare and enable stages. This is useful because most panels have specific requirements when it comes to the amount of time it takes them to receive video data (after being powered up) and the amount of time it takes them to show the first valid frame after it has been received. The former is used to keep drivers from sending video data to make sure it can be properly received by the panel, and the latter is used to keep the backlight off until the first valid frame is visible on the display. This is used to avoid glitches and seems to work well enough for simple panels. More complex panels have more involved sequences, so separate drivers are required. Also note that the simple-panel driver will try to use EDID if available and only fall back to the hard-coded mode or timings if there is no DDC to probe or no modes could be parsed from EDID. > >> 2. As far as I could tell, there is no way to declare a generic > >> (unspecified) panel in the device tree. Everyone seems to include > >> "simple-panel" in their compatible string but as far as I can tell > >> nothing in the kernel looks at it. > >> > >> 3. In theory, all the info specified here should match the EDID > >> exactly and thus (as you said) be probable. However, it sounds like > >> (for power sequencing reasons) there might be reasons why you'd want > >> to know exactly what panel was present beforehand. You might need to > >> power the panel and backlight in very specific sequences, for > >> instance. I'm not sure it's always 100% possible in all embedded > >> designs to read the EDID before you know how the sequencing should > >> work (but, of course, I'm a NOOB). > >> > >> 4. Reading the EDID can be slow. If you happen to know all the info > >> on the panel beforehand you can significantly speed up boot speed, > >> notably how fast you can get something on the screen. > > > > The theory is (although I think not true currently for most of the arm > > drivers) that we should be reading back from hw the current config > > from bootloader splash screen, to avoid a modeset (and conveniently > > also the need to read edid) at boot. > > On some devices the firmware doesn't set any video mode, so there > isn't anything we can read back. That is our case :) Reading out hardware state also doesn't give you all the information that you need. I've never seen hardware that is programmed with the physical size of the panel, so there's no way to read that back and you'd still have to either parse EDID or use the value hard-coded in the simple-panel driver if you want to compute the pixel density. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/d4012955/attachment.sig>
[[RESEND][PATCH v2] 2/2] dt-bindings: Add jdi lt070me05000 panel bindings
On Sun, Jun 12, 2016 at 10:21:24PM +0530, Vinay Simha BN wrote: > Add documentation for lt070me05000 panel > > Cc: Archit Taneja > Cc: John Stultz > Cc: Thierry Reding > Cc: Sumit Semwal > Signed-off-by: Vinay Simha BN > Acked-by: Rob Herring > > -- That's not a valid separator, so git am doesn't cut it off at the right point, which means that I had to manually delete this. I've done so now but in the future, please make sure to use the proper separator (---) so that maintainers don't have to manually intervene. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/4e412a35/attachment-0001.sig>
[Bug 119991] Screen is corrupt upon resume from hybrid-sleep with Radeon HD5xxx cards
https://bugzilla.kernel.org/show_bug.cgi?id=119991 --- Comment #4 from Felix Schwarz --- (In reply to Jani-Markus Maunus from comment #3) > I might be just rambling at this point, but 4.6.1 stable was definitely > bugged for me, yet this commit is dated well before 4.6.1 release - any idea > what's up with that? Well it seems to me as if Jérôme's patch was merged via Alex's 'drm-next' and Dave's 'drm-next-4.7' branches so it just missed the boat for 4.6. Also the commit you pointed out above has no "stable" tag so it won't be picked up automatically for point releases. If you really care about 4.6 you might want to ping the authors and/or the reviewers who might be willing to nominate the patch for the stable series. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v4 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel
ruct jdi_panel *jdi = to_jdi_panel(panel);
> + struct regulator_bulk_data *s = jdi->supplies;
There's no need for this temporary variable, jdi->supplies isn't
terrible long.
> + int num = PANEL_DEV_REGULATOR_MAX;
This should be unsigned int. Also, might be worth to simply drop this
usage and do...
> + struct device *dev = &jdi->dsi->dev;
> + int ret;
> +
> + if (jdi->prepared)
> + return 0;
> +
> + DRM_DEBUG("prepare\n");
> +
> + ret = regulator_bulk_enable(num, s);
ret = regulator_bulk_enable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
here.
> + if (ret < 0) {
> + dev_err(dev, "regulator enable failed, %d\n", ret);
Can you please be more consistent with how you report errors? Other
drivers use "...: %d\n", ret and you do so yourself in other parts of
this same driver, so make them all consistent, please.
> +static int jdi_panel_enable(struct drm_panel *panel)
> +{
> + struct jdi_panel *jdi = to_jdi_panel(panel);
> +
> + if (jdi->enabled)
> + return 0;
> +
> + DRM_DEBUG("enable\n");
Do you really need these? You can use the kernel's built-in function
tracing for the same purpose.
> +static const struct drm_display_mode default_mode = {
> + .clock = 155493,
> + .hdisplay = 1200,
> + .hsync_start = 1200 + 48,
> + .hsync_end = 1200 + 48 + 32,
> + .htotal = 1200 + 48 + 32 + 60,
> + .vdisplay = 1920,
> + .vsync_start = 1920 + 3,
> + .vsync_end = 1920 + 3 + 5,
> + .vtotal = 1920 + 3 + 5 + 6,
> + .vrefresh = 60,
> + .flags = 0,
> + .width_mm = 95,
> + .height_mm = 151,
It's slightly unusual to set this in the mode. Typically you'd set the
connector->display_info.{width,height}_mm directly.
> +static int dsi_dcs_bl_get_brightness(struct backlight_device *bl)
> +{
> + struct mipi_dsi_device *dsi = bl_get_data(bl);
> + int ret;
> + u16 brightness;
> + u8 bl_value[2];
> +
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_get_display_brightness(dsi, &brightness);
> + if (ret < 0)
> + return ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + bl_value[0] = brightness & 0xff;
> + bl_value[1] = brightness >> 8;
> +
> + return bl_value[0];
> +}
Why not simply return "brightness & 0xff" here?
> +static int dsi_dcs_bl_update_status(struct backlight_device *bl)
> +{
> + struct mipi_dsi_device *dsi = bl_get_data(bl);
> + int ret;
> + u16 brightness = bl->props.brightness;
There's no need for this temporary variable.
> +
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_set_display_brightness(dsi, brightness);
> + if (ret < 0)
> + return ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + return 0;
> +}
[...]
> +struct backlight_device
> + *drm_panel_create_dsi_backlight(struct mipi_dsi_device *dsi)
Your indentation is wrong here. The * should go on the same line as the
type, and the function name should start in column 1.
> +{
> + struct device *dev = &dsi->dev;
> + struct backlight_properties props;
> +
> + memset(&props, 0, sizeof(props));
> + props.type = BACKLIGHT_RAW;
> + props.brightness = PANEL_MAX_BRIGHTNESS;
> + props.max_brightness = PANEL_MAX_BRIGHTNESS;
Just use 255 for the maximum and default brightness here.
> +static int jdi_panel_add(struct jdi_panel *jdi)
> +{
> + struct device *dev = &jdi->dsi->dev;
> + struct regulator_bulk_data *s = jdi->supplies;
> + int num = PANEL_DEV_REGULATOR_MAX;
Again, no need for these two temporary variables.
> + int i, ret;
i should be unsigned int.
> +
> + jdi->mode = &default_mode;
> +
> + for (i = 0; i < num; i++)
> + s[i].supply = regs[i];
> +
> + ret = devm_regulator_bulk_get(dev, num, s);
> + if (ret < 0) {
> + dev_err(dev, "%s: failed to init regulator, ret=%d\n",
> + __func__, ret);
> + return ret;
> + }
> +
> + jdi->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(jdi->reset_gpio)) {
> + dev_err(dev, "cannot get reset-gpios %ld\n",
> + PTR_ERR(jdi->reset_gpio));
This is a third variant of error reporting. Please stick to one.
> + jdi->reset_gpio = NULL;
> + } else {
> + gpiod_direction_output(jdi->reset_gpio, 0);
> + }
> +
> + jdi->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(jdi->enable_gpio)) {
> + dev_err(dev, "cannot get enable-gpio %ld\n",
> + PTR_ERR(jdi->enable_gpio));
> + jdi->enable_gpio = NULL;
> + } else {
> + gpiod_direction_output(jdi->enable_gpio, 0);
> + }
> +
> + jdi->backlight = drm_panel_create_dsi_backlight(jdi->dsi);
You should check for errors here.
> +MODULE_AUTHOR("Vinay Simha BN ");
> +MODULE_DESCRIPTION("JDI WUXGA LT070ME05000 DSI video mode panel driver");
The commit message names this "JDI LT070ME05000 WUXGA", please use the
same here.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/bbec2c12/attachment.sig>
[RESENT PATCH] drm/i915: use #defines for qemu subsystem ids
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f313b4d..3099390 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -515,8 +515,10 @@ void intel_detect_pch(struct drm_device *dev)
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
(id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
- pch->subsystem_vendor == 0x1af4 &&
- pch->subsystem_device == 0x1100)) {
+ pch->subsystem_vendor ==
+ PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
+ pch->subsystem_device ==
+ PCI_SUBDEVICE_ID_QEMU)) {
dev_priv->pch_type = intel_virt_detect_pch(dev);
} else
continue;
--
1.8.3.1
[RESENT PATCH] bochs: ignore device if there isn't enougth memory
The qemu stdvga can be configured with a wide range of video memory,
from 1 MB to 256 MB (default is 16 MB). In case it is configured
with only 1 or 2 MB it isn't really usable with bochsdrm, due to
depths other than 32bpp not being supported so that isn't enough
memory for a reasonable sized framebuffer. So skip the device
and let vgacon or vesafb+fbcon handle the it.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index b332b4d3..6cf4b18 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -162,8 +162,15 @@ static int bochs_kick_out_firmware_fb(struct pci_dev *pdev)
static int bochs_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
+ unsigned long fbsize;
int ret;
+ fbsize = pci_resource_len(pdev, 0);
+ if (fbsize < 4 * 1024 * 1024) {
+ DRM_ERROR("less than 4 MB video memory, ignoring device\n");
+ return -ENOMEM;
+ }
+
ret = bochs_kick_out_firmware_fb(pdev);
if (ret)
return ret;
--
1.8.3.1
[PATCH] drm: hdlcd: Unwind the DRM setup on error conditions in the right order.
On Mon, Jun 13, 2016 at 12:02:31PM +0100, Robin Murphy wrote: > On 08/06/16 13:56, Liviu Dudau wrote: > >In hdlcd_drm_bind()/hdlcd_drm_unbind() we unwind the DRM setup in the > >wrong order (drm_mode_config_cleanup() before connector and encoder > >had a chance to cleanup their memory or before drm_dev_unregister()). > >The correct order should match in both functions. > > > >Reported-by: Robin Murphy > >Signed-off-by: Liviu Dudau > >--- > > > >Robin, > > > >I believe this should fix your problems with HDLCD failing to allocate CMA > >memory and then crashing. > > Heh, I'm not sure I'd even clocked that there was yet another propblem > beyond the original gem_free_object() crash. I've just tried 4.7-rc3 with > the relevant fixes for that, and indeed drm_connector_cleanup() does go > bang, and this patch makes it happy again. > > Tested-by: Robin Murphy Cheers! I will push it for the next -rc. Best regards, Liviu > > Thanks, > Robin. > > > > >Best regards, > >Liviu > > > > drivers/gpu/drm/arm/hdlcd_drv.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > >diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c > >b/drivers/gpu/drm/arm/hdlcd_drv.c > >index 3422ca2..2c6eddb 100644 > >--- a/drivers/gpu/drm/arm/hdlcd_drv.c > >+++ b/drivers/gpu/drm/arm/hdlcd_drv.c > >@@ -382,7 +382,6 @@ static int hdlcd_drm_bind(struct device *dev) > > > > err_fbdev: > > drm_kms_helper_poll_fini(drm); > >-drm_mode_config_cleanup(drm); > > drm_vblank_cleanup(drm); > > err_vblank: > > pm_runtime_disable(drm->dev); > >@@ -390,6 +389,7 @@ err_pm_active: > > component_unbind_all(dev, drm); > > err_unregister: > > drm_dev_unregister(drm); > >+drm_mode_config_cleanup(drm); > > err_unload: > > drm_irq_uninstall(drm); > > of_reserved_mem_device_release(drm->dev); > >@@ -410,15 +410,15 @@ static void hdlcd_drm_unbind(struct device *dev) > > hdlcd->fbdev = NULL; > > } > > drm_kms_helper_poll_fini(drm); > >-component_unbind_all(dev, drm); > > drm_vblank_cleanup(drm); > >+component_unbind_all(dev, drm); > > pm_runtime_get_sync(drm->dev); > > drm_irq_uninstall(drm); > > pm_runtime_put_sync(drm->dev); > > pm_runtime_disable(drm->dev); > >-of_reserved_mem_device_release(drm->dev); > >-drm_mode_config_cleanup(drm); > > drm_dev_unregister(drm); > >+drm_mode_config_cleanup(drm); > >+of_reserved_mem_device_release(drm->dev); > > drm_dev_unref(drm); > > drm->dev_private = NULL; > > dev_set_drvdata(dev, NULL); > > > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ã)_/¯
[RESENT PATCH] drm/i915: use #defines for qemu subsystem ids
On Mon, 13 Jun 2016, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f313b4d..3099390 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -515,8 +515,10 @@ void intel_detect_pch(struct drm_device *dev)
> } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
> (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
> ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
> - pch->subsystem_vendor == 0x1af4 &&
> - pch->subsystem_device == 0x1100)) {
> + pch->subsystem_vendor ==
> + PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
> + pch->subsystem_device ==
> + PCI_SUBDEVICE_ID_QEMU)) {
> dev_priv->pch_type = intel_virt_detect_pch(dev);
> } else
> continue;
--
Jani Nikula, Intel Open Source Technology Center
[Bug 96508] Artefacts while playing video with vaapi or vdpau acceleration on amd apu (Radeon HD 8280E)
https://bugs.freedesktop.org/show_bug.cgi?id=96508 Bug ID: 96508 Summary: Artefacts while playing video with vaapi or vdpau acceleration on amd apu (Radeon HD 8280E) Product: Mesa Version: 11.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: jan.burgmeier at unicon-software.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 124502 --> https://bugs.freedesktop.org/attachment.cgi?id=124502&action=edit Video with artefacts While playing the attached video with mpv and vaapi or vdpau acceleration some artefacts are shown. The same artefacts are also shown when using gstreamer-0.10 with vaapi acceleration. Versions used: - Mesa: 11.2.2 and 12.0.0-rc4 - MPV: git commit 2b1656b1aced3d81b31c83e8c310a630ca5d5d1c - FFmpeg: 3.0.2 Hardware: - CPU: AMD GX-217GA SOC with Radeon(tm) HD Graphic - GPU: Radeon HD 8280E -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/32524460/attachment.html>
[Bug 96508] Artefacts while playing video with vaapi or vdpau acceleration on amd apu (Radeon HD 8280E)
https://bugs.freedesktop.org/show_bug.cgi?id=96508 --- Comment #1 from Jan Burgmeier --- Created attachment 124503 --> https://bugs.freedesktop.org/attachment.cgi?id=124503&action=edit /proc/cpuinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/3885c64a/attachment.html>
[Bug 96508] Artefacts while playing video with vaapi or vdpau acceleration on amd apu (Radeon HD 8280E)
https://bugs.freedesktop.org/show_bug.cgi?id=96508 --- Comment #2 from Jan Burgmeier --- Created attachment 124504 --> https://bugs.freedesktop.org/attachment.cgi?id=124504&action=edit lspci -vv -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/e6dbb8e8/attachment.html>
[Bug 96508] Artefacts while playing video with vaapi or vdpau acceleration on amd apu (Radeon HD 8280E)
https://bugs.freedesktop.org/show_bug.cgi?id=96508 --- Comment #3 from Jan Burgmeier --- Created attachment 124505 --> https://bugs.freedesktop.org/attachment.cgi?id=124505&action=edit vainfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/374c5a41/attachment.html>
[PATCH] drm/dsi: Make set_tear_scanline command consistent
From: Thierry Reding
Use a consistent name for the function that implements set_tear_scanline
and reword and reformat the kerneldoc slightly.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_mipi_dsi.c | 16
include/drm/drm_mipi_dsi.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 7938ce7ebed8..5d70b1bec038 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,17 +983,17 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
/**
- * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
- * output signal on the TE signal line when display module reaches line N
- * defined by STS[n:0].
+ * mipi_dsi_dcs_set_tear_scanline() - set the scanline to use as trigger for
+ *the Tearing Effect output signal of the display module
* @dsi: DSI peripheral device
- * @param: STS[10:0]
+ * @scanline: scanline to use as trigger
+ *
* Return: 0 on success or a negative error code on failure
*/
-int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u16 param)
+int mipi_dsi_dcs_set_tear_scanline(struct mipi_dsi_device *dsi, u16 scanline)
{
- u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param >> 8,
- param & 0xff };
+ u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, scanline >> 8,
+ scanline & 0xff };
ssize_t err;
err = mipi_dsi_generic_write(dsi, payload, sizeof(payload));
@@ -1002,7 +1002,7 @@ int mipi_dsi_set_tear_scanline(struct mipi_dsi_device
*dsi, u16 param)
return 0;
}
-EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
+EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_scanline);
/**
* mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index ec552854a8f8..6ccf144e300b 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,7 +263,7 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device
*dsi, u16 start,
u16 end);
int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
u16 end);
-int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u16 param);
+int mipi_dsi_dcs_set_tear_scanline(struct mipi_dsi_device *dsi, u16 scanline);
int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dsi_dcs_tear_mode mode);
--
2.8.3
[Bug 96508] Artefacts while playing video with vaapi or vdpau acceleration on amd apu (Radeon HD 8280E)
https://bugs.freedesktop.org/show_bug.cgi?id=96508 --- Comment #4 from Jan Burgmeier --- Created attachment 124506 --> https://bugs.freedesktop.org/attachment.cgi?id=124506&action=edit vdpauinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/07afb113/attachment-0001.html>
[PATCH] drm/virtio: Don't reinvent a flipping wheel
On Mon, Jun 13, 2016 at 11:20 AM, Gerd Hoffmann wrote: > On Fr, 2016-06-10 at 17:20 +0200, Daniel Vetter wrote: >> On Fri, Jun 10, 2016 at 12:07:53AM +0200, Daniel Vetter wrote: >> > Now that the core helpers support nonblocking atomic commits there's >> > no need to invent that wheel separately (instead of fixing the bug in >> > the atomic implementation of virtio, as it should have been done!). >> > >> > v2: Rebased on top of >> > >> > commit e7cf0963f816fa44190caaf51aeffaa614c340c6 >> > Author: Gerd Hoffmann >> > Date: Tue May 31 08:50:47 2016 +0200 >> > >> > virtio-gpu: add atomic_commit function >> > >> > Cc: Gerd Hoffmann >> > Tested-by: Gerd Hoffmann (v1) >> > Reviewed-by: Gerd Hoffmann (v1) >> > Signed-off-by: Daniel Vetter >> >> Gerd, can you pls retest? I think due to your change in the above >> referenced commit to switch to active_only=true in commit_planes() this is >> now broken. > > Yes, probably it'll break things. > > Any branch I can test? Your "stuff" branch seems to not yet have the > commit above. > > I guess virtio-gpu should switch over to override .atomic_commit_tail > instead of .atomic_commit? See v2 that I've sent out - it contains these changes already. Patch applies on top of topic/drm-misc, but I'll be pushing out a new version of stuff asap. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 96508] Artefacts while playing video with vaapi or vdpau acceleration on amd apu (Radeon HD 8280E)
https://bugs.freedesktop.org/show_bug.cgi?id=96508 Jan Burgmeier changed: What|Removed |Added Hardware|Other |x86 (IA32) OS|All |Linux (All) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/91d3ee3f/attachment.html>
[PATCH] drm/prime: fix error path deadlock fail
On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote: > There were a couple messed up things about this fail path. > (1) it would drop object_name_lock twice > (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles()) > needs to grab prime_lock > > Reported-by: Alex Deucher > Signed-off-by: Rob Clark fyi, Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117861 > --- > Untested, but I think this should fix the potential deadlock that Alex > reported. Would be nice if someone with setup to reproduce could test > this. > > drivers/gpu/drm/drm_prime.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index aab0f3f..780589b 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -593,7 +593,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > get_dma_buf(dma_buf); > } > > - /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ > + /* _handle_create_tail unconditionally unlocks dev->object_name_lock. > */ > ret = drm_gem_handle_create_tail(file_priv, obj, handle); > drm_gem_object_unreference_unlocked(obj); > if (ret) > @@ -601,11 +601,10 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > > ret = drm_prime_add_buf_handle(&file_priv->prime, > dma_buf, *handle); > + mutex_unlock(&file_priv->prime.lock); > if (ret) > goto fail; > > - mutex_unlock(&file_priv->prime.lock); > - > dma_buf_put(dma_buf); > > return 0; > @@ -615,11 +614,14 @@ fail: > * to detach.. which seems ok.. > */ > drm_gem_handle_delete(file_priv, *handle); > + dma_buf_put(dma_buf); > + return ret; > + > out_unlock: > mutex_unlock(&dev->object_name_lock); > out_put: > - dma_buf_put(dma_buf); > mutex_unlock(&file_priv->prime.lock); > + dma_buf_put(dma_buf); > return ret; > } > EXPORT_SYMBOL(drm_gem_prime_fd_to_handle); > -- > 2.5.5 >
[PATCH 23/27] drm: Replace fb_helper->atomic with mode_config->atomic_commit
On Mon, Jun 13, 2016 at 05:26:28PM +0800, Ying Liu wrote:
> On Mon, Jun 13, 2016 at 3:58 PM, Daniel Vetter wrote:
> > On Sun, Jun 12, 2016 at 05:01:27PM +0800, Ying Liu wrote:
> >> On Wed, Jun 8, 2016 at 8:19 PM, Daniel Vetter
> >> wrote:
> >> > Drivers transitioning to atomic might not yet want to enable full
> >> > DRIVER_ATOMIC support when it's not entirely working. But using atomic
> >> > internally makes a lot more sense earlier.
> >> >
> >> > Instead of spreading such flags to more places I figured it's simpler
> >> > to just check for mode_config->funcs->atomic_commit, and use atomic
> >> > paths if that is set. For the only driver currently transitioning
> >> > (i915) this does the right thing.
> >>
> >> Well, imx-drm is transitioning.
> >> Unfortunately, after applying this patch, legacy fbdev cannot enable
> >> displays when the imx-drm transitional patch set reaches phase 3 step 1[1].
> >>
> >> For those transitioning drivers with fine-grained steps, this patch
> >> is likely to expose the atomic function __drm_atomic_helper_set_config
> >> to legacy fbdev support too early. They could still be using
> >> drm_crtc_helper_set_config when adding ->atomic_commit.
> >>
> >> BTW, this patch and those for generic nonblocking commit are making
> >> the imx-drm transition a bit harder. Not good timing probably.
> >> But, I'll go on with the task anyway.
> >
> > Hm, making transition harder wasn't really the intention. What exactly is
> > blowing up for you? At least how I planned the transition the first thing
> > you should be able to do is basic modesets (once you fill out
> > ->atomic_commit), so I hoped that this wouldn't cause trouble.
>
> At the imx-drm transition phase 1, ipu_plane_atomic_check checks
> crtc->enabled and hopes it to be true. Till phase 3 step 1, this function
> is not changed. This patch exposes restore_fbdev_mode_atomic and
> pan_display_atomic to legacy fbdev too early. Both of them call
> drm_atomic_commit which does plane check at atomic check stage.
> Then, the plane check fails for the legacy fbdev, because
> drm_atomic_commit sets crtc->enabled later than the legacy path
> drm_crtc_helper_set_mode does. Actually, drm_atomic_commit
> doesn't set crtc->enabled until the commit stage if you use the
> atomic helper.
Hm, my idea was that in phase 2 (when you roll out state structures and
checks), you'd change your atomic_check functions from looking at legacy
stuff like crtc->enabled, to instead look at new state like
crtc_state->enabled.
> OTOH, we fill out ->atomic_commit with drm_atomic_helper_commit
> at phase 3 step 1, then exposing drm_atomic_commit means that we
> need to handle crtc_state->event no later than phase 3 step 1...
> I haven't decided the right order/process to add the handling.
Yes, this is a change: Before you can start with phase 3 you need to
handle crtc_state->event in atomic_flush (or a similar place).
> So, would it be an option to revert this patch...
I'd really like to avoid that - the old hack of adding a knob for every
place we should use atomic was getting complicated :( And right now
there's many more atomic drivers than legacy ones, and only 2 drivers in
transition (i915 and imx). Given that I think we should optimize more for
atomic drivers.
But like I said, of course transition shouldn't be too painful.
> > Wrt nonblocking commit helpers breaking transitioning drivers: The most
> > likely cause is your driver isn't handling crtc_state->event yet. Before
> > you start using ->atomic_commit or one of the helpers to map legacy ioctl
> > to atomic, you need to fill out some code to handle that in ->atomic_begin
> > or ->atomic_flush. Then the transition should still work as before.
>
> I do have confusion on the event handling in some drivers' ->atomic_flush.
> At least sun4i, kirin and fsl-dcu have the below snip:
> ==
> if (event) {
> crtc->state->event = NULL;
>
> spin_lock_irq(&crtc->dev->event_lock);
> if (drm_crtc_vblank_get(crtc) == 0)
> drm_crtc_arm_vblank_event(crtc, event);
> else
> drm_crtc_send_vblank_event(crtc, event);
> spin_unlock_irq(&crtc->dev->event_lock);
> }
> ==
> It looks drm_crtc_vblank_get seldom fails?
If it never fails for you, then you haven't put drm_crtc_vblank_on/off()
into your crtc enable/disable callbacks. Ofc this assumes you have real
vblank support.
> And why do we send vblank event when it fails?
This is just the most failsafe way to make sure the event gets out. It's
rather inaccurate though, so would be much better if you can make that
decision by instead looking at crtc->state->active, like i915 does.
drm_crtc_vblank_get always works in-betwen drm_crtc_vblank_on/off() calls,
i.e. when the crtc is supposed to be on. And when you disable the crtc and
it stays disable t
[Bug 96445] [amdgpu][tonga] display freezes soon after X start
https://bugs.freedesktop.org/show_bug.cgi?id=96445 --- Comment #4 from Nicolai Hähnle --- This patches does the trick. I've run my stress test for about an hour, so it's safe to say that it's fixed - feel free to add my Tested-by. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/79824d28/attachment-0001.html>
[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
On Mon, Jun 13, 2016 at 05:58:29PM +0900, Michel Dänzer wrote: > On 06/13/16 17:06, Daniel Vetter wrote: > > On Mon, Jun 13, 2016 at 10:54:37AM +0900, Michel Dänzer wrote: > >> On 10.06.2016 23:43, Daniel Vetter wrote: > >>> On Fri, Jun 10, 2016 at 05:57:12PM +0900, Michel Dänzer wrote: > From: Michel Dänzer > > If userspace wants a page flip to take effect during vblank sequence n, > it has to wait for vblank seqno n-1 before calling the > DRM_IOCTL_MODE_PAGE_FLIP ioctl. > > This change makes sure that we do not program the flip to the hardware > before the end of vblank seqno n-1 in this case, to prevent the flip > from taking effect too early. > > On the other hand, if the DRM_IOCTL_MODE_PAGE_FLIP ioctl is called > during vblank, but userspace didn't wait for the current vblank seqno > before, this change would still allow the flip to be programmed during > the current vblank seqno. > >>> > >>> This just sounds like you're sending vblank events out a bit too early. > >>> And watching vblank waits that userspace does works, but it's fragile, > >>> add-hoc and I don't really jump in joy about adding that to the vblank > >>> core. Is there no way you can adjust sending out the vblank events > >>> similarly, to make sure userspace can never sneak in a pageflip too early? > >> > >> What you call "too early" is actually "during the vertical blank period > >> waited for". IMHO only notifying userspace of a vertical blank period > >> when it's already over would defeat the purpose. > > > > Afaiui the rules are: > > - The timestamp for vblank event needs to agree with whatever oml_sync > > requries. > > - The event delivery itself needs to be consistent with what page_flip > > takes, i.e. if userspace sees an event and immediately issues a > > page_flip then it should not be able to hit the same vblank with that > > pageflip. > > - The event needs to be after the old buffers are not longer used and can > > be reused for rendering. > > That's only relevant for DRM_IOCTL_MODE_PAGE_FLIP, not > DRM_IOCTL_WAIT_VBLANK. Yup, mixed that up. > > - There's no requirement at all that the event gets delivered at a > > specific point in the vblank, hardware is too different for that to work > > As the name implies, the purpose of DRM_IOCTL_WAIT_VBLANK is to wait for > a vertical blank period. If that doesn't work as intended with some > hardware, that's tough luck but not really my problem. :) > > > - that kind of precision is why we have a separate timestamp. > > I'm afraid this last item gives away that you're relatively new to this > code. ;) The timestamp was originally literally just the current > gettimeofday when the wait finished (the original DRM_IOCTL_WAIT_VBLANK > ioctl didn't have any asynchronous notification functionality). It was > relatively recently that Mario changed the timestamp to correspond to > the end of the vertical blank period / start of scanout of the next > frame, presumably due to your first rule above. Most hw just seems to give you a vblank interrupt somewhere in the vblank are, or sometimes even slightly before that. Also there's scheduling jitter. > > I assume you're goal is to not delay page_flips unecessarily, without > > breaking requirement 2 here. Imo a simpler fix would be to delay the > > vblank handling to end of vblank. Fixes everything without hacks, [...] > > Except it breaks the original purpose of the wait for vblank > functionality, which is to wait for the beginning of a vertical blank > period. [0] You're focusing too much on page flips and suggesting to > throw out the vblank baby with the bathwater. I really don't see the big > issue which would justify that. > > > [0] As an analogy, how useful would e.g. calendar notifications be if > they arrived at the end of the events they're about? "Hey, that meeting > you were supposed to attend? It just finished!" Ok, what exactly is the use-case for waiting for vblanks _without_ scheduling a flip afterwards? At least in drm the rule is that ABI is what userspace observes and actually cares about. The above few rules are what generic userspace (afaik at least) cares about, and what therefore drivers should implement. Note that at least to my knowledge absolutely nothing cares when exactly in the vblank the interrupt fires, and the event gets delivered. We even moved that around in the i915 driver iirc, exactly because you could squeeze in a page-flip like you can here on radeon. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/3 v2] drm/arcpgu: Make ARC PGU usable on simulation platforms
On Mon, Jun 13, 2016 at 12:47:33PM +, Alexey Brodkin wrote: > Hi Daniel, > > On Fri, 2016-06-10 at 17:29 +0300, Alexey Brodkin wrote: > > From: Ruud Derwig > > > > In case of simulation there's no real encoder/transmitter device > > because in the model's virtual LCDÂ Â we're rendering whatever > > appears in frame-buffer memory. > > > > Signed-off-by: Ruud Derwig > > Signed-off-by: Alexey Brodkin > > --- > > > > Changes v1 -> v2: > > Â * Got rid of dummy arcpgu_drm_encoder_helper_funcs and now rely on default > > Â Â Â best encoder > > If that version looks good to you could you please provide your Ack? I just do drive-by comments on driver submissions, review/merge rules are up to each driver maintainer mostly. But for the warm and fuzzy feeling I'm happy to ack ;-) Acked-by: Daniel Vetter -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled
From: Christian König
Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven
for working a lot with the PLLs and figuring this out.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/atombios_crtc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index bdc7b9e..482df5f 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -589,7 +589,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE61(rdev) ||
ASIC_IS_DCE8(rdev))
radeon_crtc->pll_flags |= RADEON_PLL_USE_FRAC_FB_DIV;
/* use frac fb div on RS780/RS880 */
- if ((rdev->family == CHIP_RS780) || (rdev->family ==
CHIP_RS880))
+ if (((rdev->family == CHIP_RS780) || (rdev->family ==
CHIP_RS880))
+ && !radeon_crtc->ss_enabled)
radeon_crtc->pll_flags |= RADEON_PLL_USE_FRAC_FB_DIV;
if (ASIC_IS_DCE32(rdev) && mode->clock > 165000)
radeon_crtc->pll_flags |= RADEON_PLL_USE_FRAC_FB_DIV;
@@ -626,7 +627,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (radeon_crtc->ss.refdiv) {
radeon_crtc->pll_flags |=
RADEON_PLL_USE_REF_DIV;
radeon_crtc->pll_reference_div =
radeon_crtc->ss.refdiv;
- if (ASIC_IS_AVIVO(rdev))
+ if (rdev->family >= CHIP_RV770)
radeon_crtc->pll_flags |=
RADEON_PLL_USE_FRAC_FB_DIV;
}
}
--
2.5.0
[PATCH 1/2] drm/amdgpu: stop trying to schedule() with a spin held
From: Christian König
Drop the lock before calling cancel_delayed_work_sync().
Signed-off-by: Christian König
Tested-by: Nicolai Hähnle
---
drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
index 74aa0b3..b1d49c5 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
@@ -339,7 +339,9 @@ static void amd_sched_job_finish(struct work_struct *work)
if (sched->timeout != MAX_SCHEDULE_TIMEOUT) {
struct amd_sched_job *next;
+ spin_unlock_irqrestore(&sched->job_list_lock, flags);
cancel_delayed_work_sync(&s_job->work_tdr);
+ spin_lock_irqsave(&sched->job_list_lock, flags);
/* queue TDR for next job */
next = list_first_entry_or_null(&sched->ring_mirror_list,
--
2.5.0
[PATCH 2/2] drm/amdgpu: stop disabling irqs when it isn't neccessary
From: Christian König
A regular spin_lock/unlock should do here as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
index b1d49c5..e13b140 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
@@ -331,17 +331,16 @@ static void amd_sched_job_finish(struct work_struct *work)
struct amd_sched_job *s_job = container_of(work, struct amd_sched_job,
finish_work);
struct amd_gpu_scheduler *sched = s_job->sched;
- unsigned long flags;
/* remove job from ring_mirror_list */
- spin_lock_irqsave(&sched->job_list_lock, flags);
+ spin_lock(&sched->job_list_lock);
list_del_init(&s_job->node);
if (sched->timeout != MAX_SCHEDULE_TIMEOUT) {
struct amd_sched_job *next;
- spin_unlock_irqrestore(&sched->job_list_lock, flags);
+ spin_unlock(&sched->job_list_lock);
cancel_delayed_work_sync(&s_job->work_tdr);
- spin_lock_irqsave(&sched->job_list_lock, flags);
+ spin_lock(&sched->job_list_lock);
/* queue TDR for next job */
next = list_first_entry_or_null(&sched->ring_mirror_list,
@@ -350,7 +349,7 @@ static void amd_sched_job_finish(struct work_struct *work)
if (next)
schedule_delayed_work(&next->work_tdr, sched->timeout);
}
- spin_unlock_irqrestore(&sched->job_list_lock, flags);
+ spin_unlock(&sched->job_list_lock);
sched->ops->free_job(s_job);
}
@@ -364,15 +363,14 @@ static void amd_sched_job_finish_cb(struct fence *f,
struct fence_cb *cb)
static void amd_sched_job_begin(struct amd_sched_job *s_job)
{
struct amd_gpu_scheduler *sched = s_job->sched;
- unsigned long flags;
- spin_lock_irqsave(&sched->job_list_lock, flags);
+ spin_lock(&sched->job_list_lock);
list_add_tail(&s_job->node, &sched->ring_mirror_list);
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
list_first_entry_or_null(&sched->ring_mirror_list,
struct amd_sched_job, node) == s_job)
schedule_delayed_work(&s_job->work_tdr, sched->timeout);
- spin_unlock_irqrestore(&sched->job_list_lock, flags);
+ spin_unlock(&sched->job_list_lock);
}
static void amd_sched_job_timedout(struct work_struct *work)
--
2.5.0
[PATCH v4 3/3] MAINTAINERS: Add entry for Mali-DP driver
Add MAINTAINERS entry for ARM Mali-DP driver and update the HDLCD file matching pattern to cover only HDLCD rather than the whole drivers/gpu/drm/arm directory. Signed-off-by: Liviu Dudau --- MAINTAINERS | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 81382b2..2581ea4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -865,9 +865,17 @@ F: Documentation/devicetree/bindings/display/snps,arcpgu.txt ARM HDLCD DRM DRIVER M: Liviu Dudau S: Supported -F: drivers/gpu/drm/arm/ +F: drivers/gpu/drm/arm/hdlcd_* F: Documentation/devicetree/bindings/display/arm,hdlcd.txt +ARM MALI-DP DRM DRIVER +M: Liviu Dudau +M: Brian Starkey +M: Mali DP Maintainers +S: Supported +F: drivers/gpu/drm/arm/ +F: Documentation/devicetree/bindings/display/arm,malidp.txt + ARM MFM AND FLOPPY DRIVERS M: Ian Molton S: Maintained -- 2.8.2
[PATCH v4 0/3] Add support for ARM Mali Display Processors
Hello, This is the fourth revision of the driver for the Mali Display Processors (Mali DP). Currently, the driver supports the Display Engine found in Mali DP500, DP550 and DP650, with up to 3 planes that can be rotated by the hardware. There are features that the hardware supports that are not currently implemented in the driver, but in the current form it is capable of supporting X11 using fbdev emulation as well as Wayland with pixman rendering. A copy of the patchset has been published here: git://linux-arm.org/linux-ld.git for-upstream/mali-dp After Daniel's non-blocking series gets into linux-next I plan to add that branch as well, in preparation for v4.8. Changes in v4: - Removed check for active crtc in malidp_crtc_disable() as this was unnecessary - Moved the dispatching of state events from malidp_crtc_atomic_flush() into the malidp_atomic_commit_hw_done() function where we can guarantee the GO status bit has been raised by the HW. - Used gem_free_object_unlocked hook instead of gem_free_object one. - Introduce a malidp_state structure to track per plane->state data related to the rotation memory usage so as not to break the TEST_ONLY atomic commits. Changes in v3: - rebased on top of Daniel Vetter's drm/stuff branch that implements non-blocking atomic commits. - Addressed comments from Emil Velikov's review - Re-ordered the malidp_hw_regmap struct to eliminate the un-needed padding - Lots more functions made static if they are not shared - Planes are now allocated with vanilla kzalloc() rather than devm_kzalloc() and freed in malidp_de_planes_destroy() Changes in v2 vs initial RFC: - merged malidp_crtc_mode_set_nofb into malidp_crtc_enable and removed the mode_set hooks. This removed the need for a custom destroy hook as well, switched to using drm_crtc_cleanup for that. - implemented proper async support for atomic page flip. - removed un-necessary checks and empty hooks. - clarifications in the bindings document for the use of interrupt-names. - removed the MALIDP_HW_FEATURE_DS (display split) from this version pending further development - Renamed module from malidp to mali-dp. - Added MAINTAINERS update Many thanks, Liviu Liviu Dudau (3): dt/bindings: display: Add DT bindings for Mali Display Processors. drm/arm: Add support for Mali Display Processors MAINTAINERS: Add entry for Mali-DP driver .../devicetree/bindings/display/arm,malidp.txt | 65 ++ MAINTAINERS| 10 +- drivers/gpu/drm/arm/Kconfig| 16 + drivers/gpu/drm/arm/Makefile | 2 + drivers/gpu/drm/arm/malidp_crtc.c | 214 +++ drivers/gpu/drm/arm/malidp_drv.c | 512 +++ drivers/gpu/drm/arm/malidp_drv.h | 54 ++ drivers/gpu/drm/arm/malidp_hw.c| 691 + drivers/gpu/drm/arm/malidp_hw.h| 241 +++ drivers/gpu/drm/arm/malidp_planes.c| 298 + drivers/gpu/drm/arm/malidp_regs.h | 172 + 11 files changed, 2274 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c create mode 100644 drivers/gpu/drm/arm/malidp_drv.c create mode 100644 drivers/gpu/drm/arm/malidp_drv.h create mode 100644 drivers/gpu/drm/arm/malidp_hw.c create mode 100644 drivers/gpu/drm/arm/malidp_hw.h create mode 100644 drivers/gpu/drm/arm/malidp_planes.c create mode 100644 drivers/gpu/drm/arm/malidp_regs.h -- 2.8.2
[PATCH v4 2/3] drm/arm: Add support for Mali Display Processors
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig | 16 +
drivers/gpu/drm/arm/Makefile| 2 +
drivers/gpu/drm/arm/malidp_crtc.c | 214 +++
drivers/gpu/drm/arm/malidp_drv.c| 512 ++
drivers/gpu/drm/arm/malidp_drv.h| 54 +++
drivers/gpu/drm/arm/malidp_hw.c | 691
drivers/gpu/drm/arm/malidp_hw.h | 241 +
drivers/gpu/drm/arm/malidp_planes.c | 298
drivers/gpu/drm/arm/malidp_regs.h | 172 +
9 files changed, 2200 insertions(+)
create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c
create mode 100644 drivers/gpu/drm/arm/malidp_drv.c
create mode 100644 drivers/gpu/drm/arm/malidp_drv.h
create mode 100644 drivers/gpu/drm/arm/malidp_hw.c
create mode 100644 drivers/gpu/drm/arm/malidp_hw.h
create mode 100644 drivers/gpu/drm/arm/malidp_planes.c
create mode 100644 drivers/gpu/drm/arm/malidp_regs.h
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index eaed454..1b29065 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -25,3 +25,19 @@ config DRM_HDLCD_SHOW_UNDERRUN
Enable this option to show in red colour the pixels that the
HDLCD device did not fetch from framebuffer due to underrun
conditions.
+
+config DRM_MALI_DISPLAY
+ tristate "ARM Mali Display Processor"
+ depends on DRM && OF && (ARM || ARM64)
+ depends on COMMON_CLK
+ select DRM_ARM
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_GEM_CMA_HELPER
+ select VIDEOMODE_HELPERS
+ help
+ Choose this option if you want to compile the ARM Mali Display
+ Processor driver. It supports the DP500, DP550 and DP650 variants
+ of the hardware.
+
+ If compiled as a module it will be called mali-dp.
diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
index 89dcb7b..bb8b158 100644
--- a/drivers/gpu/drm/arm/Makefile
+++ b/drivers/gpu/drm/arm/Makefile
@@ -1,2 +1,4 @@
hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
+mali-dp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
+obj-$(CONFIG_DRM_MALI_DISPLAY) += mali-dp.o
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
new file mode 100644
index 000..da42376
--- /dev/null
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -0,0 +1,214 @@
+/*
+ * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
+ * Author: Liviu Dudau
+ *
+ * This program is free software and is provided to you under the terms of the
+ * GNU General Public License version 2 as published by the Free Software
+ * Foundation, and any use by you of this program is subject to the terms
+ * of such GNU licence.
+ *
+ * ARM Mali DP500/DP550/DP650 driver (crtc operations)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "malidp_drv.h"
+#include "malidp_hw.h"
+
+static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
+ struct malidp_hw_device *hwdev = malidp->dev;
+
+ /*
+* check that the hardware can drive the required clock rate,
+* but skip the check if the clock is meant to be disabled (req_rate =
0)
+*/
+ long rate, req_rate = mode->crtc_clock * 1000;
+
+ if (req_rate) {
+ rate = clk_round_rate(hwdev->mclk, req_rate);
+ if (rate < req_rate) {
+ DRM_DEBUG_DRIVER("mclk clock unable to reach %d kHz\n",
+mode->crtc_clock);
+ return false;
+ }
+
+ rate = clk_round_rate(hwdev->pxlclk, req_rate);
+ if (rate != req_rate) {
+ DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
+req_rate);
+ return false;
+ }
+ }
+
+ return true;
+}
+
+static void malidp_crtc_enable(struct drm_crtc *crtc)
+{
+ struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
+ struct malidp_hw_device *hwdev = malidp->dev;
+ struct videomode vm;
+
+ drm_display_mode_to_videomode(&crtc->state->adjusted_mode, &vm);
+
+ clk_prepare_enable(hwdev->pxlclk);
+
+ /* mclk needs to be set to the same or higher rate than pxlclk */
+ clk_set_rate(hwdev->mclk, crtc->state->adjusted_mode.crtc_clock * 1000);
+ clk_set_rate(hwdev->pxlclk, crtc->state->a
[PATCH v4 1/3] dt/bindings: display: Add DT bindings for Mali Display Processors.
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
Acked-by: Rob Herring
---
.../devicetree/bindings/display/arm,malidp.txt | 65 ++
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt
b/Documentation/devicetree/bindings/display/arm,malidp.txt
new file mode 100644
index 000..2f78709
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
@@ -0,0 +1,65 @@
+ARM Mali-DP
+
+The following bindings apply to a family of Display Processors sold as
+licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
+DP650 processors that offer multiple composition layers, support for
+rotation and scaling output.
+
+Required properties:
+ - compatible: should be one of
+ "arm,mali-dp500"
+ "arm,mali-dp550"
+ "arm,mali-dp650"
+depending on the particular implementation present in the hardware
+ - reg: Physical base address and size of the block of registers used by
+the processor.
+ - interrupts: Interrupt list, as defined in
../interrupt-controller/interrupts.txt,
+interrupt client nodes.
+ - interrupt-names: name of the engine inside the processor that will
+use the corresponding interrupt. Should be one of "DE" or "SE".
+ - clocks: A list of phandle + clock-specifier pairs, one for each entry
+in 'clock-names'
+ - clock-names: A list of clock names. It should contain:
+ - "pclk": for the APB interface clock
+ - "aclk": for the AXI interface clock
+ - "mclk": for the main processor clock
+ - "pxlclk": for the pixel clock feeding the output PLL of the processor.
+ - arm,malidp-output-port-lines: Array of u8 values describing the number
+of output lines per channel (R, G and B).
+
+Required sub-nodes:
+ - port: The Mali DP connection to an encoder input port. The connection
+is modelled using the OF graph bindings specified in
+Documentation/devicetree/bindings/graph.txt
+
+Optional properties:
+ - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+to be used for the framebuffer; if not present, the framebuffer may
+be located anywhere in memory.
+
+
+Example:
+
+/ {
+ ...
+
+ dp0: malidp at 6f20 {
+ compatible = "arm,mali-dp650";
+ reg = <0 0x6f20 0 0x2>;
+ memory-region = <&display_reserved>;
+ interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>,
+<0 168 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "DE", "SE";
+ clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>;
+ clock-names = "pxlclk", "mclk", "aclk", "pclk";
+ arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+ port {
+ dp0_output: endpoint {
+ remote-endpoint = <&tda998x_2_input>;
+ };
+ };
+ };
+
+ ...
+};
--
2.8.2
[RESENT PATCH] drm/i915: use #defines for qemu subsystem ids
On Mon, 13 Jun 2016, Jani Nikula wrote:
> On Mon, 13 Jun 2016, Gerd Hoffmann wrote:
>> Signed-off-by: Gerd Hoffmann
>
> Reviewed-by: Jani Nikula
And pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
>
>
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f313b4d..3099390 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -515,8 +515,10 @@ void intel_detect_pch(struct drm_device *dev)
>> } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
>> (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
>> ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
>> -pch->subsystem_vendor == 0x1af4 &&
>> -pch->subsystem_device == 0x1100)) {
>> +pch->subsystem_vendor ==
>> +PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
>> +pch->subsystem_device ==
>> +PCI_SUBDEVICE_ID_QEMU)) {
>> dev_priv->pch_type = intel_virt_detect_pch(dev);
>> } else
>> continue;
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/prime: fix error path deadlock fail
On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote: > There were a couple messed up things about this fail path. > (1) it would drop object_name_lock twice > (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles()) > needs to grab prime_lock > > Reported-by: Alex Deucher > Signed-off-by: Rob Clark > --- > Untested, but I think this should fix the potential deadlock that Alex > reported. Would be nice if someone with setup to reproduce could test > this. Sorry for the confusion. There were actually two deadlocks. The first one (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579610 fixed by https://github.com/torvalds/linux/commit/6984128d01cf935820a0563f3a00c6623ba58109) was that one we hit in testing. This one was just one that Qiang noticed by inspection while debugging the first. That said, the error path is obviously wrong and the patch looks correct to me. Reviewed-by: Alex Deucher > > drivers/gpu/drm/drm_prime.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index aab0f3f..780589b 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -593,7 +593,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > get_dma_buf(dma_buf); > } > > - /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ > + /* _handle_create_tail unconditionally unlocks dev->object_name_lock. > */ > ret = drm_gem_handle_create_tail(file_priv, obj, handle); > drm_gem_object_unreference_unlocked(obj); > if (ret) > @@ -601,11 +601,10 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > > ret = drm_prime_add_buf_handle(&file_priv->prime, > dma_buf, *handle); > + mutex_unlock(&file_priv->prime.lock); > if (ret) > goto fail; > > - mutex_unlock(&file_priv->prime.lock); > - > dma_buf_put(dma_buf); > > return 0; > @@ -615,11 +614,14 @@ fail: > * to detach.. which seems ok.. > */ > drm_gem_handle_delete(file_priv, *handle); > + dma_buf_put(dma_buf); > + return ret; > + > out_unlock: > mutex_unlock(&dev->object_name_lock); > out_put: > - dma_buf_put(dma_buf); > mutex_unlock(&file_priv->prime.lock); > + dma_buf_put(dma_buf); > return ret; > } > EXPORT_SYMBOL(drm_gem_prime_fd_to_handle); > -- > 2.5.5 >
linux-4.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c: 2 * pointless tests ?
yup, looks like we can drop the two pipe<0 checks. Care to send a patch?
BR,
-R
On Mon, Jun 13, 2016 at 10:51 AM, David Binderman
wrote:
> Hello there,
>
> 1.
>
> linux-4.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:545]: (style)
> Checking if unsigned variable 'pipe' is less than zero.
>
> Source code is
>
> if (pipe < 0 || pipe >= priv->num_crtcs) {
>
> 2.
>
> linux-4.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:567]: (style)
> Checking if unsigned variable 'pipe' is less than zero.
>
> Duplicate a few lines further down.
>
>
> Regards
>
> David Binderman
[PATCH] drm/prime: fix error path deadlock fail
On Mon, Jun 13, 2016 at 11:19:20AM -0400, Alex Deucher wrote: > On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote: > > There were a couple messed up things about this fail path. > > (1) it would drop object_name_lock twice > > (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles()) > > needs to grab prime_lock > > > > Reported-by: Alex Deucher > > Signed-off-by: Rob Clark > > --- > > Untested, but I think this should fix the potential deadlock that Alex > > reported. Would be nice if someone with setup to reproduce could test > > this. > > Sorry for the confusion. There were actually two deadlocks. The > first one (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579610 > fixed by > https://github.com/torvalds/linux/commit/6984128d01cf935820a0563f3a00c6623ba58109) > was that one we hit in testing. This one was just one that Qiang > noticed by inspection while debugging the first. That said, the error > path is obviously wrong and the patch looks correct to me. > > Reviewed-by: Alex Deucher Ok, I didn't add the bugzilla to this one. Applied to drm-misc, thanks. -Daniel > > > > > drivers/gpu/drm/drm_prime.c | 10 ++ > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > > index aab0f3f..780589b 100644 > > --- a/drivers/gpu/drm/drm_prime.c > > +++ b/drivers/gpu/drm/drm_prime.c > > @@ -593,7 +593,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > > get_dma_buf(dma_buf); > > } > > > > - /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ > > + /* _handle_create_tail unconditionally unlocks > > dev->object_name_lock. */ > > ret = drm_gem_handle_create_tail(file_priv, obj, handle); > > drm_gem_object_unreference_unlocked(obj); > > if (ret) > > @@ -601,11 +601,10 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, > > > > ret = drm_prime_add_buf_handle(&file_priv->prime, > > dma_buf, *handle); > > + mutex_unlock(&file_priv->prime.lock); > > if (ret) > > goto fail; > > > > - mutex_unlock(&file_priv->prime.lock); > > - > > dma_buf_put(dma_buf); > > > > return 0; > > @@ -615,11 +614,14 @@ fail: > > * to detach.. which seems ok.. > > */ > > drm_gem_handle_delete(file_priv, *handle); > > + dma_buf_put(dma_buf); > > + return ret; > > + > > out_unlock: > > mutex_unlock(&dev->object_name_lock); > > out_put: > > - dma_buf_put(dma_buf); > > mutex_unlock(&file_priv->prime.lock); > > + dma_buf_put(dma_buf); > > return ret; > > } > > EXPORT_SYMBOL(drm_gem_prime_fd_to_handle); > > -- > > 2.5.5 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 --- Comment #11 from Daniel Scharrer --- Created attachment 124508 --> https://bugs.freedesktop.org/attachment.cgi?id=124508&action=edit GALLIUM_DDEBUG="800 noflush" dump I tried to record an apitrace but could not get any lockups while recording or glretracing the traces. I also was not able to get a hang while using GALLIUM_DDEBUG="800" without noflush. Maybe the hang is framerate related, or at least much less likely to occur at really low framerates? However, I did reproduce a hang while using GALLIUM_DDEBUG="800 noflush". Attached is the ddebug dump, not sure if it will be of any use. Mesa 12.1.0-devel (git-a048047) LLVM r272544 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/d0d700cf/attachment.html>
[PATCH] drm: sti: use drm_platform_set_busid() helper
Fill set_busid field with drm_platform_set_busid helper function
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index b440617..98d67b4 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -304,6 +304,7 @@ static struct drm_driver sti_driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
.load = sti_load,
+ .set_busid = drm_platform_set_busid,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
.dumb_create = drm_gem_cma_dumb_create,
--
1.9.1
[PATCH] drm/prime: fix error path deadlock fail
On Mon, Jun 13, 2016 at 11:33 AM, Daniel Vetter wrote: > On Mon, Jun 13, 2016 at 11:19:20AM -0400, Alex Deucher wrote: >> On Thu, Jun 9, 2016 at 3:29 PM, Rob Clark wrote: >> > There were a couple messed up things about this fail path. >> > (1) it would drop object_name_lock twice >> > (2) drm_gem_handle_delete() (in drm_gem_remove_prime_handles()) >> > needs to grab prime_lock >> > >> > Reported-by: Alex Deucher >> > Signed-off-by: Rob Clark >> > --- >> > Untested, but I think this should fix the potential deadlock that Alex >> > reported. Would be nice if someone with setup to reproduce could test >> > this. >> >> Sorry for the confusion. There were actually two deadlocks. The >> first one (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579610 >> fixed by >> https://github.com/torvalds/linux/commit/6984128d01cf935820a0563f3a00c6623ba58109) >> was that one we hit in testing. This one was just one that Qiang >> noticed by inspection while debugging the first. That said, the error >> path is obviously wrong and the patch looks correct to me. >> >> Reviewed-by: Alex Deucher > > Ok, I didn't add the bugzilla to this one. Applied to drm-misc, thanks. There actually is a bugzilla for the potential deadlock fixed by this patch: https://bugzilla.kernel.org/show_bug.cgi?id=117861 Alex
[PATCH] drm: sti: use drm_platform_set_busid() helper
On Mon, Jun 13, 2016 at 05:48:15PM +0200, Benjamin Gaignard wrote:
> Fill set_busid field with drm_platform_set_busid helper function
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/sti/sti_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index b440617..98d67b4 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -304,6 +304,7 @@ static struct drm_driver sti_driver = {
> .driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
> DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
> .load = sti_load,
> + .set_busid = drm_platform_set_busid,
You're not supposed to use these anymore. Use drm_dev_alloc() and
drm_dev_register() instead.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/2ffa8a91/attachment.sig>
[Bug 96487] Cannot force power_dpm_force_performance_level to high
https://bugs.freedesktop.org/show_bug.cgi?id=96487
--- Comment #6 from Alex Deucher ---
The hardware automatically adjusts the clock speeds on demand based on GPU load
when in auto mode. Trinity/richland chips do not support forcing to high.
>From the driver code in trinity_dpm.c:
int trinity_dpm_force_performance_level(struct radeon_device *rdev,
enum radeon_dpm_forced_level level)
{
struct trinity_power_info *pi = trinity_get_pi(rdev);
struct radeon_ps *rps = &pi->current_rps;
struct trinity_ps *ps = trinity_get_ps(rps);
int i, ret;
if (ps->num_levels <= 1)
return 0;
if (level == RADEON_DPM_FORCED_LEVEL_HIGH) {
/* not supported by the hw */
return -EINVAL;
} else if (level == RADEON_DPM_FORCED_LEVEL_LOW) {
ret = trinity_dpm_n_levels_disabled(rdev, ps->num_levels - 1);
if (ret)
return ret;
} else {
for (i = 0; i < ps->num_levels; i++) {
ret = trinity_dpm_n_levels_disabled(rdev, 0);
if (ret)
return ret;
}
}
rdev->pm.dpm.forced_level = level;
return 0;
}
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/30c1c874/attachment.html>
[PATCH] drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled
On Mon, Jun 13, 2016 at 10:09 AM, Christian König
wrote:
> From: Christian König
>
> Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven
> for working a lot with the PLLs and figuring this out.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/atombios_crtc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index bdc7b9e..482df5f 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -589,7 +589,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE61(rdev) ||
> ASIC_IS_DCE8(rdev))
> radeon_crtc->pll_flags |= RADEON_PLL_USE_FRAC_FB_DIV;
> /* use frac fb div on RS780/RS880 */
> - if ((rdev->family == CHIP_RS780) || (rdev->family ==
> CHIP_RS880))
> + if (((rdev->family == CHIP_RS780) || (rdev->family ==
> CHIP_RS880))
> + && !radeon_crtc->ss_enabled)
> radeon_crtc->pll_flags |= RADEON_PLL_USE_FRAC_FB_DIV;
> if (ASIC_IS_DCE32(rdev) && mode->clock > 165000)
> radeon_crtc->pll_flags |= RADEON_PLL_USE_FRAC_FB_DIV;
> @@ -626,7 +627,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> if (radeon_crtc->ss.refdiv) {
> radeon_crtc->pll_flags |=
> RADEON_PLL_USE_REF_DIV;
> radeon_crtc->pll_reference_div =
> radeon_crtc->ss.refdiv;
> - if (ASIC_IS_AVIVO(rdev))
> + if (rdev->family >= CHIP_RV770)
> radeon_crtc->pll_flags |=
> RADEON_PLL_USE_FRAC_FB_DIV;
> }
> }
> --
> 2.5.0
>
[PATCH 2/2] drm/amdgpu: stop disabling irqs when it isn't neccessary
On Mon, Jun 13, 2016 at 04:12:43PM +0200, Christian König wrote:
> From: Christian König
>
> A regular spin_lock/unlock should do here as well.
>
> Signed-off-by: Christian König
Just drive-by comment, but you can't mix up irq spinlocks with normal
ones. And there's places where this is still irqsave, but some of these
functions can be called directly from the scheduler kthread. You can only
drop the _irqsave if you know you're always called from hardirq context
(softirq isn't enough), or when you know someone already disabled
interrupts. And you can simplify the _irqsave to just _irq when you are in
always in process context and irqs are always still enabled.
On a super-quick look seems fishy.
-Daniel
> ---
> drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> index b1d49c5..e13b140 100644
> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> @@ -331,17 +331,16 @@ static void amd_sched_job_finish(struct work_struct
> *work)
> struct amd_sched_job *s_job = container_of(work, struct amd_sched_job,
> finish_work);
> struct amd_gpu_scheduler *sched = s_job->sched;
> - unsigned long flags;
>
> /* remove job from ring_mirror_list */
> - spin_lock_irqsave(&sched->job_list_lock, flags);
> + spin_lock(&sched->job_list_lock);
> list_del_init(&s_job->node);
> if (sched->timeout != MAX_SCHEDULE_TIMEOUT) {
> struct amd_sched_job *next;
>
> - spin_unlock_irqrestore(&sched->job_list_lock, flags);
> + spin_unlock(&sched->job_list_lock);
> cancel_delayed_work_sync(&s_job->work_tdr);
> - spin_lock_irqsave(&sched->job_list_lock, flags);
> + spin_lock(&sched->job_list_lock);
>
> /* queue TDR for next job */
> next = list_first_entry_or_null(&sched->ring_mirror_list,
> @@ -350,7 +349,7 @@ static void amd_sched_job_finish(struct work_struct *work)
> if (next)
> schedule_delayed_work(&next->work_tdr, sched->timeout);
> }
> - spin_unlock_irqrestore(&sched->job_list_lock, flags);
> + spin_unlock(&sched->job_list_lock);
> sched->ops->free_job(s_job);
> }
>
> @@ -364,15 +363,14 @@ static void amd_sched_job_finish_cb(struct fence *f,
> struct fence_cb *cb)
> static void amd_sched_job_begin(struct amd_sched_job *s_job)
> {
> struct amd_gpu_scheduler *sched = s_job->sched;
> - unsigned long flags;
>
> - spin_lock_irqsave(&sched->job_list_lock, flags);
> + spin_lock(&sched->job_list_lock);
> list_add_tail(&s_job->node, &sched->ring_mirror_list);
> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> list_first_entry_or_null(&sched->ring_mirror_list,
>struct amd_sched_job, node) == s_job)
> schedule_delayed_work(&s_job->work_tdr, sched->timeout);
> - spin_unlock_irqrestore(&sched->job_list_lock, flags);
> + spin_unlock(&sched->job_list_lock);
> }
>
> static void amd_sched_job_timedout(struct work_struct *work)
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/etnaviv: initialize iommu domain page size
Since d16e0faab91 (iommu: Allow selecting page sizes per domain) the iommu core demands the page size to be set per domain, otherwise any mapping attempts will be dropped. Make sure to set a valid page size for the etnaviv iommu. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c index 522cfd447892..16353ee81651 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c @@ -225,6 +225,7 @@ struct iommu_domain *etnaviv_iommu_domain_alloc(struct etnaviv_gpu *gpu) etnaviv_domain->domain.type = __IOMMU_DOMAIN_PAGING; etnaviv_domain->domain.ops = &etnaviv_iommu_ops.ops; + etnaviv_domain->domain.pgsize_bitmap = SZ_4K; etnaviv_domain->domain.geometry.aperture_start = GPU_MEM_START; etnaviv_domain->domain.geometry.aperture_end = GPU_MEM_START + PT_ENTRIES * SZ_4K - 1; -- 2.8.1
[PATCH 10/10] drm/radeon: use crtc directly in drm_crtc_vblank_put()
On Tue, Jun 07, 2016 at 11:08:02AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> We don't need to use &radeon_crtc->base there as crtc is available
> in the function.
>
> Signed-off-by: Gustavo Padovan
All expect patch 5 merged, thanks.
-Daniel
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 2fb18f1..fb461f9 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -625,7 +625,7 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
> return 0;
>
> vblank_cleanup:
> - drm_crtc_vblank_put(&radeon_crtc->base);
> + drm_crtc_vblank_put(crtc);
>
> pflip_cleanup:
> if (unlikely(radeon_bo_reserve(new_rbo, false) != 0)) {
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 119861] Kernel BUG() when Xorg server is started using nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=119861 Dmitrii Tcvetkov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE --- Comment #5 from Dmitrii Tcvetkov --- (In reply to Lucas Stach from comment #4) > Probably the same bug as seen on imx-drm by Philipp and fixed with the > following 2 patches: > https://patchwork.kernel.org/patch/9151037/ > https://patchwork.kernel.org/patch/9151039/ > > Please test if those also fix this bug. Thanks. Thanks, the patch helps on 4.7-rc2, Xorg starts like with 4.6 without errors in dmesg. Although 4.7-rc3 panics with same .config even without the patch (I can't see anything on screen and I assume it's a panic because kernel reacts on panic= parameter). Looks like it is another issue. I'll make separate report when get any info with netconsole. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
Am Donnerstag, den 02.06.2016, 22:28 +0200 schrieb Daniel Vetter:
> On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> > Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> > in a modeset. (v2)"), the reference counts of all connectors in the
> > drm_mode_set given to drm_crtc_helper_set_config are incremented, and then
> > the reference counts of all connectors are decremented on success, but in a
> > temporary copy of the connector structure. This leads to the following
> > error after the first modeset on imx-drm:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 0004
> > pgd = ad8c4000
> > [0004] *pgd=3d9c5831, *pte=, *ppte=
> > Internal error: Oops: 817 [#1] PREEMPT SMP ARM
> > Modules linked in:
> > CPU: 1 PID: 190 Comm: kmsfb-manage Not tainted 4.7.0-rc1+ #657
> > Hardware name: Freescale i.MX6 Quad/DualLit: [<80506098>]lr :
> > [<80252e94>]psr: 200c0013
> > sp : adca7ca8 ip : adca7b90 fp : adca7cd4
> > r10: r9 : 0100 r8 : 0200
> > r7 : af3c9800 r6 : aded7848 r5 : aded7800 r4 :
> > r3 : af3ca058 r2 : 0200 r1 : af3ca058 r0 :
> > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > Control: 10c5387d Table: 3d8c404a DAC: 0051
> > Process kmsfb-manage (pid: 190, stack limit = 0xadca6210)
> > Stack: (0xadca7ca8 to 0xadca8000)
> > 7ca0: 805190e0 aded7800 aded7820 80501a88 8155a290
> > af3c9c6c
> > 7cc0: adca7ddc 000f adca7cec adca7cd8 80519104 80506044 805190e0
> > aded7800
> > 7ce0: adca7d04 adca7cf0 80501ac0 805190ec aded7820 aded7814 adca7d24
> > adca7d08
> > 7d00: 804fdb80 80501a94 aded7800 af3ca010 aded7afc af3c9c60 adca7d94
> > adca7d28
> > 7d20: 804e3518 804fdb20 af3c9b1c adca7d50 81506f44
> > 8093c500
> > 7d40: af3c9c6c ae4f2ca8 ae4f2c18 ae637f00
> > aded7800
> > 7d60: 0001 af3c9800 af23c300 ae77fcc0 ae4f2c18 0001 af3c9800
> > 8155a290
> > 7d80: af1af700 adca6000 adca7db4 adca7d98 804fea6c 804e2de4 adca7e50
> > adb3d940
> > 7da0: 0001 af3c9800 adca7e24 adca7db8 8050440c 804fea0c ae77fcc0
> > 0003
> > 7dc0: adca7e24 adb3d940 af1af700 ae77fcc0 ae77fccc ae4f2c18 8083d44c
> > ae77fcc0
> > 7de0: ae4002 80d03040 adca7e64 adca7e40 adca7e50 80503f08
> > 7e40: 7ebd5630 adca7e50 0068 c06864a2 7ebd5be8 0001
> > 0018
> > 7e60: 0026 0001 000115bc 05010500
> > 05a0059f
> > 7e80: 0320 03360321 0337 003c 0040 30383231
> > 30303878
> > 7ea0: 80173058
> > 80172e30
> > 7ec0: 80d77d32 4000 adf7d900 0003 7ebd5630 af342bb0
> > adfe3b80
> > 7ee0: 80272f50 0003 adca6000 adca7f7c adca7f00 802725ec
> > 804f52cc
> > 7f00: 802809cc 80178450 80280880 80145904 adb3d8c0
> > adf7d990
> > 7f20: 0003 4000 01614c10 c06864a2 0003 adca6000
> >
> > 7f40: adca7f6c adca7f50 80280b04 8028088c 000115bc adfe3b81 7ebd5630
> > adfe3b80
> > 7f60: c06864a2 0003 adca6000 adca7fa4 adca7f80 80272f50
> > 80272548
> > 7f80: 000115bc 00017050 0001 01614c10 0036 801089e4
> > adca7fa8
> > 7fa0: 80108840 80272f18 00017050 0001 0003 c06864a2 7ebd5630
> > 000115bc
> > 7fc0: 00017050 0001 01614c10 0036 0003 0026
> > 0018
> > 7fe0: 00016f38 7ebd562c b5e9 76ef31e6 400c0030 0003 ff5f37db
> > bfe7dd4d
> > Backtrace:
> > [<80506038>] (drm_connector_cleanup) from [<80519104>]
> > (dw_hdmi_connector_destroy+0x24/0x28)
> > r10:000f r9:adca7ddc r8:af3c9c6c r7:8155a290 r6:80501a88
> > r5:aded7820
> > r4:aded7800 r3:805190e0
> > [<805190e0>] (dw_hdmi_connector_destroy) from [<80501ac0>]
> > (drm_connector_free+0x38/0x3c)
> > r4:aded7800 nreference) from [<804e3518>]
> > (drm_crtc_helper_set_config+0x740/0xbf4)
> > r6:af3c9c60 r5:aded7afc r4:af3ca010 r3:aded7800
> > [<804e2dd8>] (drm_crtc_helper_set_config) from [<804fea6c>]
> > (drm_mode_set_config_internal+0x6c/0xf4)
> > r10:adca6000 r9:af1af700 r8:8155a290 r7:af3c9800 r6:0001
> > r5:ae4f2c18
> > r4:ae77fcc0
> > [<804fea00>] (drm_mode_set_config_internal) from [<8050440c>]
> > (drm_mode_setcrtc+0x504/0x57c)
> > r7:af3c9800 r6:0001 r5:adb3d940 r4:adca7e50
> > [<80503f08>] (drm_mode_setcrtc) from [<804f5404>]
> > (drm_ioctl+0x144/0x4dc)
> > r10:ada2e000 r9:00a2 r8:af3c9800 r7:8155a290 r6:809320b4
> > r5:0051
> > r4:adca7e50
> > [<804f52c0>] (drm_ioctl) from [<802725ec>] (do_vfs_ioctl+0xb0/0x9d0)
> > r10: r9:adca6000 r8:0003 r7:80272f50 r6:adfe3b80
> > r5:af342bb0
> > r4:7ebd5630
[PATCH v3 4/6] drm/panel: simple: Add support for Samsung LSN122DL01-C01 2560x1600 panel
Yakir,
On Sat, Jun 11, 2016 at 7:56 PM, Yakir Yang wrote:
> The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD panel
> connected using eDP interfaces.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v3:
> - Correct the size of panel_desc to active area 262mmx164mm (Emil, Stéphane)
>
> Changes in v2: None
>
> drivers/gpu/drm/panel/panel-simple.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 2d40a21..17cc973 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1246,6 +1246,28 @@ static const struct panel_desc qd43003c0_40 = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> };
>
> +static const struct drm_display_mode samsung_lsn122dl01_c01_mode = {
> + .clock = 271560,
> + .hdisplay = 2560,
> + .hsync_start = 2560 + 48,
> + .hsync_end = 2560 + 48 + 32,
> + .htotal = 2560 + 48 + 32 + 80,
> + .vdisplay = 1600,
> + .vsync_start = 1600 + 2,
> + .vsync_end = 1600 + 2 + 5,
> + .vtotal = 1600 + 2 + 5 + 57,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc samsung_lsn122dl01_c01 = {
> + .modes = &samsung_lsn122dl01_c01_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 262,
> + .height = 164,
Earlier you said that the active area of this panel was:
> Display area 262.656(H) X 164.16(V) (12.2âdiagonal)
In other panels I looked at the EDID tended to round numbers, not
truncate them. For instance the Starry panel that I sent the patch
for says in the manual "262.7712 (H) x 164.232 (V)" but then the EDID
says "263 x 164".
That would mean your width should be 263 mm, not 262 mm.
-Doug
[PATCH 2/2] drm/amdgpu: stop disabling irqs when it isn't neccessary
Am 13.06.2016 um 18:33 schrieb Daniel Vetter:
> On Mon, Jun 13, 2016 at 04:12:43PM +0200, Christian König wrote:
>> From: Christian König
>>
>> A regular spin_lock/unlock should do here as well.
>>
>> Signed-off-by: Christian König
> Just drive-by comment, but you can't mix up irq spinlocks with normal
> ones. And there's places where this is still irqsave, but some of these
> functions can be called directly from the scheduler kthread. You can only
> drop the _irqsave if you know you're always called from hardirq context
> (softirq isn't enough), or when you know someone already disabled
> interrupts. And you can simplify the _irqsave to just _irq when you are in
> always in process context and irqs are always still enabled.
>
> On a super-quick look seems fishy.
The point is there isn't even any IRQ involved in all of this.
The spin is either locked from a work item or the kthread, never from
irq context.
Christian.
> -Daniel
>
>> ---
>> drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 14 ++
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> index b1d49c5..e13b140 100644
>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> @@ -331,17 +331,16 @@ static void amd_sched_job_finish(struct work_struct
>> *work)
>> struct amd_sched_job *s_job = container_of(work, struct amd_sched_job,
>> finish_work);
>> struct amd_gpu_scheduler *sched = s_job->sched;
>> -unsigned long flags;
>>
>> /* remove job from ring_mirror_list */
>> -spin_lock_irqsave(&sched->job_list_lock, flags);
>> +spin_lock(&sched->job_list_lock);
>> list_del_init(&s_job->node);
>> if (sched->timeout != MAX_SCHEDULE_TIMEOUT) {
>> struct amd_sched_job *next;
>>
>> -spin_unlock_irqrestore(&sched->job_list_lock, flags);
>> +spin_unlock(&sched->job_list_lock);
>> cancel_delayed_work_sync(&s_job->work_tdr);
>> -spin_lock_irqsave(&sched->job_list_lock, flags);
>> +spin_lock(&sched->job_list_lock);
>>
>> /* queue TDR for next job */
>> next = list_first_entry_or_null(&sched->ring_mirror_list,
>> @@ -350,7 +349,7 @@ static void amd_sched_job_finish(struct work_struct
>> *work)
>> if (next)
>> schedule_delayed_work(&next->work_tdr, sched->timeout);
>> }
>> -spin_unlock_irqrestore(&sched->job_list_lock, flags);
>> +spin_unlock(&sched->job_list_lock);
>> sched->ops->free_job(s_job);
>> }
>>
>> @@ -364,15 +363,14 @@ static void amd_sched_job_finish_cb(struct fence *f,
>> struct fence_cb *cb)
>> static void amd_sched_job_begin(struct amd_sched_job *s_job)
>> {
>> struct amd_gpu_scheduler *sched = s_job->sched;
>> -unsigned long flags;
>>
>> -spin_lock_irqsave(&sched->job_list_lock, flags);
>> +spin_lock(&sched->job_list_lock);
>> list_add_tail(&s_job->node, &sched->ring_mirror_list);
>> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
>> list_first_entry_or_null(&sched->ring_mirror_list,
>> struct amd_sched_job, node) == s_job)
>> schedule_delayed_work(&s_job->work_tdr, sched->timeout);
>> -spin_unlock_irqrestore(&sched->job_list_lock, flags);
>> +spin_unlock(&sched->job_list_lock);
>> }
>>
>> static void amd_sched_job_timedout(struct work_struct *work)
>> --
>> 2.5.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
On Mon, Jun 13, 2016 at 06:49:57PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 02.06.2016, 22:28 +0200 schrieb Daniel Vetter:
> > On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> > > Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> > > in a modeset. (v2)"), the reference counts of all connectors in the
> > > drm_mode_set given to drm_crtc_helper_set_config are incremented, and then
> > > the reference counts of all connectors are decremented on success, but in
> > > a
> > > temporary copy of the connector structure. This leads to the following
> > > error after the first modeset on imx-drm:
> > >
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 0004
> > > pgd = ad8c4000
> > > [0004] *pgd=3d9c5831, *pte=, *ppte=
> > > Internal error: Oops: 817 [#1] PREEMPT SMP ARM
> > > Modules linked in:
> > > CPU: 1 PID: 190 Comm: kmsfb-manage Not tainted 4.7.0-rc1+ #657
> > > Hardware name: Freescale i.MX6 Quad/DualLit: [<80506098>]lr :
> > > [<80252e94>]psr: 200c0013
> > > sp : adca7ca8 ip : adca7b90 fp : adca7cd4
> > > r10: r9 : 0100 r8 : 0200
> > > r7 : af3c9800 r6 : aded7848 r5 : aded7800 r4 :
> > > r3 : af3ca058 r2 : 0200 r1 : af3ca058 r0 :
> > > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > > Control: 10c5387d Table: 3d8c404a DAC: 0051
> > > Process kmsfb-manage (pid: 190, stack limit = 0xadca6210)
> > > Stack: (0xadca7ca8 to 0xadca8000)
> > > 7ca0: 805190e0 aded7800 aded7820 80501a88 8155a290
> > > af3c9c6c
> > > 7cc0: adca7ddc 000f adca7cec adca7cd8 80519104 80506044 805190e0
> > > aded7800
> > > 7ce0: adca7d04 adca7cf0 80501ac0 805190ec aded7820 aded7814 adca7d24
> > > adca7d08
> > > 7d00: 804fdb80 80501a94 aded7800 af3ca010 aded7afc af3c9c60 adca7d94
> > > adca7d28
> > > 7d20: 804e3518 804fdb20 af3c9b1c adca7d50 81506f44
> > > 8093c500
> > > 7d40: af3c9c6c ae4f2ca8 ae4f2c18 ae637f00
> > > aded7800
> > > 7d60: 0001 af3c9800 af23c300 ae77fcc0 ae4f2c18 0001 af3c9800
> > > 8155a290
> > > 7d80: af1af700 adca6000 adca7db4 adca7d98 804fea6c 804e2de4 adca7e50
> > > adb3d940
> > > 7da0: 0001 af3c9800 adca7e24 adca7db8 8050440c 804fea0c ae77fcc0
> > > 0003
> > > 7dc0: adca7e24 adb3d940 af1af700 ae77fcc0 ae77fccc ae4f2c18 8083d44c
> > > ae77fcc0
> > > 7de0: ae4002 80d03040 adca7e64 adca7e40 adca7e50 80503f08
> > > 7e40: 7ebd5630 adca7e50 0068 c06864a2 7ebd5be8 0001
> > > 0018
> > > 7e60: 0026 0001 000115bc 05010500
> > > 05a0059f
> > > 7e80: 0320 03360321 0337 003c 0040 30383231
> > > 30303878
> > > 7ea0: 80173058
> > > 80172e30
> > > 7ec0: 80d77d32 4000 adf7d900 0003 7ebd5630 af342bb0
> > > adfe3b80
> > > 7ee0: 80272f50 0003 adca6000 adca7f7c adca7f00 802725ec
> > > 804f52cc
> > > 7f00: 802809cc 80178450 80280880 80145904 adb3d8c0
> > > adf7d990
> > > 7f20: 0003 4000 01614c10 c06864a2 0003 adca6000
> > >
> > > 7f40: adca7f6c adca7f50 80280b04 8028088c 000115bc adfe3b81 7ebd5630
> > > adfe3b80
> > > 7f60: c06864a2 0003 adca6000 adca7fa4 adca7f80 80272f50
> > > 80272548
> > > 7f80: 000115bc 00017050 0001 01614c10 0036 801089e4
> > > adca7fa8
> > > 7fa0: 80108840 80272f18 00017050 0001 0003 c06864a2 7ebd5630
> > > 000115bc
> > > 7fc0: 00017050 0001 01614c10 0036 0003 0026
> > > 0018
> > > 7fe0: 00016f38 7ebd562c b5e9 76ef31e6 400c0030 0003 ff5f37db
> > > bfe7dd4d
> > > Backtrace:
> > > [<80506038>] (drm_connector_cleanup) from [<80519104>]
> > > (dw_hdmi_connector_destroy+0x24/0x28)
> > > r10:000f r9:adca7ddc r8:af3c9c6c r7:8155a290 r6:80501a88
> > > r5:aded7820
> > > r4:aded7800 r3:805190e0
> > > [<805190e0>] (dw_hdmi_connector_destroy) from [<80501ac0>]
> > > (drm_connector_free+0x38/0x3c)
> > > r4:aded7800 nreference) from [<804e3518>]
> > > (drm_crtc_helper_set_config+0x740/0xbf4)
> > > r6:af3c9c60 r5:aded7afc r4:af3ca010 r3:aded7800
> > > [<804e2dd8>] (drm_crtc_helper_set_config) from [<804fea6c>]
> > > (drm_mode_set_config_internal+0x6c/0xf4)
> > > r10:adca6000 r9:af1af700 r8:8155a290 r7:af3c9800 r6:0001
> > > r5:ae4f2c18
> > > r4:ae77fcc0
> > > [<804fea00>] (drm_mode_set_config_internal) from [<8050440c>]
> > > (drm_mode_setcrtc+0x504/0x57c)
> > > r7:af3c9800 r6:0001 r5:adb3d940 r4:adca7e50
> > > [<80503f08>] (drm_mode_setcrtc) from [<804f5404>]
> > > (drm_ioctl+0x144/0x4dc)
> > > r10:ada2e000 r9:00
[PATCH v2 03/10] dt-bindings: msm/mdp: Fix up clock related bindings
On Fri, Jun 10, 2016 at 04:16:33PM +0530, Archit Taneja wrote: > MDP5: > - Don't ask for source clock > > MDP4: > - Give a better name for MDP_TV_CLK > - Remove TV_SRC > - Add MDP_AXI_CLK This could use the explanation in the commit msg why it is okay you are breaking compatibility. With that, Acked-by: Rob Herring
[Bug 96512] Portal Stories Mel: Player's hands appear black at high shader quality
https://bugs.freedesktop.org/show_bug.cgi?id=96512 Bug ID: 96512 Summary: Portal Stories Mel: Player's hands appear black at high shader quality Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: robin at paxnos.de QA Contact: dri-devel at lists.freedesktop.org Created attachment 124512 --> https://bugs.freedesktop.org/attachment.cgi?id=124512&action=edit Example from Portal Stories: Mel. Upper picture: Shader quality "Very high" (or high), Lower picture: Shader quality "medium" (or lower) Hello, this is my first bug report, so I hope the information provided is sufficient. In Portal Stories: Mel and Portal 2 (reportedly), the player's arms and hands (and a few other objects, as demonstrated in the attached picture) appear black when the shader quality setting is set to "High" or "Very High", but appears normal if it is medium or lower. This seems to only happen to a few objects, like the arms. In Portal 2 this is not visible as often, as the player's arms are usually not visible like that. Not sure if this is a Mesa bug, but it has been pointed out that the reports have so far only been on different versions of Mesa, so.. just thought I'd report it here in case. I actually wanted to provide apitrace files, but I could not get it to work, sadly. I sorted this under radeonsi because this is the driver I use, but among the other reports have been Intel systems. Please correct the bug report classification if not accurate. The bug on Valve's git: https://github.com/ValveSoftware/portal2/issues/255 My system: Kubuntu 16.04 Intel i5-2400 8 GB DDR3 RAM Radeon HD 7950 Boost (Steam Overlay deactivated) OpenGL renderer string: Gallium 0.4 on AMD TAHITI (DRM 2.43.0 / 4.4.0-24-generic, LLVM 3.9.0) OpenGL core profile version string: 4.2 (Core Profile) Mesa 12.1.0-devel - padoka PPA (git-42624ea) OpenGL core profile shading language version string: 4.20 Please let me know if there's something else you need -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/695de130/attachment.html>
[PATCH v2] amdgpu: fix asic initialization for virtualized environments
On Sat, Jun 11, 2016 at 4:02 AM, Christian König
wrote:
> Am 11.06.2016 um 08:51 schrieb Andres Rodriguez:
>>
>> When executing in a PCI passthrough based virtuzliation environemnt, the
>> hypervisor will usually attempt to send a PCIe bus reset signal to the
>> ASIC when the VM reboots. In this scenario, the card is not correctly
>> initialized, but we still consider it to be posted. Therefore, in a
>> passthrough based environemnt we should always post the card to guarantee
>> it is in a good state for driver initialization.
>>
>> However, if we are operating in SR-IOV mode it is up to the GIM driver
>> to manage the asic state, therefore we should not post the card (and
>> shouldn't be able to do it either).
>>
>> Signed-off-by: Andres Rodriguez
>
>
> As a little nitpick you could have noted what has changed between v1 and v2
> in the commit message. Otherwise people sometimes wonder if there is a major
> difference.
>
> But in this case it is probably negligible, so patch is Reviewed-by:
> Christian König .
Applied to my upstream tree along with an updated note about v2 in the
commit message.
Alex
>
> And +1 for working directly on the mailing list.
>
> Regards,
> Christian.
>
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 +++
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 +++-
>> drivers/gpu/drm/amd/amdgpu/cik.c | 7 +++
>> drivers/gpu/drm/amd/amdgpu/vi.c| 15 +++
>> 4 files changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 26fe670..fe71dea 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1835,6 +1835,8 @@ struct amdgpu_asic_funcs {
>> /* MM block clocks */
>> int (*set_uvd_clocks)(struct amdgpu_device *adev, u32 vclk, u32
>> dclk);
>> int (*set_vce_clocks)(struct amdgpu_device *adev, u32 evclk, u32
>> ecclk);
>> + /* query virtual capabilities */
>> + u32 (*get_virtual_caps)(struct amdgpu_device *adev);
>> };
>> /*
>> @@ -1932,8 +1934,12 @@ void amdgpu_cgs_destroy_device(struct cgs_device
>> *cgs_device);
>> /* GPU virtualization */
>> +#define AMDGPU_VIRT_CAPS_SRIOV_EN (1 << 0)
>> +#define AMDGPU_VIRT_CAPS_IS_VF (1 << 1)
>> struct amdgpu_virtualization {
>> bool supports_sr_iov;
>> + bool is_virtual;
>> + u32 caps;
>> };
>> /*
>> @@ -2226,6 +2232,7 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
>> #define amdgpu_asic_get_xclk(adev) (adev)->asic_funcs->get_xclk((adev))
>> #define amdgpu_asic_set_uvd_clocks(adev, v, d)
>> (adev)->asic_funcs->set_uvd_clocks((adev), (v), (d))
>> #define amdgpu_asic_set_vce_clocks(adev, ev, ec)
>> (adev)->asic_funcs->set_vce_clocks((adev), (ev), (ec))
>> +#define amdgpu_asic_get_virtual_caps(adev)
>> ((adev)->asic_funcs->get_virtual_caps((adev)))
>> #define amdgpu_asic_get_gpu_clock_counter(adev)
>> (adev)->asic_funcs->get_gpu_clock_counter((adev))
>> #define amdgpu_asic_read_disabled_bios(adev)
>> (adev)->asic_funcs->read_disabled_bios((adev))
>> #define amdgpu_asic_read_bios_from_rom(adev, b, l)
>> (adev)->asic_funcs->read_bios_from_rom((adev), (b), (l))
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index b494212..b98ebac 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -1392,6 +1392,14 @@ static int amdgpu_resume(struct amdgpu_device
>> *adev)
>> return 0;
>> }
>> +static bool amdgpu_device_is_virtual(void)
>> +{
>> +#ifdef CONFIG_X86
>> + return boot_cpu_has(X86_FEATURE_HYPERVISOR);
>> +#else
>> + return false;
>> +#endif
>> +}
>> /**
>>* amdgpu_device_has_dal_support - check if dal is supported
>> @@ -1560,8 +1568,14 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>> adev->virtualization.supports_sr_iov =
>> amdgpu_atombios_has_gpu_virtualization_table(adev);
>> + /* Check if we are executing in a virtualized environment */
>> + adev->virtualization.is_virtual = amdgpu_device_is_virtual();
>> + adev->virtualization.caps = amdgpu_asic_get_virtual_caps(adev);
>> +
>> /* Post card if necessary */
>> - if (!amdgpu_card_posted(adev)) {
>> + if (!amdgpu_card_posted(adev) ||
>> + (adev->virtualization.is_virtual &&
>> +!adev->virtualization.caps & AMDGPU_VIRT_CAPS_SRIOV_EN)) {
>> if (!adev->bios) {
>> dev_err(adev->dev, "Card not posted and no BIOS -
>> ignoring\n");
>> return -EINVAL;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c
>> b/drivers/gpu/drm/amd/amdgpu/cik.c
>> index 40f4fda..907bb28 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/cik.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/cik.c
>> @@ -963,6 +963,12 @@ static bo
[PATCH] drm/radeon: fix asic initialization for virtualized environments
When executing in a PCI passthrough based virtuzliation environment, the
hypervisor will usually attempt to send a PCIe bus reset signal to the
ASIC when the VM reboots. In this scenario, the card is not correctly
initialized, but we still consider it to be posted. Therefore, in a
passthrough based environemnt we should always post the card to guarantee
it is in a good state for driver initialization.
Ported from amdgpu commit:
amdgpu: fix asic initialization for virtualized environments
Cc: Andres Rodriguez
Cc: Alex Williamson
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_device.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index e61c763..21c44b2 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -630,6 +630,23 @@ void radeon_gtt_location(struct radeon_device *rdev,
struct radeon_mc *mc)
/*
* GPU helpers function.
*/
+
+/**
+ * radeon_device_is_virtual - check if we are running is a virtual environment
+ *
+ * Check if the asic has been passed through to a VM (all asics).
+ * Used at driver startup.
+ * Returns true if virtual or false if not.
+ */
+static bool radeon_device_is_virtual(void)
+{
+#ifdef CONFIG_X86
+ return boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#else
+ return false;
+#endif
+}
+
/**
* radeon_card_posted - check if the hw has already been initialized
*
@@ -643,6 +660,10 @@ bool radeon_card_posted(struct radeon_device *rdev)
{
uint32_t reg;
+ /* for pass through, always force asic_init */
+ if (radeon_device_is_virtual())
+ return false;
+
/* required for EFI mode on macbook2,1 which uses an r5xx asic */
if (efi_enabled(EFI_BOOT) &&
(rdev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE) &&
--
2.5.5
[PATCH v2 07/10] dt-bindings: msm/dsi: Use standard data lanes binding
On Fri, Jun 10, 2016 at 04:16:37PM +0530, Archit Taneja wrote: > The "qcom,data-lane-map" binding mentioned in the document is changed to > the more generic "data-lanes" property specified in: > > Documentation/devicetree/bindings/media/video-interfaces.txt > > The previous binding expressed physical to logical data lane mappings, > the standard "data-lanes" binding uses logical to physical data lane > mappings. Update the docs to reflect this change. The example had the > property incorrectly named as "lanes", update this too. > > The MSM DSI DT bindings aren't used anywhere at the moment, so > it's okay to update this property. > > Signed-off-by: Archit Taneja > --- > .../devicetree/bindings/display/msm/dsi.txt| 37 > +++--- > 1 file changed, 19 insertions(+), 18 deletions(-) Acked-by: Rob Herring
[PATCH] drm/radeon: fix asic initialization for virtualized environments
On Mon, 13 Jun 2016 15:45:20 -0400
Alex Deucher wrote:
> When executing in a PCI passthrough based virtuzliation environment, the
> hypervisor will usually attempt to send a PCIe bus reset signal to the
> ASIC when the VM reboots. In this scenario, the card is not correctly
> initialized, but we still consider it to be posted. Therefore, in a
> passthrough based environemnt we should always post the card to guarantee
> it is in a good state for driver initialization.
>
> Ported from amdgpu commit:
> amdgpu: fix asic initialization for virtualized environments
>
> Cc: Andres Rodriguez
> Cc: Alex Williamson
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 21 +
> 1 file changed, 21 insertions(+)
Thanks, I expect it's an improvement, though it's always a bit
disappointing when a driver starts modifying its behavior based on
what might be a transient feature of the platform, in this case a
hypervisor platform. For instance, why does our bus reset and video
ROM execution result in a different state than a physical BIOS doing
the same? Can't this condition occur regardless of a hypervisor,
perhaps a rare hot-add of a GPU, a bare metal kexec reboot, or perhaps
simply a system BIOS optimized to post a limited set of devices.
Detection based on some state of the device rather than an expectation
based on what the device is running on seems preferable. I suspect
Andres' patch for amdgpu only affects newer devices, which pretty much
all suffer reset issues, at least under QEMU/VFIO, but I wonder how this
patch affects existing working devices, like 6, 7, and some 8-series.
Anyway, if this is the solution to the poor behavior we've seen with
assigned AMD cards, maybe someone could request the same for the closed
drivers, including Windows. Thanks,
Alex
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index e61c763..21c44b2 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -630,6 +630,23 @@ void radeon_gtt_location(struct radeon_device *rdev,
> struct radeon_mc *mc)
> /*
> * GPU helpers function.
> */
> +
> +/**
> + * radeon_device_is_virtual - check if we are running is a virtual
> environment
> + *
> + * Check if the asic has been passed through to a VM (all asics).
> + * Used at driver startup.
> + * Returns true if virtual or false if not.
> + */
> +static bool radeon_device_is_virtual(void)
> +{
> +#ifdef CONFIG_X86
> + return boot_cpu_has(X86_FEATURE_HYPERVISOR);
> +#else
> + return false;
> +#endif
> +}
> +
> /**
> * radeon_card_posted - check if the hw has already been initialized
> *
> @@ -643,6 +660,10 @@ bool radeon_card_posted(struct radeon_device *rdev)
> {
> uint32_t reg;
>
> + /* for pass through, always force asic_init */
> + if (radeon_device_is_virtual())
> + return false;
> +
> /* required for EFI mode on macbook2,1 which uses an r5xx asic */
> if (efi_enabled(EFI_BOOT) &&
> (rdev->pdev->subsystem_vendor == PCI_VENDOR_ID_APPLE) &&
[Bug 96360] [bisected: 3d02b7] VM fault with kernel 4.7-rc1 on Alien: Isolation
https://bugs.freedesktop.org/show_bug.cgi?id=96360 --- Comment #11 from Nicolai Hähnle --- Created attachment 124514 --> https://bugs.freedesktop.org/attachment.cgi?id=124514&action=edit preliminary patch Problem understood - we're generating bad shader code - though I still need to double-check all the possible corner cases. In the meantime, the attached patch for LLVM should fix Alien: Isolation. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/d94c4308/attachment.html>
