dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[PATCH AUTOSEL 4.9 01/19] drm/bridge: tc358767: Increase AUX transfer length limit
by Sasha Levin 24 Sep '19

24 Sep '19

From: Andrey Smirnov <andrew.smirnov(a)gmail.com> [ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ] According to the datasheet tc358767 can transfer up to 16 bytes via its AUX channel, so the artificial limit of 8 appears to be too low. However only up to 15-bytes seem to be actually supported and trying to use 16-byte transfers results in transfers failing sporadically (with bogus status in case of I2C transfers), so limit it to 15. Signed-off-by: Andrey Smirnov <andrew.smirnov(a)gmail.com> Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Cory Tusar <cory.tusar(a)zii.aero> Cc: Chris Healy <cphealy(a)gmail.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-9-andrew… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 80993a8734e08..8b6f8fac92e89 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -300,7 +300,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) { struct tc_data *tc = aux_to_tc(aux); - size_t size = min_t(size_t, 8, msg->size); + size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); u8 request = msg->request & ~DP_AUX_I2C_MOT; u8 *buf = msg->buffer; u32 tmp = 0; -- 2.20.1

1 5

[PATCH AUTOSEL 4.14 01/28] drm/bridge: tc358767: Increase AUX transfer length limit
by Sasha Levin 24 Sep '19

24 Sep '19

From: Andrey Smirnov <andrew.smirnov(a)gmail.com> [ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ] According to the datasheet tc358767 can transfer up to 16 bytes via its AUX channel, so the artificial limit of 8 appears to be too low. However only up to 15-bytes seem to be actually supported and trying to use 16-byte transfers results in transfers failing sporadically (with bogus status in case of I2C transfers), so limit it to 15. Signed-off-by: Andrey Smirnov <andrew.smirnov(a)gmail.com> Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Cory Tusar <cory.tusar(a)zii.aero> Cc: Chris Healy <cphealy(a)gmail.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-9-andrew… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 9705ca197b90d..cefa2c1685ba4 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -300,7 +300,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) { struct tc_data *tc = aux_to_tc(aux); - size_t size = min_t(size_t, 8, msg->size); + size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); u8 request = msg->request & ~DP_AUX_I2C_MOT; u8 *buf = msg->buffer; u32 tmp = 0; -- 2.20.1

1 10

[PATCH AUTOSEL 4.19 01/50] drm/bridge: tc358767: Increase AUX transfer length limit
by Sasha Levin 24 Sep '19

24 Sep '19

From: Andrey Smirnov <andrew.smirnov(a)gmail.com> [ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ] According to the datasheet tc358767 can transfer up to 16 bytes via its AUX channel, so the artificial limit of 8 appears to be too low. However only up to 15-bytes seem to be actually supported and trying to use 16-byte transfers results in transfers failing sporadically (with bogus status in case of I2C transfers), so limit it to 15. Signed-off-by: Andrey Smirnov <andrew.smirnov(a)gmail.com> Reviewed-by: Andrzej Hajda <a.hajda(a)samsung.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Cory Tusar <cory.tusar(a)zii.aero> Cc: Chris Healy <cphealy(a)gmail.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-9-andrew… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/tc358767.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index aaca5248da070..d728b6cf61096 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -302,7 +302,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) { struct tc_data *tc = aux_to_tc(aux); - size_t size = min_t(size_t, 8, msg->size); + size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size); u8 request = msg->request & ~DP_AUX_I2C_MOT; u8 *buf = msg->buffer; u32 tmp = 0; -- 2.20.1

1 16

[PATCH AUTOSEL 5.2 01/70] drm/vkms: Fix crc worker races
by Sasha Levin 24 Sep '19

24 Sep '19

