dri-devel July 2018

dri-devel@lists.freedesktop.org

277 participants
1883 discussions

[RFC PATCH v2] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
by Ayan Kumar Halder 05 Jul '18

05 Jul '18

On planes which support AFBC, expose an AFBC modifier for use with BGR888. Signed-off-by: Ayan Kumar halder <ayan.halder(a)arm.com> Reviewed-by: Brian Starkey <brian.starkey(a)arm.com> Reviewed-by: Liviu Dudau <liviu.dudau(a)arm.com> Changes from v2: - Removed the gerrit change-id - Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported() to report unsupported modifiers. --- drivers/gpu/drm/arm/malidp_drv.c | 1 + drivers/gpu/drm/arm/malidp_planes.c | 46 +++++++++++++++++++++++++++++++++++-- 2 files changed, 45 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 7b6a848..7bcd679 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -392,6 +392,7 @@ static int malidp_init(struct drm_device *drm) drm->mode_config.max_height = hwdev->max_line_size; drm->mode_config.funcs = &malidp_mode_config_funcs; drm->mode_config.helper_private = &malidp_mode_config_helpers; + drm->mode_config.allow_fb_modifiers = true; ret = malidp_crtc_init(drm); if (ret) { diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c index 3950504..914cc58 100644 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@ -124,6 +124,35 @@ static void malidp_plane_atomic_print_state(struct drm_printer *p, drm_printf(p, "\tn_planes=%u\n", ms->n_planes); } +static bool malidp_format_mod_supported(struct drm_plane *plane, + u32 format, u64 modifier) +{ + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID)) + return false; + + /* All the pixel formats are supported without any modifier */ + if (modifier == DRM_FORMAT_MOD_LINEAR) + return true; + + if ((modifier >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) + return false; + + if (modifier & + ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) { + DRM_DEBUG_KMS("Unsupported modifiers\n"); + return false; + } + + switch (modifier) { + case DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | + AFBC_FORMAT_MOD_YTR | + AFBC_FORMAT_MOD_SPARSE): + if (format == DRM_FORMAT_BGR888) + return true; + } + return false; +} + static const struct drm_plane_funcs malidp_de_plane_funcs = { .update_plane = drm_atomic_helper_update_plane, .disable_plane = drm_atomic_helper_disable_plane, @@ -132,6 +161,7 @@ static const struct drm_plane_funcs malidp_de_plane_funcs = { .atomic_duplicate_state = malidp_duplicate_plane_state, .atomic_destroy_state = malidp_destroy_plane_state, .atomic_print_state = malidp_plane_atomic_print_state, + .format_mod_supported = malidp_format_mod_supported, }; static int malidp_se_check_scaling(struct malidp_plane *mp, @@ -524,6 +554,13 @@ int malidp_de_planes_init(struct drm_device *drm) u32 *formats; int ret, i, j, n; + static const u64 modifiers[] = { + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | + AFBC_FORMAT_MOD_YTR | AFBC_FORMAT_MOD_SPARSE), + DRM_FORMAT_MOD_LINEAR, + DRM_FORMAT_MOD_INVALID + }; + formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL); if (!formats) { ret = -ENOMEM; @@ -547,9 +584,14 @@ int malidp_de_planes_init(struct drm_device *drm) plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY; + + /* + * All the layers except smart layer supports AFBC modifiers. + */ ret = drm_universal_plane_init(drm, &plane->base, crtcs, - &malidp_de_plane_funcs, formats, - n, NULL, plane_type, NULL); + &malidp_de_plane_funcs, formats, n, + (id == DE_SMART) ? NULL : modifiers, plane_type, NULL); + if (ret < 0) goto cleanup; -- 2.7.4

3 2

Patch "drm/sti: Depend on OF rather than selecting it" has been added to the 4.17-stable tree
by gregkh＠linuxfoundation.org 05 Jul '18

05 Jul '18

