dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH 0/3] drm/omap: add crtc properties
by Neil Armstrong 21 Sep '21

21 Sep '21

This patchset adds the following CRTC properties: - background color - transparency keying property - alpha blender on DSS3 Tomi Valkeinen (3): drm/omap: add crtc background property drm/omap: add crtc transparency key property drm/omap: add alpha blender property drivers/gpu/drm/omapdrm/dss/dispc.c | 4 +- drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 85 ++++++++++++++++++++++++++- drivers/gpu/drm/omapdrm/omap_drv.c | 30 ++++++++++ drivers/gpu/drm/omapdrm/omap_drv.h | 6 ++ 5 files changed, 121 insertions(+), 6 deletions(-) -- 2.25.1

2 5

[PATCH v2] drm/i915/request: fix early tracepoints
by Matthew Auld 21 Sep '21

21 Sep '21

Currently we blow up in trace_dma_fence_init, when calling into get_driver_name or get_timeline_name, since both the engine and context might be NULL(or contain some garbage address) in the case of newly allocated slab objects via the request ctor. Note that we also use SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately freed, but delay freeing the underlying page by an RCU grace period. With this scheme requests can be re-allocated, at the same time as they are also being read by some lockless RCU lookup mechanism. In the ctor case, which is only called for new slab objects(i.e allocate new page and call the ctor for each object) it's safe to reset the context/engine prior to calling into dma_fence_init, since we can be certain that no one is doing an RCU lookup which might depend on peeking at the engine/context, like in active_engine(), since the object can't yet be externally visible. In the recycled case(which might also be externally visible) the request refcount always transitions from 0->1 after we set the context/engine etc, which should ensure it's valid to dereference the engine for example, when doing an RCU list-walk, so long as we can also increment the refcount first. If the refcount is already zero, then the request is considered complete/released. If it's non-zero, then the request might be in the process of being re-allocated, or potentially still in flight, however after successfully incrementing the refcount, it's possible to carefully inspect the request state, to determine if the request is still what we were looking for. Note that all externally visible requests returned to the cache must have zero refcount. One possible fix then is to move dma_fence_init out from the request ctor. Originally this was how it was done, but it was moved in: commit 855e39e65cfc33a73724f1cc644ffc5754864a20 Author: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Mon Feb 3 09:41:48 2020 +0000 drm/i915: Initialise basic fence before acquiring seqno where it looks like intel_timeline_get_seqno() relied on some of the rq->fence state, but that is no longer the case since: commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc Author: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Date: Tue Mar 23 16:49:50 2021 +0100 drm/i915: Do not share hwsp across contexts any more, v8. intel_timeline_get_seqno() could also be cleaned up slightly by dropping the request argument. Moving dma_fence_init back out of the ctor, should ensure we have enough of the request initialised in case of trace_dma_fence_init. Functionally this should be the same, and is effectively what we were already open coding before, except now we also assign the fence->lock and fence->ops, but since these are invariant for recycled requests(which might be externally visible), and will therefore already hold the same value, it shouldn't matter. An alternative fix, since we don't yet have a fully initialised request when in the ctor, is just setting the context/engine as NULL, but this does require adding some extra handling in get_driver_name etc. v2(Daniel): - Try to make the commit message less confusing Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Michael Mason <michael.w.mason(a)intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/i915/i915_request.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index ce446716d092..79da5eca60af 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -829,8 +829,6 @@ static void __i915_request_ctor(void *arg) i915_sw_fence_init(&rq->submit, submit_notify); i915_sw_fence_init(&rq->semaphore, semaphore_notify); - dma_fence_init(&rq->fence, &i915_fence_ops, &rq->lock, 0, 0); - rq->capture_list = NULL; init_llist_head(&rq->execute_cb); @@ -905,17 +903,12 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) rq->ring = ce->ring; rq->execution_mask = ce->engine->mask; - kref_init(&rq->fence.refcount); - rq->fence.flags = 0; - rq->fence.error = 0; - INIT_LIST_HEAD(&rq->fence.cb_list); - ret = intel_timeline_get_seqno(tl, rq, &seqno); if (ret) goto err_free; - rq->fence.context = tl->fence_context; - rq->fence.seqno = seqno; + dma_fence_init(&rq->fence, &i915_fence_ops, &rq->lock, + tl->fence_context, seqno); RCU_INIT_POINTER(rq->timeline, tl); rq->hwsp_seqno = tl->hwsp_seqno; -- 2.26.3