From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit 18d0952a838ba559655b0cd9cf85097ad63d9bca ] The issue we have is that the crc worker might fall behind. We've tried to handle this by tracking both the earliest frame for which it still needs to compute a crc, and the last one. Plus when the crtc_state changes, we have a new work item, which are all run in order due to the ordered workqueue we allocate for each vkms crtc. Trouble is there's been a few small issues in the current code: - we need to capture frame_end in the vblank hrtimer, not in the worker. The worker might run much later, and then we generate a lot of crc for which there's already a different worker queued up. - frame number might be 0, so create a new crc_pending boolean to track this without confusion. - we need to atomically grab frame_start/end and clear it, so do that all in one go. This is not going to create a new race, because if we race with the hrtimer then our work will be re-run. - only race that can happen is the following: 1. worker starts 2. hrtimer runs and updates frame_end 3. worker grabs frame_start/end, already reading the new frame_end, and clears crc_pending 4. hrtimer calls queue_work() 5. worker completes 6. worker gets re-run, crc_pending is false Explain this case a bit better by rewording the comment. v2: Demote warning level output to debug when we fail to requeue, this is expected under high load when the crc worker can't quite keep up. Cc: Shayenne Moura <shayenneluzmoura(a)gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Cc: Haneen Mohammed <hamohammed.sa(a)gmail.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606222751.32567-2-daniel… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/vkms/vkms_crc.c | 27 +++++++++++++-------------- drivers/gpu/drm/vkms/vkms_crtc.c | 9 +++++++-- drivers/gpu/drm/vkms/vkms_drv.h | 2 ++ 3 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c index d7b409a3c0f8c..66603da634fe3 100644 --- a/drivers/gpu/drm/vkms/vkms_crc.c +++ b/drivers/gpu/drm/vkms/vkms_crc.c @@ -166,16 +166,24 @@ void vkms_crc_work_handle(struct work_struct *work) struct drm_plane *plane; u32 crc32 = 0; u64 frame_start, frame_end; + bool crc_pending; unsigned long flags; spin_lock_irqsave(&out->state_lock, flags); frame_start = crtc_state->frame_start; frame_end = crtc_state->frame_end; + crc_pending = crtc_state->crc_pending; + crtc_state->frame_start = 0; + crtc_state->frame_end = 0; + crtc_state->crc_pending = false; spin_unlock_irqrestore(&out->state_lock, flags); - /* _vblank_handle() hasn't updated frame_start yet */ - if (!frame_start || frame_start == frame_end) - goto out; + /* + * We raced with the vblank hrtimer and previous work already computed + * the crc, nothing to do. + */ + if (!crc_pending) + return; drm_for_each_plane(plane, &vdev->drm) { struct vkms_plane_state *vplane_state; @@ -196,20 +204,11 @@ void vkms_crc_work_handle(struct work_struct *work) if (primary_crc) crc32 = _vkms_get_crc(primary_crc, cursor_crc); - frame_end = drm_crtc_accurate_vblank_count(crtc); - - /* queue_work can fail to schedule crc_work; add crc for - * missing frames + /* + * The worker can fall behind the vblank hrtimer, make sure we catch up. */ while (frame_start <= frame_end) drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32); - -out: - /* to avoid using the same value for frame number again */ - spin_lock_irqsave(&out->state_lock, flags); - crtc_state->frame_end = frame_end; - crtc_state->frame_start = 0; - spin_unlock_irqrestore(&out->state_lock, flags); } static int vkms_crc_parse_source(const char *src_name, bool *enabled) diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c index e447b7588d06e..77a1f5fa5d5c8 100644 --- a/drivers/gpu/drm/vkms/vkms_crtc.c +++ b/drivers/gpu/drm/vkms/vkms_crtc.c @@ -30,13 +30,18 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer) * has read the data */ spin_lock(&output->state_lock); - if (!state->frame_start) + if (!state->crc_pending) state->frame_start = frame; + else + DRM_DEBUG_DRIVER("crc worker falling behind, frame_start: %llu, frame_end: %llu\n", + state->frame_start, frame); + state->frame_end = frame; + state->crc_pending = true; spin_unlock(&output->state_lock); ret = queue_work(output->crc_workq, &state->crc_work); if (!ret) - DRM_WARN("failed to queue vkms_crc_work_handle"); + DRM_DEBUG_DRIVER("vkms_crc_work_handle already queued\n"); } spin_unlock(&output->lock); diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h index 81f1cfbeb9362..3c7e06b19efd5 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.h +++ b/drivers/gpu/drm/vkms/vkms_drv.h @@ -56,6 +56,8 @@ struct vkms_plane_state { struct vkms_crtc_state { struct drm_crtc_state base; struct work_struct crc_work; + + bool crc_pending; u64 frame_start; u64 frame_end; }; -- 2.20.1

1 24

[PATCH AUTOSEL 5.3 01/87] drm/vkms: Fix crc worker races
by Sasha Levin 24 Sep '19

24 Sep '19

From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit 18d0952a838ba559655b0cd9cf85097ad63d9bca ] The issue we have is that the crc worker might fall behind. We've tried to handle this by tracking both the earliest frame for which it still needs to compute a crc, and the last one. Plus when the crtc_state changes, we have a new work item, which are all run in order due to the ordered workqueue we allocate for each vkms crtc. Trouble is there's been a few small issues in the current code: - we need to capture frame_end in the vblank hrtimer, not in the worker. The worker might run much later, and then we generate a lot of crc for which there's already a different worker queued up. - frame number might be 0, so create a new crc_pending boolean to track this without confusion. - we need to atomically grab frame_start/end and clear it, so do that all in one go. This is not going to create a new race, because if we race with the hrtimer then our work will be re-run. - only race that can happen is the following: 1. worker starts 2. hrtimer runs and updates frame_end 3. worker grabs frame_start/end, already reading the new frame_end, and clears crc_pending 4. hrtimer calls queue_work() 5. worker completes 6. worker gets re-run, crc_pending is false Explain this case a bit better by rewording the comment. v2: Demote warning level output to debug when we fail to requeue, this is expected under high load when the crc worker can't quite keep up. Cc: Shayenne Moura <shayenneluzmoura(a)gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Cc: Haneen Mohammed <hamohammed.sa(a)gmail.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo(a)gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606222751.32567-2-daniel… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/vkms/vkms_crc.c | 27 +++++++++++++-------------- drivers/gpu/drm/vkms/vkms_crtc.c | 9 +++++++-- drivers/gpu/drm/vkms/vkms_drv.h | 2 ++ 3 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c index e66ff25c008e6..e9fb4ebb789fd 100644 --- a/drivers/gpu/drm/vkms/vkms_crc.c +++ b/drivers/gpu/drm/vkms/vkms_crc.c @@ -166,16 +166,24 @@ void vkms_crc_work_handle(struct work_struct *work) struct drm_plane *plane; u32 crc32 = 0; u64 frame_start, frame_end; + bool crc_pending; unsigned long flags; spin_lock_irqsave(&out->state_lock, flags); frame_start = crtc_state->frame_start; frame_end = crtc_state->frame_end; + crc_pending = crtc_state->crc_pending; + crtc_state->frame_start = 0; + crtc_state->frame_end = 0; + crtc_state->crc_pending = false; spin_unlock_irqrestore(&out->state_lock, flags); - /* _vblank_handle() hasn't updated frame_start yet */ - if (!frame_start || frame_start == frame_end) - goto out; + /* + * We raced with the vblank hrtimer and previous work already computed + * the crc, nothing to do. + */ + if (!crc_pending) + return; drm_for_each_plane(plane, &vdev->drm) { struct vkms_plane_state *vplane_state; @@ -196,20 +204,11 @@ void vkms_crc_work_handle(struct work_struct *work) if (primary_crc) crc32 = _vkms_get_crc(primary_crc, cursor_crc); - frame_end = drm_crtc_accurate_vblank_count(crtc); - - /* queue_work can fail to schedule crc_work; add crc for - * missing frames + /* + * The worker can fall behind the vblank hrtimer, make sure we catch up. */ while (frame_start <= frame_end) drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32); - -out: - /* to avoid using the same value for frame number again */ - spin_lock_irqsave(&out->state_lock, flags); - crtc_state->frame_end = frame_end; - crtc_state->frame_start = 0; - spin_unlock_irqrestore(&out->state_lock, flags); } static const char * const pipe_crc_sources[] = {"auto"}; diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c index 4d11292bc6f38..f392fa13015b8 100644 --- a/drivers/gpu/drm/vkms/vkms_crtc.c +++ b/drivers/gpu/drm/vkms/vkms_crtc.c @@ -30,13 +30,18 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer) * has read the data */ spin_lock(&output->state_lock); - if (!state->frame_start) + if (!state->crc_pending) state->frame_start = frame; + else + DRM_DEBUG_DRIVER("crc worker falling behind, frame_start: %llu, frame_end: %llu\n", + state->frame_start, frame); + state->frame_end = frame; + state->crc_pending = true; spin_unlock(&output->state_lock); ret = queue_work(output->crc_workq, &state->crc_work); if (!ret) - DRM_WARN("failed to queue vkms_crc_work_handle"); + DRM_DEBUG_DRIVER("vkms_crc_work_handle already queued\n"); } spin_unlock(&output->lock); diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h index b92c30c66a6f2..2b37eb1062d34 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.h +++ b/drivers/gpu/drm/vkms/vkms_drv.h @@ -48,6 +48,8 @@ struct vkms_plane_state { struct vkms_crtc_state { struct drm_crtc_state base; struct work_struct crc_work; + + bool crc_pending; u64 frame_start; u64 frame_end; }; -- 2.20.1

1 36

[PATCH v2] dt-bindings: gpu: Convert Samsung 2D Graphics Accelerator to dt-schema
by Marek Szyprowski 24 Sep '19

24 Sep '19

From: Maciej Falkowski <m.falkowski(a)samsung.com> Convert Samsung 2D Graphics Accelerator to newer dt-schema format Signed-off-by: Maciej Falkowski <m.falkowski(a)samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- v2: - Added if-then statements for 'clocks' and 'clock-names' properties. Best regards, Maciej Falkowski --- .../devicetree/bindings/gpu/samsung-g2d.txt | 27 ------- .../devicetree/bindings/gpu/samsung-g2d.yaml | 76 +++++++++++++++++++ 2 files changed, 76 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.txt create mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.yaml diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt deleted file mode 100644 index 1e7959332dbc..000000000000 --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Samsung 2D Graphics Accelerator - -Required properties: - - compatible : value should be one among the following: - (a) "samsung,s5pv210-g2d" for G2D IP present in S5PV210 & Exynos4210 SoC - (b) "samsung,exynos4212-g2d" for G2D IP present in Exynos4x12 SoCs - (c) "samsung,exynos5250-g2d" for G2D IP present in Exynos5250 SoC - - - reg : Physical base address of the IP registers and length of memory - mapped region. - - - interrupts : G2D interrupt number to the CPU. - - clocks : from common clock binding: handle to G2D clocks. - - clock-names : names of clocks listed in clocks property, in the same - order, depending on SoC type: - - for S5PV210 and Exynos4 based SoCs: "fimg2d" and - "sclk_fimg2d" - - for Exynos5250 SoC: "fimg2d". - -Example: - g2d@12800000 { - compatible = "samsung,s5pv210-g2d"; - reg = <0x12800000 0x1000>; - interrupts = <0 89 0>; - clocks = <&clock 177>, <&clock 277>; - clock-names = "sclk_fimg2d", "fimg2d"; - }; diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml b/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml new file mode 100644 index 000000000000..5e05e8ccc83f --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/samsung-g2d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SoC 2D Graphics Accelerator + +maintainers: + - Inki Dae <inki.dae(a)samsung.com> + +properties: + compatible: + enum: + - samsung,s5pv210-g2d # in S5PV210 & Exynos4210 SoC + - samsung,exynos4212-g2d # in Exynos4x12 SoCs + - samsung,exynos5250-g2d + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos5250-g2d + + then: + properties: + clocks: + items: + - description: fimg2d clock + clock-names: + items: + - const: fimg2d + + - if: + properties: + compatible: + contains: + enum: + - samsung,s5pv210-g2d + - samsung,exynos4212-g2d + + then: + properties: + clocks: + items: + - description: sclk_fimg2d clock + - description: fimg2d clock + clock-names: + items: + - const: sclk_fimg2d + - const: fimg2d + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +examples: + - | + g2d@12800000 { + compatible = "samsung,s5pv210-g2d"; + reg = <0x12800000 0x1000>; + interrupts = <0 89 0>; + clocks = <&clock 177>, <&clock 277>; + clock-names = "sclk_fimg2d", "fimg2d"; + }; + -- 2.17.1

2 1

[Bug 105651] Vega64 doesn't output properly onto dell up2715k at 5120x2880
by bugzilla-daemon＠freedesktop.org 24 Sep '19

24 Sep '19

https://bugs.freedesktop.org/show_bug.cgi?id=105651 Bug ID: 105651 Summary: Vega64 doesn't output properly onto dell up2715k at 5120x2880 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: spgle212(a)gmail.com I have tested 4.16 and drm-next-4.17 both under wayland and xorg. All only show the monitor as 2 displays with 2560x2880 side by side. (I previously had an nvidia gpu using their binary blob on this display without issue) -- You are receiving this mail because: You are the assignee for the bug.

1 14

TTM huge page-faults WAS: Re: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit
by Thomas Hellström (VMware) 24 Sep '19

24 Sep '19

removing people that are probably not interested from CC adding dri-devel On 9/11/19 11:08 AM, Koenig, Christian wrote: > Am 10.09.19 um 21:26 schrieb Thomas Hellström (VMware): >> On 9/10/19 6:11 PM, Andy Lutomirski wrote: >>>> On Sep 5, 2019, at 8:24 AM, Christoph Hellwig <hch(a)infradead.org> >>>> wrote: >>>> >>>>> On Thu, Sep 05, 2019 at 05:21:24PM +0200, Thomas Hellström (VMware) >>>>> wrote: >>>>>> On 9/5/19 4:15 PM, Dave Hansen wrote: >>>>>> Hi Thomas, >>>>>> >>>>>> Thanks for the second batch of patches! These look much improved >>>>>> on all >>>>>> fronts. >>>>> Yes, although the TTM functionality isn't in yet. Hopefully we >>>>> won't have to >>>>> bother you with those though, since this assumes TTM will be using >>>>> the dma >>>>> API. >>>> Please take a look at dma_mmap_prepare and dma_mmap_fault in this >>>> branch: >>>> >>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-mmap-im… >>>> >>>> they should allow to fault dma api pages in the page fault handler. >>>> But >>>> this is totally hot off the press and not actually tested for the last >>>> few patches. Note that I've also included your two patches from this >>>> series to handle SEV. >>> I read that patch, and it seems like you’ve built in the assumption >>> that all pages in the mapping use identical protection or, if not, >>> that the same fake vma hack that TTM already has is used to fudge >>> around it. Could it be reworked slightly to avoid this? >>> >>> I wonder if it’s a mistake to put the encryption bits in vm_page_prot >>> at all. >> From my POW, the encryption bits behave quite similar in behaviour to >> the caching mode bits, and they're also in vm_page_prot. They're the >> reason TTM needs to modify the page protection in the fault handler in >> the first place. >> >> The problem seen in TTM is that we want to be able to change the >> vm_page_prot from the fault handler, but it's problematic since we >> have the mmap_sem typically only in read mode. Hence the fake vma >> hack. From what I can tell it's reasonably well-behaved, since >> pte_modify() skips the bits TTM updates, so mprotect() and mremap() >> works OK. I think split_huge_pmd may run into trouble, but we don't >> support it (yet) with TTM. > Ah! I actually ran into this while implementing huge page support for > TTM and never figured out why that doesn't work. Dropped CPU huge page > support because of this. By incident, I got slightly sidetracked the other day and started looking at this as well. Got to the point where I figured out all the hairy alignment issues and actually got huge_fault() calls, but never implemented the handler. I think that's definitely something worth having. Not sure it will work for IO memory, though, (split_huge_pmd will just skip non-page-backed memory) but if we only support VM_SHARED (non COW) vmas there's no reason to split the huge pmds anyway. Definitely something we should have IMO. >> We could probably get away with a WRITE_ONCE() update of the >> vm_page_prot before taking the page table lock since >> >> a) We're locking out all other writers. >> b) We can't race with another fault to the same vma since we hold an >> address space lock ("buffer object reservation") >> c) When we need to update there are no valid page table entries in the >> vma, since it only happens directly after mmap(), or after an >> unmap_mapping_range() with the same address space lock. When another >> reader (for example split_huge_pmd()) sees a valid page table entry, >> it also sees the new page protection and things are fine. > Yeah, that's exactly why I always wondered why we need this hack with > the vma copy on the stack. > >> But that would really be a special case. To solve this properly we'd >> probably need an additional lock to protect the vm_flags and >> vm_page_prot, taken after mmap_sem and i_mmap_lock. > Well we already have a special lock for this: The reservation object. So > memory barriers etc should be in place and I also think we can just > update the vm_page_prot on the fly. I agree. This is needed for huge pages. We should make this change, and perhaps add the justification above as a comment. /Thomas > Christian. > >> /Thomas >> >> >> >>