This is a note to let you know that I've just added the patch titled drm/sti: Depend on OF rather than selecting it to the 4.17-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-sti-depend-on-of-rather-than-selecting-it.patch and it can be found in the queue-4.17 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c9fea6f4379c72b7c59e1efceab09a35bc7eac43 Mon Sep 17 00:00:00 2001 From: Oliver O'Halloran <oohall(a)gmail.com> Date: Tue, 3 Apr 2018 15:34:01 +1000 Subject: drm/sti: Depend on OF rather than selecting it From: Oliver O'Halloran <oohall(a)gmail.com> commit c9fea6f4379c72b7c59e1efceab09a35bc7eac43 upstream. Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") reworked some code inside of this driver and made it select CONFIG_OF. This results in the entire OF layer being enabled when building an allmodconfig on ia64. OF on ia64 is completely unsupported so this isn't a great state of affairs. The 0day robot noticed a link-time failure on ia64 caused by using of_node_to_nid() in an otherwise unrelated driver. The generic fallback for of_node_to_nid() only exists when: defined(CONFIG_OF) && defined(CONFIG_NUMA) == false Since CONFIG_NUMA is usually selected for IA64 we get the link failure. Fix this by making the driver depend on OF rather than selecting it, odds are that was the original intent. Link: https://lists.01.org/pipermail/kbuild-all/2018-March/045172.html Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Vincent Abriou <vincent.abriou(a)st.com> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-ia64(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Oliver O'Halloran <oohall(a)gmail.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Signed-off-by: Philippe Cornu <philippe.cornu(a)st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403053401.30045-1-oohall… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/sti/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -1,6 +1,6 @@ config DRM_STI tristate "DRM Support for STMicroelectronics SoC stiH4xx Series" - depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM) + depends on OF && DRM && (ARCH_STI || ARCH_MULTIPLATFORM) select RESET_CONTROLLER select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER @@ -8,6 +8,5 @@ config DRM_STI select DRM_PANEL select FW_LOADER select SND_SOC_HDMI_CODEC if SND_SOC - select OF help Choose this option to enable DRM on STM stiH4xx chipset Patches currently in stable-queue which might be from oohall(a)gmail.com are queue-4.17/drm-sti-depend-on-of-rather-than-selecting-it.patch

1 0

[PATCH] drm/amd/display: Use 2-factor allocator calls
by Kees Cook 05 Jul '18

05 Jul '18

