dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[v5 1/2] dt/bindings: display: Add optional property node define for Mali DP500
by Wen He 16 Oct '19

16 Oct '19

Add optional property node 'arm,malidp-arqos-value' for the Mali DP500. This property describe the ARQoS levels of DP500's QoS signaling. Signed-off-by: Wen He <wen.he_1(a)nxp.com> Reviewed-by: Rob Herring <robh(a)kernel.org> --- Documentation/devicetree/bindings/display/arm,malidp.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt b/Documentation/devicetree/bindings/display/arm,malidp.txt index 2f7870983ef1..7a97a2b48c2a 100644 --- a/Documentation/devicetree/bindings/display/arm,malidp.txt +++ b/Documentation/devicetree/bindings/display/arm,malidp.txt @@ -37,6 +37,8 @@ Optional properties: 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. + - arm,malidp-arqos-high-level: integer of u32 value describing the ARQoS + levels of DP500's QoS signaling. Example: @@ -54,6 +56,7 @@ Example: clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>; clock-names = "pxlclk", "mclk", "aclk", "pclk"; arm,malidp-output-port-lines = /bits/ 8 <8 8 8>; + arm,malidp-arqos-high-level = <0xd000d000>; port { dp0_output: endpoint { remote-endpoint = <&tda998x_2_input>; -- 2.17.1

3 4

[PATCH 1/2] drm/shmem: Add madvise state and purge helpers
by Rob Herring 16 Oct '19

16 Oct '19

Add support to the shmem GEM helpers for tracking madvise state and purging pages. This is based on the msm implementation. The BO provides a list_head, but the list management is handled outside of the shmem helpers as there are different locking requirements. Cc: Tomeu Vizoso <tomeu.vizoso(a)collabora.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <maxime.ripard(a)bootlin.com> Cc: Sean Paul <sean(a)poorly.run> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Eric Anholt <eric(a)anholt.net> Signed-off-by: Rob Herring <robh(a)kernel.org> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 57 ++++++++++++++++++++++++++ include/drm/drm_gem_shmem_helper.h | 15 +++++++ 2 files changed, 72 insertions(+) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 2f64667ac805..4b442576de1c 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -75,6 +75,7 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t shmem = to_drm_gem_shmem_obj(obj); mutex_init(&shmem->pages_lock); mutex_init(&shmem->vmap_lock); + INIT_LIST_HEAD(&shmem->madv_list); /* * Our buffers are kept pinned, so allocating them @@ -362,6 +363,62 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv, } EXPORT_SYMBOL(drm_gem_shmem_create_with_handle); +/* Update madvise status, returns true if not purged, else + * false or -errno. + */ +int drm_gem_shmem_madvise(struct drm_gem_object *obj, int madv) +{ + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); + + mutex_lock(&shmem->pages_lock); + + if (shmem->madv >= 0) + shmem->madv = madv; + + madv = shmem->madv; + + mutex_unlock(&shmem->pages_lock); + + return (madv >= 0); +} +EXPORT_SYMBOL(drm_gem_shmem_madvise); + +void drm_gem_shmem_purge_locked(struct drm_gem_object *obj) +{ + struct drm_device *dev = obj->dev; + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); + + WARN_ON(!drm_gem_shmem_is_purgeable(shmem)); + + drm_gem_shmem_put_pages_locked(shmem); + + shmem->madv = -1; + + drm_vma_node_unmap(&obj->vma_node, dev->anon_inode->i_mapping); + drm_gem_free_mmap_offset(obj); + + /* Our goal here is to return as much of the memory as + * is possible back to the system as we are called from OOM. + * To do this we must instruct the shmfs to drop all of its + * backing pages, *now*. + */ + shmem_truncate_range(file_inode(obj->filp), 0, (loff_t)-1); + + invalidate_mapping_pages(file_inode(obj->filp)->i_mapping, + 0, (loff_t)-1); +} +EXPORT_SYMBOL(drm_gem_shmem_purge_locked); + +void drm_gem_shmem_purge(struct drm_gem_object *obj) +{ + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); + + mutex_lock(&shmem->pages_lock); + drm_gem_shmem_purge_locked(obj); + mutex_unlock(&shmem->pages_lock); +} +EXPORT_SYMBOL(drm_gem_shmem_purge); + /** * drm_gem_shmem_dumb_create - Create a dumb shmem buffer object * @file: DRM file structure to create the dumb buffer for diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem_helper.h index 038b6d313447..ce1600fdfc3e 100644 --- a/include/drm/drm_gem_shmem_helper.h +++ b/include/drm/drm_gem_shmem_helper.h @@ -44,6 +44,9 @@ struct drm_gem_shmem_object { */ unsigned int pages_use_count; + int madv; + struct list_head madv_list; + /** * @pages_mark_dirty_on_put: * @@ -121,6 +124,18 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj); void *drm_gem_shmem_vmap(struct drm_gem_object *obj); void drm_gem_shmem_vunmap(struct drm_gem_object *obj, void *vaddr); +int drm_gem_shmem_madvise(struct drm_gem_object *obj, int madv); + +static inline bool drm_gem_shmem_is_purgeable(struct drm_gem_shmem_object *shmem) +{ + return (shmem->madv > 0) && + !shmem->vmap_use_count && shmem->sgt && + !shmem->base.dma_buf && !shmem->base.import_attach; +} + +void drm_gem_shmem_purge_locked(struct drm_gem_object *obj); +void drm_gem_shmem_purge(struct drm_gem_object *obj); + struct drm_gem_shmem_object * drm_gem_shmem_create_with_handle(struct drm_file *file_priv, struct drm_device *dev, size_t size, -- 2.20.1

5 8

[Bug 111599] [CI][RESUME] igt@gem_ctx_isolation@* - skip - Test requirement: !(gen > LAST_KNOWN_GEN), SKIP
by bugzilla-daemon＠freedesktop.org 16 Oct '19

16 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=111599 Bug ID: 111599 Summary: [CI][RESUME] igt@gem_ctx_isolation@* - skip - Test requirement: !(gen > LAST_KNOWN_GEN), SKIP Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: IGT Assignee: dri-devel(a)lists.freedesktop.org Reporter: martin.peres(a)free.fr https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_is… Test requirement not met in function __real_main808, file ../tests/i915/gem_ctx_isolation.c:827: Test requirement: !(gen > LAST_KNOWN_GEN) Subtest bcs0-dirty-switch: SKIP -- You are receiving this mail because: You are the assignee for the bug.

1 6

[RFC PATCH] drm/virtio: Export resource handles via DMA-buf API
by Tomasz Figa 16 Oct '19

16 Oct '19

This patch is an early RFC to judge the direction we are following in our virtualization efforts in Chrome OS. The purpose is to start a discussion on how to handle buffer sharing between multiple virtio devices. On a side note, we are also working on a virtio video decoder interface and implementation, with a V4L2 driver for Linux. Those will be posted for review in the near future as well. Any feedback will be appreciated! Thanks in advance. === With the range of use cases for virtualization expanding, there is going to be more virtio devices added to the ecosystem. Devices such as video decoders, encoders, cameras, etc. typically work together with the display and GPU in a pipeline manner, which can only be implemented efficiently by sharing the buffers between producers and consumers. Existing buffer management framework in Linux, such as the videobuf2 framework in V4L2, implements all the DMA-buf handling inside generic code and do not expose any low level information about the buffers to the drivers. To seamlessly enable buffer sharing with drivers using such frameworks, make the virtio-gpu driver expose the resource handle as the DMA address of the buffer returned from the DMA-buf mapping operation. Arguably, the resource handle is a kind of DMA address already, as it is the buffer identifier that the device needs to access the backing memory, which is exactly the same role a DMA address provides for native devices. A virtio driver that does memory management fully on its own would have code similar to following. The code is identical to what a regular driver for real hardware would do to import a DMA-buf. static int virtio_foo_get_resource_handle(struct virtio_foo *foo, struct dma_buf *dma_buf, u32 *id) { struct dma_buf_attachment *attach; struct sg_table *sgt; int ret = 0; attach = dma_buf_attach(dma_buf, foo->dev); if (IS_ERR(attach)) return PTR_ERR(attach); sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); if (IS_ERR(sgt)) { ret = PTR_ERR(sgt); goto err_detach; } if (sgt->nents != 1) { ret = -EINVAL; goto err_unmap; } *id = sg_dma_address(sgt->sgl); err_unmap: dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL); err_detach: dma_buf_detach(dma_buf, attach); return ret; } On the other hand, a virtio driver that uses an existing kernel framework to manage buffers would not need to explicitly handle anything at all, as the framework part responsible for importing DMA-bufs would already do the work. For example, a V4L2 driver using the videobuf2 framework would just call thee vb2_dma_contig_plane_dma_addr() function to get what the above open-coded function would return. Signed-off-by: Tomasz Figa <tfiga(a)chromium.org> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 2 + drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 81 ++++++++++++++++++++++++++ 3 files changed, 87 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index 0fc32fa0b3c0..ac095f813134 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -210,6 +210,8 @@ static struct drm_driver driver = { #endif .prime_handle_to_fd = drm_gem_prime_handle_to_fd, .prime_fd_to_handle = drm_gem_prime_fd_to_handle, + .gem_prime_export = virtgpu_gem_prime_export, + .gem_prime_import = virtgpu_gem_prime_import, .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table, .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table, .gem_prime_vmap = virtgpu_gem_prime_vmap, diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index e28829661724..687cfce91885 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -367,6 +367,10 @@ void virtio_gpu_object_free_sg_table(struct virtio_gpu_object *bo); int virtio_gpu_object_wait(struct virtio_gpu_object *bo, bool no_wait); /* virtgpu_prime.c */ +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags); +struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev, + struct dma_buf *buf); struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj); struct drm_gem_object *virtgpu_gem_prime_import_sg_table( struct drm_device *dev, struct dma_buf_attachment *attach, diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c b/drivers/gpu/drm/virtio/virtgpu_prime.c index dc642a884b88..562eb1a2ed5b 100644 --- a/drivers/gpu/drm/virtio/virtgpu_prime.c +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c @@ -22,6 +22,9 @@ * Authors: Andreas Pokorny */ +#include <linux/dma-buf.h> +#include <linux/dma-direction.h> + #include <drm/drm_prime.h> #include "virtgpu_drv.h" @@ -30,6 +33,84 @@ * device that might share buffers with virtgpu */ +static struct sg_table * +virtgpu_gem_map_dma_buf(struct dma_buf_attachment *attach, + enum dma_data_direction dir) +{ + struct drm_gem_object *obj = attach->dmabuf->priv; + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); + struct sg_table *sgt; + int ret; + + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); + if (!sgt) + return ERR_PTR(-ENOMEM); + + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); + if (ret) { + kfree(sgt); + return ERR_PTR(-ENOMEM); + } + + sg_dma_address(sgt->sgl) = bo->hw_res_handle; + sg_dma_len(sgt->sgl) = obj->size; + sgt->nents = 1; + + return sgt; +} + +static void virtgpu_gem_unmap_dma_buf(struct dma_buf_attachment *attach, + struct sg_table *sgt, + enum dma_data_direction dir) +{ + sg_free_table(sgt); + kfree(sgt); +} + +static const struct dma_buf_ops virtgpu_dmabuf_ops = { + .cache_sgt_mapping = true, + .attach = drm_gem_map_attach, + .detach = drm_gem_map_detach, + .map_dma_buf = virtgpu_gem_map_dma_buf, + .unmap_dma_buf = virtgpu_gem_unmap_dma_buf, + .release = drm_gem_dmabuf_release, + .mmap = drm_gem_dmabuf_mmap, + .vmap = drm_gem_dmabuf_vmap, + .vunmap = drm_gem_dmabuf_vunmap, +}; + +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, + int flags) +{ + struct dma_buf *buf; + + buf = drm_gem_prime_export(obj, flags); + if (!IS_ERR(buf)) + buf->ops = &virtgpu_dmabuf_ops; + + return buf; +} + +struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev, + struct dma_buf *buf) +{ + struct drm_gem_object *obj; + + if (buf->ops == &virtgpu_dmabuf_ops) { + obj = buf->priv; + if (obj->dev == dev) { + /* + * Importing dmabuf exported from our own gem increases + * refcount on gem itself instead of f_count of dmabuf. + */ + drm_gem_object_get(obj); + return obj; + } + } + + return drm_gem_prime_import(dev, buf); +} + struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj) { struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); -- 2.23.0.237.gc6a4ce50a0-goog

4 16

Re: imx6: hdmi black screen issue after resume
by Pintu Agarwal 16 Oct '19

16 Oct '19

Dear Philipp, Can you reply to my issue below? It will be of great help! Regards, Pintu On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal <pintu.ping(a)gmail.com> wrote: > > Dear Philipp, > > I have a iMX6dl custom board with custom Linux Kernel 4.8. > I have both LCD and HDMI connected to the board. > And we are using weston/wayland as the display interface. > In normal boot, both LCD and HDMI display is working fine. > > But, currently, for one of our customer, I am trying to explore and > support snapshot image booting on it. > Currently, we are able to resume the system without display. > Also, if we make the entire imx-drm as modules, and then install the > modules are resume, even LCD is also coming up. > But HDMI display is black out. > > After, resume, when I try to launch the weston, I noticed the following errors: > enabling vblank on crtc 0, ret: 0 > [PINTU]: drm_vblank_get: CALLED: vblank->refcount: 1 > ------------[ cut here ]------------ > WARNING: at drivers/gpu/drm/drm_atomic_helper.c:1121 > drm_atomic_helper_wait_for_vblanks+0x228/0x24c [drm_kms_helper]() > [CRTC:24] vblank wait timed out > ..... > [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* > [CRTC:24:crtc-0] flip_done timed out > > .... > [00:06:42.600] Warning: computed repaint delay is insane: -5069 msec > [00:06:42.665] unexpectedly large timestamp jump (from 397522 to 402648) > .... > > And, when I try to reboot the system, the system does not reboot. > And I get the following error: > /wayland # reboot > .... > [17:55:01.180] destroy output while page flip pending > ... > imx-ipuv3 2400000.ipu: DC stop timeout after 50 ms > > > ------------- > If you have any clue about this issue, please let me know. > > Any help will be really appreciated! > > > Thank You! > > Regards, > Pintu

1 3

[PATCH v9 0/8] drm/i915/dp: Support for DP HDR outputs
by Gwan-gyeong Mun 15 Oct '19

15 Oct '19

Support for HDR10 video was introduced in DisplayPort 1.4. On GLK+ platform, in order to use DisplayPort HDR10, we need to support BT.2020 colorimetry and HDR Static metadata. It implements the CTA-861-G standard for transport of static HDR metadata. It enables writing of HDR metadata infoframe SDP to the panel. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. And It refactors, renames and extends a function which handled vsc sdp header and data block setup for supporting colorimetry format. And It attaches the colorspace connector property and HDR metadata property to a DisplayPort connector. These patches tested on below test environment. Test Environment: - Tested System: GLK and Gen11 platform. - Monitor: Dell UP2718Q 4K HDR Monitor. - In order to test DP HDR10, test environment uses patched Kodi-gbm, patched Media driver and HDR10 video. You can find these on below. [patched Kodi-gbm] - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr [download 4K HDR video file] - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ [Media Driver for GLK] - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver master branch [Media Driver for ICL] - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite v2: - Add a missed blank line after function declaration. - Remove useless parentheses. - Minor style fix. v3: - Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] - Add handling of different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms [Uma] - Add new colorimetry options for DP 1.4a spec. [Ville] - Separate set of colorimetry enum values for DP. [Ville] - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.[Ville] - Remove a pointless variable. [Ville] v4: - Add additional comments to struct drm_prop_enum_list. - Polishing an enum string of struct drm_prop_enum_list. v5: - Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and DP abbreviations. - Add missed variables on dp_colorspaces. - Fix typo. [Uma] v6: - Addressed review comments from Ilia and Ville Split drm_mode_create_colorspace_property() to DP and HDMI connector. Becasue between HDMI and DP have different colorspaces, it renames drm_mode_create_colorspace_property() function to drm_mode_create_hdmi_colorspace_property() function for HDMI connector. And it adds drm_mode_create_dp_colorspace_property() function for creating of DP colorspace property. In order to apply changed and added drm api, i915 driver has channged. v7: - Fix typo [Jani Saarinen] - Fix white space. v8: - Addressed review comments from Ville Drop colorimetries which have another way to distinguish or which would not be used. v9: - Addressed review comments from Ville - Remove a duplicated output color space from intel_crtc_state. - In order to handle colorspace of drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp() - Split hunk into renaming and adding of code. - Add a handling of drm_mode_create_dp_colorspace_property() to intel_attach_colorspace_property(). - Add WARN_ON() when buffer size if larger than register size. - Add BUILD_BUG_ON to check a changing of struct dp_sdp size. - Change a passed size toward write_infoframe() for DP infoframe sdp packet for HDR static metadata. Gwan-gyeong Mun (8): drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA drm: Rename HDMI colorspace property creation function drm: Add DisplayPort colorspace property creation function drm/i915/dp: Attach colorspace property drm/i915: Add new GMP register size for GEN11 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata drm/i915/dp: Attach HDR metadata property to DP connector drivers/gpu/drm/drm_connector.c | 101 +++++++-- .../gpu/drm/i915/display/intel_connector.c | 21 +- drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- drivers/gpu/drm/i915/display/intel_ddi.h | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 1 - drivers/gpu/drm/i915/display/intel_display.h | 2 - drivers/gpu/drm/i915/display/intel_dp.c | 196 ++++++++++++++++-- drivers/gpu/drm/i915/display/intel_dp.h | 8 + drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- drivers/gpu/drm/i915/i915_reg.h | 1 + include/drm/drm_connector.h | 7 +- 11 files changed, 323 insertions(+), 46 deletions(-) -- 2.23.0

2 10

[PATCH] drm/komeda: Adds output-color format/depth support
by Lowry Li (Arm Technology China) 15 Oct '19

15 Oct '19

From: "Lowry Li (Arm Technology China)" <Lowry.Li(a)arm.com> Sets color_depth according to connector->bpc. Adds a new optional DT attribute "color-format" to represent a preferred color formats for a specific pipeline, and the select order is: YCRCB420 > YCRCB422 > YCRCB444 > RGB444 The color-format can be anyone of these 4 format, one color-format not only represent one format, but also include the lower formats, like color-format preferred_color_formats YCRCB420 YCRCB420 > YCRCB422 > YCRCB444 > RGB444 YCRCB422 YCRCB422 > YCRCB444 > RGB444 YCRCB444 YCRCB444 > RGB444 RGB444 RGB444 Then the final color_format is calculated by 3 steps: 1. calculate HW available formats. avail_formats = connector_color_formats & improc->color_formats; 2. filter out un-preferred format. avail_formats &= preferred_color_formats; 3. select the final format according to the preferred order. color_format = BIT(__fls(aval_formats)); Changes since v1: Rebased to the drm-misc-next branch. Signed-off-by: Lowry Li (Arm Technology China) <lowry.li(a)arm.com> --- .../arm/display/komeda/d71/d71_component.c | 15 ++++++++- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 27 ++++++++++++++++ .../gpu/drm/arm/display/komeda/komeda_dev.c | 32 ++++++++++++++++++- .../gpu/drm/arm/display/komeda/komeda_kms.h | 2 ++ .../drm/arm/display/komeda/komeda_pipeline.h | 3 ++ .../display/komeda/komeda_pipeline_state.c | 31 ++++++++++++++++++ .../arm/display/komeda/komeda_wb_connector.c | 5 +++ 7 files changed, 113 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c index c3d29c0b051b..7b374a3b911e 100644 --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c @@ -944,13 +944,26 @@ static void d71_improc_update(struct komeda_component *c, { struct komeda_improc_state *st = to_improc_st(state); u32 __iomem *reg = c->reg; - u32 index; + u32 index, mask = 0, ctrl = 0; for_each_changed_input(state, index) malidp_write32(reg, BLK_INPUT_ID0 + index * 4, to_d71_input_id(state, index)); malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize)); + malidp_write32(reg, IPS_DEPTH, st->color_depth); + + mask |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420; + + /* config color format */ + if (st->color_format == DRM_COLOR_FORMAT_YCRCB420) + ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420; + else if (st->color_format == DRM_COLOR_FORMAT_YCRCB422) + ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422; + else if (st->color_format == DRM_COLOR_FORMAT_YCRCB444) + ctrl |= IPS_CTRL_YUV; + + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl); } static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c index 624d257da20f..38d5cb20e908 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c @@ -18,6 +18,33 @@ #include "komeda_dev.h" #include "komeda_kms.h" +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st, + u32 *color_depths, u32 *color_formats) +{ + struct drm_connector *conn; + struct drm_connector_state *conn_st; + u32 conn_color_formats = ~0u; + int i, min_bpc = 31, conn_bpc = 0; + + for_each_new_connector_in_state(crtc_st->state, conn, conn_st, i) { + if (conn_st->crtc != crtc_st->crtc) + continue; + + conn_bpc = conn->display_info.bpc ? conn->display_info.bpc : 8; + conn_color_formats &= conn->display_info.color_formats; + + if (conn_bpc < min_bpc) + min_bpc = conn_bpc; + } + + /* connector doesn't config any color_format, use RGB444 as default */ + if (conn_color_formats == 0) + conn_color_formats = DRM_COLOR_FORMAT_RGB444; + + *color_depths = GENMASK(conn_bpc, 0); + *color_formats = conn_color_formats; +} + static void komeda_crtc_update_clock_ratio(struct komeda_crtc_state *kcrtc_st) { u64 pxlclk, aclk; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c index 9cbcd56e54cd..bee4633cdd9f 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c @@ -113,12 +113,34 @@ static struct attribute_group komeda_sysfs_attr_group = { .attrs = komeda_sysfs_entries, }; +static int to_color_format(const char *str) +{ + int format; + + if (!strncmp(str, "RGB444", 7)) { + format = DRM_COLOR_FORMAT_RGB444; + } else if (!strncmp(str, "YCRCB444", 9)) { + format = DRM_COLOR_FORMAT_YCRCB444; + } else if (!strncmp(str, "YCRCB422", 9)) { + format = DRM_COLOR_FORMAT_YCRCB422; + } else if (!strncmp(str, "YCRCB420", 9)) { + format = DRM_COLOR_FORMAT_YCRCB420; + } else { + DRM_WARN("invalid color_format: %s, please set it to RGB444, YCRCB444, YCRCB422 or YCRCB420\n", + str); + format = DRM_COLOR_FORMAT_RGB444; + } + + return format; +} + static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node *np) { struct komeda_pipeline *pipe; struct clk *clk; u32 pipe_id; - int ret = 0; + int ret = 0, color_format; + const char *str; ret = of_property_read_u32(np, "reg", &pipe_id); if (ret != 0 || pipe_id >= mdev->n_pipelines) @@ -133,6 +155,14 @@ static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node *np) } pipe->pxlclk = clk; + /* fetch DT configured color-format, if not set, use RGB444 */ + if (!of_property_read_string(np, "color-format", &str)) + color_format = to_color_format(str); + else + color_format = DRM_COLOR_FORMAT_RGB444; + + pipe->improc->preferred_color_formats = (color_format << 1) - 1; + /* enum ports */ pipe->of_output_links[0] = of_graph_get_remote_node(np, KOMEDA_OF_PORT_OUTPUT, 0); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h index 45c498e15e7a..456f3c435719 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h @@ -166,6 +166,8 @@ static inline bool has_flip_h(u32 rot) return !!(rotation & DRM_MODE_REFLECT_X); } +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st, + u32 *color_depths, u32 *color_formats); unsigned long komeda_crtc_get_aclk(struct komeda_crtc_state *kcrtc_st); int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms, struct komeda_dev *mdev); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h index a7a84e66549d..910d279ae48d 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h @@ -315,6 +315,8 @@ struct komeda_splitter_state { struct komeda_improc { struct komeda_component base; u32 supported_color_formats; /* DRM_RGB/YUV444/YUV420*/ + /* the preferred order is from MSB to LSB YUV420 --> RGB444 */ + u32 preferred_color_formats; u32 supported_color_depths; /* BIT(8) | BIT(10)*/ u8 supports_degamma : 1; u8 supports_csc : 1; @@ -323,6 +325,7 @@ struct komeda_improc { struct komeda_improc_state { struct komeda_component_state base; + u8 color_format, color_depth; u16 hsize, vsize; }; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c index ea26bc9c2d00..5526731f5a33 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c @@ -743,6 +743,7 @@ komeda_improc_validate(struct komeda_improc *improc, struct komeda_data_flow_cfg *dflow) { struct drm_crtc *crtc = kcrtc_st->base.crtc; + struct drm_crtc_state *crtc_st = &kcrtc_st->base; struct komeda_component_state *c_st; struct komeda_improc_state *st; @@ -756,6 +757,36 @@ komeda_improc_validate(struct komeda_improc *improc, st->hsize = dflow->in_w; st->vsize = dflow->in_h; + if (drm_atomic_crtc_needs_modeset(crtc_st)) { + u32 output_depths, output_formats; + u32 avail_depths, avail_formats; + + komeda_crtc_get_color_config(crtc_st, &output_depths, + &output_formats); + + avail_depths = output_depths & improc->supported_color_depths; + if (avail_depths == 0) { + DRM_DEBUG_ATOMIC("No available color depths, conn depths: 0x%x & display: 0x%x\n", + output_depths, + improc->supported_color_depths); + return -EINVAL; + } + + avail_formats = output_formats & + improc->supported_color_formats & + improc->preferred_color_formats; + if (avail_formats == 0) { + DRM_DEBUG_ATOMIC("No available color_formats, conn formats 0x%x & display: 0x%x & preferred: 0x%x\n", + output_formats, + improc->supported_color_formats, + improc->preferred_color_formats); + return -EINVAL; + } + + st->color_depth = __fls(avail_depths); + st->color_format = BIT(__fls(avail_formats)); + } + komeda_component_add_input(&st->base, &dflow->input, 0); komeda_component_set_output(&dflow->input, &improc->base, 0); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c index 617e1f7b8472..49e5469ba48e 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c @@ -142,6 +142,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, struct komeda_dev *mdev = kms->base.dev_private; struct komeda_wb_connector *kwb_conn; struct drm_writeback_connector *wb_conn; + struct drm_display_info *info; u32 *formats, n_formats = 0; int err; @@ -171,6 +172,10 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, drm_connector_helper_add(&wb_conn->base, &komeda_wb_conn_helper_funcs); + info = &kwb_conn->base.base.display_info; + info->bpc = __fls(kcrtc->master->improc->supported_color_depths); + info->color_formats = kcrtc->master->improc->supported_color_formats; + kcrtc->wb_conn = kwb_conn; return 0; -- 2.17.1