2 3

[PATCH 00/14] drm/amdgpu: introduce secure buffer object support (trusted memory zone)
by Huang, Ray 24 Sep '19

24 Sep '19

Hi all, These series of patches introduce a feature to support secure buffer object. The Trusted Memory Zone (TMZ) is a method to protect the contents being written to and read from memory. We use TMZ hardware memory protection scheme to implement the secure buffer object support. TMZ is the page-level protection that hardware will detect the TMZ bit in the page table entry to set the current page is encrypted. With this hardware feature, we design a BO-level protection in kernel driver to provide a new flag AMDGPU_GEM_CREATE_ENCRYPTED to gem create ioctl to libdrm for the secure buffer allocation. And also provide the AMDGPU_CTX_ALLOC_FLAGS_SECURE to indicate the context is trusted or not. If the BO is secure, then the data is encrypted, only the trusted IP blocks such as gfx, sdma, vcn are able to decrypt. CPU as the un-trusted IP are unable to read the secure buffer. We will submit the new secure context interface later for libdrm, and create a new test suite to verify the security feature in the libdrm unit tests. Suite id = 11: Name 'Security Tests status: ENABLED' Test id 1: Name: 'allocate secure buffer test status: ENABLED' Test id 2: Name: 'graphics command submission under secure context status: ENABLED' Thanks, Ray Alex Deucher (4): drm/amdgpu: add UAPI for creating encrypted buffers drm/amdgpu: add UAPI for creating secure contexts (v2) drm/amdgpu: define the TMZ bit for the PTE drm/amdgpu: set TMZ bits in PTEs for secure bo (v2) Huang Rui (10): drm/amdgpu: add tmz feature parameter (v2) drm/amdgpu: add amdgpu_tmz data structure drm/amdgpu: add function to check tmz capability (v4) drm/ttm: add helper to get buffer object with ttm_mem_reg drm/amdgpu: revise the function to allocate secure context (v2) drm/amdgpu: add tmz bit in frame control packet drm/amdgpu: expand the emit tmz interface with trusted flag drm/amdgpu: expand the context control interface with trust flag drm/amdgpu: set trusted mode while the job is under secure context (v2) drm/amdgpu: modify the method to use mem under buffer object for amdgpu_ttm_tt_pte_flags drivers/gpu/drm/amd/amdgpu/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 ++++- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 19 +++++++++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 12 +++++++- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 10 ++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 9 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_tmz.c | 49 ++++++++++++++++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_tmz.h | 39 ++++++++++++++++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 +++++++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ++ drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 20 +++++++++--- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 3 +- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 3 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 16 +++++++--- drivers/gpu/drm/amd/amdgpu/nvd.h | 1 + drivers/gpu/drm/amd/amdgpu/soc15d.h | 1 + include/drm/ttm/ttm_bo_driver.h | 13 ++++++++ include/uapi/drm/amdgpu_drm.h | 9 +++++- 25 files changed, 230 insertions(+), 34 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_tmz.c create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_tmz.h -- 2.7.4