1 0

[PATCH] drm/nouveau/fifo/ga102: initialise chid on return from channel creation
by Ben Skeggs 21 Sep '21

21 Sep '21

From: Ben Skeggs <bskeggs(a)redhat.com> Turns out caller isn't zero-initialised after-all. Fixes: 6b457230bfa1 ("drm/nouveau/ga102-: support ttm buffer moves via copy engine") Reported-by: Karol Herbst <kherbst(a)redhat.com> Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c index f897bef13acf..c630dbd2911a 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c @@ -179,6 +179,9 @@ ga102_chan_new(struct nvkm_device *device, return -ENODEV; chan->ctrl.chan = nvkm_rd32(device, chan->ctrl.runl + 0x004) & 0xfffffff0; + + args->chid = 0; + args->inst = 0; args->token = nvkm_rd32(device, chan->ctrl.runl + 0x008) & 0xffff0000; ret = nvkm_memory_new(device, NVKM_MEM_TARGET_INST, 0x1000, 0x1000, true, &chan->mthd); -- 2.31.1

2 1

[PATCH v1] drm/i915/bdb: Fix version check
by Lukasz Majczak 21 Sep '21

21 Sep '21

With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+" the size of bdb_lfp_backlight_data structure has been increased, causing if-statement in the parse_lfp_backlight function that comapres this structure size to the one retrieved from BDB, always to fail for older revisions. This patch fixes it by comparing a total size of all fileds from the structure (present before the change) with the value gathered from BDB. Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221) Cc: <stable(a)vger.kernel.org> # 5.4+ Tested-by: Lukasz Majczak <lma(a)semihalf.com> Signed-off-by: Lukasz Majczak <lma(a)semihalf.com> --- drivers/gpu/drm/i915/display/intel_bios.c | 4 +++- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index 3c25926092de..052a19b455d1 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -452,7 +452,9 @@ parse_lfp_backlight(struct drm_i915_private *i915, i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI; if (bdb->version >= 191 && - get_blocksize(backlight_data) >= sizeof(*backlight_data)) { + get_blocksize(backlight_data) >= (sizeof(backlight_data->entry_size) + + sizeof(backlight_data->data) + + sizeof(backlight_data->level))) { const struct lfp_backlight_control_method *method; method = &backlight_data->backlight_control[panel_type]; diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h b/drivers/gpu/drm/i915/display/intel_vbt_defs.h index 330077c2e588..fff456bf8783 100644 --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h @@ -814,6 +814,11 @@ struct lfp_brightness_level { u16 reserved; } __packed; +/* + * Changing struct bdb_lfp_backlight_data might affect its + * size comparation to the value hold in BDB. + * (e.g. in parse_lfp_backlight()) + */ struct bdb_lfp_backlight_data { u8 entry_size; struct lfp_backlight_data_entry data[16]; -- 2.33.0.464.g1972c5931b-goog

4 5

[PATCH v2 0/6] drm/mediatek: Add mt8195 DisplayPort driver
by Markus Schneider-Pargmann 21 Sep '21

21 Sep '21

