- 04 Oct, 2023 3 commits
-
-
Adrián Larumbe authored
A new DRM GEM object function is added so that drm_show_memory_stats can provide more accurate memory usage numbers. Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked after locking the driver's shrinker mutex, but drm_show_memory_stats takes over the drm file's object handle database spinlock, so there's potential for a race condition here. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230929181616.2769345-4-adrian.larumbe@collabora.com
-
Adrián Larumbe authored
The drm-stats fdinfo tags made available to user space are drm-engine, drm-cycles, drm-max-freq and drm-curfreq, one per job slot. This deviates from standard practice in other DRM drivers, where a single set of key:value pairs is provided for the whole render engine. However, Panfrost has separate queues for fragment and vertex/tiler jobs, so a decision was made to calculate bus cycles and workload times separately. Maximum operating frequency is calculated at devfreq initialisation time. Current frequency is made available to user space because nvtop uses it when performing engine usage calculations. It is important to bear in mind that both GPU cycle and kernel time numbers provided are at best rough estimations, and always reported in excess from the actual figure because of two reasons: - Excess time because of the delay between the end of a job processing, the subsequent job IRQ and the actual time of the sample. - Time spent in the engine queue waiting for the GPU to pick up the next job. To avoid race conditions during enablement/disabling, a reference counting mechanism was introduced, and a job flag that tells us whether a given job increased the refcount. This is necessary, because user space can toggle cycle counting through a debugfs file, and a given job might have been in flight by the time cycle counting was disabled. The main goal of the debugfs cycle counter knob is letting tools like nvtop or IGT's gputop switch it at any time, to avoid power waste in case no engine usage measuring is necessary. Also add a documentation file explaining the possible values for fdinfo's engine keystrings and Panfrost-specific drm-curfreq-<keystr> pairs. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230929181616.2769345-3-adrian.larumbe@collabora.com
-
Adrián Larumbe authored
These GPU registers will be used when programming the cycle counter, which we need for providing accurate fdinfo drm-cycles values to user space. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230929181616.2769345-2-adrian.larumbe@collabora.com
-
- 03 Oct, 2023 1 commit
-
-
Ville Syrjälä authored
Silently cancelling vblank works is a bit rude, especially if said works do any resource management (eg. free memory). WARN if we ever hit this. TODO: Maybe drm_crtc_vblank_off() should wait for any pending work to reach its target vblank before actually doing anything drastic? Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920140339.28322-2-ville.syrjala@linux.intel.comReviewed-by: Lyude Paul <lyude@redhat.com>
-
- 02 Oct, 2023 11 commits
-
-
André Almeida authored
Create a section that specifies how to deal with DRM device resets for kernel and userspace drivers. Signed-off-by: André Almeida <andrealmeid@igalia.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Sebastian Wick <sebastian.wick@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230929092509.42042-1-andrealmeid@igalia.com
-
Konrad Dybcio authored
Add support for the 2700x1224 AMOLED BOE panel bundled with a RM692E5 driver IC, as found on the Fairphone 5 smartphone. Co-developed-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230927-topic-fp5_disp-v2-2-7b5e1d1662a6@linaro.org
-
Konrad Dybcio authored
Raydium RM692E5 is a display driver IC used to drive AMOLED DSI panels. Describe it. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230927-topic-fp5_disp-v2-1-7b5e1d1662a6@linaro.org
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231001-drm-sn65dsi83-maple-v1-2-5519799a55e5@kernel.org
-
Mark Brown authored
The ili9322 driver has a volatile_reg() operation in it's regmap which always returns false. This is redundant since it is the default in the regmap core, remove the operation for a trivial code size and performance improvement. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231001-drm-sn65dsi83-maple-v1-1-5519799a55e5@kernel.org
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231001-drm-sn65dsi83-maple-v1-1-cf8ad22b6be0@kernel.org
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231001-drm-lt9211-maple-v1-1-1cf74fb10991@kernel.org
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231001-drm-chipone-maple-v1-1-fb3ce5a53710@kernel.org
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231001-drm-tc358767-maple-v1-1-f759fcc4bd98@kernel.org
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231001-drm-dlpc3433-maple-v1-1-7d71170c010b@kernel.org
-
Mark Brown authored
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230929-drm-adv7511-v1-1-b871b28ee594@kernel.org
-
- 30 Sep, 2023 2 commits
-
-
Arthur Grillo authored
To fully cover drm_fb_blit(), add format conversion tests that are only supported through drm_fb_blit(). Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by: Maíra Canal <mairacanal@riseup.net> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230918-final-gsoc-v3-2-b999c042a4cc@riseup.net
-
Arthur Grillo authored
Add a call to drm_fb_blit() on existing format conversion tests that has support. Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by: Maíra Canal <mairacanal@riseup.net> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230918-final-gsoc-v3-1-b999c042a4cc@riseup.net
-
- 28 Sep, 2023 4 commits
-
-
Jani Nikula authored
Make drm_bridge_get_edid() the one place to call the hook. Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131450.2473061-2-jani.nikula@intel.com
-
Jani Nikula authored
Make drm_bridge_get_edid() the one place to call the hook. Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131450.2473061-1-jani.nikula@intel.com
-
Douglas Anderson authored
As per the discussion on the lists [1], changes to this driver generally flow through drm-misc. Add a tag in MAINTAINERS to document this [1] https://lore.kernel.org/r/20230925054710.r3guqn5jzdl4giwd@fsr-ub1664-121.ea.freescale.netSigned-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230925154929.1.I3287e895ce8e68d41b458494a49a1b5ec5c71013@changeid
-
Maxime Ripard authored
We've had a number of times when a patch slipped through and we couldn't pick them up either because our MAINTAINERS entry only covers the framework and thus we weren't Cc'd. Let's take another approach where we match everything, and remove all the drivers that are not maintained through drm-misc. Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230921105743.2611263-1-mripard@kernel.org
-
- 27 Sep, 2023 5 commits
-
-
Arnd Bergmann authored
After a recent change, two variables are only used in an #ifdef: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_sor_atomic_disable': drivers/gpu/drm/nouveau/dispnv50/disp.c:1569:13: error: unused variable 'ret' [-Werror=unused-variable] 1569 | int ret; | ^~~ drivers/gpu/drm/nouveau/dispnv50/disp.c:1568:28: error: unused variable 'aux' [-Werror=unused-variable] 1568 | struct drm_dp_aux *aux = &nv_connector->aux; | ^~~ Move them into the same conditional block, along with the nv_connector variable that becomes unused during that fix. Fixes: 75703380 ("drm/nouveau/kms/nv50-: fixup sink D3 before tearing down link") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230925155930.677620-1-arnd@kernel.org
-
Danilo Krummrich authored
Commit f72c2db4 ("drm/gpuvm: rename struct drm_gpuva_manager to struct drm_gpuvm") did also change the corresponding filenames which are referenced from the documentation, but were not adjusted accordingly. Hence, fix up those filenames. Fixes: f72c2db4 ("drm/gpuvm: rename struct drm_gpuva_manager to struct drm_gpuvm") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20230926150725.4cca5fc5@canb.auug.org.au/Signed-off-by: Danilo Krummrich <dakr@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230926105146.10808-1-dakr@redhat.com
-
Stanislaw Gruszka authored
Only compile ivpu_debugfs.c file with CONFIG_DEBUG_FS. Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907072610.433497-2-stanislaw.gruszka@linux.intel.com
-
Stanislaw Gruszka authored
Use new drm debugfs helpers. This is needed after changes from commit 78346ebf9f94 ("drm/debugfs: drop debugfs_init() for the render and accel node v2"). Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907072610.433497-1-stanislaw.gruszka@linux.intel.com
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. Since `chan->base.name` is expected to be NUL-terminated, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without also unnecessarily NUL-padding (since `chan` is kzalloc'd already). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230919-drivers-gpu-drm-gma500-oaktrail_lvds_i2c-c-v2-1-9ebe6983b4cb@google.com
-
- 25 Sep, 2023 6 commits
-
-
Danilo Krummrich authored
Rename struct drm_gpuvm within struct nouveau_uvmm from 'umgr' to base. Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920144343.64830-4-dakr@redhat.com
-
Danilo Krummrich authored
Currently, the DRM GPUVM does not have any core dependencies preventing a module build. Also, new features from subsequent patches require helpers (namely drm_exec) which can be built as module. Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920144343.64830-3-dakr@redhat.com
-
Danilo Krummrich authored
Rename struct drm_gpuva_manager to struct drm_gpuvm including corresponding functions. This way the GPUVA manager's structures align very well with the documentation of VM_BIND [1] and VM_BIND locking [2]. It also provides a better foundation for the naming of data structures and functions introduced for implementing a common dma-resv per GPU-VM including tracking of external and evicted objects in subsequent patches. [1] Documentation/gpu/drm-vm-bind-async.rst [2] Documentation/gpu/drm-vm-bind-locking.rst Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920144343.64830-2-dakr@redhat.com
-
Douglas Anderson authored
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Tested-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230921122641.RFT.v2.1.I134336fce7eac5a63bdac46d57b0888858fc8081@changeid
-
Xin Ji authored
For the no-interrupt design (sink device is panel, polling HPD status when chip power on), anx7625 FW has more than 200ms HPD de-bounce time in FW, for the safety to get HPD status, driver better to wait 200ms before HPD detection after OS resume back. Signed-off-by: Xin Ji <xji@analogixsemi.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230922093450.3574349-1-xji@analogixsemi.com
-
Janne Grunau authored
Multiple power domains need to be handled explicitly in each driver. The driver core can not handle it automatically since it is not aware of power sequencing requirements the hardware might have. This is not a problem for simpledrm since everything is expected to be powered on by the bootloader. simpledrm has just ensure it remains powered on during its lifetime. This is required on Apple silicon M2 and M2 Pro/Max/Ultra desktop systems. The HDMI output initialized by the bootloader requires keeping the display controller and a DP phy power domain on. Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sven Peter <sven@svenpeter.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230912-simpledrm-multiple-power-domains-v2-1-01b66bfb1980@jannau.net
-
- 22 Sep, 2023 8 commits
-
-
Pranjal Ramajor Asha Kanojiya authored
Once a BO is attached with slicing configuration that BO can only be used for that particular setting. With this new feature user can detach slicing configuration off an already sliced BO and attach new slicing configuration using QAIC_ATTACH_SLICE_BO. This will support BO recycling. detach_slice_bo() detaches slicing configuration from a BO. This new helper function can also be used in release_dbc() as we are doing the exact same thing. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> [jhugo: add documentation for new ioctl] Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-8-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
This makes sure that we have a single place to initialize and re-initialize BO. Use this new API to cleanup release_dbc() We will need this for next patch to detach slicing to a BO. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-7-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
Variables that are set while adding the corresponding BO in transfer list should be cleaned when flushing them out of transfer list prematurely. After this patch we do not need some of the cleanup done in release_dbc() This patch would also pave the way to have a central location to clean BO, during an undesired situation. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-6-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
qaic_attach_slicing_bo() updates slicing config on BO. Use the existing function qaic_free_slices_bo() to remove slicing config done in qaic_attach_slicing_bo(). Use qaic_free_slices_bo() to cleanup release_dbc() This would be helpful when we introduce a new IOCTL to detach slicing configuration onto a BO. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-5-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
Once the BO is declared 'sliced' by setting bo->sliced to true we can perform DMA (QAIC_EXECUTE_BO) operation on that BO. Hence we should declare a BO sliced after completing all the operations. Adding BO to its respective DBC list in qaic_attach_slicing_bo() seems out of place as qaic_attach_slicing_bo() should just update BO with slicing configuration. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-4-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
Update/Clean up BO metadata in a central location, this will help maintain the code and looks cleaner. Use qaic_unprepare_bo() to cleanup release_dbc() Next few patches will be implementing detach IOCTL which will leverage this patch. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-3-quic_jhugo@quicinc.com
-
Pranjal Ramajor Asha Kanojiya authored
->size field in struct qaic_bo stores user requested buffer size for allocate path or size of the dmabuf(PRIME). Now for allocate path driver allocates a BO of size which is PAGE_SIZE aligned, this size is already stored in base BO structure (struct drm_gem_object). So difference is ->size of struct qaic_bo stores the raw value coming from user and ->size in struct drm_gem_object stores the PAGE_SZIE aligned size. Do not use ->size from struct qaic_bo for any validation or operation instead use ->size from struct drm_gem_object since we already have allocated that much memory then why not use it. Only validate if user is trying to use more then the BO size. This make the driver more flexible. After this change ->size field of struct qaic_bo becomes redundant. Remove it. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230901172247.11410-2-quic_jhugo@quicinc.com
-
Javier Martinez Canillas authored
The driver uses a naming convention where functions for struct drm_*_funcs callbacks are named ssd130x_$object_$operation, while the callbacks for struct drm_*_helper_funcs are named ssd130x_$object_helper_$operation. The idea is that this helper_ prefix in the function names denote that are for struct drm_*_helper_funcs callbacks. This convention was copied from other drivers when ssd130x was written, but Maxime pointed out that is the exception rather than the norm. So let's get rid of the _helper prefixes from the function handlers names. Suggested-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230914195138.1518065-1-javierm@redhat.com
-