dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH v2 0/3] drm: Add aperture helpers
by Thomas Zimmermann 12 Apr '21

12 Apr '21

Adds helpers for maintaining aperture ownership. Currently wraps the infrastructure around fbdev's remove_conflicting_framebuffers(). For adding generic drivers to DRM, we need a hand-over mechanism that unloads the generic driver before loading the hardware's native driver. So far, this was supported for generic fbdev drivers, but not for DRM drivers. As a first step, this patchset provides a DRM interface to release ownership of a framebuffer aperture. When called, all generic drivers for framebuffers in the range are being unloaded. At this point the functions wrap similar fbdev functionality. The old fbdev-based interface is being inlined into the new functionsa and drivers are converted. The patchset is based on patches 3 and 4 of [1]. I incorporated the review comments and kept the acked-bys. All converted drivers have been built at least once on either x86-64, aarch64 or arm. [1] https://lore.kernel.org/dri-devel/20210318102921.21536-1-tzimmermann@suse.d… v2: * fix docs for drm_aperture_remove_framebuffers() Thomas Zimmermann (3): drm/aperture: Add infrastructure for aperture ownership drm/aperture: Convert drivers to aperture interfaces drm/aperture: Inline fbdev conflict helpers into aperture helpers Documentation/gpu/drm-internals.rst | 12 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +- drivers/gpu/drm/armada/armada_drv.c | 5 +- drivers/gpu/drm/ast/ast_drv.c | 23 ++- drivers/gpu/drm/bochs/bochs_drv.c | 3 +- drivers/gpu/drm/drm_aperture.c | 131 ++++++++++++++++++ .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/meson/meson_drv.c | 27 ++-- drivers/gpu/drm/mgag200/mgag200_drv.c | 5 +- drivers/gpu/drm/msm/msm_fbdev.c | 5 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- drivers/gpu/drm/qxl/qxl_drv.c | 5 +- drivers/gpu/drm/radeon/radeon_drv.c | 3 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +- drivers/gpu/drm/tegra/drm.c | 4 +- drivers/gpu/drm/tiny/cirrus.c | 3 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 3 +- drivers/gpu/drm/vc4/vc4_drv.c | 5 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +- include/drm/drm_aperture.h | 31 +++++ include/drm/drm_fb_helper.h | 51 ------- 24 files changed, 242 insertions(+), 108 deletions(-) create mode 100644 drivers/gpu/drm/drm_aperture.c create mode 100644 include/drm/drm_aperture.h -- 2.31.1

1 3

[RFC PATCH] drm/doc/rfc: i915 DG1 uAPI
by Matthew Auld 12 Apr '21

12 Apr '21