Hi everyone, this series is built around the DisplayPort driver. The dpi/dpintf driver and the added helper functions are required for the DisplayPort driver to work. For v2 I rebased the series on top of v5.15-rc1. There still is a functional dependency on many different patches pulled in through the main two dependencies, vdosys0 and vdosys1, but I wasn't able to get a clean base with these patches yet so to continue improving this series in the meantime, I decided to go with v5.15-rc1 as a base. The main potential merge-conflict points of this series with other series are mtk_drm_drv.c and mtk_drm_ddp_comp.* etc. which should be easy to resolve later on. Note: This patch series is currently tested on v5.10 and I am still working on testing it on v5.15. Dependencies: - Add Mediatek Soc DRM (vdosys0) support for mt8195 https://lore.kernel.org/linux-mediatek/20210825144833.7757-1-jason-jh.lin@m… - Add MediaTek SoC DRM (vdosys1) support for mt8195 https://lore.kernel.org/linux-mediatek/20210825100531.5653-1-nancy.lin@medi… Older revisions: RFC - https://lore.kernel.org/linux-mediatek/20210816192523.1739365-1-msp@baylibr… v1 - https://lore.kernel.org/linux-mediatek/20210906193529.718845-1-msp@baylibre… Thanks in advance for any feedback and comments. Best, Markus Markus Schneider-Pargmann (6): dt-bindings: mediatek,dpintf: Add DP_INTF binding dt-bindings: mediatek,dp: Add Display Port binding drm/edid: Add cea_sad helpers for freq/length video/hdmi: Add audio_infoframe packing for DP drm/mediatek: dpi: Add dpintf support drm/mediatek: Add mt8195 DisplayPort driver .../display/mediatek/mediatek,dp.yaml | 89 + .../display/mediatek/mediatek,dpintf.yaml | 78 + drivers/gpu/drm/drm_edid.c | 74 + drivers/gpu/drm/mediatek/Kconfig | 7 + drivers/gpu/drm/mediatek/Makefile | 2 + drivers/gpu/drm/mediatek/mtk_dp.c | 2855 +++++++++++++++++ drivers/gpu/drm/mediatek/mtk_dp_reg.h | 498 +++ drivers/gpu/drm/mediatek/mtk_dpi.c | 248 +- drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 12 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/phy/mediatek/Kconfig | 8 + drivers/phy/mediatek/Makefile | 1 + drivers/phy/mediatek/phy-mtk-dp.c | 218 ++ drivers/video/hdmi.c | 83 +- include/drm/drm_dp_helper.h | 2 + include/drm/drm_edid.h | 18 +- include/linux/hdmi.h | 7 +- include/linux/soc/mediatek/mtk-mmsys.h | 2 + 21 files changed, 4140 insertions(+), 74 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpintf.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h create mode 100644 drivers/phy/mediatek/phy-mtk-dp.c -- 2.33.0

2 9

[PATCH] drm/rockchip: handle non-platform devices in rockchip_drm_endpoint_is_subdriver
by Alex Bee 21 Sep '21

21 Sep '21

As discussed at [1] rockchip_drm_endpoint_is_subdriver will currently always return -ENODEV for non-platform-devices (e.g. external i2c bridges), what makes them never being considered in rockchip_rgb_init. As suggested at [1] this additionally adds a of_device_is_available for the node found, which will work for both platform and non-platform devices. Also we can return early for non-platform-devices if they are enabled, as rockchip_sub_drivers contains exclusively platform-devices. [1] https://lore.kernel.org/all/20210316182753.GA25685@earth.li/ Suggested-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Alex Bee <knaerzche(a)gmail.com> --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index bfba9793d238..81a5ec30ef4f 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -275,10 +275,17 @@ int rockchip_drm_endpoint_is_subdriver(struct device_node *ep) return -ENODEV; /* status disabled will prevent creation of platform-devices */ + if (!of_device_is_available(node)) { + of_node_put(node); + return -ENODEV; + } + pdev = of_find_device_by_node(node); of_node_put(node); + + /* enabled non-platform-devices can immediately return here */ if (!pdev) - return -ENODEV; + return false; /* * All rockchip subdrivers have probed at this point, so base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f -- 2.30.2

2 1

[PATCH] drm/rockchip: add DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to drm_bridge_attach
by Alex Bee 21 Sep '21

21 Sep '21