2 20

[PATCH] dt-bindings: gpu: Convert Samsung 2D Graphics Accelerator to dt-schema
by Marek Szyprowski 24 Sep '19

24 Sep '19

From: Maciej Falkowski <m.falkowski(a)samsung.com> Convert Samsung 2D Graphics Accelerator to newer dt-schema format Signed-off-by: Maciej Falkowski <m.falkowski(a)samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- .../devicetree/bindings/gpu/samsung-g2d.txt | 27 ---------- .../devicetree/bindings/gpu/samsung-g2d.yaml | 53 +++++++++++++++++++ 2 files changed, 53 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.txt create mode 100644 Documentation/devicetree/bindings/gpu/samsung-g2d.yaml diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt deleted file mode 100644 index 1e7959332dbc..000000000000 --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Samsung 2D Graphics Accelerator - -Required properties: - - compatible : value should be one among the following: - (a) "samsung,s5pv210-g2d" for G2D IP present in S5PV210 & Exynos4210 SoC - (b) "samsung,exynos4212-g2d" for G2D IP present in Exynos4x12 SoCs - (c) "samsung,exynos5250-g2d" for G2D IP present in Exynos5250 SoC - - - reg : Physical base address of the IP registers and length of memory - mapped region. - - - interrupts : G2D interrupt number to the CPU. - - clocks : from common clock binding: handle to G2D clocks. - - clock-names : names of clocks listed in clocks property, in the same - order, depending on SoC type: - - for S5PV210 and Exynos4 based SoCs: "fimg2d" and - "sclk_fimg2d" - - for Exynos5250 SoC: "fimg2d". - -Example: - g2d@12800000 { - compatible = "samsung,s5pv210-g2d"; - reg = <0x12800000 0x1000>; - interrupts = <0 89 0>; - clocks = <&clock 177>, <&clock 277>; - clock-names = "sclk_fimg2d", "fimg2d"; - }; diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml b/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml new file mode 100644 index 000000000000..bb0a4bf168cc --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpu/samsung-g2d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SoC 2D Graphics Accelerator + +maintainers: + - Inki Dae <inki.dae(a)samsung.com> + +properties: + compatible: + enum: + - samsung,s5pv210-g2d # in S5PV210 & Exynos4210 SoC + - samsung,exynos4212-g2d # in Exynos4x12 SoCs + - samsung,exynos5250-g2d + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: # for Exynos5250 SoC + - const: fimg2d + - items: # for S5PV210 and Exynos4 based SoCs + - const: sclk_fimg2d + - const: fimg2d + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +examples: + - | + g2d@12800000 { + compatible = "samsung,s5pv210-g2d"; + reg = <0x12800000 0x1000>; + interrupts = <0 89 0>; + clocks = <&clock 177>, <&clock 277>; + clock-names = "sclk_fimg2d", "fimg2d"; + }; + -- 2.17.1

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019