dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH 1/2] drm/vc4: hdmi: Remove redundant variables
by Maxime Ripard 28 Jul '21

28 Jul '21

The vc4_hdmi_audio_prepare function and the functions it's calling have in several occurences multiple dereferences of either the sample rate or the number of channels. It turns out that these variables are also passed through the hdmi codec parameters structure. Convert all the users to use this structure, and if it's used multiple times use a variable to store it instead of dereferencing it every time. Reviewed-by: Nicolas Saenz Julienne <nsaenz(a)kernel.org> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 26 ++++++++++++-------------- drivers/gpu/drm/vc4/vc4_hdmi.h | 2 -- 2 files changed, 12 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index cbeec6a5cb90..3165f39a4557 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1176,12 +1176,13 @@ static u32 vc5_hdmi_channel_map(struct vc4_hdmi *vc4_hdmi, u32 channel_mask) } /* HDMI audio codec callbacks */ -static void vc4_hdmi_audio_set_mai_clock(struct vc4_hdmi *vc4_hdmi) +static void vc4_hdmi_audio_set_mai_clock(struct vc4_hdmi *vc4_hdmi, + unsigned int samplerate) { u32 hsm_clock = clk_get_rate(vc4_hdmi->audio_clock); unsigned long n, m; - rational_best_approximation(hsm_clock, vc4_hdmi->audio.samplerate, + rational_best_approximation(hsm_clock, samplerate, VC4_HD_MAI_SMP_N_MASK >> VC4_HD_MAI_SMP_N_SHIFT, (VC4_HD_MAI_SMP_M_MASK >> @@ -1193,12 +1194,11 @@ static void vc4_hdmi_audio_set_mai_clock(struct vc4_hdmi *vc4_hdmi) VC4_SET_FIELD(m - 1, VC4_HD_MAI_SMP_M)); } -static void vc4_hdmi_set_n_cts(struct vc4_hdmi *vc4_hdmi) +static void vc4_hdmi_set_n_cts(struct vc4_hdmi *vc4_hdmi, unsigned int samplerate) { struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base; struct drm_crtc *crtc = encoder->crtc; const struct drm_display_mode *mode = &crtc->state->adjusted_mode; - u32 samplerate = vc4_hdmi->audio.samplerate; u32 n, cts; u64 tmp; @@ -1332,27 +1332,25 @@ static int vc4_hdmi_audio_prepare(struct device *dev, void *data, { struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev); struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base; + unsigned int sample_rate = params->sample_rate; + unsigned int channels = params->channels; u32 audio_packet_config, channel_mask; u32 channel_map; u32 mai_audio_format; u32 mai_sample_rate; dev_dbg(dev, "%s: %u Hz, %d bit, %d channels\n", __func__, - params->sample_rate, params->sample_width, - params->channels); - - vc4_hdmi->audio.channels = params->channels; - vc4_hdmi->audio.samplerate = params->sample_rate; + sample_rate, params->sample_width, channels); HDMI_WRITE(HDMI_MAI_CTL, - VC4_SET_FIELD(params->channels, VC4_HD_MAI_CTL_CHNUM) | + VC4_SET_FIELD(channels, VC4_HD_MAI_CTL_CHNUM) | VC4_HD_MAI_CTL_WHOLSMP | VC4_HD_MAI_CTL_CHALIGN | VC4_HD_MAI_CTL_ENABLE); - vc4_hdmi_audio_set_mai_clock(vc4_hdmi); + vc4_hdmi_audio_set_mai_clock(vc4_hdmi, sample_rate); - mai_sample_rate = sample_rate_to_mai_fmt(vc4_hdmi->audio.samplerate); + mai_sample_rate = sample_rate_to_mai_fmt(sample_rate); if (params->iec.status[0] & IEC958_AES0_NONAUDIO && params->channels == 8) mai_audio_format = VC4_HDMI_MAI_FORMAT_HBR; @@ -1370,7 +1368,7 @@ static int vc4_hdmi_audio_prepare(struct device *dev, void *data, VC4_HDMI_AUDIO_PACKET_ZERO_DATA_ON_INACTIVE_CHANNELS | VC4_SET_FIELD(0x8, VC4_HDMI_AUDIO_PACKET_B_FRAME_IDENTIFIER); - channel_mask = GENMASK(vc4_hdmi->audio.channels - 1, 0); + channel_mask = GENMASK(channels - 1, 0); audio_packet_config |= VC4_SET_FIELD(channel_mask, VC4_HDMI_AUDIO_PACKET_CEA_MASK); @@ -1389,7 +1387,7 @@ static int vc4_hdmi_audio_prepare(struct device *dev, void *data, channel_map = vc4_hdmi->variant->channel_map(vc4_hdmi, channel_mask); HDMI_WRITE(HDMI_MAI_CHANNEL_MAP, channel_map); HDMI_WRITE(HDMI_AUDIO_PACKET_CONFIG, audio_packet_config); - vc4_hdmi_set_n_cts(vc4_hdmi); + vc4_hdmi_set_n_cts(vc4_hdmi, sample_rate); memcpy(&vc4_hdmi->audio.infoframe, &params->cea, sizeof(params->cea)); vc4_hdmi_set_audio_infoframe(encoder); diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h index b6697b695f71..33e9f665ab8e 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.h +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h @@ -111,8 +111,6 @@ struct vc4_hdmi_audio { struct snd_soc_dai_link_component cpu; struct snd_soc_dai_link_component codec; struct snd_soc_dai_link_component platform; - int samplerate; - int channels; struct snd_dmaengine_dai_dma_data dma_data; struct hdmi_audio_infoframe infoframe; bool streaming; -- 2.31.1

2 3

[PATCH 1/5] drm/vmwgfx: unbind in vmw_ttm_unpopulate
by Christian König 28 Jul '21

28 Jul '21

Doing this in vmw_ttm_destroy() is to late. It turned out that this is not a good idea at all because it leaves pointers to freed up system memory pages in the GART tables of the drivers. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c index b0973c27e774..904031d03dbe 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c @@ -526,14 +526,9 @@ static void vmw_ttm_destroy(struct ttm_device *bdev, struct ttm_tt *ttm) struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, dma_ttm); - vmw_ttm_unbind(bdev, ttm); ttm_tt_destroy_common(bdev, ttm); vmw_ttm_unmap_dma(vmw_be); - if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent) - ttm_tt_fini(&vmw_be->dma_ttm); - else - ttm_tt_fini(ttm); - + ttm_tt_fini(ttm); if (vmw_be->mob) vmw_mob_destroy(vmw_be->mob); @@ -578,6 +573,8 @@ static void vmw_ttm_unpopulate(struct ttm_device *bdev, dma_ttm); unsigned int i; + vmw_ttm_unbind(bdev, ttm); + if (vmw_tt->mob) { vmw_mob_destroy(vmw_tt->mob); vmw_tt->mob = NULL; -- 2.25.1

3 13

[PATCH v2 0/3] drm, drm/vmwgfx: fixes and updates related to drm_master
by Desmond Cheong Zhi Xi 28 Jul '21

28 Jul '21

Hi, Just a note that only patch 2 changed from v1 to v2 of this series. This series contains some improvements that Daniel Vetter proposed following a discussion on a recent series: https://lore.kernel.org/lkml/20210712043508.11584-1-desmondcheongzx@gmail.c… While preparing these patches, I also noticed some unprotected uses of drm_master in the vmwgfx driver that can be addressed by new functions from the previous series. This series is thus broken up into three patches: 1. Switch from the outer drm_device.master_mutex to the inner drm_file.master_lookup_lock in drm_is_current_master. 2. Update the kerneldoc for drm leases to clarify usage and lifetime/locking rules. 3. Prevent potential use-after-free bugs by replacing calls to drm_master_get with drm_file_get_master in vmwgfx_surface.c. v1 -> v2: Changes to patch 2: - Clarified description of lease fields in drm_master with suggestions from Daniel Vetter. - Added an overview DOC: section for drm leases in drm-uapi.rst. - Cleaned up function documentation in drm_lease.c to use kernel-doc formatting. Best wishes, Desmond Desmond Cheong Zhi Xi (3): drm: use the lookup lock in drm_is_current_master drm: clarify usage of drm leases drm/vmwgfx: fix potential UAF in vmwgfx_surface.c Documentation/gpu/drm-uapi.rst | 15 ++ drivers/gpu/drm/drm_auth.c | 9 +- drivers/gpu/drm/drm_lease.c | 182 ++++++++++++++---------- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 +- include/drm/drm_auth.h | 67 +++++++-- 5 files changed, 187 insertions(+), 90 deletions(-) -- 2.25.1

2 6

[PATCH] efi: sysfb_efi: fix build when EFI is not set
by Randy Dunlap 28 Jul '21

28 Jul '21

When # CONFIG_EFI is not set, there are 2 definitions of sysfb_apply_efi_quirks(). The stub from sysfb.h should be used and the __init function from sysfb_efi.c should not be used. ../drivers/firmware/efi/sysfb_efi.c:337:13: error: redefinition of ‘sysfb_apply_efi_quirks’ __init void sysfb_apply_efi_quirks(struct platform_device *pd) ^~~~~~~~~~~~~~~~~~~~~~ In file included from ../drivers/firmware/efi/sysfb_efi.c:26:0: ../include/linux/sysfb.h:65:20: note: previous definition of ‘sysfb_apply_efi_quirks’ was here static inline void sysfb_apply_efi_quirks(struct platform_device *pd) ^~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: linux-efi(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: Javier Martinez Canillas <javierm(a)redhat.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Mark Brown <broonie(a)kernel.org> Cc: linux-next(a)vger.kernel.org --- drivers/firmware/efi/sysfb_efi.c | 2 ++ 1 file changed, 2 insertions(+) --- linext-20210726.orig/drivers/firmware/efi/sysfb_efi.c +++ linext-20210726/drivers/firmware/efi/sysfb_efi.c @@ -332,6 +332,7 @@ static const struct fwnode_operations ef .add_links = efifb_add_links, }; +#ifdef CONFIG_EFI static struct fwnode_handle efifb_fwnode; __init void sysfb_apply_efi_quirks(struct platform_device *pd) @@ -354,3 +355,4 @@ __init void sysfb_apply_efi_quirks(struc pd->dev.fwnode = &efifb_fwnode; } } +#endif

7 7

[PATCH] drm/i915/gt: Fix a lockdep warning with disable interrupts
by Jun Miao 28 Jul '21

28 Jul '21

When disable local interrupt irq of CPU hardware, some spin_lock are called by inside signal_irq_work(), intel_breadcrumbs_disarm_irq() and intel_breadcrumbs_arm_irq(). RT complains about might sleep inside interrupt disable by spin_lock, so switch spin_lock to spin_lock_irqsave with the shutdown interrupt at the same time. --- --- BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:969 #0: ffff89c4c00ca970 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1cf/0x6d0 #1: ffffa433c1f53e60 ((work_completion)(&engine->retire_work)){+.+.}-{0:0}, at: process_one_work+0x1cf 0x6d #2: ffff89c4ccb0a0a8 (kernel_context){+.+.}-{0:0}, at: engine_retire+0x62/0x110 [i915] #3: ffff89c4cf682300 (wakeref.mutex#3){+.+.}-{0:0}, at: __intel_wakeref_put_last+0x20/0x60 [i915] #4: ffff89c4ccb08398 (&b->irq_lock){+.+.}-{0:0}, at: intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915] irq event stamp: 2126 hardirqs last enabled at (2125): [<ffffffffbb134739>] cancel_delayed_work+0xa9/0xc0 hardirqs last disabled at (2126): [<ffffffffc0507fe6>] __intel_breadcrumbs_park+0x76/0x80 [i915] softirqs last enabled at (0): [<ffffffffbb1099ce>] copy_process+0x63e/0x1630 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 281 Comm: kworker/3:3 Not tainted 5.10.27-rt34-yocto-preempt-rt #1 Hardware name: Intel(R) Client Systems NUC7i5DNKE/NUC7i5DNB, BIOS DNKBLi5v.86A.0064.2019.0523.1933 05/23 2019 Workqueue: events engine_retire [i915] Call Trace: show_stack+0x52/0x58 dump_stack+0x7d/0x9f ___might_sleep.cold+0xe3/0xf4 rt_spin_lock+0x3f/0xc0 ? intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915] intel_breadcrumbs_disarm_irq+0x20/0xd0 [i915] signal_irq_work+0x241/0x660 [i915] ? __this_cpu_preempt_check+0x13/0x20 ? lockdep_hardirqs_off+0x106/0x120 __intel_breadcrumbs_park+0x3f/0x80 [i915] __engine_park+0xbd/0xe0 [i915] ____intel_wakeref_put_last+0x22/0x60 [i915] __intel_wakeref_put_last+0x50/0x60 [i915] intel_context_exit_engine+0x5f/0x70 [i915] i915_request_retire+0x139/0x2d0 [i915] engine_retire+0xb0/0x110 [i915] process_one_work+0x26d/0x6d0 worker_thread+0x53/0x330 kthread+0x1b0/0x1d0 ? process_one_work+0x6d0/0x6d0 ? __kthread_parkme+0xc0/0xc0 ret_from_fork+0x22/0x30 Fixes: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission") Signed-off-by: Jun Miao <jun.miao(a)windriver.com> --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c index 38cc42783dfb..9b74d0a56bc5 100644 --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c @@ -63,13 +63,15 @@ static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b) static void intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b) { + unsigned long flags; + if (!b->irq_engine) return; - spin_lock(&b->irq_lock); + spin_lock_irqsave(&b->irq_lock, flags); if (!b->irq_armed) __intel_breadcrumbs_arm_irq(b); - spin_unlock(&b->irq_lock); + spin_unlock_irqrestore(&b->irq_lock, flags); } static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b) @@ -84,10 +86,12 @@ static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b) static void intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b) { - spin_lock(&b->irq_lock); + unsigned long flags; + + spin_lock_irqsave(&b->irq_lock, flags); if (b->irq_armed) __intel_breadcrumbs_disarm_irq(b); - spin_unlock(&b->irq_lock); + spin_unlock_irqrestore(&b->irq_lock, flags); } static void add_signaling_context(struct intel_breadcrumbs *b, @@ -181,6 +185,7 @@ static void signal_irq_work(struct irq_work *work) const ktime_t timestamp = ktime_get(); struct llist_node *signal, *sn; struct intel_context *ce; + unsigned long flags; signal = NULL; if (unlikely(!llist_empty(&b->signaled_requests))) @@ -259,11 +264,11 @@ static void signal_irq_work(struct irq_work *work) llist_entry(signal, typeof(*rq), signal_node); struct list_head cb_list; - spin_lock(&rq->lock); + spin_lock_irqsave(&rq->lock, flags); list_replace(&rq->fence.cb_list, &cb_list); __dma_fence_signal__timestamp(&rq->fence, timestamp); __dma_fence_signal__notify(&rq->fence, &cb_list); - spin_unlock(&rq->lock); + spin_unlock_irqrestore(&rq->lock, flags); i915_request_put(rq); } @@ -318,9 +323,7 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b) /* Kick the work once more to drain the signalers, and disarm the irq */ irq_work_sync(&b->irq_work); while (READ_ONCE(b->irq_armed) && !atomic_read(&b->active)) { - local_irq_disable(); signal_irq_work(&b->irq_work); - local_irq_enable(); cond_resched(); } } -- 2.32.0

1 0

[Bug 213779] New: Screen stays blank on resume. from hibernate
by bugzilla-daemon＠bugzilla.kernel.org 28 Jul '21

28 Jul '21

https://bugzilla.kernel.org/show_bug.cgi?id=213779 Bug ID: 213779 Summary: Screen stays blank on resume. from hibernate Product: Drivers Version: 2.5 Kernel Version: 5.13 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: alex14641(a)yahoo.com Regression: No If I close my laptop lid and reopen it, the screen stays blank. Reverting the following commit fixes the issue: commit 9127daa0a8d88a6e6452eb8b7c9be4c3f42a867e Author: Stylon Wang <stylon.wang(a)amd.com> Date: Tue Mar 2 19:25:56 2021 +0800 drm/amd/display: Guard ASSR with internal display flag [Why] ASSR enabling only considers capability declared in DPCD. We also need to check whether the connector is internal. [How] ASSR enabling need to check both DPCD capability and internal display flag. Signed-off-by: Stylon Wang <stylon.wang(a)amd.com> Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com> Acked-by: Anson Jacob <Anson.Jacob(a)amd.com> Tested-by: Dan Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH] drm/exynos: Always initialize mapping in exynos_drm_register_dma()
by Nathan Chancellor 27 Jul '21

27 Jul '21

In certain randconfigs, clang warns: drivers/gpu/drm/exynos/exynos_drm_dma.c:121:19: warning: variable 'mapping' is uninitialized when used here [-Wuninitialized] priv->mapping = mapping; ^~~~~~~ drivers/gpu/drm/exynos/exynos_drm_dma.c:111:16: note: initialize the variable 'mapping' to silence this warning void *mapping; ^ = NULL 1 warning generated. This occurs when CONFIG_EXYNOS_IOMMU is enabled and both CONFIG_ARM_DMA_USE_IOMMU and CONFIG_IOMMU_DMA are disabled, which makes the code look like void *mapping; if (0) mapping = arm_iommu_create_mapping() else if (0) mapping = iommu_get_domain_for_dev() ... priv->mapping = mapping; Add an else branch that initializes mapping to the -ENODEV error pointer so that there is no more warning and the driver does not change during runtime. Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- drivers/gpu/drm/exynos/exynos_drm_dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c b/drivers/gpu/drm/exynos/exynos_drm_dma.c index 0644936afee2..bf33c3084cb4 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dma.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c @@ -115,6 +115,8 @@ int exynos_drm_register_dma(struct drm_device *drm, struct device *dev, EXYNOS_DEV_ADDR_START, EXYNOS_DEV_ADDR_SIZE); else if (IS_ENABLED(CONFIG_IOMMU_DMA)) mapping = iommu_get_domain_for_dev(priv->dma_dev); + else + mapping = ERR_PTR(-ENODEV); if (IS_ERR(mapping)) return PTR_ERR(mapping); base-commit: 7d549995d4e0d99b68e8a7793a0d23da6fc40fe8 -- 2.32.0.264.g75ae10bc75

1 0

[PATCH v2 0/3] drm/msm: Improved devfreq tuning
by Rob Clark 27 Jul '21

27 Jul '21

From: Rob Clark <robdclark(a)chromium.org> This is the outcome of trying to fix some bad gpu freq behavior seen in some use-cases, in particular mobile games that throttle themselves to 30fps. With the existing tuning, we'd end up spending most of the time that we should be running fast at a low freq, and most of the idle time at a high freq. First two patches are prep, 3/3 is the interesting bit. See the patch description in 3/3 for more details. v2: struct_mutex serializes the submit path, but not the retire path, so add a dedicated lock to serialize active<->idle transitions. Rob Clark (3): drm/msm: Split out devfreq handling drm/msm: Split out get_freq() helper drm/msm: Devfreq tuning drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +- drivers/gpu/drm/msm/msm_gpu.c | 132 +++-------------- drivers/gpu/drm/msm/msm_gpu.h | 61 +++++++- drivers/gpu/drm/msm/msm_gpu_devfreq.c | 203 ++++++++++++++++++++++++++ 5 files changed, 280 insertions(+), 121 deletions(-) create mode 100644 drivers/gpu/drm/msm/msm_gpu_devfreq.c -- 2.31.1

2 5

[PATCH V2] drm: mxsfb: Use bus_format from the nearest bridge if present
by Marek Vasut 27 Jul '21

27 Jul '21

In case there is a bridge connected to the LCDIF, use bus_format from the bridge, otherwise behave as before and use bus_format from the connector. This way, even if there are multiple bridges in the display pipeline, the LCDIF will use the correct format. Reviewed-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Daniel Abrecht <public(a)danielabrecht.ch> Cc: Emil Velikov <emil.l.velikov(a)gmail.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Stefan Agner <stefan(a)agner.ch> --- V2: Drop null checks for variables which must always be non-null, state and bridge_state --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 32 +++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index a6681bb699f14..4501deb48e6b2 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -47,16 +47,13 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val) * Setup the MXSFB registers for decoding the pixels out of the framebuffer and * outputting them on the bus. */ -static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb) +static void mxsfb_set_formats(struct mxsfb_drm_private *mxsfb, + const u32 bus_format) { struct drm_device *drm = mxsfb->drm; const u32 format = mxsfb->crtc.primary->state->fb->format->format; - u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24; u32 ctrl, ctrl1; - if (mxsfb->connector->display_info.num_bus_formats) - bus_format = mxsfb->connector->display_info.bus_formats[0]; - DRM_DEV_DEBUG_DRIVER(drm->dev, "Using bus_format: 0x%08X\n", bus_format); @@ -222,7 +219,8 @@ static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane) return gem->paddr; } -static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) +static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb, + const u32 bus_format) { struct drm_device *drm = mxsfb->crtc.dev; struct drm_display_mode *m = &mxsfb->crtc.state->adjusted_mode; @@ -247,7 +245,7 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) if (mxsfb->devdata->has_overlay) writel(0, mxsfb->base + LCDC_AS_CTRL); - mxsfb_set_formats(mxsfb); + mxsfb_set_formats(mxsfb, bus_format); clk_set_rate(mxsfb->clk, m->crtc_clock * 1000); @@ -345,7 +343,9 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev); + struct drm_bridge_state *bridge_state; struct drm_device *drm = mxsfb->drm; + u32 bus_format = 0; dma_addr_t paddr; pm_runtime_get_sync(drm->dev); @@ -353,7 +353,23 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc, drm_crtc_vblank_on(crtc); - mxsfb_crtc_mode_set_nofb(mxsfb); + /* If there is a bridge attached to the LCDIF, use its bus format */ + if (mxsfb->bridge) { + bridge_state = + drm_atomic_get_new_bridge_state(state, + mxsfb->bridge); + bus_format = bridge_state->input_bus_cfg.format; + } + + /* If there is no bridge, use bus format from connector */ + if (!bus_format && mxsfb->connector->display_info.num_bus_formats) + bus_format = mxsfb->connector->display_info.bus_formats[0]; + + /* If all else fails, default to RGB888_1X24 */ + if (!bus_format) + bus_format = MEDIA_BUS_FMT_RGB888_1X24; + + mxsfb_crtc_mode_set_nofb(mxsfb, bus_format); /* Write cur_buf as well to avoid an initial corrupt frame */ paddr = mxsfb_get_fb_paddr(crtc->primary); -- 2.30.2

2 1

[PATCH 0/2] Add support for querying hw info that UMDs need
by John.C.Harrison＠Intel.com 27 Jul '21

27 Jul '21

From: John Harrison <John.C.Harrison(a)Intel.com> Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. Test-with: 20210727002812.43469-2-John.C.Harrison(a)Intel.com UMD: https://github.com/intel/compute-runtime/pull/432/files Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> John Harrison (1): drm/i915/guc: Add fetch of hwconfig table Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig table drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 156 ++++++++++++++++++ .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 + drivers/gpu/drm/i915/i915_query.c | 23 +++ include/uapi/drm/i915_drm.h | 1 + 10 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h -- 2.25.1

3 4

← Newer
1
...
27
28
29
30
31
32
33
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021