Commit a25b988ff83f ("drm/bridge: Extend bridge API to disable connector creation") added DRM_BRIDGE_ATTACH_NO_CONNECTOR bridge flag and all bridges handle this flag in some way since then. Newly added bridge drivers must no longer contain the connector creation and will fail probing if this flag isn't set. In order to be able to connect to those newly added bridges as well, make use of drm_bridge_connector API and have the connector initialized by the display controller. Signed-off-by: Alex Bee <knaerzche(a)gmail.com> --- drivers/gpu/drm/rockchip/rockchip_lvds.c | 29 ++++++++++++++++-------- drivers/gpu/drm/rockchip/rockchip_rgb.c | 26 ++++++++++++++++++++- 2 files changed, 45 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c index 551653940e39..e3953c72fbdb 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -19,6 +19,7 @@ #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> +#include <drm/drm_bridge_connector.h> #include <drm/drm_dp_helper.h> #include <drm/drm_of.h> #include <drm/drm_panel.h> @@ -612,9 +613,9 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master, } drm_encoder_helper_add(encoder, lvds->soc_data->helper_funcs); + connector = &lvds->connector; if (lvds->panel) { - connector = &lvds->connector; connector->dpms = DRM_MODE_DPMS_OFF; ret = drm_connector_init(drm_dev, connector, &rockchip_lvds_connector_funcs, @@ -627,17 +628,27 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master, drm_connector_helper_add(connector, &rockchip_lvds_connector_helper_funcs); - - ret = drm_connector_attach_encoder(connector, encoder); - if (ret < 0) { - DRM_DEV_ERROR(drm_dev->dev, - "failed to attach encoder: %d\n", ret); - goto err_free_connector; - } } else { - ret = drm_bridge_attach(encoder, lvds->bridge, NULL, 0); + ret = drm_bridge_attach(encoder, lvds->bridge, NULL, + DRM_BRIDGE_ATTACH_NO_CONNECTOR); if (ret) goto err_free_encoder; + + connector = drm_bridge_connector_init(lvds->drm_dev, encoder); + if (IS_ERR(connector)) { + DRM_DEV_ERROR(drm_dev->dev, + "failed to initialize bridge connector: %pe\n", + connector); + ret = PTR_ERR(connector); + goto err_free_encoder; + } + } + + ret = drm_connector_attach_encoder(connector, encoder); + if (ret < 0) { + DRM_DEV_ERROR(drm_dev->dev, + "failed to attach encoder: %d\n", ret); + goto err_free_connector; } pm_runtime_enable(dev); diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c b/drivers/gpu/drm/rockchip/rockchip_rgb.c index d691d9bef8e7..09be9678f2bd 100644 --- a/drivers/gpu/drm/rockchip/rockchip_rgb.c +++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c @@ -10,6 +10,7 @@ #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> +#include <drm/drm_bridge_connector.h> #include <drm/drm_dp_helper.h> #include <drm/drm_of.h> #include <drm/drm_panel.h> @@ -27,6 +28,7 @@ struct rockchip_rgb { struct drm_device *drm_dev; struct drm_bridge *bridge; struct drm_encoder encoder; + struct drm_connector connector; int output_mode; }; @@ -80,6 +82,7 @@ struct rockchip_rgb *rockchip_rgb_init(struct device *dev, int ret = 0, child_count = 0; struct drm_panel *panel; struct drm_bridge *bridge; + struct drm_connector *connector; rgb = devm_kzalloc(dev, sizeof(*rgb), GFP_KERNEL); if (!rgb) @@ -142,12 +145,32 @@ struct rockchip_rgb *rockchip_rgb_init(struct device *dev, rgb->bridge = bridge; - ret = drm_bridge_attach(encoder, rgb->bridge, NULL, 0); + ret = drm_bridge_attach(encoder, rgb->bridge, NULL, + DRM_BRIDGE_ATTACH_NO_CONNECTOR); if (ret) goto err_free_encoder; + connector = &rgb->connector; + connector = drm_bridge_connector_init(rgb->drm_dev, encoder); + if (IS_ERR(connector)) { + DRM_DEV_ERROR(drm_dev->dev, + "failed to initialize bridge connector: %pe\n", + connector); + ret = PTR_ERR(connector); + goto err_free_encoder; + } + + ret = drm_connector_attach_encoder(connector, encoder); + if (ret < 0) { + DRM_DEV_ERROR(drm_dev->dev, + "failed to attach encoder: %d\n", ret); + goto err_free_connector; + } + return rgb; +err_free_connector: + drm_connector_cleanup(connector); err_free_encoder: drm_encoder_cleanup(encoder); return ERR_PTR(ret); @@ -157,6 +180,7 @@ EXPORT_SYMBOL_GPL(rockchip_rgb_init); void rockchip_rgb_fini(struct rockchip_rgb *rgb) { drm_panel_bridge_remove(rgb->bridge); + drm_connector_cleanup(&rgb->connector); drm_encoder_cleanup(&rgb->encoder); } EXPORT_SYMBOL_GPL(rockchip_rgb_fini); base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f -- 2.30.2