Add an entry for the new uAPI needed for DG1. Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Dave Airlie <airlied(a)gmail.com> --- Documentation/gpu/rfc/i915_create_ext.c | 48 ++++++++++ .../gpu/rfc/i915_create_ext_placements.c | 19 ++++ Documentation/gpu/rfc/i915_region_query.c | 54 +++++++++++ Documentation/gpu/rfc/index.rst | 91 +++++++++++++++++++ 4 files changed, 212 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_create_ext.c create mode 100644 Documentation/gpu/rfc/i915_create_ext_placements.c create mode 100644 Documentation/gpu/rfc/i915_region_query.c diff --git a/Documentation/gpu/rfc/i915_create_ext.c b/Documentation/gpu/rfc/i915_create_ext.c new file mode 100644 index 000000000000..57c98717d14c --- /dev/null +++ b/Documentation/gpu/rfc/i915_create_ext.c @@ -0,0 +1,48 @@ +struct drm_i915_gem_create_ext { + /* + * Requested size for the object. + * + * The (page-aligned) allocated size for the object will be returned. + */ + __u64 size; + /* + * Returned handle for the object. + * + * Object handles are nonzero. + */ + __u32 handle; + /* MBZ */ + __u32 flags; + /* + * For I915_GEM_CREATE_EXT_SETPARAM extension usage see both: + * struct drm_i915_gem_create_ext_setparam. + * struct drm_i915_gem_object_param for the possible parameters. + */ +#define I915_GEM_CREATE_EXT_SETPARAM 0 + __u64 extensions; +}; + +struct drm_i915_gem_object_param { + /* Object handle (0 for I915_GEM_CREATE_EXT_SETPARAM) */ + __u32 handle; + + /* Data pointer size */ + __u32 size; + +/* + * I915_OBJECT_PARAM: + * + * Select object namespace for the param. + */ +#define I915_OBJECT_PARAM (1ull<<32) + + __u64 param; + + /* Data value or pointer */ + __u64 data; +}; + +struct drm_i915_gem_create_ext_setparam { + struct i915_user_extension base; + struct drm_i915_gem_object_param param; +}; diff --git a/Documentation/gpu/rfc/i915_create_ext_placements.c b/Documentation/gpu/rfc/i915_create_ext_placements.c new file mode 100644 index 000000000000..e2d14484d50a --- /dev/null +++ b/Documentation/gpu/rfc/i915_create_ext_placements.c @@ -0,0 +1,19 @@ +#define I915_OBJECT_PARAM (1ull<<32) + +/* + * I915_OBJECT_PARAM_MEMORY_REGIONS + * + * Set the data pointer with the desired set of placements in priority + * order(each entry must be unique and supported by the device), as an array of + * drm_i915_gem_memory_class_instance, or an equivalent layout of class:instance + * pair encodings. See DRM_I915_QUERY_MEMORY_REGIONS for how to query the + * supported regions. + * + * In this case the data pointer size should be the number of + * drm_i915_gem_memory_class_instance elements in the placements array. + * + */ +#define I915_PARAM_MEMORY_REGIONS 0 +#define I915_OBJECT_PARAM_MEMORY_REGIONS (I915_OBJECT_PARAM | \ + I915_PARAM_MEMORY_REGIONS) + __u64 param; diff --git a/Documentation/gpu/rfc/i915_region_query.c b/Documentation/gpu/rfc/i915_region_query.c new file mode 100644 index 000000000000..45e688726375 --- /dev/null +++ b/Documentation/gpu/rfc/i915_region_query.c @@ -0,0 +1,54 @@ +enum drm_i915_gem_memory_class { + I915_MEMORY_CLASS_SYSTEM = 0, + I915_MEMORY_CLASS_DEVICE, +}; + +struct drm_i915_gem_memory_class_instance { + __u16 memory_class; /* see enum drm_i915_gem_memory_class */ + __u16 memory_instance; +}; + +/** + * struct drm_i915_memory_region_info + * + * Describes one region as known to the driver. + */ +struct drm_i915_memory_region_info { + /** class:instance pair encoding */ + struct drm_i915_gem_memory_class_instance region; + + /** MBZ */ + __u32 rsvd0; + + /** MBZ */ + __u64 caps; + + /** MBZ */ + __u64 flags; + + /** Memory probed by the driver (-1 = unknown) */ + __u64 probed_size; + + /** Estimate of memory remaining (-1 = unknown) */ + __u64 unallocated_size; + + /** MBZ */ + __u64 rsvd1[8]; +}; + +/** + * struct drm_i915_query_memory_regions + * + * Region info query enumerates all regions known to the driver by filling in + * an array of struct drm_i915_memory_region_info structures. + */ +struct drm_i915_query_memory_regions { + /** Number of supported regions */ + __u32 num_regions; + + /** MBZ */ + __u32 rsvd[3]; + + /* Info about each supported region */ + struct drm_i915_memory_region_info regions[]; +}; diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index a8621f7dab8b..40572f514371 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -15,3 +15,94 @@ host such documentation: * Once the code has landed move all the documentation to the right places in the main core, helper or driver sections. + +I915 DG1/LMEM RFC Section +========================= + +Object placement and region query +================================= +Starting from DG1 we need to give userspace the ability to allocate buffers from +device local-memory. Currently the driver supports gem_create, which can place +buffers in system memory via shmem, and the usual assortment of other +interfaces, like dumb buffers and userptr. + +To support this new capability, while also providing a uAPI which will work +beyond just DG1, we propose to offer three new bits of uAPI: + +DRM_I915_QUERY_MEMORY_REGIONS +----------------------------- +Query mechanism which allows userspace to discover the list of supported memory +regions(like system-memory and local-memory) for a given device. We identify +each region with a class and instance pair, which should be unique. The class +here would be DEVICE or SYSTEM, and the instance would be zero, on platforms +like DG1. + +Side note: The class/instance design is borrowed from our existing engine uAPI, +where we describe every physical engine in terms of its class, and the +particular instance, since we can have more than one per class. + +In the future we also want to expose more information which can further +describe the capabilities of a region. + +.. literalinclude:: i915_region_query.c + +GEM_CREATE_EXT +-------------- +New ioctl which is basically just gem_create but now allows userspace to +provide a chain of possible extensions. Note that if we don't provide any +extensions then we get the exact same behaviour as gem_create. + +.. literalinclude:: i915_create_ext.c + +Side note: We also need to support PXP[1] in the near future, which is also +applicable to integrated platforms, and adds its own gem_create_ext extension, +which basically lets userspace mark a buffer as "protected". + +I915_OBJECT_PARAM_MEMORY_REGIONS +-------------------------------- +Implemented as an extension for gem_create_ext, we would now allow userspace to +optionally provide an immutable list of preferred placements at creation time, +in priority order, for a given buffer object. For the placements we expect +them each to use the class/instance encoding, as per the output of the regions +query. Having the list in priority order will be useful in the future when +placing an object, say during eviction. + +.. literalinclude:: i915_create_ext_placements.c + +As an example, on DG1 if we wish to set the placement as local-memory we can do +something like: + +.. code-block:: + + struct drm_i915_gem_memory_class_instance region_param = { + .memory_class = I915_MEMORY_CLASS_DEVICE, + .memory_instance = 0, + }; + struct drm_i915_gem_create_ext_setparam setparam_region = { + .base = { .name = I915_GEM_CREATE_EXT_SETPARAM }, + .param = { + .param = I915_OBJECT_PARAM_MEMORY_REGIONS, + .data = (uintptr_t)&region_param, + .size = 1, + }, + }; + + struct drm_i915_gem_create_ext create_ext = { + .size = 16 * PAGE_SIZE, + .extensions = (uintptr_t)&setparam_region, + }; + int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext); + if (err) ... + +One fair criticism here is that this seems a little over-engineered[2]. If we +just consider DG1 then yes, a simple gem_create.flags or something is totally +all that's needed to tell the kernel to allocate the buffer in local-memory or +whatever. However looking to the future we need uAPI which can also support +upcoming Xe HP multi-tile architecture in a sane way, where there can be +multiple local-memory instances for a given device, and so using both class and +instance in our uAPI to describe regions is desirable, although specifically +for DG1 it's uninteresting, since we only have a single local-memory instance. + +[1] https://patchwork.freedesktop.org/series/86798/ + +[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 -- 2.26.3

2 1

[PATCH] gpu: drm: Replace bare "unsigned" with "unsigned int"
by Fabio M. De Francesco 12 Apr '21

12 Apr '21

Replaced the type "unsigned" with "unsigned int" because it is preferred. Issue detected by checkpatch.pl. Signed-off-by: Fabio M. De Francesco <fmdefrancesco(a)gmail.com> --- drivers/gpu/drm/drm_atomic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 5b4547e0f775..46dceb51c90f 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1302,8 +1302,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state) struct drm_crtc_state *new_crtc_state; struct drm_connector *conn; struct drm_connector_state *conn_state; - unsigned requested_crtc = 0; - unsigned affected_crtc = 0; + unsigned int requested_crtc = 0; + unsigned int affected_crtc = 0; int i, ret = 0; DRM_DEBUG_ATOMIC("checking %p\n", state); -- 2.31.1