As already done treewide, switch from open-coded multiplication to 2-factor allocation helper. Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c index 98edaefa2b47..ee69c949bfbf 100644 --- a/drivers/gpu/drm/amd/display/modules/color/color_gamma.c +++ b/drivers/gpu/drm/amd/display/modules/color/color_gamma.c @@ -1723,8 +1723,8 @@ bool mod_color_calculate_curve(enum dc_transfer_func_predefined trans, kvfree(rgb_regamma); } else if (trans == TRANSFER_FUNCTION_HLG || trans == TRANSFER_FUNCTION_HLG12) { - rgb_regamma = kvzalloc(sizeof(*rgb_regamma) * - (MAX_HW_POINTS + _EXTRA_POINTS), + rgb_regamma = kvcalloc(MAX_HW_POINTS + _EXTRA_POINTS, + sizeof(*rgb_regamma), GFP_KERNEL); if (!rgb_regamma) goto rgb_regamma_alloc_fail; @@ -1802,8 +1802,8 @@ bool mod_color_calculate_degamma_curve(enum dc_transfer_func_predefined trans, kvfree(rgb_degamma); } else if (trans == TRANSFER_FUNCTION_HLG || trans == TRANSFER_FUNCTION_HLG12) { - rgb_degamma = kvzalloc(sizeof(*rgb_degamma) * - (MAX_HW_POINTS + _EXTRA_POINTS), + rgb_degamma = kvcalloc(MAX_HW_POINTS + _EXTRA_POINTS, + sizeof(*rgb_degamma), GFP_KERNEL); if (!rgb_degamma) goto rgb_degamma_alloc_fail; -- 2.17.1 -- Kees Cook Pixel Security

3 3

[pull] amdgpu drm-fixes-4.18
by Alex Deucher 05 Jul '18

05 Jul '18

Hi Dave, Fixes for 4.18. Highlights: - Fix an HDMI 2.0 4k@60 regression - Hotplug fixes for PX/HG laptops - Fixes for vbios changes in vega12 - Fix a race in the user fence code - Fix a couple of misc typos The following changes since commit 4de9f38bb2cce3a4821ffb8a83d6b08f6e37d905: drm/amd/display: release spinlock before committing updates to stream (2018-06-27 14:35:53 -0500) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.18 for you to fetch changes up to 413ff0b942481c7ac2e800abbbac5af318a65e61: drm/amd/display: add a check for display depth validity (2018-07-05 10:19:53 -0500) ---------------------------------------------------------------- Alex Deucher (2): drm/amdgpu: fix swapped emit_ib_size in vce3 drm/amdgpu/pm: fix display count in non-DC path Evan Quan (3): drm/amd/powerplay: correct vega12 thermal support as true drm/amd/powerplay: correct vega12 bootup values settings drm/amd/powerplay: smc_dpm_info structure change Lyude Paul (3): drm/amdgpu: Make struct amdgpu_atif private to amdgpu_acpi.c drm/amdgpu: Add amdgpu_atpx_get_dhandle() drm/amdgpu: Dynamically probe for ATIF handle (v2) Mikita Lipski (2): drm/amd/display: adding ycbcr420 pixel encoding for hdmi drm/amd/display: add a check for display depth validity Nicolai Hähnle (1): drm/amdgpu: fix user fence write race condition drivers/gpu/drm/amd/amdgpu/amdgpu.h | 46 ++------ drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 131 +++++++++++++++++---- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 6 + drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 +- drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 4 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 49 +++++++- drivers/gpu/drm/amd/include/atomfirmware.h | 5 +- drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c | 96 +++++++++++++-- drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h | 5 + drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 4 + drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.h | 3 + .../amd/powerplay/hwmgr/vega12_processpptables.c | 2 + .../drm/amd/powerplay/inc/vega12/smu9_driver_if.h | 5 +- 14 files changed, 284 insertions(+), 86 deletions(-)

1 0

[GIT PULL] mali-dp for drm-next
by Liviu Dudau 05 Jul '18

05 Jul '18

Hi Dave, mali-dp driver changes for drm-next, includes the driver implementation for writeback, improvements for power management handling in the driver and a debugfs entry for reporting possible internal errors. Please pull at your earliest convenience. Boris Brezillon is also interested in this pull as he is going to change slightly the parameter for the writeback connector's atomic_commit() and he needs to fix the mali-dp driver in his series. Best regards, Liviu The following changes since commit f29135ee4e0d4e01911ed569f731bfdb841cea6d: Merge v4.18-rc3 into drm-next (2018-07-04 10:27:12 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/mali-dp for you to fetch changes up to e368fc75c190a4ad5853e4ec5a0c8acf86bd5119: drm/arm/malidp: Added the late system pm functions (2018-07-05 15:19:10 +0100) ---------------------------------------------------------------- Alexandru Gheorghe (1): drm: mali-dp: Add debugfs file for reporting internal errors Ayan Kumar Halder (5): drm/arm/malidp: Modified the prototype of malidp irq de-initializers drm/arm/malidp: Split malidp interrupt initialization functions. drm/arm/malidp: Enable/disable interrupts in runtime pm drm/arm/malidp: Set the output_depth register in modeset drm/arm/malidp: Added the late system pm functions Brian Starkey (2): drm: mali-dp: Add RGB writeback formats for DP550/DP650 drm: mali-dp: Add writeback connector Liviu Dudau (4): drm: mali-dp: Add support for writeback on DP550/DP650 drm/mali-dp: Add writeback support for DP500. drm/mali-dp: Add RGB writeback formats for DP500. drm/mali-dp: Improve writeback handling for DP500. drivers/gpu/drm/arm/Makefile | 1 + drivers/gpu/drm/arm/malidp_crtc.c | 10 ++ drivers/gpu/drm/arm/malidp_drv.c | 177 +++++++++++++++++++++-- drivers/gpu/drm/arm/malidp_drv.h | 26 ++++ drivers/gpu/drm/arm/malidp_hw.c | 297 +++++++++++++++++++++++++++++++------- drivers/gpu/drm/arm/malidp_hw.h | 40 ++++- drivers/gpu/drm/arm/malidp_mw.c | 250 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/arm/malidp_mw.h | 14 ++ drivers/gpu/drm/arm/malidp_regs.h | 24 ++- drivers/gpu/drm/drm_atomic.c | 4 + 10 files changed, 771 insertions(+), 72 deletions(-) create mode 100644 drivers/gpu/drm/arm/malidp_mw.c create mode 100644 drivers/gpu/drm/arm/malidp_mw.h -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯

1 0

DRM COLOR_RANGE property
by Russell King - ARM Linux 05 Jul '18

05 Jul '18

Can someone provide a deeper explanation about exactly what this property represents please? Does this represent the range of YCbCr values _into_ a YCbCr-to-RGB conversion (in other words, the range of values in the framebuffer), or the expected output range from the conversion? This matters, because a "limited", (iow, eg, BT601 compliant YCbCr) framebuffer where the Y signal is between 16..235 being displayed on a full-range RGB output would need different conversion from needing a limited-range RGB output. If it is indeed the output, then why is this a property of the plane? Is that not a property of: (a) whether the plane is being blended or overlaid onto a graphics plane which uses full-range RGB (b) the properties of the output(s) to which the plane is being displayed. IOW, it seems that the output of the CSC is more to do with what's downstream of the plane than with the plane itself. For example, take this situation: plane 0 - graphics, full range RGB >-- CRTC --> HDMI sink only supporting plane 1 - video, limited range YUV limited range RGB In order to display the graphics correctly in that scenario, the HDMI output needs to compress the RGB 0-255 range down to 16..236 to be compliant. If the video is limited range, and the CSC produces a limited range RGB output, then plane 1 gets its range further compressed at the HDMI output, which surely is undesirable. It would surely be better, if it's not possible to map the range of plane 0 to limited range, to instead expand the YUV range and then recompress it at the HDMI output to match the capabilities of the attached source. It also seems logical that describing the range of the RGB plane would also be sane - if the application is limiting graphics RGB to 16..235, then you'd want the CSC output to do the same and there'd be no need for any range expansion or compression. I'd personally like drm_plane_create_color_properties() to allow creation of COLOR_ENCODING without COLOR_RANGE (iow, supported_ranges being zero) until COLOR_RANGE is better defined than it is at present. Thoughts? I'm bringing this up, because the hardware I have has a CSC that accepts BT601 and BT709 formats, controlled by a single bit. Another bit controls whether the CSC produces 0..255 output or 16..235 output. That is then blended/overlaid with the graphics plane (0..255) and sent to the output. Having a "limited range" YUV plane produce 16..235 range output makes it look low-contrast compared to the graphics, which is what would be expected - "16" is not black compared to the black of the graphics in the same way that "235" is not white compared to the graphics. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up

4 9

[PATCH v2 0/9] drm: Third attempt at fixing the fb-helper .best_encoder() mess
by Ville Syrjala 05 Jul '18

05 Jul '18

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Changes from the previous version mainly involve Danoie's suggestion of hiding the drm_encoder_find() in the iterator macro. I also polished the msm and tilcdc cases a bit more with another small helper. Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: amd-gfx(a)lists.freedesktop.org Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: "David (ChunMing) Zhou" <David1.Zhou(a)amd.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: freedreno(a)lists.freedesktop.org Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Jyri Sarha <jsarha(a)ti.com> Cc: linux-arm-msm(a)vger.kernel.org Cc: nouveau(a)lists.freedesktop.org Cc: Rob Clark <robdclark(a)gmail.com> Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Ville Syrjälä (9): drm/fb-helper: Eliminate the .best_encoder() usage drm/i915: Nuke intel_mst_best_encoder() drm: Add drm_connector_for_each_possible_encoder() drm/amdgpu: Use drm_connector_for_each_possible_encoder() drm/nouveau: Use drm_connector_for_each_possible_encoder() drm/radeon: Use drm_connector_for_each_possible_encoder() drm: Add drm_connector_has_possible_encoder() drm/msm: Use drm_connector_has_possible_encoder() drm/tilcdc: Use drm_connector_has_possible_encoder() drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 81 ++++++----------------- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 15 ++--- drivers/gpu/drm/drm_connector.c | 44 +++++++++---- drivers/gpu/drm/drm_fb_helper.c | 34 +++++----- drivers/gpu/drm/drm_probe_helper.c | 10 +-- drivers/gpu/drm/i915/intel_dp_mst.c | 10 --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 8 +-- drivers/gpu/drm/nouveau/nouveau_connector.c | 21 +----- drivers/gpu/drm/radeon/radeon_connectors.c | 90 ++++++++------------------ drivers/gpu/drm/tilcdc/tilcdc_external.c | 9 ++- include/drm/drm_connector.h | 16 +++++ 11 files changed, 128 insertions(+), 210 deletions(-) -- 2.16.4

6 20

Proposal to merge KFD into amdgpu
by Felix Kuehling 05 Jul '18

05 Jul '18

Since KFD is only supported by a single GPU driver now (amdgpu), it makes sense to merge the two. This has been raised on the amd-gfx list before and I've been putting it off to avoid more churn while I was working on upstreaming KFD. Now seems a good time to pick this up again. At this stage there are some things that I don't expect to change significantly: * Directory structure * KFD function naming conventions * KFD device and sysfs interfaces This is a rough overview of the changes I have in mind. We should be able to implement these step-by-step and minimize disruption: 1. Change the build system to build KFD into amdgpu.ko This should make KFD similar to DAL or powerplay. It's still a mostly separate code base and Makefile with its own directory, but gets linked into amdgpu.ko. In the kernel configuration HSA_AMD would become a boolean option under DRM_AMDGPU that controls whether KFD functionality gets built into amdgpu. Any code inside #if defined(CONFIG_HSA_AMD_MODULE) can be removed. 2. Simplify the kfd2kgd and kgd2kfg interfaces Function pointers in struct kgd2kfd_calls are no longer needed. These functions can be called directly from amdgpu. Hardware-independent function pointers in kfd2kgd_calls are no longer needed. These function can be called directly from amdkfd. Some of the function pointers in kfd2kgd_calls are used for hardware abstraction with different implementations for each GFX HW generation. These will need to remain function pointers. At some later stage, the HW-specific functions could be moved into gfx_v*.c and the function pointers added to struct amdgpu_gfx. But at this stage I think I'd leave them where they are. 3. Reduce duplicate tracking of device and BO structures Currently KFD and AMDGPU pretend to not know each other's data structures. If both are in the same module, we could allow KFD to access some amdgpu structures directly (e.g. amdgpu_device and amdgpu_bo). This way some of the duplicate tracking of devices and buffer objects could be eliminated. This may present opportunities to simplify some functionality that's currently split across both modules, such as suspend/resume, memory management and evictions. Some interfaces that just query information from amdgpu could be removed if KFD can access that information directly (e.g. firmware versions, CU info, ...). Please let me know if you have any objections, suggestions, ideas ... Regards, Felix -- F e l i x K u e h l i n g PMTS Software Development Engineer | Linux Compute Kernel 1 Commerce Valley Dr. East, Markham, ON L3T 7X6 Canada (O) +1(289)695-1597 _ _ _ _____ _____ / \ | \ / | | _ \ \ _ | / A \ | \M/ | | |D) ) /|_| | /_/ \_\ |_| |_| |_____/ |__/ \| facebook.com/AMD | amd.com

2 1

[PATCH] drm/i915: Mark expected switch fall-throughs
by Gustavo A. R. Silva 05 Jul '18

05 Jul '18

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 141432 Addresses-Coverity-ID: 141433 Addresses-Coverity-ID: 141434 Addresses-Coverity-ID: 141435 Addresses-Coverity-ID: 141436 Addresses-Coverity-ID: 1357360 Addresses-Coverity-ID: 1357403 Addresses-Coverity-ID: 1357433 Addresses-Coverity-ID: 1392622 Addresses-Coverity-ID: 1415273 Addresses-Coverity-ID: 1435752 Addresses-Coverity-ID: 1441500 Addresses-Coverity-ID: 1454596 Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> --- drivers/gpu/drm/i915/i915_gem.c | 1 + drivers/gpu/drm/i915/i915_gem_stolen.c | 1 + drivers/gpu/drm/i915/intel_cdclk.c | 5 +++++ drivers/gpu/drm/i915/intel_ddi.c | 1 + drivers/gpu/drm/i915/intel_display.c | 2 ++ drivers/gpu/drm/i915/intel_dpll_mgr.c | 3 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_engine_cs.c | 1 + drivers/gpu/drm/i915/intel_runtime_pm.c | 1 + drivers/gpu/drm/i915/intel_sdvo.c | 6 ++++++ 10 files changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 4cb720b..ed7bb24 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2114,6 +2114,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf) */ if (!i915_terminally_wedged(&dev_priv->gpu_error)) return VM_FAULT_SIGBUS; + /* else: fall through */ case -EAGAIN: /* * EAGAIN means the gpu is hung and we'll wait for the error diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index 79a34729..055f868 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -254,6 +254,7 @@ static void vlv_get_stolen_reserved(struct drm_i915_private *dev_priv, switch (reg_val & GEN7_STOLEN_RESERVED_SIZE_MASK) { default: MISSING_CASE(reg_val & GEN7_STOLEN_RESERVED_SIZE_MASK); + /* fall through */ case GEN7_STOLEN_RESERVED_1M: *size = 1024 * 1024; break; diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index bf9433d..29075c7 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -316,6 +316,7 @@ static void pnv_get_cdclk(struct drm_i915_private *dev_priv, break; default: DRM_ERROR("Unknown pnv display core clock 0x%04x\n", gcfgc); + /* fall through */ case GC_DISPLAY_CLOCK_133_MHZ_PNV: cdclk_state->cdclk = 133333; break; @@ -1797,6 +1798,7 @@ static int icl_calc_cdclk(int min_cdclk, unsigned int ref) switch (ref) { default: MISSING_CASE(ref); + /* fall through */ case 24000: ranges = ranges_24; break; @@ -1824,6 +1826,7 @@ static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int cdclk) switch (cdclk) { default: MISSING_CASE(cdclk); + /* fall through */ case 307200: case 556800: case 652800: @@ -1896,6 +1899,7 @@ static u8 icl_calc_voltage_level(int cdclk) return 1; default: MISSING_CASE(cdclk); + /* fall through */ case 652800: case 648000: return 2; @@ -1913,6 +1917,7 @@ static void icl_get_cdclk(struct drm_i915_private *dev_priv, switch (val & ICL_DSSM_CDCLK_PLL_REFCLK_MASK) { default: MISSING_CASE(val); + /* fall through */ case ICL_DSSM_CDCLK_PLL_REFCLK_24MHz: cdclk_state->ref = 24000; break; diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 0319825..c74b01a 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1069,6 +1069,7 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder, switch (id) { default: MISSING_CASE(id); + /* fall through */ case DPLL_ID_ICL_DPLL0: case DPLL_ID_ICL_DPLL1: return DDI_CLK_SEL_NONE; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index eaa0663..d3f2cf6 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9359,6 +9359,7 @@ static bool hsw_get_transcoder_state(struct intel_crtc *crtc, switch (tmp & TRANS_DDI_EDP_INPUT_MASK) { default: WARN(1, "unknown pipe linked to edp transcoder\n"); + /* fall through */ case TRANS_DDI_EDP_INPUT_A_ONOFF: case TRANS_DDI_EDP_INPUT_A_ON: trans_edp_pipe = PIPE_A; @@ -11023,6 +11024,7 @@ static bool check_digital_port_conflicts(struct drm_atomic_state *state) case INTEL_OUTPUT_DDI: if (WARN_ON(!HAS_DDI(to_i915(dev)))) break; + /* else: fall through */ case INTEL_OUTPUT_DP: case INTEL_OUTPUT_HDMI: case INTEL_OUTPUT_EDP: diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c b/drivers/gpu/drm/i915/intel_dpll_mgr.c index 5734236..058696b 100644 --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c @@ -2566,6 +2566,7 @@ int icl_calc_dp_combo_pll_link(struct drm_i915_private *dev_priv, switch (index) { default: MISSING_CASE(index); + /* fall through */ case 0: link_clock = 540000; break; @@ -2639,6 +2640,7 @@ static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool use_ssc, switch (div1) { default: MISSING_CASE(div1); + /* fall through */ case 2: hsdiv = 0; break; @@ -2903,6 +2905,7 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum intel_dpll_id id) switch (id) { default: MISSING_CASE(id); + /* fall through */ case DPLL_ID_ICL_DPLL0: case DPLL_ID_ICL_DPLL1: return CNL_DPLL_ENABLE(id); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a6ff260..3cb6e87 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1254,6 +1254,7 @@ enc_to_dig_port(struct drm_encoder *encoder) switch (intel_encoder->type) { case INTEL_OUTPUT_DDI: WARN_ON(!HAS_DDI(to_i915(encoder->dev))); + /* fall through */ case INTEL_OUTPUT_DP: case INTEL_OUTPUT_EDP: case INTEL_OUTPUT_HDMI: diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index d3264bd..d2ed44d 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -230,6 +230,7 @@ __intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class) break; default: MISSING_CASE(class); + /* fall through */ case VIDEO_DECODE_CLASS: case VIDEO_ENHANCEMENT_CLASS: case COPY_ENGINE_CLASS: diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index d81b2cf..6b5aa3b 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -3212,6 +3212,7 @@ static void cnl_set_procmon_ref_values(struct drm_i915_private *dev_priv, switch (val & (PROCESS_INFO_MASK | VOLTAGE_INFO_MASK)) { default: MISSING_CASE(val); + /* fall through */ case VOLTAGE_INFO_0_85V | PROCESS_INFO_DOT_0: procmon = &cnl_procmon_values[PROCMON_0_85V_DOT_0]; break; diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index e6a64b3..a7f4a56 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1340,6 +1340,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder *intel_encoder, switch (crtc_state->pixel_multiplier) { default: WARN(1, "unknown pixel multiplier specified\n"); + /* fall through */ case 1: rate = SDVO_CLOCK_RATE_MULT_1X; break; case 2: rate = SDVO_CLOCK_RATE_MULT_2X; break; case 4: rate = SDVO_CLOCK_RATE_MULT_4X; break; @@ -2316,14 +2317,19 @@ intel_sdvo_guess_ddc_bus(struct intel_sdvo *sdvo) switch (sdvo->controlled_output) { case SDVO_OUTPUT_LVDS1: mask |= SDVO_OUTPUT_LVDS1; + /* fall through */ case SDVO_OUTPUT_LVDS0: mask |= SDVO_OUTPUT_LVDS0; + /* fall through */ case SDVO_OUTPUT_TMDS1: mask |= SDVO_OUTPUT_TMDS1; + /* fall through */ case SDVO_OUTPUT_TMDS0: mask |= SDVO_OUTPUT_TMDS0; + /* fall through */ case SDVO_OUTPUT_RGB1: mask |= SDVO_OUTPUT_RGB1; + /* fall through */ case SDVO_OUTPUT_RGB0: mask |= SDVO_OUTPUT_RGB0; break; -- 2.7.4

2 3

[PULL] drm-misc-fixes
by Maarten Lankhorst 05 Jul '18

05 Jul '18

Hi Dave, drm-misc-fixes-2018-07-05: Fixes for v4.18-rc4: - A few small fixes for the sii8620 bridge. - Allocate blob property memory using kvzalloc instead of kmalloc. The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063: Linux 4.18-rc3 (2018-07-01 16:04:53 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-07-05 for you to fetch changes up to 44f9a4b0dc7563669772198e5b226cab58a00167: drm/bridge/sii8620: Fix link mode selection (2018-07-04 16:27:51 +0200) ---------------------------------------------------------------- Fixes for v4.18-rc4: - A few small fixes for the sii8620 bridge. - Allocate blob property memory using kvzalloc instead of kmalloc. ---------------------------------------------------------------- Maciej Purski (3): drm/bridge/sii8620: Send AVI infoframe in all MHL versions drm/bridge/sii8620: Fix display of packed pixel modes drm/bridge/sii8620: Fix link mode selection Michel Dänzer (1): drm: Use kvzalloc for allocating blob property memory drivers/gpu/drm/bridge/sil-sii8620.c | 86 +++++++++++++++++++++++------------- drivers/gpu/drm/drm_property.c | 6 +-- 2 files changed, 58 insertions(+), 34 deletions(-)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2018