5 10

[Bug 110371] HP Dreamcolor display *Error* No EDID read
by bugzilla-daemon＠freedesktop.org 15 Oct '19

15 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=110371 Bug ID: 110371 Summary: HP Dreamcolor display *Error* No EDID read Product: DRI Version: unspecified Hardware: All OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: Babblebones(a)gmail.com My Tonga Firepro W7170M MXM GPU seems to have a bad reaction to kernels higher than Ubuntu's 4.18 on 18.10. I just tried a whole bunch of mainlines and Ubuntu 19.04 and nailed it down that any kernel higher than 4.18 is causing the GPU to no longer be able to get the EDID of my dreamcolor IPS display. Not sure how to best go about bisecting this... It uses a colorboard to convert what I can only assume to be horizontal signal and vertical signalling information to two separate channels of LVDS from a single eDP connector coming off the board. This results in the image shown on screen being completely unreadable with crazy scan wrapping from the channels getting mixed. May be related to: https://bugs.freedesktop.org/show_bug.cgi?id=108806 -- You are receiving this mail because: You are the assignee for the bug.

1 13

[PATCH v4 0/9 drm: rcar-du: Add Color Management Module (CMM)
by Jacopo Mondi 14 Oct '19

14 Oct '19

[ Ugh, sorry for the double sending, but I forgot --cc-cover to git-send email and the series has not been delivered to the mailing lists. Sorry about that. ] Hello, new iteration of CMM support, with quite a few changes compared to v3: References: A reference to the v1 cover letter, with some background on the CMM is available here: https://lkml.org/lkml/2019/6/6/583 v2: https://lore.kernel.org/linux-renesas-soc/20190706140746.29132-10-jacopo+re… v3: https://lore.kernel.org/linux-renesas-soc/20190825135154.11488-1-jacopo+ren… Change log: *Bindings/DT: - Rebased on renesas-devel-2019-09-03-v5.3-rc7 - Bindings converted to yaml: thanks Laurent for help - s/'cmms'/'renesas,cmms'/ in DU bindings as suggested by Rob - s/cmm-<soctype>/<soctype>-cmm/ as suggested by Geert - squashed CMM addition for Gen3 SoCs in a single path at the end of the series *CMM/DU: - Only accept fully populated LUT tables, remove the 'size' from the CMM configuration structure as suggested by Laurent - Simplify CMM configuration logic: only rely on color_mgmt_changed flag and unconditionally provide a populated LUT table to the cmm_setup() function - Protect against probing order inversion (DU is operation while CMM still has not been probed) by adding rcar_cmm_init() operation as it is done for VSP as suggested by Laurent - Add CMM function stubs to fix compilation erros when CONFIG_DRM_RCAR_CMM is not selected - Minors in the CMM driver as suggested by Laurent - Remove per-soc strings - Make comments style consistent (not using /** anywhere in the .c file, unify comment style) - s/rcar_cmm_load()/rcar_cmm_write()/ - Squash cmm configuration and suspend/resume support in rcar_du_kms.c Testing: I have tested by injecting a color inversion LUT table at test program initialization: https://jmondi.org/cgit/kmsxx/commit/?h=gamma_lut&id=3c6af4db165e5b3dc8996f… And by changing the CMM content to switch between a color inversion table and a linear table every 50 frames: https://jmondi.org/cgit/kmsxx/commit/?h=gamma_lut&id=fe178a43861da7c8e79618… Pretty happy with the result, which seems to be consistent across system suspend/resume. Testing with real world use cases might be beneficial. Rajesh are you still interested in giving this series a spin? Thanks j Jacopo Mondi (9): dt-bindings: display: renesas,cmm: Add R-Car CMM documentation dt-bindings: display, renesas,du: Document cmms property drm: rcar-du: Add support for CMM drm: rcar-du: Claim CMM support for Gen3 SoCs drm: rcar-du: kms: Initialize CMM instances drm: rcar-du: crtc: Enable and disable CMMs drm: rcar-du: crtc: Register GAMMA_LUT properties drm: rcar-du: kms: Update CMM in atomic commit tail arm64: dts: renesas: Add CMM units to Gen3 SoCs .../bindings/display/renesas,cmm.yaml | 64 +++++ .../bindings/display/renesas,du.txt | 5 + arch/arm64/boot/dts/renesas/r8a7795.dtsi | 40 ++- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 28 ++ arch/arm64/boot/dts/renesas/r8a77965.dtsi | 28 ++ arch/arm64/boot/dts/renesas/r8a77990.dtsi | 22 +- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 22 +- drivers/gpu/drm/rcar-du/Kconfig | 7 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_cmm.c | 251 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_cmm.h | 61 +++++ drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 17 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 32 ++- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 8 + drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 106 ++++++++ drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 + 19 files changed, 697 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- 2.23.0

7 37

[Bug 204725] New: black screen
by bugzilla-daemon＠bugzilla.kernel.org 14 Oct '19

14 Oct '19

https://bugzilla.kernel.org/show_bug.cgi?id=204725 Bug ID: 204725 Summary: black screen Product: Drivers Version: 2.5 Kernel Version: linux-5.3-rc6, linux-5.3-rc6 latest, Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: drjoms(a)gmail.com Regression: No Created attachment 284671 --> https://bugzilla.kernel.org/attachment.cgi?id=284671&action=edit black screen kernel 5.30 Hello, Hardware: Linux (none)dimko's Desktop 5.2.10 #1 SMP PREEMPT Tue Aug 27 22:48:11 IST 2019 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux 32 gigs of ram, nvme sdd. OS: Gentoo AMD 64 bit Soft: sys-devel/llvm Latest version available: 10.0.0.9999 media-libs/mesa Latest version available: 9999 * x11-base/xorg-server Latest version available: 1.20.5 x11-drivers/xf86-input-evdev-2.10.6 x11-drivers/xf86-input-libinput-0.28.2 x11-drivers/xf86-video-amdgpu-19.0.1 x11-drivers/xf86-video-vesa-2.4.0 all drivers are compiled/installed after mesa/xorg installation, so no linkage problem can occur. problem: Under linux-5.3-rc6 I get completely black screen. output of 'startx -- :0' is not indicative of problem. As far as I am concerned, silent failure with complete failure of output system, hence high priority. See dmesg please for more info. md5sum /lib/firmware/amdgpu/navi10_* d80e7585b046f9da0edfdf5c4840030c /lib/firmware/amdgpu/navi10_asd.bin 3f52075a7db731365236d3050aa23d9e /lib/firmware/amdgpu/navi10_ce.bin d99c5124e5560153768a71cec8a4726e /lib/firmware/amdgpu/navi10_gpu_info.bin 98ddcd564bddf7ed6045afff4abf6704 /lib/firmware/amdgpu/navi10_me.bin c9cd7f8cdd97c18f3068887f1877e2a6 /lib/firmware/amdgpu/navi10_mec2.bin c9cd7f8cdd97c18f3068887f1877e2a6 /lib/firmware/amdgpu/navi10_mec.bin 2dd1563ba76158c98d9409eb94daab2e /lib/firmware/amdgpu/navi10_pfp.bin 39a53ba9e86b52fa6be045932bb0b12f /lib/firmware/amdgpu/navi10_rlc.bin a4b33f7ad896e7b876dcb224f02faf4c /lib/firmware/amdgpu/navi10_sdma1.bin a4b33f7ad896e7b876dcb224f02faf4c /lib/firmware/amdgpu/navi10_sdma.bin 26f69a4d53d4511c4587ce3713a70d99 /lib/firmware/amdgpu/navi10_smc.bin 0273f9cd89f85d58942e1a57be143077 /lib/firmware/amdgpu/navi10_sos.bin b0f5b346a394d9ec4027ef01ba3853c7 /lib/firmware/amdgpu/navi10_vcn.bin firmware is loaded into kernel at time of compilation. usual compilation set done: make -j12 make modules (this one seems redundant) make modules_install make install grub-mkconfig -o /boot/grub/grub.cfg after that /usr/src/linux is checked for link to current version of kernel. additional notes. machine IS responsive after start, just not the screen. Brand new video card. works in kernel 5.2.10 in VESA mode power cable checked motherboard bios updated literally today till latest version as far as I know no proprietary drivers loaded. Module Size Used by bridge 147456 0 stp 16384 1 bridge llc 16384 2 bridge,stp tun 53248 4 uvcvideo 106496 0 videobuf2_vmalloc 16384 1 uvcvideo kvm_amd 90112 4 videobuf2_memops 16384 1 videobuf2_vmalloc videobuf2_v4l2 24576 1 uvcvideo joydev 24576 0 mousedev 24576 0 kvm 651264 1 kvm_amd videodev 184320 2 videobuf2_v4l2,uvcvideo snd_virtuoso 49152 2 irqbypass 16384 5 kvm snd_usb_audio 208896 0 videobuf2_common 49152 2 videobuf2_v4l2,uvcvideo snd_oxygen_lib 49152 1 snd_virtuoso snd_hwdep 16384 1 snd_usb_audio snd_usbmidi_lib 28672 1 snd_usb_audio snd_mpu401_uart 16384 1 snd_oxygen_lib snd_rawmidi 32768 2 snd_usbmidi_lib,snd_mpu401_uart i2c_piix4 24576 0 sr_mod 28672 0 cdrom 36864 1 sr_mod acpi_cpufreq 20480 0 k10temp 16384 0 Possibly some proprietary firmware is loaded in. At least firmware from above, for AMDGPU itself. -- You are receiving this mail because: You are watching the assignee of the bug.

1 58

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019