2 2

[PATCH v4, 0/3] support gce on mt8192 platform
by Yongqiang Niu 12 Apr '21

12 Apr '21

Change since v3: -fix review comment in v2 Change since v2: - add controy_by_sw for mt8192 Change since v1: - move out shift jump patch - remove useless patch Yongqiang Niu (3): dt-binding: gce: add gce header file for mt8192 arm64: dts: mt8192: add gce node mailbox: cmdq: add mt8192 support .../devicetree/bindings/mailbox/mtk-gce.txt | 7 +- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 + drivers/mailbox/mtk-cmdq-mailbox.c | 10 + include/dt-bindings/gce/mt8192-gce.h | 335 +++++++++++++++++++++ 4 files changed, 359 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8192-gce.h -- 1.8.1.1.dirty

1 3

[PATCH 0/3] drm: Add aperture helpers
by Thomas Zimmermann 12 Apr '21

12 Apr '21

Adds helpers for maintaining aperture ownership. Currently wraps the infrastructure around fbdev's remove_conflicting_framebuffers(). For adding generic drivers to DRM, we need a hand-over mechanism that unloads the generic driver before loading the hardware's native driver. So far, this was supported for generic fbdev drivers, but not for DRM drivers. As a first step, this patchset provides a DRM interface to release ownership of a framebuffer aperture. When called, all generic drivers for framebuffers in the range are being unloaded. At this point the functions wrap similar fbdev functionality. The old fbdev-based interface is being inlined into the new functionsa and drivers are converted. The patchset is based on patches 3 and 4 of [1]. I incorporated the review comments and kept the acked-bys. All converted drivers have been built at least once on either x86-64, aarch64 or arm. [1] https://lore.kernel.org/dri-devel/20210318102921.21536-1-tzimmermann@suse.d… Thomas Zimmermann (3): drm/aperture: Add infrastructure for aperture ownership drm/aperture: Convert drivers to aperture interfaces drm/aperture: Inline fbdev conflict helpers into aperture helpers Documentation/gpu/drm-internals.rst | 12 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +- drivers/gpu/drm/armada/armada_drv.c | 5 +- drivers/gpu/drm/ast/ast_drv.c | 23 ++- drivers/gpu/drm/bochs/bochs_drv.c | 3 +- drivers/gpu/drm/drm_aperture.c | 131 ++++++++++++++++++ .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/meson/meson_drv.c | 27 ++-- drivers/gpu/drm/mgag200/mgag200_drv.c | 5 +- drivers/gpu/drm/msm/msm_fbdev.c | 5 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- drivers/gpu/drm/qxl/qxl_drv.c | 5 +- drivers/gpu/drm/radeon/radeon_drv.c | 3 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +- drivers/gpu/drm/tegra/drm.c | 4 +- drivers/gpu/drm/tiny/cirrus.c | 3 +- drivers/gpu/drm/vboxvideo/vbox_drv.c | 3 +- drivers/gpu/drm/vc4/vc4_drv.c | 5 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 +- include/drm/drm_aperture.h | 31 +++++ include/drm/drm_fb_helper.h | 51 ------- 24 files changed, 242 insertions(+), 108 deletions(-) create mode 100644 drivers/gpu/drm/drm_aperture.c create mode 100644 include/drm/drm_aperture.h -- 2.31.1