2 1

[PATCH v2] drm/rockchip: remove of_match_ptr()
by Souptick Joarder 21 Sep '21

21 Sep '21

Kernel test robot throws below warning when CONFIG_OF is not set. >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:457:34: warning: unused variable 'rockchip_dp_dt_ids' [-Wunused-const-variable] static const struct of_device_id rockchip_dp_dt_ids[] = { Fixed it by removing of_match_ptr(). Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Souptick Joarder <jrdr.linux(a)gmail.com> Cc: Robin Murphy <robin.murphy(a)arm.com> --- v2: Address review comment from Robin. updated change logs and subject line. drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index ade2327a10e2..8abb5ac26807 100644 --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c @@ -467,6 +467,6 @@ struct platform_driver rockchip_dp_driver = { .driver = { .name = "rockchip-dp", .pm = &rockchip_dp_pm_ops, - .of_match_table = of_match_ptr(rockchip_dp_dt_ids), + .of_match_table = rockchip_dp_dt_ids, }, }; -- 2.25.1

2 1

[PATCH] drm/rockchip: remove of_match_ptr() from vop_driver_dt_match
by Souptick Joarder 21 Sep '21

21 Sep '21

kernel test robot throws warning when CONFIG_OF not set. >> drivers/gpu/drm/rockchip/rockchip_vop_reg.c:1038:34: warning: unused variable 'vop_driver_dt_match' [-Wunused-const-variable] static const struct of_device_id vop_driver_dt_match[] = { Fixed it by removing of_match_ptr(). Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Souptick Joarder <jrdr.linux(a)gmail.com> Cc: Robin Murphy <robin.murphy(a)arm.com> --- drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c index ca7cc82125cb..1f7353f0684a 100644 --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c @@ -1124,6 +1124,6 @@ struct platform_driver vop_platform_driver = { .remove = vop_remove, .driver = { .name = "rockchip-vop", - .of_match_table = of_match_ptr(vop_driver_dt_match), + .of_match_table = vop_driver_dt_match, }, }; -- 2.25.1

2 1

[PATCH] drm/rockchip: dsi: make hstt_table static
by Jiapeng Chong 21 Sep '21

21 Sep '21

This symbol is not used outside of dw-mipi-dsi-rockchip.c, so marks it static. Fix the following sparse warning: drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:646:13: warning: symbol 'hstt_table' was not declared. Should it be static? Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c index a2262be..12fa3db 100644 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c @@ -643,7 +643,7 @@ struct hstt { } /* Table A-3 High-Speed Transition Times */ -struct hstt hstt_table[] = { +static struct hstt hstt_table[] = { HSTT( 90, 32, 20, 26, 13), HSTT( 100, 35, 23, 28, 14), HSTT( 110, 32, 22, 26, 13), -- 1.8.3.1

2 1

← Newer
1
...
41
42
43
44
45
46
47
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021