2 7

[PATCH v2 0/5] drm/vc4: hdmi: Support the 4k @ 60Hz modes
by Maxime Ripard 12 Apr '21

12 Apr '21

Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. The firmware also has a glitch at the moment and will not properly release the BSC controllers, which will make the EDID retrieval fail. We can work around this using the following config.txt options: disable_fw_kms_setup=1 hdmi_edid_file:0=1 hdmi_edid_filename:0=1366x768.bin hdmi_ignore_edid:0=1 hdmi_edid_file:1=1 hdmi_edid_filename:1=1366x768.bin hdmi_ignore_edid:1=1 A fix will come for the firmware eventually. Let me know what you think, Maxime --- Changes from v1: - Dropped the range accessors - Drop the mention of force_turbo - Reordered the SCRAMBLER_CTL register to match the offset - Removed duplicate HDMI_14_MAX_TMDS_CLK define - Warn about enable_hdmi_4kp60 only if there's some modes that can't be reached - Rework the BVB clock computation Maxime Ripard (5): drm/vc4: hvs: Make the HVS bind first drm/vc4: hdmi: Properly compute the BVB clock rate drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies drm/vc4: hdmi: Enable the scrambler drm/vc4: hdmi: Raise the maximum clock rate drivers/gpu/drm/vc4/vc4_drv.c | 11 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 101 +++++++++++++++++++++++++--- drivers/gpu/drm/vc4/vc4_hdmi.h | 8 +++ drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 + 4 files changed, 113 insertions(+), 10 deletions(-) -- 2.30.2

3 11

[PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
by Hans de Goede 12 Apr '21

12 Apr '21

After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot"), the DSI panel on a Cherry Trail based Predia Basic tablet would no longer properly light up after reboot. I've managed to reproduce this without rebooting by doing: chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\ echo 0 > /sys/class/graphics/fb0/blank Which rapidly turns the panel off and back on again. The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays used for panel on/off, since starting with MIPI-sequences version >= 3 the delays are already included inside the MIPI-sequences. The problems exposed by the "Shut down displays gracefully on reboot" change, show that using this helper for the panel_pwr_cycle_delay is not the right thing to do. This has not been noticed until now because normally the panel never is cycled off and directly on again in quick succession. Change the msleep for the panel_pwr_cycle_delay to a normal msleep() call to avoid the panel staying black after a quick off + on cycle. Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/i915/display/vlv_dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c index d5a3f69c5df3..38d5a1f3ded5 100644 --- a/drivers/gpu/drm/i915/display/vlv_dsi.c +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c @@ -996,14 +996,14 @@ static void intel_dsi_post_disable(struct intel_atomic_state *state, * FIXME As we do with eDP, just make a note of the time here * and perform the wait before the next panel power on. */ - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay); + msleep(intel_dsi->panel_pwr_cycle_delay); } static void intel_dsi_shutdown(struct intel_encoder *encoder) { struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder); - intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay); + msleep(intel_dsi->panel_pwr_cycle_delay); } static bool intel_dsi_get_hw_state(struct intel_encoder *encoder, -- 2.30.2

2 6

adjust rdma fifo threshold calculate formula
by Yongqiang Niu 12 Apr '21

12 Apr '21

This patch base Linux 5.12-rc2 provide one patch Yongqiang Niu (1): drm/mediatek: adjust rdma fifo threshold calculate formula drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.1.1.dirty

2 2

[PATCH] gpu/drm: mediatek: hdmi: check for valid modes on MT8167
by Neil Armstrong 12 Apr '21

12 Apr '21

On MT8167, only CEA modes and anything using a clock below 148500 is supported for HDMI. This change adds some checks to make sure the video format is OK for MT8167. Signed-off-by: Fabien Parent <fparent(a)baylibre.com> Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c index 8ee55f9e2954..991e2e935b93 100644 --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c @@ -148,6 +148,8 @@ struct hdmi_audio_param { struct mtk_hdmi_conf { bool tz_disabled; + unsigned long max_mode_clock; + bool cea_modes_only; }; struct mtk_hdmi { @@ -1259,6 +1261,13 @@ static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn, return MODE_BAD; } + if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode)) + return MODE_BAD; + + if (hdmi->conf->max_mode_clock && + mode->clock > hdmi->conf->max_mode_clock) + return MODE_CLOCK_HIGH; + if (mode->clock < 27000) return MODE_CLOCK_LOW; if (mode->clock > 297000) @@ -1810,10 +1819,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = { .tz_disabled = true, }; +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = { + .max_mode_clock = 148500, + .cea_modes_only = true, +}; + static const struct of_device_id mtk_drm_hdmi_of_ids[] = { { .compatible = "mediatek,mt2701-hdmi", .data = &mtk_hdmi_conf_mt2701, }, + { .compatible = "mediatek,mt8167-hdmi", + .data = &mtk_hdmi_conf_mt8167, + }, { .compatible = "mediatek,mt8173-hdmi", }, {} -- 2.25.1

2 2

[PATCH] drm/nouveau/hwmon: Convert sysfs sprintf/snprintf family to sysfs_emit
by Tian Tao 12 Apr '21

12 Apr '21

Fix the following coccicheck warning: drivers/gpu/drm/nouveau/nouveau_hwmon.c:44:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/nouveau/nouveau_hwmon.c:57:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/nouveau/nouveau_hwmon.c:90:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c b/drivers/gpu/drm/nouveau/nouveau_hwmon.c index 1c3104d..c6e5ee9 100644 --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c @@ -41,7 +41,7 @@ static ssize_t nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d, struct device_attribute *a, char *buf) { - return snprintf(buf, PAGE_SIZE, "%d\n", 100); + return sysfs_emit(buf, "%d\n", 100); } static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, 0444, nouveau_hwmon_show_temp1_auto_point1_pwm, NULL, 0); @@ -54,7 +54,7 @@ nouveau_hwmon_temp1_auto_point1_temp(struct device *d, struct nouveau_drm *drm = nouveau_drm(dev); struct nvkm_therm *therm = nvxx_therm(&drm->client.device); - return snprintf(buf, PAGE_SIZE, "%d\n", + return sysfs_emit(buf, "%d\n", therm->attr_get(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST) * 1000); } static ssize_t @@ -87,7 +87,7 @@ nouveau_hwmon_temp1_auto_point1_temp_hyst(struct device *d, struct nouveau_drm *drm = nouveau_drm(dev); struct nvkm_therm *therm = nvxx_therm(&drm->client.device); - return snprintf(buf, PAGE_SIZE, "%d\n", + return sysfs_emit(buf, "%d\n", therm->attr_get(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST_HYST) * 1000); } static ssize_t -- 2.7.4

1 0

← Newer
1
...
50
51
52
53
54
55
56
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021